Subject: Re: [consensus] comments on draft-housley-aaa-key-mgmt-07.txt

From: "Dan Harkins" <[email-masked]>
Date: Mon, 2 Apr 2007 14:27:56 -0700 (PDT)

Sam,

  I guess the question is, what text in this I-D would prevent a new
key distribution protocol based on AAA in which the authentication
server sent a copy of the peer's keys willy-nilly to every
authenticator it had a security association with?

  Another question: has the peer no say in to whom its secrets are
disclosed? If you think it does then what in the I-D addresses that
concern and if you don't think it does then why?

  As I have stated (starting with my 16 Feb 07 comments) I think this
is an important I-D and we need an RFC on this subject. I just don't think
it goes far enough in proscribing bad behavior and mandating good behavior.
Again, the 802.11 Task Group "r" is a prime example of why this I-D
does not go far enough.

  I think this I-D has to discuss the use of AAA as a key distribution
protocol and it does not do that right now.

  At the SAAG meeting you said (something to the effect of) "everyone
understands the 'channel binding' issue". I don't necessarily agree with
you (see 802.11r) but the problem is that when AAA is used as a key
distribution protocol that issue explodes in another dimension. And people
think that if it's OK to ignore that issue in the traditional EAP case
where an authentication server gives single key to single authenticator
through whom the peer is speaking then it must be OK to ignore it when
distributing keys to a multiplicity of authenticators that the peer is not,
and may never be, speaking to.

  Dan.

On Fri, March 30, 2007 10:52 am, Sam Hartman wrote:
>
>
> Hi.  I had a few discussions in Prague and think that we're all
> basically on the same page about what the document should say.  I'm
> going to describe that consensus here.  I'd like to ask Russ to
> confirm that the document reflects the consensus
> and if so to ask me to remove my discuss and approve the document.
>
> Unless I've really gotten something wrong here, I think we're done
> deciding what we are trying to say and are only left with deciding if
> we've managed to say it.  When two parties communicate in these
> protocols they must authenticate each other.  Typically EAP is used to
> authenticate the peer and the EAP server.  Typically AAA protocols
> authenticate the authenticator and the AAA server.
>
> Typically secure association protocols  run between the peer and
> authenticator.
>
> It's common for the EAP layer identities to be different from the
> lower layer identities.
>
> There are two types of lower layer identities: those that are used for
> authorization and those that are not.  AN example of an identity not
> used for authorization would be a network that had a concept like a
> MAC address that is not used for access control.  The MAC address is
> used to look up keys, but all people granted access to the network
> have the same authorizations.  In this case it's not important to make
> sure that the peer is claiming a MAC address that is appropriate for
> the EAP layer identity of the peer.
>
> However in a network where the MAC address is used to make
> authorization decisions, someone needs to make sure that the peer's
> EAP identity is authorized to claim the MAC address that it claims.
> Typically the AAA server fills this role.  However it would be OK to
> architect a design where the authenticator filled that role--I don't
> think you'd use RADIUS or Diameter in such a design though.
>
>
> The authenticator probably has a lower layer identity too.  The AAA
> server needs to authorize this identity to the peer. Typically this
> would happen by the AAA server looking at what authenticator the peer
> claims it is connecting to, looking at the higher layer identity that
> the authenticator is using to communicate to the AAA server and
> confirming that the higher layer identity is authorized to claim the
> lower layer identity to peers.
>
> It's OK to have things like WLAN switches that are authenticators
> including a large number of physical devices.  They can have one
> higher layer identifier and a lot of lower layer identifiers.  They
> could potentially also have one lower layer identifier.
>
>
> Unlike the peer identity, we always assume that the lower layer
> authenticator identity needs to be authorized.
>
>
>

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

---

From: Sam Hartman <[email-masked]>
Date: Tue, 03 Apr 2007 20:23:52 -0400

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

    Dan>   Sam,

    Dan>   I guess the question is, what text in this I-D would
    Dan> prevent a new key distribution protocol based on AAA in which
    Dan> the authentication server sent a copy of the peer's keys
    Dan> willy-nilly to every authenticator it had a security
    Dan> association with?

