Subject: [HOKEY] HOKEY threat model and requirements

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 15 Feb 2007 10:30:27 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/hokey

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 15 Feb 2007 13:11:39 -0800

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:[email-masked]] 
> Sent: Thursday, February 15, 2007 10:30 AM
> To: [email-masked]
> Cc: Sam Hartman
> Subject: [HOKEY] HOKEY threat model and requirements
> 
> 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."
> 
> 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
>

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 15 Feb 2007 14:44:27 -0800 (PST)

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.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Feb 2007 17:51:15 -0500

>>>>> "Dan" == Dan Harkins <[email-masked]> writes:

    Dan>   Hi Vidya,

    Dan>   I agree with Russ's statement (although I wish it was
    Dan> stronger). But! A key distribution protocol could be
    Dan> implemented in which the principle of least privilege will be
    Dan> followed only when there are honest participants in the
    Dan> exchange or when there is no adversary involved-- I'll only
    Dan> give the secret out to "Vidya" but if anyone merely says "I'm
    Dan> Vidya" I'll give them the secret. Such a protocol is
    Dan> obviously not acceptable.

    Dan>   So while I agree with that snippet from
    Dan> draft-housley-aaa-key-mgmt-07 I don't feel that just meeting
    Dan> that requirement addresses my concerns.

Russ's draft also requires that all parties who communicate be
authenticated to each other.

The requirements you're stating seem fairly basic.  I'd really
appreciate it if you would read Russ's draft and if you feel it does
not include the requirements you are talking about propose specific
comments to the IESG and me.  You have approximately one week before
it is approved.

---

From: Charles Clancy <[email-masked]>
Date: Mon, 19 Feb 2007 21:03:56 -0500

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.  |  [email-masked]  |  www.cs.umd.edu/~clancy