Subject: Re: [HOKEY] consensus call: key delivery security protocol

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 7 Aug 2007 11:17:37 -0400

I was taking vacation and sorry for delayed response.

How does option #1 with hop-by-hop security satisfy
draft-housley-aaa-key-mgmt-09.txt, especially "Authenticate all
parties" and "Keying material confidentiality and integrity"
requirements?

Regards,
Yoshihiro Ohba

On Mon, Jul 23, 2007 at 01:32:36PM -0400, Charles Clancy wrote:
> Related issue: #28
> 
> The current key distribution document describes protocols that require a 
> shared key between the server and third party.  According to RFC 4107, 
> we are required to specify how those keys are provisioned.  The result 
> was 3 options:
> 
> #1: convert the current protocol into one that uses hop-by-hop security 
> with channel bindings based on AAA
> 
> #2: define a protocol to provision keys, as necessary, between AAA 
> servers and any remote AAA client that needs a pairwise key for 
> end-to-end security
> 
> #3: use something like cross-realm Kerberos to provide the necessary 
> cryptographics to improve upon hop-by-hop security
> 
> An initial hum eliminated option #2.  A vote for options #1 and #3 
> yielded 23 in favor of #1 and 11 in favor of #3.  This email is to 
> confirm the consensus in the room during the meeting.
> 
> Please comment by August 2.
> 
> -- 
> t. charles clancy, ph.d.  <>  [email-masked]  <>  eng.umd.edu/~tcc
> adjunct professor, electrical engineering, university of maryland
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
> 

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

---

From: "T. Charles Clancy" <[email-masked]>
Date: Wed, 8 Aug 2007 14:51:16 -0400 (EDT)

If AAA-proxy compromise is not part of our threat model, then all parties 
are securely authenticated and keying material remains undisclosed to 
non-trusted parties.  The draft-housley-aaa-key-mgmt doesn't say to whom 
the keying material must remain confidential, or that only the two 
endpoints can know a key.

Sure, a proxy can be compromised and misbehave, but so can a AAA server.

The cryptographic protocol academic in me cringes to say that, but I don't 
see any practical way to avoid it.  We need to trust the AAA 
infrastructure.  We can certainly document the concerns associated with a 
hop-by-hop protocol in the security considerations section.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 9 Aug 2007 10:21:05 -0400

I think that this issue is fundamental.  Please see my comment inline.

> Sure, a proxy can be compromised and misbehave, but so can a AAA server.

The issue is not about compromise of an entity that generates or uses
the keying material (any key distribution cannot securely work if such
compromise happens).  The issue is whether it is acceptable for the
keying material to be seen by an entity that does not generate or use
it in order for the key distribution to work.  In the case of HOKEY,
such an entity is typically a AAA proxy that may sit on the key
distribution path between an authenticator and a HOKEY server or
between a HOKEY server and a AAA server.  This can happen in real
deployment in which there is an intermediate AAA domain between the
home AAA domain and visited AAA domain.

With regard to draft-housley-aaa-key-mgmt, there is a hint to indicate
to whom the keying material must remain confidential:

"
   For example, [RFC4072] enables EAP keying material to be delivered
   from a AAA server to a AAA client without disclosure to third
   parties.  Thus, key confidentiality is mandatory to implement in
   Diameter [RFC3588].  However, key confidentiality is not mandatory to
   use.
"

I have a doubt if hop-by-hop security is really acceptable for our key
distribution mechanism.

> hop-by-hop protocol in the security considerations section.

As Glen mentioned before, Kerberos-like architecture that supports
cross-realm operation can work without the keying material exposed to
a AAA proxy in the intermediate AAA domain.  Do you think that
Kerberos is not practical?

Also, depending on security policy, we may not fully trust the AAA
infrastructure.  Otherwise, why does RFC 3588 have the following text?

"
   It is strongly RECOMMENDED that all Diameter implementations support
   end-to-end security.
"

Regards,
Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Thu, 9 Aug 2007 10:25:18 -0700

think that this issue is fundamental.  Please see my comment inline.

"

One of the major problems with that draft (now RFC 4962) is that while claiming to be "guidance for AAA key management", it essentially ignores the question of proxies.

I have a doubt if hop-by-hop security is really acceptable for our key
distribution mechanism.
There was clear consensus at the Chicago meeting to utilize the "standard AAA methods" for key transport.

There was clear consensus at the Chicago meeting not to use Kerberos.  Given that that consensus has not been contradicted on the list, I think that this conversation is over.