First, note that I do not claim we have the text right; I'm asking
Russ and Bernard to evaluate that.

So, I'll tell you what the closest text is for this, but you are
welcome to argue that the current text does not reflect our consensus.

Under limit key scope:

	 Following the principle of least privilege, parties MUST NOT
	 have access to keying material that is not needed to perform
	 their role.
Also see:

      Strong, fresh session keys

	 While preserving algorithm independence, session keys MUST be
	 strong and fresh.  Each session deserves an independent session
	 key.  
	 A fresh cryptographic key is one that is generated specifically
	 for the intended use.  In this situation, a secure association
	 protocol is used to establish session keys.  The AAA protocol
	 and EAP method MUST ensure that the keying material supplied as
	 an input to session key derivation is fresh, and the secure
	 association protocol MUST generate a separate session key for
	 each session, even if the keying material provided by EAP is
	 cached.  A cached key persists after the authentication
	 exchange has completed.  For the AAA/EAP server, key caching
	 can happen when state is kept on the server.  For the NAS or
	 client, key caching can happen when the NAS or client does not
	 destroy keying material immediately following the derivation of
	 session keys.

      Prevent the Domino effect

         Compromise of a single peer MUST NOT compromise keying material
         held by any other peer within the system, including session
         keys and long-term keys.  Likewise, compromise of a single
         authenticator MUST NOT compromise keying material held by any
         other authenticator within the system.  In the context of a key
         hierarchy, this means that the compromise of one node in the
         key hierarchy must not disclose the information necessary to
         compromise other branches in the key hierarchy.  Obviously, the
         compromise of the root of the key hierarchy will compromise all
         of the keys; however, a compromise in one branch MUST NOT
         result in the compromise of other branches.  

I think given these requirements what you propose would not be
appropriate.

    Dan>   Another question: has the peer no say in to whom its
    Dan> secrets are disclosed? If you think it does then what in the
    Dan> I-D addresses that concern and if you don't think it does
    Dan> then why?

I find no requirements related to this.  I do not believe there is
consensus to have such requirements nor do I believe it appropriate to
delay the document while you attempt to build such a consensus.

--Sam

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 4 Apr 2007 17:06:23 -0700 (PDT)

Sam,

  The keys in this hypothetical protocol are for network access and
giving them to authenticators for that purpose would seem to fall
under the "key scope" requirement.

  These are not session keys so the text relating the session keys
is not applicable.

  So the domino effect is the only text that could seem to prohibit
this. As long as the same key wasn't given to more than one authenticator
though then this is satisfied. A way to prevent the same key being sent
to different authenticators is to allow the authenticator to choose an
identity to advertise to the peer-- "I'm 'foo'"-- and to tell the server--
"give me a key specific to 'foo'". That identity is mixed into the key
derivation function. This is essentially what 802.11r is doing. This has
channel binding/lying NAS issues though. I'm not quite sure yet what HOKEY
is doing in this regard (how is the distributed key separated from other
keys) but it appears to suffer from the same problems since people are
advocating solutions that do not fix this problem.

  Finally, I'm not trying to delay anything. I said it before and I'll
say it again: if the general feeling is that the I-D already addresses
these issues or there is no consensus to solve the problem then publish it
as an RFC. It is important to have an RFC talking about these things, it's
just my personal opinion that it does not go far enough.

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Apr 2007 21:16:39 -0400

Dan>   Sam,

    Dan>   The keys in this hypothetical protocol are for network
    Dan> access and giving them to authenticators for that purpose
    Dan> would seem to fall under the "key scope" requirement.

Key scope means giving an authenticator a key for a specific
purpose--something like authentication for network access between peer
foo and authenticator bar--not something general like network access.

    Dan>   These are not session keys so the text relating the session
    Dan> keys is not applicable.

