Subject: [HOKEY] Summary of preauth discussion

From: "Glen Zorn" <[email-masked]>
Date: Sat, 21 Mar 2009 16:56:11 -0700

I would like to put to bed (if not death ;-) the discussion of the
P->SA->AAA->CA model of preauthentication at the meeting in San Francisco
(or shortly thereafter).  Toward that end, I'm going to try to summarize the
discussion so far.

PRO

.         satisfies the list of qualities listed in RFC 5247 that apply to
EAP pre-authentication in section 4 of RFC 5247

o    does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
exchanges

o    the Secure Association Protocol (phase 2) is not eliminated

o    Discovery (phase 0) takes place as usual (whatever that may be ;-)

.         can work with existing technology developed in the hokey WG (e.g.,
ERP)

.         should work transparently across AAA realms

o    both domains must support the AAA messages necessary

CON

.         does not match the overall model of EAP preauthentication
described in RFC 5247

o    Authorization (including key delivery) and Secure Association Protocol
take place on a physically different box than the one through which the EAP
conversation passed

.         appears to be impossible to implement with RADIUS

.         would require changes to Diameter

AFAIK, neither the security nor the efficiency of the proposal have received
any discussion.

Although it's tempting to view the last months' discussions as a waste of
time, several positive outcomes can be noted even though the major issue has
yet to be resolved, among them the imprecise language and rampant confusion
present in RFC 5247 (one easy example: why is it illegal to authenticate
using a key-generating EAP method without using the keys (implied by the
mandatory status of the Secure Association Protocol)?) and at least a little
of the same in the preauth draft itself.

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 22 Mar 2009 04:24:49 +0200

PRO
• satisfies the list of qualities listed in RFC 5247 that apply to EAP
pre-authentication in section 4 of RFC 5247
o does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b) exchanges
o the Secure Association Protocol (phase 2) is not eliminated
o Discovery (phase 0) takes place as usual (whatever that may be ;-)
• can work with existing technology developed in the hokey WG (e.g., ERP)
• should work transparently across AAA realms
o both domains must support the AAA messages necessary

Alper> 

	Proactive key distribution

      In proactive key distribution, keying material and authorizations
      are transported from the backend authentication server to a
      candidate authenticator in advance of a handoff.

Alper> Isn't this what exactly happens with P->SA->AAA->CA?

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 21 Mar 2009 19:54:12 -0700

> Alper> Isn't this what exactly happens with P->SA->AAA->CA?

Quote the rest, Alper:

 	As a result, EAP (phase 1a) is not needed, but the Discovery (phase
0), and Secure
      Association Protocol exchanges (phase 2) are still necessary.
      Within the AAA exchange (phase 1b), authorization and key
      distribution functions are typically supported, but not
      authentication. 

As I have stated many times and you well know, authentication _does_ take
place in the P->SA->AAA->CA model.  Therefore, it would appear to me that
the model doesn't fit precisely in either of the neat categories posited by
5247.  

   EAP pre-authentication
      In EAP pre-authentication, an EAP peer pre-establishes EAP keying
      material with an authenticator prior to arrival.  EAP
      pre-authentication only affects the timing of EAP authentication,
      but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
      exchanges

This is _also_ precisely what happens with P->SA->AAA->CA. 

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sat, 21 Mar 2009 23:17:23 -0400

First, "the discussion of the P->SA->AAA->CA model of
preauthentication" is misleading since many folks are against
qualifying P->SA->AAA->CA as EAP pre-authentication (and instead
qualifying it as proactive key distribution).

Second, the text "satisfies the list of qualities listed in RFC 5247
that apply to EAP pre-authentication in section 4 of RFC 5247" and the
text "does not match the overall model of EAP preauthentication
described in RFC 5247" are clearly contradictory.  In fact, the first
text is wrong because the model does not fit Figure 1 of RFC 5247.

Third, no one stated that it is illegal to use a key-generating EAP
method without using the keys.

BTW, why not invite the authors of RFC 5247 to the HOKEY meeting and
let them state their opinions?  That may help this WG to quickly come
to a conclusion.

Regards,
Yoshihiro Ohba

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

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 21 Mar 2009 20:55:12 -0700