Also, depending on security policy, we may not fully trust the AAA
infrastructure.  Otherwise, why does RFC 3588 have the following text?
Because the editor forgot to take it out?

"

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 9 Aug 2007 16:32:17 -0400

Glen,

A consensus in a face-to-face meeting does not mean it's final
consensus simply because not all WG members can participate in
face-to-face meetings.  It needs to be confirmed over the WG mailing
list.  Otherwise, what is the purpose of this consensus call?

I would like to hear more technical opinion from other WG members on
this fundamental issue rather than seeing further discussion being
shut up administratively.

I believe that RFC 4902 is generic enough to cover proxy environment.

Regards,
Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Thu, 9 Aug 2007 16:40:55 -0700

Glen,

Absolutely.  However, 20 or 30 people in a face-to-face meeting cannot be shouted down by a couple of people on a mailing list.

I would like to hear more technical opinion from other WG members on
this fundamental issue rather than seeing further discussion being
shut up administratively.
The largest part of a WG chair's job is to gauge WG consensus and move the work in that direction.  The operative terms here are gauge and  move.  I have stated my opinion of the WG Consensus.  If you choose to see that as being "administratively shut up" that's up to you.  IMHO we have spent far too much time discussing this already and these endless arguments amongst a small group of people are seriously impeding the progress of the WG.  If you want to discuss fundamental problems, I would suggest that an IRTF RG might be a good place to do it.

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 10 Aug 2007 02:45:24 -0400

Glen,

I don't think that we had a fair amount of discussion on this topic
before raising hands.  Especially no one had raised the issue on how
option #1 can meet RFC 4902 until I send an email on this thread, and
I still don't see a satisfactory technical answer on the issue.  BTW,
I have absolutely no intent to impede the progress of the WG.

Regards,
Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 10 Aug 2007 08:55:02 -0700

Glen,

I don't think that we had a fair amount of discussion on this topic
before raising hands.  
Yoshi, we've been discussing this topic for months now, ever since the interim meeting in San Jose.
Especially no one had raised the issue on how
option #1 can meet RFC 4902 until I send an email on this thread, and
I still don't see a satisfactory technical answer on the issue.  
My personal opinion is that RFC 4902 is just wrong, in the interesting way in which only statements can be: totally.  It's not just not Best Current Practice, it's not _any_ current practice & forcing IETF standards to conform to it virtually guarantees a steep spiral into irrelevance.
BTW,
I have absolutely no intent to impede the progress of the WG.
Sometimes our actions have unintended consequences.

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 12 Aug 2007 21:58:40 -0400

Glen,

RFC 4962 (4902 was a typo) is Best Current Practice (BCP 132).  

Shouldn't HOKEY WG drafts ratify RFC 4962 according to RFC 2026?

"
5.  BEST CURRENT PRACTICE (BCP) RFCs

   The BCP subseries of the RFC series is designed to be a way to
   standardize practices and the results of community deliberations.  A
   BCP document is subject to the same basic set of procedures as
   standards track documents and thus is a vehicle by which the IETF
   community can define and ratify the community's best current thinking
   on a statement of principle or on what is believed to be the best way
   to perform some operations or IETF process function.
"

Regards,
Yoshihiro Ohba

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Wed, 15 Aug 2007 08:57:25 -0700

Glen,

RFC 4962 (4902 was a typo) is Best Current Practice (BCP 132). 
gwz> Another typo was "My personal opinion is that RFC 4992 is just wrong, in the interesting way in which only statements can be: totally."  It _should_ have said "My personal opinion is that RFC 4962 is just wrong, in the interesting way in which only _religious_ statements can be: totally." 

Shouldn't HOKEY WG drafts ratify RFC 4962 according to RFC 2026?
I hope I've made my opinion of RFC 4062 clear ;-).  Be that as it may, however, as WG chair I suppose I have to agree with your statement.  So what, exactly, do you think violates it?  AFAICT, RFC 4962 (among its other flaws) completely ignores the existence of RADIUS proxies.  What _might_ have relevance to the question is in section 3, under the heading "Limit key scope".  It says "Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role."  This statement is ambiguous: is it the _access_ that is not needed to perform the role or the _keying material_?  I prefer to resolve the ambiguity in favor of utility & say that it is the _access_; since RADIUS proxies MUST have access to the plaintext contents of any encrypted attribute (including passwords) in order to perform their role, they don't violate RFC 4962 in this case.  Can you find a case where they do?

"

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 15 Aug 2007 13:43:12 -0400

Glen,

