Subject: RE: PANA and cryptographic keys

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 5 Dec 2002 10:46:56 -0800

Yoshihiro,

We should still be able to protect those messages. A node belonging to
some home network really means it shares a secret with its home
network (HAAA). It can be used to calculate a HASH of all the PANA
messages that encapsulate EAP messages. In turn the same can be
used by the home network for replying back to PaC. This way all
messages exchanged can be integrity protected. As we discussed
in Atlanta, we should soon start discussing the possible approaches
to solutions. We have TLS based approach and this could be one other
approach I guess.

-mohan

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:[email-masked]] 
> Sent: Thursday, December 05, 2002 9:35 AM
> To: Alper E. YEGIN
> Cc: Pana (E-mail)
> Subject: Re: PANA and cryptographic keys
> 
> 
> Does the analysis mean that protecting EAP message exchange 
> outside the EAP is out of the scope of PANA even optionally?  
> I ask this question because most EAP methods that are 
> strictly compliant with RFC2284 do not have a mechanism to 
> protect EAP Success/Failure message which should actually be 
> protected especially in multi-access environments.  (PEAP is 
> able to protect EAP Success/Failure message within TLS, but I 
> don't think PEAP is strictly compliant with
> RFC2284.)
> 
> Yoshihiro Ohba
> 
> On Mon, Dec 02, 2002 at 05:45:34PM -0800, Alper E. YEGIN wrote:
> > 
> > Hello,
> > 
> > At the last IETF meeting, some concerns were raised regarding the 
> > relation between cryptographic keys and PANA. We should be 
> looking at 
> > different type of keys and their usage to understand this issue 
> > better.
> > 
> > First, there is one (or more) key(s) to authenticate the 
> client to the 
> > authentication backend and vice versa. These keys are part of the 
> > authentication method used and they are not really visible to PANA. 
> > PANA simply carries EAP regardless of the particular EAP 
> > authentication method. An example of such a key is the 
> shared secret 
> > in MD5-challenge method.
> > 
> > Secondly, depending on the authentication method used, 
> there might be 
> > derived or distributed keys. For example, with EAP-TLS 
> method. These 
> > keys might be used for integrity protection of the rest of the PANA 
> > exchange, or in conjunction with per-packet protection 
> following PANA 
> > authentication.
> > 
> > An instance of PANA authentication might be multi-phased. 
> First phase 
> > might generate such keys to be used in protecting the second phase. 
> > Using PEAP or EAP-TTLS, or PoTLS or SeNAA are such examples.
> > 
> > Also, depending on the environment, access control by using 
> filters on 
> > the source mac address or IP address might not be sufficient. For 
> > example public access wireless networks. In this case, using 
> > cryptographic methods for per-packet authentication is needed to 
> > prevent service theft by free-loaders. Now the keys become 
> part of the 
> > filtering information just like mac and IP addresses are. 
> They would 
> > be part of the provisioning information passed from PAA to EPs. EP 
> > would have to know how to use them once received.
> > 
> > In either case, key distribution and derivation are outside 
> the scope 
> > of PANA. Respective EAP methods take care of these tasks for the 
> > authentication end-points, i.e, PaC and the authentication 
> server. If 
> > the authentication server is separate from the PAA, then the AAA 
> > protocol running between two should take care of key 
> distribution from 
> > authentication server to PAA. And finally, if these keys 
> are needed by 
> > the EP for per-packet protection, they should be delivered 
> from PAA to 
> > EP, using the yet-to-be-identified protocol (which is not PANA).
> > 
> > 
> > Comments?
> > 
> > alper
> > 
> > 
> > 
> 
>

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 5 Dec 2002 11:16:17 -0800

Dan,

I guess we need to understand the details about session hijacking.
There are 3 ways to do this :

1) Malicious node pretending to be a real PaC sends a disconnect
2) Malicious node pretending to be a real PAA sends a disconnect
3) Malicious node taking a free ride by spoofing the IP address
   of a PaC that was authenticated.

