Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-reauth-ps

From: Charles Clancy <[email-masked]>
Date: Sun, 10 Feb 2008 17:00:21 -0500

Alan,

Thanks for your review.

WRT AAA proxies, they were not discussed because the PS document makes 
no assumption that AAA will be used for key distribution.

WRT key hierarchies, the document says "If a key hierarchy is 
deployed..." so again we don't make any assumption about what the 
solution will be.  We only say that if a hierarchy is used it must not 
be susceptible to the domino effect.

Same thing for the architectural diagram... the goal was to minimize our 
influence on the solution -- we're just trying to state the problem.

The next rev will address your other comments.

--
t. charles clancy, ph.d.                 eng.umd.edu/~tcc
electrical & computer engineering, university of maryland

Alan DeKok wrote:
>   Reviewing the document, it looks very good overall.  I have a few
> comments and questions:
> 
> Section 3:
> 
>    ... Handover keying allows an EAP server to
>    pass authentication information to a remote re-authentication server,
>    allowing a peer to re-authenticate to that re-authentication server
>    without having to communicate with its home re-authentication server.
> 
>   Can that authentication information be passed to multiple
> re-authentication servers?  e.g. Section 5.5 discusses AAA proxies, but
> they are not mentioned in Section 3.  It would seem that AAA proxies
> should be part of the problem statement.  Discussing AAA proxies here
> would also help motivate the discussion of key hierarchies in Section 5.1.
> 
>   e.g. Each AAA proxy is a natural point in the network for a
> re-authentication server, and for a separate point in a key hierarchy.
> They may be part of the solution, so it would be useful to mention them
> explicitly.
> 
> 
> Section 5.1
> 
>   Key hierarchies are mentioned, but no motivation is given for using
> them.  Section 1 discusses current EAP key hierarchies, but the text
> here in Section 5.1 applies to Hokey, and not to EAP.
> 
> 
> Section 5.5
> 
>    ... In the
>    architecture introduced in this document, ...
> 
>   This is the first mention of "architecture".  Previous text in the
> document discussed participants, without having an explicit
> architectural diagram, or even defining the participants in the Hokey
> process.  e.g. Section 4 lists design goals, but there is no
> corresponding section defining the participants or roles.
> 
>   Perhaps Section 2 could be expanded to include such a list.  Section 3
> could also be expanded to include an architectural diagram.
> 
> 
> Section 6.4
> 
>    An EAP peer that has multiple radio technologies (802.11 and GSM, for
>    instance) must perform the full EAP exchange on each interface upon
>    every horizontal or vertical handover.
> 
>   The terms "horizontal" and "vertical" handover should be defined
> 
>   Alan DeKok.
> 
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/hokey
_______________________________________________
HOKEY mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hokey

---

From: "Dan Harkins" <[email-masked]>
Date: Sun, 10 Feb 2008 16:33:22 -0800 (PST)

Hi Charles,

  What can be used besides AAA to allow "an EAP server to pass
authentication information to a remote re-authentication server"?

  This whole approach of "you could do this, or you could do something
else, you could use this or you could use something else" seems too
clever and I don't understand the point of that.

  Dan.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Feb 2008 08:45:46 +0100

> no assumption that AAA will be used for key distribution.

  What else would be used?  This is not a theoretical question...

> be susceptible to the domino effect.

  The document spends a lot of time explaining key hierarchies without
describing the problem that the hierarchies solves.

> influence on the solution -- we're just trying to state the problem.

  I have no idea what problem the document is solving, because it is
carefully not referencing existing definitions, practices or systems.

  The point of such references is not to constrain the solution, but to
define common terms for understanding.  It is not clear to me how this
system would be used in an AAA environment, which is the overwhelmingly
dominant use of EAP.  I don't think that the authors know either.

  As evidence, every attempt to ask questions about real-world (i.e.
AAA) uses of this solution results in discussions of key hierarchies.
You say "IF a hierarchy is used", yet the majority of discussion is
centered around such hierarchies.  This makes it seem like key
hierarchies are a requirement.

  I think the document needs a lot more clarity on WHO is doing WHAT and
WHY.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 11 Feb 2008 04:59:04 -0800

Some comments on
http://www.ietf.org/internet-drafts/draft-ietf-hokey-reauth-ps-08.txt:

Editorial:
In section 1, change:
In many common deployment scenario

to:
In many common deployment scenarios

In section 4, change:
      network support fast re-authentication.
   Cryptographic Agility:  Any re-authentication protocol MUST support

to:
      network support fast re-authentication.

   Cryptographic Agility:  Any re-authentication protocol MUST support

Section 5.6, last sentence says: "The relation of the identities used by
the transport protocol and the identities used for keying also needs to
be explored."  Do you mean "The relation between the identities used by
the transport protocol and the identities used for keying also needs to
be explored."?

