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

From: Sam Hartman <[email-masked]>
Date: Wed, 07 Mar 2007 11:05:51 -0500

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

Subject: comments on draft-houseley-aaa-key-mgmt-07.txt
From: "Dan Harkins" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Fri, 16 Feb 2007 13:16:15 -0800 (PST)

  Hi,

  I understand this draft is in IESG evaluation and would like to register
some comments. I apologize for the tardiness of this email.

  This draft is well-written and much needed but I feel it does not
completely address the issue of using AAA for key distribution. Let me
summarize the problematic scenario in mind, why I think the draft does
not address this, and suggested additions to the draft to address my
concern.

  PROBLEM

  It is desired to use AAA to distribute keys for network access and what
is basically a 2 party model is applied to a 3 party protocol.

  A client authenticates through an authenticator to a AAA server. Upon
successful completion of the 2 party authentication protocol between the
client and AAA server a key derived from a shared secret is delivered to
the authenticator. (Known channel binding issues here). Then, a new key
hierarchy, built off another shared secret, is derived and keys from
it are sent, using AAA, to other authenticators to faccilitate fast
handoff. These keys typically have an "identity" of the authenticator
mixed into the key derivation function.

  The explaination given by proponents of this type of scheme on why
this is secure is that the authenticators all have a security association
with the AAA server, the distributed keying material is sent under the
protection of that security association, and the AAA server is trusted.
This, again, takes a 2 party model and attempts to apply it to what is
essentially a 3 party problem.

  The concern is that the security associations are most likely based on
some identity that is not known to the client and therefore is not bound
into the key, for example an IP address. The authenticator's identity mixed
into the key is a NAS Identifier and the security association it has with
the AAA server is based on its IP address. This allows an authenticator
to lie about its identity to the AAA server, through it's secure and
trusted link to the AAA server, and obtain a key intended for another
authenticator.

  Since this key is symmetric it can be used to impersonate the client
to the entity to whom it should've been delivered.

  If a key distribution protocol cannot guarantee that a key will not be
sent to the wrong entity then it is flawed.

  Also, the client is not involved in the distribution of this secret
that it shares. It just notices that some new entity has the key and
must just assume that possession of the key implies authorization to hold
the key.

  WHY IS THIS NOT ADDRESSED IN THE DRAFT

  Two groups, IEEE 802.11 Task Group "r" and the HOKEY working group,
are discussing using such a 2 party model in a 3 party key distribution
scheme. They are coming up with schemes that suffer from the problem
described above and justify them by saying that the authenticators share
a security association with the server and that the key being distributed
has the "identity" of the new authenticator mixed into it.

  People in both these groups advocating this type of flawed scheme are
well aware of the "Housley Criteria" and this draft. In fact, they point
to "Authenticate all parties" and "Bind key to its context" as specific
requirements they meet.

  (In the case of HOKEY the problem is more compound as they wish to
distribute keys from a "home" domain to visited domains and a server in
verizon.net could request a key for the sprint.net domain).

  If this draft explicitly discussed this type of flawed scheme I presume
these groups would not persist in advancing them, but persist they do.
So I would like to see some explicit guidance in this draft to direct
people away from them. Some guidance on how to ensure that this type of
subtle flaw is not perpetuated in future systems would be most helpful.

  SUGGESTED ADDTIONS TO THE DRAFT

  In "Limit Key Scope" it says, "parties MUST NOT have access to keying
material that is not needed to perform their role." In the problem above
the role of the entity lying about its identity is an authenticator and
it is obtaining keying material necessary to perform the role of an
authenticator, it's just that it has obtained a key for a different
authenticator. I would like to see an additional requirement stating "Key
distribution protocols MUST ensure that keying material is not given to
the wrong party."

  In "Authenticate all parties" it specifically mentions different
identities being used in the AAA protocol. This is in the context of
establishment of session keys and the only problem it notes with different
identities is one of difficulty with authorization decisions. I suggest
the following paragraph be added to "Authenticate all parties":

    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.

  Then I would like to see a new section entitled "Confirm identities
when distributing keying material" which contains the following:

    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.

This paragraph should appear after "Authenticate all parties".

  If any of my writing is in need of wordsmithing I would be happy if
it was fixed up. But I really think something to address this subtle flaw
is needed in this draft prior to its publication as an RFC. Once again,
I apologize in not bringing my desires to the authors' attention before
it reached the IESG.

  I would appreciate hearing any comments on my suggestions and whether
they will be accepted or denied.

  thanks,

  Dan.

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 07 Mar 2007 14:49:57 -0800

Hi Sam,

Many thanks for the opportunity to comment on the proposed text before 
approval.

I do have concerns with the proposed text.  Some of the new requirements 
are overly burdensome.  In other places, it is not clear what is expected.

Some notes below:

> 	 attack, and it ensures that an unauthorized authenticator is

I must say I do not fully understand the paragraph above.  I took a 
quick look at 2906 and that RFC has a more nuanced take on 
authorization.  If we are going to require something we need to be more 
specific.

Specifically, what does it mean to say "Peer and authenticator 
authorization MUST be performed?"  Who is authorizing whom to do what?

Is proof of possession of keying material proof of authorization?  Not 
according to the text below (on the 4-way exchange etc.).

> 	 hold a common view of the authorizations associated the other

This is better.  (Nit: There is an editorial mistake in the last sentence.)

> 	 to possess keying material.  

What does this mean?  How do key management protocols demonstrate that 
the parties are authorized to possess keying material?  Does this mean 
that key management protocols must facilitate carrying authorization 
information?  Or must carry authorization information?  Or that a party 
requesting a key must prove that it is authorized to possess that keying 
material?

> Note that proof of possession of
>          authentication server to possess that keying material.  

The example is helpful, but are we then saying that 802.11i and the 
4-way handshake are non-compliant?  Or put differently, how do we fix 
the 4-way handshake so that the authenticator can prove to the peer that 
it was authorized to possess the keying material it has?  Does the peer 
need to prove to the authenticator of its authorization to hold the same 
keying material?

> As

Consistent sure, but why is correctness of the claim of identity 
necessary?  Put another way, is there a way to solve the problem of the 
authenticator providing the same incorrect identity to the peer and the 
server.  I think there is in a number of usage scenarios, and therefore 
propose that the requirement on correctness should be relaxed.  More 
specifically, I think we should stick to the guidance level of RFC 3579.

> If no serious objections are raised, I'll finally be able to approve

Once again thanks for the opportunity.  Please do consider this as an 
objection to the new text.

regards,
Lakshminath