Subject: RE: The problem with CxTP (was: Re: [Mipshop] MIPSHOP discussion on newitems and milestones)

From: Narayanan Vidya-CVN065 <[email-masked]>
Date: Thu, 17 Mar 2005 12:39:30 -0600

Alper, James, 
Is there a distinction between transferring security context between two entities and exposing the same security context to multiple entities? In my mind, it seems like it is a problem when more than one entity *sees* (or derives a key that is meant for only one device. In other words, for instance, AP A should not, at any point, know the PMK of AP B. 

That is different from saying that no keying material should ever be transferred between entities - right? The exposure of the keying material should not result in entities other than the target entity being able to derive the actual key. 

Am I missing something here? 

Vidya

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James Kempf
Sent: Thursday, March 17, 2005 10:58 AM
To: Alper Yegin; 'Charles E.Perkins'
Cc: [email-masked]
Subject: Re: The problem with CxTP (was: Re: [Mipshop] MIPSHOP discussion on newitems and milestones)

Alper,

> "transferring keys is a bad idea"... I hope we can use such blanket 
> statements a bit more cautiously. If everyone were to follow this 
> advice, the most of the Internet access would stop now (note that 
> RADIUS server transfers AAA-Key to NAS for a host to gain Internet 
> access -- this is a typical deployment).
>

Yes, and that is, in fact, the only key transfer application that the security guys are willing to bless. When you ask them about this seeming contradiction, they state that they've convinced themselves that it will work, even though it involves transferring the AAA-Key outside the "cryptographic boundary" of the RADIUS server. When you dig a little deeper, there were some practical considerations involving how existing drivers work that drove the decision in 802.11 to use this method.

> We really need to scratch the surface and get to more details.
>
> For example, NAS1 sharing its EAP AAA-Key with NAS2 is a bad idea 
> because compromise of one leads to compromise of the other NAS. Or, 
> the context applicable to NAS1 may not be applicable to NAS2. ... We 
> should be talking about these details, not making a wide open 
> statements and spend next couple years explaining people "but, it is 
> not that bad...."
>

If you want to convince the security guys of this, I'd suggest you look at constructing a formal proof of security for whatever key transfer protocol you are interested in. That way, they will be unable to wriggle out of approving it, provided, of course, the proof is sound.

Please don't get me wrong, I am not opposed to key transfer on any grounds other than that some fairly useful and general principles in security design suggest that it might not be secure.

            jak

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "James Kempf" <[email-masked]>
Date: Thu, 17 Mar 2005 11:41:32 -0800

> Is there a distinction between transferring security context between two
entities and exposing the same security context to multiple entities? In my
mind, it seems like it is a problem when more than one entity *sees* (or
derives a key that is meant for only one device. In other words, for
instance, AP A should not, at any point, know the PMK of AP B.
>
> That is different from saying that no keying material should ever be
transferred between entities - right? The exposure of the keying material
should not result in entities other than the target entity being able to
derive the actual key.

My understanding is that that primary issue is transferring any keying
material which would allow the success of an attack on a single network
entity, such as a NAS, to compromise other entities without the attacker
actually needing to directly attack those entities.

So any keying material that either is used directly or where there's a
straightforward deterministic algorithm for deriving keys would be covered.

            jak