There is an extra space between sections 5.6 and 6.

In section 6.1, change:
EAP-SIM [RFC4186] and EAP-AKA [RFC4187] supports fast 

to:
EAP-SIM [RFC4186] and EAP-AKA [RFC4187] support fast 
_______________________________________________
HOKEY mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/hokey

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 11 Feb 2008 05:09:54 -0800

Alan DeKok <> scribbled on Monday, February 11, 2008 2:46 PM:

> Charles Clancy wrote:
>> WRT AAA proxies, they were not discussed because the PS document
>> makes no assumption that AAA will be used for key distribution.
> 

But I think that it is a irrelevant one, in the context of a problem
statement.

>> solution will be.  We only say that if a hierarchy is used it must
>> not be susceptible to the domino effect.
> 
>   The document spends a lot of time explaining key hierarchies
> without describing the problem that the hierarchies solves. 

From section 3:

   In summary, it is undesirable to run an EAP Identity and complete EAP
   method exchange each time a peer authenticates to a new authenticator
   or needs to extend its current authentication with the same
   authenticator.  Furthermore, it is desirable to specify a method-
   independent, efficient, re-authentication protocol.  Keying material
   from the initial authentication can be used to enable efficient re-
   authentication.

Is that unclear?  

> 
>> Same thing for the architectural diagram... the goal was to minimize
>> our influence on the solution -- we're just trying to state the
>> problem. 
> 

Actually, it references the current EAP practices and systems
repeatedly.

> 
>   The point of such references is not to constrain the solution, but
> to define common terms for understanding.  It is not clear to me how
> this system would be used in an AAA environment, which is the
> overwhelmingly dominant use of EAP.  I don't think that the authors
> know either.    
> 
>   I think the document needs a lot more clarity on WHO is doing WHAT
> and WHY. 

That sounds like a solution definition, not a problem statement, to me.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Feb 2008 14:27:43 +0100

>    from the initial authentication can be used to enable efficient re-

  No.  Keying material != key hierarchies

  A re-authentication key is useful for hokey.  Multiple keys for
"future-proofing" the specification are likely unnecessary.

> Actually, it references the current EAP practices and systems

  Which live within an AAA system.  The document touches on AAA, but is
silent on most points where EAP / ERP may affect AAA, or be affected by
AAA issues.

> That sounds like a solution definition, not a problem statement, to me.

  It would help to ground a problem statement by saying *who* has a
problem, *what* the problem is, and *how* the problem affects them.

  I understand what hokey is intended to do.  It's a great idea.  But
divorcing hokey from current practices will doom it to failure.  We will
have a wonderful solution that can't be deployed because the people
designing it haven't communicated with people who build real systems.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 11 Feb 2008 05:55:52 -0800

Alan DeKok <mailto:[email-masked]> scribbled on Monday,
February 11, 2008 8:28 PM:

> Glen Zorn wrote:
>>> From section 3:
>> 
>>    In summary, it is undesirable to run an EAP Identity and complete
>>    EAP method exchange each time a peer authenticates to a new
>>    authenticator or needs to extend its current authentication with
>>    the same authenticator.  Furthermore, it is desirable to specify
>>    a method- independent, efficient, re-authentication protocol. 
>>    Keying material from the initial authentication can be used to
>> enable efficient re-    authentication. 
>> 
>> Is that unclear?
> 

One more time: draft-ietf-hokey-emsk-hierarchy _should_ have been done
in the eap WG, possibly as part of the EAP keying framework, but it
wasn't.  In any case, what does that have to do with the problem
statement?  It doesn't specify "Multiple keys for "future-proofing" the
specification".

>   Which live within an AAA system.  The document touches on AAA, but
> is silent on most points where EAP / ERP may affect AAA, or be
> affected by AAA issues.  
> 
> divorcing hokey from current practices will doom it to failure.  We
> will have a wonderful solution that can't be deployed because the
> people designing it haven't communicated with people who build real
> systems.    

I couldn't agree more, but we're not talking about the _solution_ here,
we're talking about the _problem_  In a sentence, the problem is that
mobility is impaired by the amount of time it takes to do a complete EAP
authentication (which includes, typically, AAA transit time).  This
problem is especially severe when the peer is not in its "home" network.
One solution seems to be to generate a new key as a side-effect of the
EAP authentication & transfer it along with the MSK that is sent now in
802.11i (for example) that will be used in some way to speed up the
handover process.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Feb 2008 15:16:36 +0100

Glen Zorn wrote:
> authentication (which includes, typically, AAA transit time).  ...

  In a word: Yes.  Good.  Wonderful.  Absolutely.

  Back to my original review of the document: it would be good to
include in the problem statement which parties are involved, and what
their current capabilities and limitations are.

  From the discussion on this list, it appears that some people are not