(1) and (2) can be avoided by redoing the authentication process
from scratch. If the network cannot determine that the PaC disconnected
from the network but some malicious node knows about it, I don't
know how to prevent it. It could be possible that some malicious
node can do something at physical layer (radio jamming) to fool a PaC to
disconnect and the network not detecting it (not sure whether it is
feasible or not). Now the malicious node can free ride on the real PaC's
service. I don't know what sort of protection we can assume at layers
below IP. 

(3) might be a bit difficult to stop. In this case, the attacker is not
injecting/modifying data of some other PaC. But just getting a free
ride.
One possible way (as in CDMA2000) the network can require the PaC to
authenticate to the network at layer 2.

-mohan

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, December 04, 2002 11:43 PM
> To: [email-masked]; Mohan Parthasarathy; 
> [email-masked]
> Subject: RE: PANA and cryptographic keys
> 
> 
> Alper and Mohan,
> 
> One small comment. In PANA we are interested in preventing 
> session hijacking. Thus, for example the VPN connection(s) to 
> some other network(s) could protect the packets. But in this 
> case the session hijacking is still possible since, the EP 
> can't verify the packet's origin in L3 level. So, if L2 
> doesn't provide session hijacking protection (IP spoofing), 
> PANA should provide it.
> 
> One possibility is to use IPSec per-packet authentication 
> between PaC and EP/PAA after proper key derivation (for 
> example with TLS or with EAP "key derivation").
> 
> - Dan
> 
> 
> > From: ext Alper E. YEGIN [mailto:[email-masked]]
> > Sent: 05 December, 2002 04:48
> > To: Mohan Parthasarathy; Pana (E-mail)
> > Mohan,
> > > Ok, to summarize, PANA does not care what EAP method is 
> used. If it 
> > > does not derive keys, some one else can steal your service.
> > PANA does
> > > not
> > > enforce/care what EAP methods will be used.
> > 
> > Yes. And someone might want to write a document that 
> identifies what 
> > methods are appropriate in what kind of environments. But note that 
> > this would not be specific to PANA, it'd be also applicable 
> to other 
> > encapsulations of EAP, such as PPP and 802.1x. This 
> document would be 
> > outside the scope of PANA.
> > 
> > > 
> > > When you are pushing the keys as part of fliters to EP, 
> what does it 
> > > mean to EP ? Does it mean that the EP should be expecting 
> some sort 
> > > of key exchange shortly from the PaC ? Or the PaC is free 
> to ignore 
> > > setting up SA with the EP and setup a secure channel 
> (VPN) back to 
> > > home network ? I prefer the latter.
> > 
> > These all depend on the access network architecture. It 
> might be using 
> > L2 (e.g., WEP) or L3 (e.g., IKE and IPsec) mechanisms for that 
> > purpose. PaC might need to have profiles to know what 
> exactly is being 
> > used in a particular network, etc.
> > 
> > 
> > > Also, there might be more
> > > information
> > > needed along with the keys e.g. identity of the PaC that
> > will establish
> > > the SA etc.  The key information is slightly different from
> > the other
> > > filter information pushed in the sense that it needs lot of
> > additional
> > > bits for it to be useful. We can safely classify all this
> > as outside the
> > > scope of PANA. But pushing some information to EP and not
> > knowing what
> > > to do with it does not seem very useful.
> > 
> > I'd encourage anyone to write a draft that outlines how these
> > keys and 
> > associated information can be used in various networks. 
> This could be
> > a guideline document, not inventing new protocols and 
> mechanisms, but 
> > instead pointing out how existing ones can be used for this purpose.
> > I think this would be useful for general discussions, though this
> > problem space is outside the scope of PANA protocol. 
> > 
> > alper
> > 
> > > 
> > > -mohan
> > >  
> > > 
> > > 
> > > > From: Alper E. YEGIN [mailto:[email-masked]]
> > > > Sent: Tuesday, December 03, 2002 12:23 PM
> > > > To: Mohan Parthasarathy; Pana (E-mail)
> > > > Mohan,
> > > > > > filters on the source mac address or IP address 
> might not be 
> > > > > > sufficient. For example public access wireless networks. In 
> > > > > > this case, using cryptographic methods for per-packet 
> > > > > > authentication is needed to prevent service theft by 
> > > > > > free-loaders. Now the keys become part of the filtering
> > > > > > information just like mac and IP addresses are. They 
> > > > would be part
> > > > > > of the provisioning information passed from PAA to EPs.
> > > > EP would have
> > > > > > to know how to use them once received.
> > > > > > 
> > > > > What if I use a method that does not derive keys ? Then,
> > > > service theft
> > > > > becomes very easy.
> > > > 
> > > > That's right. Therefore right authentication method must be
> > > > used depending on the environment. If service theft is an 
> > > > issue, client and network better use use an authentication 
> > > > method that 
> > > > derives/distributes keys. 
> > > > 
> > > > > Are we saying that PANA will develop solution that
> > > > > will enable per-packet protection or not ? It is still not
> > > > clear to me
> > > > > from the above.
> > > > 
> > > > PANA carries EAP, EAP supports various authentication
> > methods some
> > > > of which does key distribution/derivation (which is needed
> > > > for per-packet protection). So, PANA enables per-packet 
> > > > protection in this indirect way. Current understanding is 
> > > > that, PANA doesn't have to do anything other than to carry 
> > > > EAP to accomplish this.
> > > > 
> > > > > 
> > > > > > the scope of PANA. Respective EAP methods take care of these
> > > > > 
> > > > > What do you mean by key distrbution here ? In your above
> > > > description,
> > > > > you just distributed keys from PAA to EP.
> > > > 
> > > > But that protocol is not called PANA, which runs between
> > PaC and PAA.
> > > > That protocol is either COPS or SNMP or DIAMETER or
> > something else...
> > > > 
> > > > > I think you meant something
> > > > > like setting up an SA between PaC and EP.
> > > > > 
> > > > > > tasks for the
> > > > > > authentication end-points, i.e, PaC and the
> > > > authentication server.
> > > > > > If the authentication server is separate from the PAA,
> > > > then the AAA
> > > > > > authentication server to PAA. And finally, if these 
> keys are 
> > > > > > needed by the EP for per-packet protection, they should be 
> > > > > > delivered from PAA to EP, using the yet-to-be-identified 
> > > > > > protocol (which is not PANA).
> > > > > > 
> > > > > I am not disagreeing with anything here. But what do we
> > > > expect out of
> > > > > the PANA solution ? Should it be an enabler of per-packet
> > > > protection
> > > > > to avoid service thefts i.e should the solution (e.g. EAP
> > > > method) used
> > > > > derive keys or not ?
> > > > 
> > > > Please see above and let us know if it helped clarifying
> > the issue.
> > > > 
> > > > alper
> > > > 
> > > > 
> > > > 
> > > 
> > 
> > 
>