On Wed, Aug 15, 2007 at 08:57:25AM -0700, Glen Zorn (gwz) wrote:
> I hope I've made my opinion of RFC 4062 clear ;-).  

There is another typo, s/4062/4962/ :)

>Be that as it may, however, as WG chair I suppose I have to agree with your statement.  So what, exactly, do you think violates it?  AFAICT, RFC 4962 (among its other flaws) completely ignores the existence of RADIUS proxies.  What _might_ have relevance to the question is in section 3, under the heading "Limit key scope".  It says "Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role."  This statement is ambiguous: is it the _access_ that is not needed to perform the role or the _keying material_?  I prefer to resolve the ambiguity in favor of utility & say that it is the _access_; since RADIUS proxies MUST have access to the plaintext contents of any encrypted attribute (including passwords) in order to perform their role, they don't violate RFC 4962 in this case.  Can you find a case where they do?

Although I don't think that the statement you quoted above is
ambiguous, I don't think we can classify the RADIUS proxies as an
entity that is allowed to have access to the keying material, because
the RADIUS proxies do not need to have access to the keying material
in order to perform their role unless hop-by-hop security is used for
transporting the keying material.  It would be important to note that
use of RADIUS proxies is not the same as use of hop-by-hop security.
It appears to me that a solution that relies on hop-by-hop security
violates RFC 4962.

Regards,
Yoshihiro Ohba

---

From: "Alper Yegin" <[email-masked]>
Date: Wed, 15 Aug 2007 22:20:22 +0300

> It appears to me that a solution that relies on hop-by-hop security

Isn't that plain obvious?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 16 Aug 2007 10:41:23 -0400

So, here is my conclusion: it might be difficult to adopt a solution
that violates RFC 4962, regardless of how 23 people in the meeting
room were in favor of the solution.

(Again, I have no intent to impede the progress of the work.  What I
really care is to waste our time to work on something that has a risk
of being pushed back from IETF community and IESG in the later stages.
BTW, I have a different type of concern on another concensus call on
ERX transport which requires modification to EAP state machine.)

Best Regards,
Yoshihiro Ohba

---

From: Madjid Nakhjiri <[email-masked]>
Date: Fri, 17 Aug 2007 16:28:28 -0700

Hi Glen,

The issue with sending keys through AAA proxy and its conflict with
aaa-key-mgm draft was put in front of us during a recent security area
review of RADIUS support for Mobile IP.

Ambigious or not, the "limited scope" requirement comes from Russ Housley,
former security AD and now chair of IETF and 

4962 (when it was a draft) was used as a basis and motivator for creation of
HOKEY WG, so if you think it is wrong, or it should fit itself to legacy
RADIUS infrastructure, then with all due respect you have put the wrong hat
on.

During the BoFs and many other discussions in other SDOs people were telling
us, you can pass the key from one authenticator/Base station to another as
you handover, since it is all trusted infrastructure, so you don't need a
new hierarchy or re-authentication (please see Dallas meeting minutes as an
example), so where does that leave this group?

Without stating my opinion about 4962 and as much as I personally like to
use the AAA infrastructure for our solution, before you declare this a done
deal, I think the chairs should really make sure that the IESG, especially
security area is ok with this (this with no disrespect to your personal
opinion, we all have put a lot of time, energy and money, not mention nerves
here). 

Given the track record of this group reneging its own past declarations of
consensus (both DSRK and ERX as examples), we might want to check this with
the ADs.

As an editor of this (or a "potential" editor based on what I am
experiencing), I would have hard time committing to going two years down the
road with this document only to get a push back from IESG later.

I rather see the progress being "impeded" now for a month, than for 2 years
between 2008-2010.

We are simply doing an impedance matching between HOKEY and IESG (sorry for
the RF joke).

Sure we had a good hum in Chicago, and the consensus of course needs to be
confirmed on the list (you may say it has been done), but I like to see this
being confirmed with security area directorate. My experience in IETF, is
when it comes to security, we should be proactive.

Madjid

  _____  

