Subject: Re: [Dan Harkins] comments on draft-houseley-aaa-key-mgmt-07.txt

From: "Dan Harkins" <[email-masked]>
Date: Wed, 7 Mar 2007 10:14:57 -0800 (PST)

Hi Sam,

  Thanks for the update. My original comment never made it to the ietf
list because I wasn't a member at the time of posting. I was informed that
if the moderator approved my posting it would be sent to the list,
unfortunately it wasn't. :-(

  In the new "Peer and authenticator authorization" section the last
paragraph has no keywords signifying a requirement. That seems strange
to me considering the message the paragraph is trying to convey seems
important. "...key management protocols need to demonstrate..." seems
like it should be "...key management protocols MUST demonstrate..." The
final sentence says "...channel binding is required..." and that should
be "...channel binding MUST be performed..." I bring this up because I
have seen people attempt to maneuver in such weasel room in an attempt
to not do The Right Thing.

  Also, my comment on the "Authenticate all parties" section regarding
authenticator impersonation was because the only mention of identities
is in the context of generating session keys. My concern is around key
distribution from a AAA server to an authenticator. I asked for the
following text to be added:

    When a security association is used to distribute keying material
    the security association SHOULD be bound to a unique identity that
    can be commonly known by all the parties-- including the peer. If the
    security association cannot be based on such an identity then it MUST
    be statically configured to be an attribute of the security
    association.

And that unique identity was then to be used as follows in a new section:

    When another party requires access to keying material the
    identity of that party MUST be authenticated prior to distribution
    of the keying material. The distributor MUST ensure that the
    keying material is not disclosed to the wrong party. This can be
    accomplished, for example, by verifying the identity of the party
    to whom the keying material is being disclosed with the identity
    bound to the security association under which it will be sent.

    When keying material is disclosed the other party on whose behalf
    it is being disclosed MUST confirm disclosure. For example, a peer
    MUST acknowledge disclosure of keying material from a AAA server
    to an authenticator and the identity of the authenticator MUST be
    confirmed by the peer and AAA server.

  I think my first two points are serious objections but will accept the
fact that other people don't. Also, I reiterate my suggestion for text
regarding identities because the post never made it to the list. If
the authors considered my suggestion but did not accept it then that's
all I could ask for. So I would still like to see some changes but
understand if no one else views these as serious objections.

  thanks,

  Dan.

On Wed, March 7, 2007 8:05 am, Sam Hartman wrote:
>
> Hi, folks.  The following last call comment was received and based on
> discussion the draft was updated.  This comment never seems to have
> made it to the ietf list though.
>
>
> The following text was added to address the comment.  Please confirm
> that this text addresses the comment and that from the following text
> it is clear that these requirements prohibit authenticator
> impersonination:
>
>       Peer and authenticator authorization
>
> 	 Peer and authenticator authorization MUST be performed.  These
> 	 entities MUST demonstrate possession of the appropriate keying
> 	 material, without disclosing it.  Authorization is REQUIRED
> 	 whenever a peer associates with a new authenticator.  The
> 	 authorization checking prevents an elevation of privilege
> 	 attack, and it ensures that an unauthorized authenticator is
> 	 detected.
>
> 	 Authorizations SHOULD be synchronized between the peer, NAS,
> 	 and backend authentication server.  Once the AAA key management
> 	 protocol exchanges are complete, all of these parties should
> 	 hold a common view of the authorizations associated the other
> 	 parties.
>
> 	 In addition to authenticating all parties, key management
> 	 protocols need to demonstrate that the parties are authorized
> 	 to possess keying material.  Note that proof of possession of
> 	 keying material does not necessarily prove authorization to
> 	 hold that keying material.  For example, within an IEEE
> 	 802.11i, the 4-way handshake demonstrates that both the peer
> 	 and authenticator possess the same EAP keying material.
>          However, by itself, this possession proof does not demonstrate
>          that the authenticator was authorized by the backend
>          authentication server to possess that keying material.  As
>          noted in RFC 3579 in section 4.3.7, where AAA proxies are
>          present, it is possible for one authenticator to impersonate
>          another, unless each link in the AAA chain implements checks
>          against impersonation.  Even with these checks in place, an
>          authenticator may still claim different identities to the peer
>          and the backend authentication server.  As described in RFC
>          3748 in section 7.15, channel binding is required to enable the
>          peer to verify that the authenticator claim of identity is both
>          consistent and correct.
>
>
> If no serious objections are raised, I'll finally be able to approve
> this draft next week
>
>
>
>
>

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Mar 2007 13:53:40 -0500