---

From: <[email-masked]>
Date: Thu, 5 Dec 2002 17:41:52 -0600

Mohan,

While I generally tend to agree with what you are saying, you have
to consider the scenario that there is not always a HAAA involved.

Message integrity is required only between the PaC and the PAA in
the context of the PANA WG.

-Basavaraj

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Thu, 5 Dec 2002 19:07:27 -0800

> 
> While I generally tend to agree with what you are saying, you 
> have to consider the scenario that there is not always a HAAA 
> involved.
I am not assuming the existence of HAAA. But the most common scenario
would be authenticating using a backend. Clients need to have some
shared secret with the backend to authenticate. Once done with
authentication,
you can use to derive keys to protect all your exchanges between PaC and
PAA.

Does it make sense ?

-mohan

> 
> Message integrity is required only between the PaC and the 
> PAA in the context of the PANA WG.
> 
> -Basavaraj
> 
> > 
> > Yoshihiro,
> > 
> > messages that encapsulate EAP messages. In turn the same 
> can be used 
> > by the home network for replying back to PaC. This way all messages 
> > exchanged can be integrity protected. As we discussed in 
> Atlanta, we 
> > should soon start discussing the possible approaches to 
> solutions. We 
> > have TLS based approach and this could be one other 
> approach I guess.
> > 
> > -mohan
>