From: Glen Zorn (gwz) [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2007 8:57 AM
To: Yoshihiro Ohba
Cc: [email-masked]
Subject: RE: [HOKEY] consensus call: key delivery security protocol

Glen,

gwz> Another typo was "My personal opinion is that RFC 4992 is just wrong,
in the interesting way in which only statements can be: totally."  It
_should_ have said "My personal opinion is that RFC 4962 is just wrong, in
the interesting way in which only _religious_ statements can be: totally." 

Shouldn't HOKEY WG drafts ratify RFC 4962 according to RFC 2026?
I hope I've made my opinion of RFC 4062 clear ;-).  Be that as it may,
however, as WG chair I suppose I have to agree with your statement.  So
what, exactly, do you think violates it?  AFAICT, RFC 4962 (among its other
flaws) completely ignores the existence of RADIUS proxies.  What _might_
have relevance to the question is in section 3, under the heading "Limit key
scope".  It says "Following the principle of least privilege, parties MUST
NOT have access to keying material that is not needed to perform their
role."  This statement is ambiguous: is it the _access_ that is not needed
to perform the role or the _keying material_?  I prefer to resolve the
ambiguity in favor of utility & say that it is the _access_; since RADIUS
proxies MUST have access to the plaintext contents of any encrypted
attribute (including passwords) in order to perform their role, they don't
violate RFC 4962 in this case.  Can you find a case where they do?

"

Regards,
Yoshihiro Ohba

On Fri, Aug 10, 2007 at 08:55:02AM -0700, Glen Zorn (gwz) wrote:
> My personal opinion is that RFC 4902 is just wrong, in the interesting way
in which only statements can be: totally.  It's not just not Best Current
Practice, it's not _any_ current practice & forcing IETF standards to
conform to it virtually guarantees a steep spiral into irrelevance.
> > Absolutely.  However, 20 or 30 people in a face-to-face meeting cannot
be shouted down by a couple of people on a mailing list.
> > The largest part of a WG chair's job is to gauge WG consensus and move
the work in that direction.  The operative terms here are gauge and  move.
I have stated my opinion of the WG Consensus.  If you choose to see that as
being "administratively shut up" that's up to you.  IMHO we have spent far
too much time discussing this already and these endless arguments amongst a
small group of people are seriously impeding the progress of the WG.  If you
want to discuss fundamental problems, I would suggest that an IRTF RG might
be a good place to do it.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Aug 2007 13:17:44 -0400

I will admit that I find it hard to tell wether Russ's draft permits
sharing keys through AAA infrastructure or not.

It's ambiguous because it seems clearly permitted for the MSK.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Tue, 21 Aug 2007 14:40:27 -0700

Well, this much uncertainty is worrisome, it almost seem that we need to
somehow force this through IESG and sec area review before going further.
Given that the ps draft is the only one with any requirements in it, the
quickest way I see this happening is possibly capture it in the PS draft
somehow...

Madjid

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 21 Aug 2007 15:06:27 -0700 (PDT)

Sam,

  Where do you read that it is permitted for the MSK? It seems to me
that RFC4962 deals with the security around distribution and generation
of session keys and not with distribution of network access credentials
(like the MSK).

  Look at "Limit Key Scope": you have access to a key if you have
all the secret information needed derive it. That's clearly talking
about session keys since it is obviously false when talking about an
MSK-- I have access to an MSK if I know it even if I don't know the
inputs to the TLS PRF that derived it. This section also specifically
mentions "session keys".

  Look at "Authenticate All Parties": RADIUS and DIAMETER provide a
mechanism for identification of AAA clients. Which follows from the
preceding paragraph talking about parties involved in a session key
establishment protocol needing to identify themselves.

  The section on "Peer and authenticator authorization" uses the example
of 802.11's 4-way handshake which is a protocol used to derive session
keys.

  In the "Prevent the Domino Effect" section it says, "the scope of the
keying material must be defined and understood by all parties that
communicate with a party that holds that keying material." If the "keying
material" is an MSK and there are proxies among "all parties" how do you
address that requirement?

  Dan.

---

From: Glen Zorn <[email-masked]>
Date: Tue, 21 Aug 2007 15:25:29 -0700

> Sam,> > Where do you read that it is permitted for the MSK? It seems to me> that RFC4962 deals with the security around distribution and generation> of session keys and not with distribution of network access credentials> (like the MSK).
 
Let's just say that (despite the name) the MSK is not a "Master Session Key" & is in fact a network access credential (where do you get that from, BTW?).  Since AFAIK the MSK is the only key commonly transferred via AAA, doesn't that make RFC 4962 kind of, well, irrelevant?
> > Look at "Limit Key Scope": you have access to a key if you have> all the secret information needed derive it. That's clearly talking> about session keys since it is obviously false when talking about an> MSK-- I have access to an MSK if I know it even if I don't know the> inputs to the TLS PRF that derived it. This section also specifically> mentions "session keys".
 
So why isn't that statement false WRT any symmetric key, session or otherwise?  How can I know a key without having (possibly unauthorized) access to it?
 
...
 
> > In the "Prevent the Domino Effect" section it says, "the scope of the> keying material must be defined and understood by all parties that> communicate with a party that holds that keying material." If the "keying> material" is an MSK and there are proxies among "all parties" how do you> address that requirement?
 
Good question.  As I've said before, I consider the biggest flaw in the document is its insistence on ignoring the way that AAA systems in the real world actually function.> > Dan.> > On Mon, August 20, 2007 10:17 am, Sam Hartman wrote:> > I will admit that I find it hard to tell wether Russ's draft permits> > sharing keys through AAA infrastructure or not.> >> > It's ambiguous because it seems clearly permitted for the MSK.> >> > _______________________________________________> > HOKEY mailing list> > [email-masked]> > https://www1.ietf.org/mailman/listinfo/hokey> >> > > > _______________________________________________> HOKEY mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/hokey
_________________________________________________________________
Connect to the next generation of MSN Messenger 
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Aug 2007 19:12:52 -0400

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

    Dan>   Sam,

    Dan>   Where do you read that it is permitted for the MSK? It
    Dan> seems to me that RFC4962 deals with the security around
    Dan> distribution and generation of session keys and not with
    Dan> distribution of network access credentials (like the MSK).

It is definitely true that some parts of RFC 4962 only deal with
session keys.  It is also true that the MSK is not a session key.

    Dan>   Look at "Limit Key Scope": you have access to a key if you
    Dan> have all the secret information needed derive it. That's
    Dan> clearly talking about session keys since it is obviously
    Dan> false when talking about an MSK-- I have access to an MSK if
    Dan> I know it even if I don't know the inputs to the TLS PRF that
    Dan> derived it. This section also specifically mentions "session
    Dan> keys".

I think you also have a key if you have been given that key.
That's an if statement not an only if statement.

I agree that the limit key scope section does not apply to the MSK.

    Dan>   Look at "Authenticate All Parties": RADIUS and DIAMETER
    Dan> provide a mechanism for identification of AAA clients. Which
    Dan> follows from the preceding paragraph talking about parties
    Dan> involved in a session key establishment protocol needing to
    Dan> identify themselves.

    Dan>   The section on "Peer and authenticator authorization" uses
    Dan> the example of 802.11's 4-way handshake which is a protocol
    Dan> used to derive session keys.

    Dan>   In the "Prevent the Domino Effect" section it says, "the
    Dan> scope of the keying material must be defined and understood
    Dan> by all parties that communicate with a party that holds that
    Dan> keying material." If the "keying material" is an MSK and
    Dan> there are proxies among "all parties" how do you address that
    Dan> requirement?
This is a good question.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 21 Aug 2007 21:29:09 -0400

Dan,

> of session keys and not with distribution of network access credentials

While some part of RFC 4962 specifically talks about session keys, I
don't think that it does not deal with distribution of other keying
material including MSK.  For example:

"
      Keying material confidentiality and integrity

         While preserving algorithm independence, confidentiality and
         integrity of all keying material MUST be maintained.
"

The above requirement mentions "all keying material".  I can interpret
this to cover both session keys and network access credentials.

> inputs to the TLS PRF that derived it. This section also specifically

This section mentions "session keys" in the second paragraph, but I
can interpret that the first paragraph covers both session keys and
network access credentials:

"
      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.  A party has access to a particular key if it has
         access to all of the secret information needed to derive it.

         Any protocol that is used to establish session keys MUST
         specify the scope for session keys, clearly identifying the
         parties to whom the session key is available.
"

Yoshihiro Ohba

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 24 Aug 2007 11:56:57 -0700 (PDT)

Glen,

On Tue, August 21, 2007 3:25 pm, Glen Zorn wrote:
>> Sam,> > Where do you read that it is permitted for the MSK? It seems to
>> me> that RFC4962 deals with the security around distribution and
>> generation> of session keys and not with distribution of network access
>> credentials> (like the MSK).
>
> Let's just say that (despite the name) the MSK is not a "Master Session
> Key" & is in fact a network access credential (where do you get that from,
> BTW?).  Since AFAIK the MSK is the only key commonly transferred via AAA,
> doesn't that make RFC 4962 kind of, well, irrelevant?

  I get "network access credential" from its use. If a client can