O, I definitely think they are session keys.

    Dan>   So the domino effect is the only text that could seem to
    Dan> prohibit this. As long as the same key wasn't given to more
    Dan> than one authenticator though then this is satisfied. A way
    Dan> to prevent the same key being sent to different
    Dan> authenticators is to allow the authenticator to choose an
    Dan> identity to advertise to the peer-- "I'm 'foo'"-- and to tell
    Dan> the server-- "give me a key specific to 'foo'". That identity
    Dan> is mixed into the key derivation function. This is
    Dan> essentially what 802.11r is doing. This has channel
    Dan> binding/lying NAS issues though. I'm not quite sure yet what
    Dan> HOKEY is doing in this regard (how is the distributed key
    Dan> separated from other keys) but it appears to suffer from the
    Dan> same problems since people are advocating solutions that do
    Dan> not fix this problem.

Wait, what's wrong with giving 100 authenticators 100 different keys
provided that each authenticator is authorized to claim the identity
it plans to claim?
Isn't that exactly the sort of thing we do want to do?

BTW, I think your questions exploring what key scope and session keys
mean are good.  The only issue I'm asking you to step away from at
this late point in the process is the question of whether clients
should be involved in deciding who their keys are given to.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 Apr 2007 12:03:05 -0400

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:

    Bernard> O, I definitely think they are session keys.  [BA] They
    Bernard> are not TSKs according to the definition in the EAP Key
    Bernard> Management Framework.

That's true.
But  that definition is not normative for draft-housley-aaa-key-mgmt.

    Bernard> Wait, what's wrong with giving 100 authenticators 100
    Bernard> different keys provided that each authenticator is
    Bernard> authorized to claim the identity it plans to claim?
    Bernard> Isn't that exactly the sort of thing we do want to do?
 
    Bernard> [BA] The creation of cryptographically separate keys for
    Bernard> each authenticator is not sufficient; the EAP Key
    Bernard> Management Framework describes the problems that can
    Bernard> result without authentication and authorization.

Again, I think that correctness of accounting in this instance is an
additional requirement the key management framework puts on top of
draft-housley-aaa-key-mgmt.

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 5 Apr 2007 11:00:56 -0700 (PDT)

Hi Sam,

> foo and authenticator bar--not something general like network access.

  I just don't see that in draft-housley-aaa-key-mgmt-09.txt which says:

         Following the principle of least privilege, parties MUST NOT
         have access to keying material that is not needed to perform
         their role.  A party has access to a particular key if it has
         access to all of the secret information needed to derive it.

The role of the particular party is an authenticator and this key is
for that purpose. There's nothing there about a purpose involving
specific entities ("peer foo and authenticator bar"). I snipped the 2nd

> O, I definitely think they are session keys.

  They are not keys used for bulk traffic protection. At least not in
my mind. There is something the aforementioned draft refers to as a
"secure association protocol" used to derive keys used for bulk traffic
protection-- like 802.11's "4 way handshake". The 2nd paragraph that I
snipped above deals with such a "secure association protocol" and the
identities identified in that protocol are low-layer identities-- a BSSID
or a MAC address-- used to send protected packets/frames between the
peer and authenticator.

  I guess you could use the key being distributed directly as a bulk
traffic protection key but then return handoffs-- peer goes from A to
B and back to A-- would require additional trips to the AAA server
which is something we want to avoid.

> Isn't that exactly the sort of thing we do want to do?

  Provided there are no channel binding issues and the all parties are
authenticated and the authenticated identity is authorized to hold the
distributed key I guess there isn't anything wrong.

  The reason I'm bringing this up, though, is because AAA is now being
used as a key distribution protocol-- 802.11r and HOKEY-- and these issues
are not being addressed in that use of AAA. In discussions with people
it is apparent they think the channel binding mention in the
aforementioned draft deals with EAP. They think authentication of all
parties just means establishing some security association (using a RADIUS
shared secret for instance, or an IPsec SA) and the identity that was
authenticated during its creation is irrelevant and not used during the
distribution of a key. Any new security issues that they might create by
using AAA as a key distribution protocol are ignored and compliance to
"the Housley Criteria" is claimed.

> should be involved in deciding who their keys are given to.

  I will step away from that question. I did not intend on introducing
