Subject: [Fwd: RE: [HOKEY] HOKEY re-key architecture]

From: "Dan Harkins" <[email-masked]>
Date: Thu, 1 Feb 2007 00:13:05 -0800 (PST)

I guess I hit "reply" and not "reply to all". Sigh.

  Dan.

---------------------------- Original Message ----------------------------
Subject: RE: [HOKEY] HOKEY re-key architecture
From:    "Dan Harkins" <[email-masked]>
Date:    Wed, January 31, 2007 11:49 pm
To:      "Glen Zorn (gwz)" <[email-masked]>
--------------------------------------------------------------------------

  Glen,

>>   If you do it right there is a handshake between the mobile device,
>> the new authenticator and the HOKEY server whereby the new
>> authenticator comes into possession of a key he can use to give the
>> mobile device network access. That handshake satisfies basic security
>> requirements for a key establishment protocol.
>
> Strange, that's exactly what AAA & H(okey)EAP do, except that the new
> authenticator gets no key at all except in the case where link
> encryption is supported.

  Really? And what handshake is that which involves the mobile device,
the new authenticator and the HOKEY server? And if the authenticator
gets no key at all then what's the point of HandOverKEYing? Handover
keying sans the key sounds like a solved problem to me.

>>
>>   If you do it wrong you just let the HOKEY server give the keys out
>> to whoever it wants under an unspecified scheme. That satisfies no
>> security requirements. It might be possible to implement such a
>> broken protocol in a way that could have legitimate security claims
>> but that requires us to trust the implementation and that is never
>> right.
>
> Dan, nobody's suggesting that, either. I'm certainly not suggesting that
> the Hokey server distribute authentication keys any more than an EAP
> server would distribute passwords.  The only keys that I, at least, am
> talking about distributing are the moral equivalent of the .11i MSK.
> AFAIK, that key can only be used for traffic encryption.  So, tell me
> again what threat is present in the "lying NAS" problem.  The key can't
> be used to eavesdrop on any traffic except that which passes through the
> access point anyway.  The key can't be used to impersonate anyone since
> it isn't used for user authentication.  It can't be used by the access
> point to forge traffic from the mobile (except to itself!) because only
> the access point & mobile use it for traffic protection.  Assuming a
> non-braindead derivation process, it should not be computationally
> feasible to backtrack from the distributed key to its progenitor.  I'm
> really trying here, Dan, but I can't see it.

  Well who, in your view, gives out the keys in this key hierarchy?
Somehow these keys have to be send out to the places that the mobile
device is going to do a handover to. How is that done? What's the protocol?

  Dan.

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