prove possession of that blob-of-bits then it gets network access. I
don't think we should get hung up on the semantics of it. Perhaps we can
call it the Mega Super Key.

  I don't think RFC4962 is necessarily irrelevent. It talks about AAA
key management and, according to it

   AAA key management often includes a collection of protocols, one of
   which is the AAA protocol.  Other protocols are used in conjunction
   with the AAA protocol to provide an overall solution.  These other
   protocols often provide authentication and security association
   establishment.

So my read is that it is giving guidance to the "other protocols" that
provide authentication and security association establishment. For
instance 802.11's 4 way handshake. It provides "authentication" by proving
possession of the Mega Super Key. It derives security associations bound
to some lower-layer identity (BSSID/MAC addr) that contain some transient
session keys used to protect a particular traffic flow.

  Unfortunately I don't think it talks directly about _key distribution_
protocols that send peers' network access credentials hither and yon.

>> > Look at "Limit Key Scope": you have access to a key if you have> all
>> the secret information needed derive it. That's clearly talking> about
>> session keys since it is obviously false when talking about an> MSK--
>> I have access to an MSK if I know it even if I don't know the> inputs
>> to the TLS PRF that derived it. This section also specifically>
>> mentions "session keys".
>
> So why isn't that statement false WRT any symmetric key, session or
> otherwise?  How can I know a key without having (possibly unauthorized)
> access to it?

  Perhaps I phrased it poorly. I'm saying that if you know the MSK then