Dan, again, with the text as it stands, what attacks do you see
permitted by these requirements that you believe should not be
permitted.  

The text changes you proposed were considered but are rather
problematic for existing protocols.  I don't think we mind mandating
changing protocols for real problems but we do mind doing so if we
cannot understand the problem we're solving.

I do agree that the proposed changes would be better using RFC 2119
language.  If the authors want to fix that in auth48, I'll permit the
change.  However I think the language is clear enough that it is a
requirement now so I will not hold up the document for that.

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 7 Mar 2007 18:06:39 -0800 (PST)

Sam,

  The problem I see is that when AAA is used as a key distribution
protocol there are 3 parties involved (peer, AAA server and authenticator)
and it's a 2 party model. For existing protocols-- the peer is speaking
to a NAS and the NAS obtains a key for the peer from the AAA server-- the
problem of identity lying is somewhat contained. The peer is going to do
a full re-auth when he goes to a new authenticator anyway so the
shenanigans a lying authenticator can do with this key are somewhat
limited.

  But for things like HOKEY or 802.11r they want to have the AAA server
create a key hierarchy rooted off the EMSK or the MSK, respectively, that
contains keys for specific authenticators. These keys are going to be
distributed using AAA (that seems to be the plan) and either proactively
distributed-- "here have a key!"-- or distributed on demand-- "gimme a
key!" The authenticator-specific key gets produced by mixing in some
identity of the authenticator and that key is then sent under the
protection of the security association between the AAA server and the
authenticator.

  The problem is that the identity of the authenticator bound to that
security association is most likely an IP address and the identity that
gets bound into the key has to be something different since the peer
doesn't necessarily know that IP address (imagine an access point with a
wired IP connection to the AAA server and a wireless connection to the
peer, the peer knows the access point by the radio's BSSID and is
completely unaware of anything about the access point's wired port).

  Since there is no binding of identities it allows an authenticator
to say "give me the key for authenticator FOO" even though it is actually
authenticator BAR. For instance the NAS-Id is put into a RADIUS request
to ask for a specific key and the key is sent back protected by the
shared secret bound to the IP address of the authenticator. Since this
network access credential is symmetric all security properties that it
could've had are are lost-- the lying authenticator can impersonate the
client to the real FOO authenticator, it can inject traffic into a
connection between the peer and the FOO authenticator, it can inspect
traffic on a connection between the peer and the FOO authenticator.

  HOKEY wants to distribute keys across domains too so an entity in the
sprint.com network can request a key for the verizon.net network.

  There is nothing in this draft that prohibits such flawed key
distribution protocols. This draft does say that entities MUST be
authenticated and that keying material MUST be bound to a specific
context. It is these two things that proponents of these flawed key
distribution protocols point to as evidence of their compliance to
the "Housley Criteria".

  The 802.11r task group is convinced that as long as there a security
association between the authenticator and AAA server (regardless of the
identity bound to that security association) and as long as they mix
some identity into the key (and again it doesn't really matter whether
that has any relation to the identity of the security association) then
they are assured to be secure. I'm sensing the same trend in HOKEY.

  There needs to be an identity binding of the key that is going to be
generated and distributed. The peer and AAA server (the two parties that
authenticated each other and hold the root of the key hierarchy) have to
agree on who the key is being distributed to. The only text in this draft
that talks about identities deals with the generation of a session key
which takes place AFTER key distribution. That was why I suggested that
text, as a way to effect such a binding.

  I don't think it's problematic for existing protocols because existing