aware of existing commercial agreements that limit the possible
*technical* solutions hokey may come up with.  These limitations should
be part of the problem statement.

  e.g. "It may seem useful to permit a newly visited domain to do ERP
without an initial EAP session (such as via an intermediate AAA proxy).
 However, doing so would open up a home domain to unbounded charges from
the newly visited domain.  This practice is not commercially viable, and
as such cannot be part of a hokey solution".

  As I said in my initial review, the document is mostly silent on these
issues.  I have tried to raise these issues on this list, and have not
made much progress in having them addressed.  Perhaps a simple statement
like "we don't care about commercial limitations" would be helpful.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 11 Feb 2008 17:18:40 -0800

Alan DeKok <mailto:[email-masked]> scribbled on Monday,
February 11, 2008 9:17 PM:

...

>   From the discussion on this list, it appears that some people are
> not aware of existing commercial agreements that limit the possible
> *technical* solutions hokey may come up with.  These limitations
> should be part of the problem statement.  
> 
>  without an initial EAP session (such as via an intermediate AAA
> proxy). However, doing so would open up a home domain to unbounded
> charges from the newly visited domain.  This practice is not
> commercially viable, and as such cannot be part of a hokey solution".

That paragraph isn't in the document because that behavior has never
been an option.  
 
...

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Feb 2008 07:30:07 +0100

> That paragraph isn't in the document because that behavior has never

  It was an "example".  The documents are silent on issues relating to
many other topics.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 12 Feb 2008 03:28:42 -0800

Alan DeKok <mailto:[email-masked]> scribbled on Tuesday,
February 12, 2008 1:30 PM:

>   It was an "example".  

Yes, I'm familiar with the term ;-).  

> The documents are silent on issues relating to many other topics. 

OK, how about a _real_ example?

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Feb 2008 13:37:42 +0100

> OK, how about a _real_ example?

  I was sure I had posted a review of the document already.  Yes...

http://www.ietf.org/mail-archive/web/hokey/current/msg00993.html

  ... which then led to this discussion.

  To start off again, I believe that the role and abilities of AAA
proxies needs to be addressed.  Saying that the "document makes no
assumption that AAA will be used for key distribution" is a bit odd.
Responding that the topic is "irrelevant" doesn't let me understand why.

  Hokey is trying to build on top of a foundation, by (1) not defining
what that foundation is, and (2) calling that foundation "irrelevant".

  While I welcome a system not founded in well-defined concepts, perhaps
"technology" is an inappropriate term to use for it.  Maybe "magic"
would be a better name.

  Alan DeKok.

---

From: Charles Clancy <[email-masked]>
Date: Mon, 18 Feb 2008 21:39:08 -0500

Alan,

When we started this process, AAA was only an option for distributing 
keys.  In fact, we even considering doing EAP re-authentication outside 
of EAP itself.  For example, one proposal used EAP keys from an initial 
authentication as Kerberos credentials, and reauth happened over IP 
using Kerberos.  After much discussion, and an interim meeting, it was 
obvious that any easily deployable solution would need to reuse an 
existing AAA infrastructure.

It was decided to split up the documentation into the "problem" and the 
"solution".  The PS document described the reauth problem and gave 
design goals for a fast reauth protocol.  It motivates WHY we need fast 
reauth, but not HOW to implement it (other than high-level design 
goals).  The "solutions" documents then provided protocols that met 
those design goals, justifying their approach.

Addressing AAA proxies will occur in detail in draft-ietf-hokey-key-mgm 
(text not there yet).  The EMSK keying hierarchy document is a specific 
charter deliverable and provides the framework for a keying hierarchy. 
The ERX document provides justification as to why it uses the EMSK 
keying hierarchy the way it does (multi-level rather than single-level).

I don't think any of these things are irrelevant -- I just think they're 
not within the defined scope of the PS document.  They are certainly 
within the scope of other WG documents.

---

From: Charles Clancy <[email-masked]>
Date: Mon, 18 Feb 2008 23:00:09 -0500

Both will be included in -09.  Thanks.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Feb 2008 08:18:05 +0100

> those design goals, justifying their approach.

  The problem statement can contain a description of the current
architecture.  That description can refer to *existing* systems without
proposing a solution to the hokey problem.

  To put it another way, I haven't followed hokey since the beginning.
There appears to be knowledge captured on the list that isn't available
in the documents.

> (text not there yet).

  Again... how do AAA proxies fit into the problem statement?  They are
first mentioned in Section 5.4.  The term "AAA proxy" is not defined in
Section 2, and there is no reference in that section to any document
that defines the term.  The document just assumes that everyone knows
what an AAA proxy is, and how it fits into the problem statement.

  I will try to come up with suggested text to address my comments.

  Alan DeKok.