you ipso facto have access to it. But "Limit Key Scope" says you have
access to a key if you know the secret information needed to derive it.
Because of that wording I think it's addressing keys derived from the MSK
by some secure association protocol. If "Limit Key Scope" was talking
about the MSK then, in my opinion, it wouldn't say what it says the way
it says it. Maybe I'm getting hung up on the semantics though....

> ...
>
>> > In the "Prevent the Domino Effect" section it says, "the scope of the>
>> keying material must be defined and understood by all parties that>
>> communicate with a party that holds that keying material." If the
>> "keying> material" is an MSK and there are proxies among "all parties"
>> how do you> address that requirement?
>
> Good question.  As I've said before, I consider the biggest flaw in the
> document is its insistence on ignoring the way that AAA systems in the
> real world actually function.

  Actually what I think the problem you have with it is that it does not
make accomodations for the way AAA systems in the "real world" actually
function. But insecure practices should be stopped. I'm sure when traffic
signs were first introduced people said, "they ignore the way carts and
buggies actually work in the real world" because previously carts and
buggy traffic was unregulated (and dangerous).

  Dan.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 27 Aug 2007 14:07:58 -0700

> call it the Mega Super Key.

[gwz] Hmm, silly me: I thought that what gained network access in 802.11i
was successful 802.1X authentication.  Now it turns out that no such thing
is actually required.  Wow.

> possession of the Mega Super Key.

[gwz] No.  The user authentication is done with EAP.  The 4-way handshake
just proves to .11i that the .1X authentication was successful.  IIRC, the
only reason the 4-way handshake is necessary is that .1X & .11i don't talk:
.1X doesn't provide any indication that authentication has succeeded to
other layers, it just opens the controlled port to traffic.  Since the
purpose of .11i is to protect data in the air w/encryption & integrity
protection, it wouldn't do for traffic to start flowing unencrypted so .11i
implements its own version of the "controlled port"; a successful 4-way
handshake & the subsequend derivation of TSKs opens that gate.  You make it
sound as if one can simply take the MSK off & use it to obtain network
access by itself but that is not possible.

.

> function. But insecure practices should be stopped. 

[gwz] Non-secure practices are only stopped because there is value perceived
in doing so, not because of IETF fiat.  

I'm sure when traffic
> buggy traffic was unregulated (and dangerous).

[gwz] Not like those ultra-safe automobiles!

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 28 Aug 2007 11:00:45 -0700 (PDT)

Glen,

> is actually required.  Wow.

  Check out how PMK caching works in 802.11. As the client does a handoff
all he has to do is prove possession of a PMK/MSK and he gets network
access. If he fails to prove possession of a PMK/MSK he gets the boot.

> access by itself but that is not possible.

  Then why is there a proof-of-possession of the PMK/MSK in the 4way
handshake? If all it had to do was create TSKs it could be the 2way
handshake-- authenticator sends nonce, supplicant sends nonce, they both
hash up some TSKs and away they go. It's there for a reason and that
reason is for a form of "authentication". Look how PMK caching works.
The client claims it has a PMK/MSK. If it can prove possession of that
_network access credential_ via another 4way handshake it gets network
access without having to do another full-blown 802.1x/EAP exchange.

  Dan.