> qualifying it as proactive key distribution).

One more time:

   Proactive key distribution
      In proactive key distribution, keying material and authorizations
      are transported from the backend authentication server to a
      candidate authenticator in advance of a handoff.  As a result, 
      EAP (phase 1a) is not needed, but the Discovery (phase 0), and Secure
      ----------------------------
      Association Protocol exchanges (phase 2) are still necessary.
      Within the AAA exchange (phase 1b), authorization and key
      distribution functions are typically supported, 
      but not authentication. 
      --- --- -------------- 

For people who are so set upon the all-inclusiveness of RFC 5247. you &
Alper certainly seem eager to ignore it when convenient.

> described in RFC 5247" are clearly contradictory.  

Hardly, what it means is that the model has elements of both what RFC 5247
calls "EAP preauthentication" and what it calls "Proactive key
distribution".  It is a hybrid.  RFC 5247 describes essentially 802.11
keying (going so far as to reference such things as the neighbor graph and
SSIDs.

> In fact, the first

I suppose I shouldn't have to say this, but an illustration is not a list of
qualities.

> method without using the keys.

Phase 2a is not optional.

> let them state their opinions?  That may help this WG to quickly come

I doubt it, unless they are actually willing to claim the omniscience you
seem to ascribe to them.  In any case, Dan Simon doesn't attend IETF
meetings.

...

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 22 Mar 2009 13:11:01 +0200

> place in the P->SA->AAA->CA model.  

Well, of course authentication has to take place at some point at somewhere.
Otherwise these keys are not falling from blue sky, are they? Stating that
P->SA->AAA->CA is not Proactive Key Distribution because there is EAP
authentication sometime/somewhere is meaningless. If what you are saying
were true, then nothing would be ever called Proactive Key Distribution
because there are no keys falling from sky.

What is not happening is "EAP authentication with the candidate
authenticator." Yes, this is not happening with your P->SA->AAA->CA scheme,
hence it fits Proactive Key Distribution. On the other hand, EAP
authentication *IS* happening with the candidate authenticator in the other
cases, hence they are called Pre-authentication. 

> Therefore, it would appear to me
> that

> This is _also_ precisely what happens with P->SA->AAA->CA.

"EAP peer" is not interacting with the "CA" at all. Therefore, you cannot
say "EAP peer pre-establishes EAP keying material with an authenticator
prior to arrival." What is happening is "keying material and authorizations
are transported from the backend authentication server to a candidate
authenticator (as said for pro-active key dist.)". 

Alper

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 22 Mar 2009 14:38:14 +0200

> > Well, of course authentication has to take place at some point at
> > somewhere.Otherwise these keys are not falling from blue sky, are
> > they? Stating that
> > authentication sometime/somewhere is meaningless. If what you are
> > sayingwere true, then nothing would be ever called Proactive Key
> > Distributionbecause there are no keys falling from sky.
> >
> > authenticator." Yes, this is not happening with your P->SA->AAA-
> > >CA scheme,
> {Qin]: I wonder whether EAP authentication happens between the peer and
> AAA or happens between the peer and Authenticator. Does authenticator
> has authority to qualify whether the peer is allowed to access?

EAP authenticator, acting as pass-through does not. But a NAS that
implements EAP authenticator and AAA client and other things has the
authority to determine whether the host gets access or not.

Having answered this question, not sure how this is related to the
discussion....

> > "EAP peer" is not interacting with the "CA" at all. Therefore, you
> > cannotsay "EAP peer pre-establishes EAP keying material with an
> > authenticatorprior to arrival." What is happening is "keying
> > material and authorizations
> [Qin]: What the draft-ietf-preauth-ps orignally said is:
> "
>    pre-authentication is
>    defined as the use of EAP to pre-establish EAP keying material on a
>   target authenticator prior to arrival of the peer at the access
>    network managed by that authenticator.
> "
> Which can be seen in the abstract of draft-ietf-preauth-ps.
> So the point is the EAP keying material is pre-established on an
> auhthenticator, not with an authenticator.

There are so many direct plain English indication of the differences between
the pre-auth and pro-active keying, I'm sure the documents/authors/WG did
not mean to contrast techniques by emphasizing on the prepositions. That's
apparent in the rest of the document (see how EAP peer runs EAP through the
target authenticator).

Alper

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 22 Mar 2009 12:43:29 -0400

Let me cc authors of RFC 5247 as the debate is closely related to the
RFC.

That is why your model exactly fits with the above definition of
proactive key distribution because EAP (phase 1a) does not take place
with the candidate authenticator where phase 2a happens.

> keying (going so far as to reference such things as the neighbor graph and

No, that is not hybrid.  See above.

> I suppose I shouldn't have to say this, but an illustration is not a list of

If the list includes reference to Section 1.3 (i.e., "an EAP
pre-authentication conversation differs little from the model
described in Section 1.3, other than the introduction of a delay
between phase 1 and phase 2.", I argue that Figure 1 is part of the
list.

Yoshihiro Ohba

---

From: wuqin 53375 <[email-masked]>
Date: Sun, 22 Mar 2009 10:04:59 -0700

Hi,

----- Original Message -----
From: Alper Yegin <[email-masked]>
Date: Sunday, March 22, 2009 5:38 am
Subject: RE: Re: [HOKEY] Summary of preauth discussion
To: 'wuqin 53375' <[email-masked]>
Cc: 'Glen Zorn' <[email-masked]>, 'Glen Zorn' <[email-masked]>, [email-masked]

> > > authenticator." Yes, this is not happening with your P->SA-
> >AAA-
> > > >CA scheme,
> > AAA or happens between the peer and Authenticator. Does 
> authenticator> has authority to qualify whether the peer is 
> allowed to access?
> 
[Qin]: 
Firstly EAP protocol is a protocol happening between the peer and the EAP server. It is EAP server who perfom authentication to the peer,not the authenticator. After the authentication between the peer and EAP server is performed successfully, then the NAS is notified by the this EAp server to allow the peer get access. And EAP conversation between the peer and authenticator then starts.
Secondly, the EAP authentication with the Candidate Authenticator is actually related to the phase2 as described in RFC5247, i.e., security association between the peer and authenticator, I am not sure the EAP conversation between the peer and the authenticator is appropriate to be called as "EAP authentication".
> candidate> > authenticator (as said for pro-active key dist.)".
> > >
> > > Alper
[Qin]: For the Proactive keying, the EAP conversation between the peer and Candidate authenticator is not necesary, However in P-SA-AAA-CA, the EAp conversation between the peer and the candidate authenticator can be allowed to verfied the keying materials on the peer and the candiate authentiator if you require.

---

From: "Alper Yegin" <[email-masked]>
Date: Sun, 22 Mar 2009 21:45:08 +0200

Qin,

> Firstly EAP protocol is a protocol happening between the peer and the
> EAP server. It is EAP server who perfom authentication to the peer,not
> the authenticator. 

Obviously. We all know that.

> After the authentication between the peer and EAP
> server is performed successfully, then the NAS is notified by the this
> EAp server to allow the peer get access. And EAP conversation between
> the peer and authenticator then starts.

This is a confusion. There is no such a thing as "EAP conversation between
peer and authenticator starting after the peer is authenticated by the EAP
server".

> Secondly, the EAP authentication with the Candidate Authenticator is
> actually related to the phase2 as described in RFC5247, i.e., security
> association between the peer and authenticator, I am not sure the EAP
> conversation between the peer and the authenticator is appropriate to
> be called as "EAP authentication".

I'm totally confused as to what this statement is about.

> > There are so many direct plain English indication of the differences
> > between the pre-auth and pro-active keying, I'm sure the
> > documents/authors/WG did not mean to contrast techniques by
> > emphasizing on the prepositions. That's apparent in the rest of the
> > document (see how EAP peer runs EAP through the target
> authenticator).
> [Qin]: For the Proactive keying, the EAP conversation between the peer
> and Candidate authenticator is not necesary, However in P-SA-AAA-CA,
> the EAp conversation between the peer and the candidate authenticator
> can be allowed to verfied the keying materials on the peer and the
> candiate authentiator if you require.

That'd be a radically new use of EAP. We are further deviating from EAP
here.

Alper