Re: [Cfrg] question on secure key distribution

[David McGrew <[e-mail]>]

Hi Dan,

this is a complex question!  I have a few comments anyway, which I  
hope can be useful.

On Oct 11, 2006, at 10:09 PM, Dan Harkins wrote:

>
>   Hi,
>
>   I have a question on a technique to distrubute a secret key. This
> technique is being proposed in an 802.11 task group (task group r)
> to have a centralized key holder distribute keys to wireless access
> points.
>
>   Assuming Alice, and a set of {Bob, Bill, Brian}, and Trent.
> Alice shares some secret with Trent, Kat, and wants Trent to  
> distribute
> keys to Bob, Bill, and Brian. Further, Trent has a "secure session"
> with each of {Bob, Bill, and Brian}-- the B's-- such that their  
> identities
> have been authenticated and communication between Trent and each of
> the B's have the properties of confidentiality, data integrity
> protection, and data source authentication. Also there is a key
> confirmation handshake HS(Alice, B) that will indicate whether Alice
> and B (one of the B's) share a key.
>
>   Is it adequate for Trent to use Kat as a master key to derive
> specific keys to each of {Bob, Bill, Brian} using some pseudo-random
> function that takes a key, k, and a message, m-- prf(k, m)-- namely,
>
>   key for Bob: Kbob = prf(Kat, "Bob"...)
>   key for Bill: Kbill = prf(Kat, "Bill"...)
>   key for Brian: Kbrian = prf(Kat, "Brian"...)
>
> and have each of those delivered over the "secure session" by Trent
> to the appropriate recipient? Alice derives the keys herself and then
> uses HS(Alice, B) to confirm that B has the right key.

I expect that, if the key distribution method met some security goals  
as long as the derived keys { Kbob, Kbill, Kbrian, ... } were random,  
plus the function prf() was indistinguishable from random to entities  
not knowing the key Kat, then the key distribution method would still  
meet those same goals, with respect to adversaries that don't know  
the key Kat.   (That's pretty vague, but it's not clear to me what  
all of the goals are, and there are lots of different goals, like  
those outlined in http://citeseer.ist.psu.edu/boyd97towards.html)

>
>   The idea being promoted is that Trent is giving a key that is based
> on a particular identity to an entity that has proven it is that
> identity.

An obvious comment: the management of the identities needs to be  
under the control of Trent.  Otherwise, we could put together attacks  
that would work by having Bob's identity get revoked, then get re- 
assigned to another user.  If the key Kat didn't change, then Bob  
could masquerade as the new user, and the new user could potentially  
disrupt Bob's sessions (or subvert confidentiality that used Kbob).

> Furthermore, Trent would not give Bill's key to Bob or Brian.
> If Alice is able to successfully perform HS(Alice, B) with one of the
> B's then she can assume that B is a trusted and authorized entity  
> since
> it got the correct key from Trent (whom she trusts). Is this adequate?
> Is there a flaw here anywhere?

You mentioned that Alice derives the keys { Kbob, Kbill,  
Kbrian, ... } herself - does this mean that she knows Kat?  In that  
case, she could impersonate Bob or one of the other entities.

Beyond these observations, I don't see any potential flaws, in the  
sense that it seems possible to build a secure system along the lines  
you describe.  But of course the system deserves a security analysis  
far better than what I've given here!  :-)

Best regards,

David

>
>   thanks,
>
>   Dan.
>
>
>
>
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/cfrg