any new issues when I brought it up. Although I honestly don't see how
you can solve the issue of binding a common authenticator identity between
the peer and AAA server (the two entities that share the secret that is
being disclosed to the authenticator) without involving the peer.

  Dan.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 Apr 2007 14:55:17 -0400

Dan, I'd appreciate it if you could work with Russ and Bernard on
seeing f the draft has adequate text to cover the issues that I think
we now agree should be covered.  My approach would be to clarify the
definition of session key to clearly include MSK and handoff keys that
fill the same role.  (session key is broader than TSK or TEK) and to
clarify what key scope needs to include.

Other approaches are also possible and I am not attached to my
proposal.

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 Apr 2007 14:51:54 -0400

Bernard> That's true.  But that definition is not normative for
    Bernard> draft-housley-aaa-key-mgmt.
 
    Bernard> [BA] If the documents are using a different definition of
    Bernard> "session keys" then I think we need to make sure that the
    Bernard> term is clearly defined in draft-housley to avoid
    Bernard> confusion.
Sure, they should use a consistent definition, but for example, the
"master session key" really needs to be included in the definition of
session key.

    Bernard> Again, I think that correctness of accounting in this
    Bernard> instance is an additional requirement the key management
    Bernard> framework puts on top of draft-housley-aaa-key-mgmt.

    Bernard> [BA] The term "AAA" stands for authentication,
    Bernard> authorization and accounting.  Why would the correctness
    Bernard> of accounting data be a requirement only for one
    Bernard> particular AAA usage?

I think it is a true statement that draft-housley-aaa-key-mgmt does
not make this requirement about accounting; you are welcome to show me
text that I've missed about this issue in draft-housley-aaa-key-mgmt.
I take no stand on whether this should have been included in the AAA
key management draft other than to say that it is really late for
adding requirements of this form.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 5 Apr 2007 08:29:22 -0700

[BA]  They are not TSKs according to the definition in the EAP Key Management Framework. 

Wait, what's wrong with giving 100 authenticators 100 different keys
provided that each authenticator is authorized to claim the identity
it plans to claim?  Isn't that exactly the sort of thing we do want to do?
 
[BA] The creation of cryptographically separate keys for each authenticator is not sufficient;  the EAP Key Management Framework describes the problems that can result without authentication and authorization.  
 
As an example,  Proactive Key Distribution as proposed in http://www.watersprings.org/pub/id/draft-irtf-aaaarch-handoff-04.txt distributes keys in advance of peer arrival at an authenticator.  The problem is that evidence is not provided to the AAA server that the peer actually arrived at an authenticator to whom a proactive key was provided. 
 
Since accounting records can now be created without a corresponding AAA conversation, new classes of attacks become possible.  For example, a rogue authenticator can claim that the authenticator has connected to itself or another authenticator in the neighbor graph by issuing bogus accounting records.  Since Bogus accounting records can be created without fear of detection, financial fraud becomes possible.  
 
Corruption of the neighbor graph is also possible unless the AAA server only creates neighbor graph entries in response to successful authentications between the peer and AAA server.  Without this, a rogue authenticator could corrupt the neighbor graph by submitting bogus accounting records, causing proactive keys to be distributed outside their authorized scope (e.g. only to legitimate 'neighbors'). 
 
Note that proactive key distribution actually provides more security safeguards than some other 'fast handoff' proposals because the creation of a neighbor graph based on successful authentications limits the scope of potential mischief.  For example, an authenticator in Hawaii cannot claim to be a neighbor of one in New York without providing evidence that a peer had actually authenticated via both. 
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 5 Apr 2007 08:29:22 -0700

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 5 Apr 2007 08:29:22 -0700

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 5 Apr 2007 10:25:07 -0700

That's true.
 
[BA] If the documents are using a different definition of "session keys" then I think we need to make sure that the term is clearly defined in draft-housley to avoid confusion.  

[BA] The term "AAA" stands for authentication, authorization and accounting.  Why would the correctness of accounting data be a requirement only for one particular AAA usage?