protocols don't include key distribution. I keep on being told that
"AAA is a 2 party protocol!" Fine, we can play that game. The split
between the NAS and AAA server is logical and the NAS functionality and
AAA server functionality can reside on one device. That's existing
protocols today. But when there are multiple authenticators involved we
can't play that game anymore. When AAA is used for key distribution to
multiple distinct entities then I feel we have to meet a new standard.

  Dan.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 7 Mar 2007 20:32:46 -0800

> 
>   Since there is no binding of identities it allows an 
> authenticator to say "give me the key for authenticator FOO" 
> even though it is actually authenticator BAR. For instance 
> the NAS-Id is put into a RADIUS request to ask for a specific 
> key and the key is sent back protected by the shared secret 
> bound to the IP address of the authenticator. Since this 
> network access credential is symmetric all security 
> properties that it could've had are are lost-- the lying 
> authenticator can impersonate the client to the real FOO 
> authenticator, it can inject traffic into a connection 
> between the peer and the FOO authenticator, it can inspect 

None of this is feasible when the key distributed to BAR (impersonating
as FOO) is different from the key distributed to FOO (appearing as FOO).
In other words, a peer connects to BAR and thinks it is connected to
FOO. The server also thinks the peer is connected to FOO; a key (say,
K1) is derived (with freshness) and given to FOO aka BAR. But, at this
point, the real FOO DOES NOT have K1. When the peer tries to attach to
the real FOO, it may attempt to use K1, but, will fail. If another key
is requested for/by the real FOO, all the server has to ensure is that
K1 is *never* given (in fact, K1 should never have been cached and MUST
be forgotten after delivery); a *different* key (say, K2) must again be
derived (with freshness, again) and given. 

In other words, no two key retrievals from the server must result in the
same key being distributed, even if the entity requesting the key is
*seemingly* the same. This only means that every transported key MUST
have an element of freshness (say, at least a server nonce) that must be
communicated with end-to-end protection between the server and peer. 

Ensuring correctness of identities while allowing the same key to be
retrievable upon multiple fetches is only *one* way to achieve the
security properties you are trying to achieve. In fact, *never* allowing
the same key to be retrievable multiple times even by the same entity
will consistently achieve these security properties, irrespective of the
correctness of identities. 

Vidya

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 7 Mar 2007 22:36:10 -0800 (PST)

If you have a 3 party key distribution scheme and at the
end of it the 3 parties do not share ALL THE SAME STATE yet
believe the protocol has successfully completed then your
key distribution scheme is flawed.

  Dan.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 07 Mar 2007 22:51:04 -0800

> protection of the security association between the AAA server and the

Dan,

I snipped all the rest of the email so I can get a clarification from 
you on this particular paragraph.  The problem you describe here is that 
the authenticator gets a key based on the claimed identity of the 
authenticator.  If the peer and the server do not have a way to verify 
the identity of the authenticator it is a problem because the key that 
the server sends to the authenticator is the same as long as the claimed 
identity of the authenticator is the same.

Do I understand correctly?

thanks,
Lakshminath

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 7 Mar 2007 23:12:31 -0800 (PST)

Hi Lakshminath,

  That's not entirely correct. As I recently stated to your
colleage if a 3 party key distribution scheme finishes and
all 3 parties think it finished successfully but they do not
agree on all state then the scheme is flawed.

  I see the path you're trying to go down-- add a server nonce,
assume everything is now fine-- and I'm not going to follow
you down there.

  This is not the forum for this discussion. Let's take this to
the HOKEY list if you really want to continue. Better yet we
can discuss it over a Budvar in Prague.

  Dan.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 08 Mar 2007 00:41:13 -0800

> agree on all state then the scheme is flawed.

Could you elaborate on what part is missing from my description please? 
  What is in the "state" that the parties need to agree on?

> assume everything is now fine-- and I'm not going to follow

In this round, I am trying to get a full description of the problem 
before jumping into solutions, but now that you mention this what in 
your view is wrong with this approach?  What necessary properties are 
lost?  Perhaps exploring this might help us agree on the problem.

> 
>   This is not the forum for this discussion. 

