Re: [HOKEY] HOKEY threat model and requirements

[Charles Clancy <[e-mail]>]

Dan,

My understanding is that your chief concern is DSRK/HRKs not getting 
sent to the proper devices in the proper domain, because in many AAA 
deployments, security associations are not linked to identity.  This is 
an artifact of using a single [RADIUS] shared secret to authenticate all 
AAA devices.

Some have indicated that this is not our problem.  In AAA, by using 
PKI-based authentication or per-device shared secrets, we can securely 
bind an identity to a security association.  Certainly the protocols 
support this, but could current implementations be easily fooled by not 
properly implementing the necessary binding?

You're proposing using something like Otway-Rees to solve this problem, 
without checking and possibly fixing current AAA 
implementations/deployments.  Otway-Rees assumes two preexisting 
pairwise keys, peer<->eap and hokey<->eap.

Certainly peer<->eap is easy -- that's the EMSK (or some child).  But, 
where do you propose hokey<->eap come from?  Would each HOKEY server be 
provisioned a shared key with each EAP server?  Or, would we instead 
reuse a AAA security association?

If we're going to reuse the AAA security association, we have the same 
problem as before with possible identity impersonation in weak 
deployments/implementations.  If we plan to provision a shared key to 
everyone, why not just provision a unique AAA shared secret instead?

Sure, there may still be flawed implementations or deployments out 
there, but we're operating under the assumptions of 
draft-housley-aaa-key-mgmt, which requires mutual authentication.  If 
identities are not properly bound, you don't have mutual authentication, 
and consequently that's not an implementation/deployment we're required 
to cater to.  We'd have a lengthy security considerations section 
telling people the adverse affects of not properly deploying AAA security.

As I mentioned in the EAP-ER consensus call, I'd appreciate it if you 
could formalize your thoughts into a strawman protocol proposal draft, 
and describe the pros/cons versus relying on channel-bound AAA security.

-- 
t. charles clancy, ph.d.  |  [e-mail]  |  www.cs.umd.edu/~clancy

Dan Harkins wrote:
>   Hi Vidya,
> 
>   I agree with Russ's statement (although I wish it was stronger). But! A
> key distribution protocol could be implemented in which the principle of
> least privilege will be followed only when there are honest participants
> in the exchange or when there is no adversary involved-- I'll only give
> the secret out to "Vidya" but if anyone merely says "I'm Vidya" I'll give
> them the secret. Such a protocol is obviously not acceptable.
> 
>   So while I agree with that snippet from draft-housley-aaa-key-mgmt-07
> I don't feel that just meeting that requirement addresses my concerns.
> 
>   Previously you admitted that just "using AAA" as the key distribution
> protocol could result in a compliant implementation that was not able to
> ensure that the key was not given to the wrong entity and was, in your
> words, "broken". That being the case, surely you must share my concern.
> 
>   Dan.
> 
>> I agree with the take below. Mainly, draft-ietf-hokey-reauth-ps-01 says:
>>
>>
>> "The designs and protocols must satisfy the AAA key management
>> requirements specified in [I-D.housley-aaa-key-mgmt]."
>>
>> And, draft-housley-aaa-key-mgmt-07 says:
>>
>> "Following the principle of least privilege, parties MUST NOT have
>> access to keying material that is not needed to perform their role."
>>
>> It would be good if Dan and others who have concerns on the security
>> model of HOKEY can make sure that meeting these requirements will
>> address their concerns.
>>
>> Thanks,
>> Vidya
>>
>>> -----Original Message-----
>>> From: Lakshminath Dondeti [mailto:[e-mail]]
>>> Sent: Thursday, February 15, 2007 10:30 AM
>>> To: [e-mail]
>>> Cc: Sam Hartman
>>> Subject: [HOKEY] HOKEY threat model and requirements
>>>
>>> Threat model:  The primary goal is to protect access network
>>> resources.
>>>   End-to-end confidentiality, integrity protection (or origin
>>> authentication) and replay protection of data is out of scope.
>>>
>>> A security association protocol (as specified in
>>> draft-ietf-eap-keying-18) is established between the
>>> authenticator (or access enforcement point) and the peer as a
>>> result of the authentication.  The security association is
>>> used to enforce network access where each party proves that
>>> is the entity that participated in the initial authentication
>>> (by proving possession of a key) and potentially for data
>>> confidentiality, integrity and replay protection over the access link.
>>>
>>> Dan Harkins brought up an additional threat related to
>>> domain-based key derivation and to mitigate that we need to
>>> ensure that an entity in
>>> domain1 cannot obtain the peer's keys corresponding to
>>> domain2 as that would allow the entity in domain1 to gain
>>> access to the peer's security
>>> association(s) in domain2.  Does that fully capture the
>>> threat?  To alleviate that threat, I had specified the
>>> following requirements:
>>>
>>> 1. "A HOKEY client SHOULD be able to detect change of the
>>> local AAA server and/or local HOKEY server."
>>>
>>> 2. "Every request for a DSRK MUST produce a new, unique DSRK."
>>>
>>> 3. "DSRK delivery SHOULD occur with peer involvement."
>>>
>>> These requirements ensure that no two entities can ever get
>>> the same DSRK, irrespective of whether it is feasible to
>>> impersonate a NAS or HOKEY server.
>>>
>>> I wrote these twice now and I realized that I am not saying
>>> anything new.  If we follow the criteria in
>>> draft-housley-aaa-key-mgmt-07, as we are required to, these
>>> will also be met.  So, when a solution document on how domain
>>> keys are derived is written, if that derivation does not meet
>>> Russ's criteria, of course that cannot move forward.  Hope we
>>> can conclude that and move along here.
>>>
>>> thanks,
>>> Lakshminath
>>>
>>> _______________________________________________
>>> HOKEY mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/hokey
>>>
>> _______________________________________________
>> HOKEY mailing list
>> [e-mail]
>> https://www1.ietf.org/mailman/listinfo/hokey
>>
> 
> 
> 
> _______________________________________________
> HOKEY mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/hokey

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