This is the IETF Discussion list after all and we are discussing an 
individual submission that is in the IESG evaluation stage.  To my 
knowledge, this is the appropriate open forum.

> Let's take this to

I am ok with an offline discussion in Prague, but I am not sure whether 
we have that much time.

regards,
Lakshminath

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 8 Mar 2007 07:37:41 -0800

Dan,
There is a fundamental security property in all that we have been
discussing: 

It MUST NOT be possible for an entity A, impersonating as entity B, to
obtain any key material that entity B may actually possess at any time. 

And that, I fully agree with. 

However, you are going further and saying that that property can *only*
be achieved by detecting the impersonation and hence, detection of
impersonation by the key transport protocol is a MUST. 

And that, I disagree with. As I've tried to describe below, there is
more than one way of achieving the same security property. 

Vidya

> -----Original Message-----
> From: Dan Harkins [mailto:[email-masked]] 
> Sent: Wednesday, March 07, 2007 10:36 PM
> To: Narayanan, Vidya
> Cc: Dan Harkins; Sam Hartman; [email-masked]
> Subject: RE: [Dan Harkins] comments on 
> draft-houseley-aaa-key-mgmt-07.txt
> 
> 
> believe the protocol has successfully completed then your key 
> distribution scheme is flawed.
> 
>   Dan.
> 
> authenticator 
> >> to say "give me the key for authenticator FOO"
> the NAS-Id 
> >> is put into a RADIUS request to ask for a specific key and 
> the key is 
> >> sent back protected by the shared secret bound to the IP 
> address of 
> >> the authenticator. Since this network access credential is 
> symmetric 
> >> all security properties that it could've had are are 
> lost-- the lying 
> >> authenticator, it can inject traffic into a connection between the 
> >> peer and the FOO authenticator, it can inspect traffic on a 
> >> connection between the peer and the FOO authenticator.
> >>
> >
> > None of this is feasible when the key distributed to BAR 
> > (impersonating as FOO) is different from the key 
> distributed to FOO (appearing as FOO).
> > K1 is *never* given (in fact, K1 should never have been cached and 
> > MUST be forgotten after delivery); a *different* key (say, K2) must 
> > again be derived (with freshness, again) and given.
> >
> > In other words, no two key retrievals from the server must 
> result in 
> > the same key being distributed, even if the entity 
> requesting the key 
> > is
> > have an element of freshness (say, at least a server nonce) 
> that must 
> > be communicated with end-to-end protection between the 
> server and peer.
> >
> > security properties you are trying to achieve. In fact, *never* 
> > allowing the same key to be retrievable multiple times even by the 
> > same entity will consistently achieve these security properties, 
> > irrespective of the correctness of identities.
> >
> > Vidya
> >
> 
> 
>

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 8 Mar 2007 08:45:36 -0800 (PST)

Lakshminath,

  Actually we're discussing my suggested additions to an individual
submission that is in IESG evaluation stage. Since I do not believe
they will be accepted at this point in time I don't see a point in
elaborating on them here. We're intersecting on this issue for one
reason and one reason only: HOKEY.

  If you want to a full description of the problem then read (and
comment on) the "Problem Statement and Requirments on a 3-Party Key
Distribution Protocol for Handover Keying." Please do so on the HOKEY
list so we are sure to include all the people who might care but are
not on this list.

  thanks,

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Mar 2007 11:49:02 -0400

>>>>> "Narayanan," == Narayanan, Vidya <[email-masked]> writes:

    Narayanan,> Dan, There is a fundamental security property in all
    Narayanan,> that we have been discussing:

    Narayanan,> It MUST NOT be possible for an entity A, impersonating
    Narayanan,> as entity B, to obtain any key material that entity B
    Narayanan,> may actually possess at any time.

I continue to believe the model you are using is too simplistic to
have the discussion you're having.  We're focusing on issues that
arrise when entities have multiple identities in different namespaces.
At least, that is the focus of the text I'm asking for discussion
about.  i don't understand how you can discuss that text without a
model that involves entities with multiple names.

I'm going to meet with Lakshminath on Sunday and then make a consensus
call.

--Sam