Subject: [eap] Proposed resolution of issue 251

From: <[email-masked]>
Date: Tue, 10 Aug 2004 12:48:45 +0300

Hi,

To summarize the discussion about issue #251 at San Diego,
the conclusion seemed to be that

- The "canned" success/failure prohibited by RFC3748 
  means success/failure sent immediately after a 
  connection is established.

- The 1X-REV behavior of sending success/failure on 
  administrative change is not totally in line with this. 

- However, you could argue that those canned messages are not 
  really part of an EAP conversation, but just use EAPOL frame 
  type.

- Perhaps using something else would have been prettier, but     
  the current behavior doesn't seem to be that harmful either
  (e.g. if you disable the port, the client is not going to get
  access anyway), and it's too late to change it. 

- EAP peer state machine discards canned success/failure 
  (because "reqId == lastId" can't be true, since lastId 
  is NONE). Thus, no changes required there.

- EAP authenticator state machine does not explicitly mention
  that canned success/failure is prohibited. If desired, we 
  could add something like "Policy.getDecision MUST comply with 
  RFC3748 restrictions about canned Success and Failure messages."
  in author's 48 hours.

- Sending success/failure after an identity request/response 
  pair is allowed by RFC3748 (and is explicitly mentioned
  in an example). The peer can, of course, have a policy 
  requiring authentication of the server.

I didn't notice this at San Diego, but additionally it 
seems that:

- The current version of EAP peer state machine does not accept 
  a Success message after identity request (because decision is FAIL;
  this still worked in version -01 where decision could be also
  COND_SUCC). 

- We could add text saying that "The peer state machine assumes 
  that the peer's policy requires that an authentication method 
  is always run. That is, an EAP Success message immediately
  following an EAP Identity or Notification exchange is ignored."

- Or, we could add a constant AllowImmediateSuccess, and 
  change "decision = FAIL" to "if (AllowImmediateSuccess) 
  decision = COND_SUCC; else decision = FAIL;" in the 
  INITIALIZE state.

Comments? What should we do about the last item? 
(Personally, I'd prefer the first alternative, as we 
could add that at author's 48 hours.)

Best regards,
Pasi
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Aug 2004 12:56:21 +0300

>   requiring authentication of the server.

Agreed. Thanks for the summary.

>   decision = COND_SUCC; else decision = FAIL;" in the 

Oops. I would actually prefer the latter. (Not sure why
you think only the former can be done in AUTH48.)

--Jari

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Aug 2004 10:57:39 -0400

I prefer the latter approach (i.e., the one that uses
AllowImmediateSuccess), too.

Thanks,

Yoshihiro Ohba

---

From: John Vollbrecht <[email-masked]>
Date: Tue, 10 Aug 2004 11:37:45 -0400

A couple questions --

>   connection is established.
-- so not a success failure sent because of administrative changes

>   administrative change is not totally in line with this.
-- it does seem different.  so not specifically prohibited.

>   really part of an EAP conversation, but just use EAPOL frame
ok - this seems reasonable

>   access anyway), and it's too late to change it.
this doesn't seem to deal with the case where a port is taken down and up, 
sending a Success, and it may be in the middle of a conversation.

>   is NONE). Thus, no changes required there.
true - but this is not the administrative success/failure
>   RFC3748 restrictions about canned Success and Failure messages."
I think this is a good idea

> could add that at author's 48 hours.)
I also prefer the first alternative, but I think input from the list would 
be useful

- John

---

From: Mohamad Badra <[email-masked]>
Date: Tue, 10 Aug 2004 18:29:01 +0200

>For example, EAP, TLS, and krb5 are all authentication protocols.  They
>all allow authentication using a miriad of methods and ciphersuites.  Why
>use two or three stacked on top of each other when one is sufficient?
>IMHO, for simple, secure methods you only need one layer between the
>authentication protocol and the lower levels.  Sure, we could implement
>PSK over TLS over EAP, but why overcomplicate things?

Charles,

I can't see where we overcomplicated things and how the PSK-TLS requires an
independant API?
The RFC 2246 defines resumed handshake so that the session can be resumed if
it is still in the memory (cache). One TLS-PSK contribution requires to copy
the session to the disk instead of the cache. In OpenSSL, the two functions
to do that are defined and used:

1) PEM_write_SSL_SESSION(fp, session) to save session to the disk
2) PEM_read_SSL_SESSION(fp, NULL, NULL, NULL) reload from the disk

So where is the overcomplicated things in that; especially where TLS is used
with almost all EAP methods.

Badra

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 10 Aug 2004 16:28:34 -0400

Hi John,

Please see my comments in line.

> sending a Success, and it may be in the middle of a conversation.

I don't understand the case where an authenticator sends a Success in
the middle of a conversation in this case.  When a port on an IEEE
802.1X authenticator is taken down and up, isn't the IEEE 802.1X
authenticator state machine initialized with restarting the EAP state
machine?  

Yoshihiro Ohba

---

From: Jim Burns <[email-masked]>
Date: Tue, 10 Aug 2004 17:19:02 -0400

Hi Yoshiro,

You asked:
   When a port on an IEEE 802.1X authenticator is taken down and up, isn't the IEEE 802.1X
authenticator state machine initialized with restarting the EAP state machine?

The answer is:
Yes. The 802.1X authenticator state machine shall restart when the port
cycles (802.1X portEnabled variable will toggle) and it will set
eapRestart to cause EAP state machine to restart as well. In fact, the
802.1X state machine will wait for the EAP state machine to reset
eapRestart before continuing.

Jim B.

---

From: John Vollbrecht <[email-masked]>
Date: Tue, 10 Aug 2004 18:43:48 -0400

Hi Yoshi - see comments in line
--On Tuesday, August 10, 2004 4:28 PM -0400 Yoshihiro Ohba 
<[email-masked]> wrote:

> > this doesn't seem to deal with the case where a port is taken down and
> > up,  sending a Success, and it may be in the middle of a conversation.
>

In the case where a port may be administratively set to "Force Auth" (sec 
8.2.4.11 of 802-1X-Rev-d11)  a port will send a canned Success message.

The scenario I imagine is that two ports are doing EAP, and the 
authenticator is taken down and its portControl variable is set to 
ForceAuthorized.  It then sends a Success.

If the Station state machine is is a state where it will accept a Success, 
it may not notice that the authenticator has gone down and back up.  It 
will accept the Success and connect to the net.  Thus the Peer could come 
up to a authenticator which to which it has not authenticated.

This is clearly an unlikely situation.   It is unlikely to happen at all. 
If it does happen it is unlikely that the AP it connects to will not be the 
one that just went down and came up.

In my mind it is something to note but not requiring change.  I just want 
to be sure everyone agrees.

John

> > I also prefer the first alternative, but I think input from the list
> > would  be useful
> >
> > - John
> >
> > > Best regards,
> > > Pasi
> > >

---

From: "T. Charles Clancy" <[email-masked]>
Date: Fri, 13 Aug 2004 03:09:53 -0400 (EDT)

> The RFC 2246 defines resumed handshake so that the session can be
> resumed if it is still in the memory (cache). One TLS-PSK contribution
> requires to copy the session to the disk instead of the cache.

True, but the TLS resume still requires 2 round trips, and as much
computation as a full reauthentication.  In the PSK case, I don't think
the TLS resume is all that useful.

> So where is the overcomplicated things in that; especially where TLS is
> used with almost all EAP methods.

Just because other methods use it doesn't mean it's the right thing to do
in the PSK case.  TLS was designed for public-key environments, and I
agree it's probably the right thing to use for public-key authentication.

We obviously have a difference of opinion, and aren't going to change each
others' mind.  The pros and cons can be argued from both directions.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 13 Aug 2004 11:15:43 +0200

T. Charles Clancy wrote:
>True, but the TLS resume still requires 2 round trips, 

1.5 RT :)

>and as much computation as a full reauthentication. 

Correct me if I'm wrong, in the full reauthentication, we authenticate using certificates which is not the case of TLS-PSK.

>in the PSK case.

I meant that the TLS-PSK allows us to call back a full TLS sessions...
Further, almost all methods use TLS to establish the channel. Where the TLS-PSK will be used instead of full TLS, these methods will be improved a lot (processing time, message flow, MitM attack, etc) and this without decrease the security level. So I think that it is the right think in our case when the majority of EAP methods use TLS.

>TLS was designed for public-key environments, and I

That is true. But in TLS, the abbreviated handshake is already specified and no text (in TLS1.0) prohibits us from using it for long duration. Again, this may not decrease the security level.
Anyway, the TLS-PSK will soon move forward to proposed through the TLS WG. 

>others' mind.  The pros and cons can be argued from both directions.

Maybe it is the holiday time, but would like to hear comments from people on the mailing list.

-- 

Mohamad Badra
ENST-Paris
Dept. Computer Sciences and Networks

---

From: "T. Charles Clancy" <[email-masked]>
Date: Mon, 16 Aug 2004 01:45:03 -0400 (EDT)

> > True, but the TLS resume still requires 2 round trips,

Due to the challenge-response nature of EAP, we have to round up. :)

> Correct me if I'm wrong, in the full reauthentication, we authenticate
> using certificates which is not the case of TLS-PSK.

I was comparing a TLS-PSK-Resume to a TLS-PSK-FullAuth with the server
certificate disabled (in order to accurately compare it to PAX).  Both
require 2RT (or 1.5 in theory) and basically the same cryptographic
operations.  Certificates are not used in either case.

>
> > Just because other methods use it doesn't mean it's the right thing to
> > do in the PSK case.
>
> Further, almost all methods use TLS to establish the channel. Where the
> TLS-PSK will be used instead of full TLS, these methods will be improved
> a lot (processing time, message flow, MitM attack, etc) and this without
> decrease the security level. So I think that it is the right think in
> our case when the majority of EAP methods use TLS.

So you could authenticate using some other EAP method running over TLS,
and then provision a PSK from that TLS session's master secret?  Then you
could use TLS-PSK for future authentications?  I can see how this might be
useful, for example a company might allow clients to authenticate via
MS-CHAPv2 over PEAP, and provision a PSK from that TLS session.  Keys can
be provisioned using existing AD credentials.

While this seems like a neat idea, "there are too many buttons to push."
Even if completely implemented, I suspect getting it to work properly in a
practical environment would be far from simple.

---

From: "Joseph Salowey" <[email-masked]>
Date: Mon, 16 Aug 2004 10:25:38 -0700

I'm not opposed to other methods, but I think methods based on existing key
exchange frameworks such as TLS and IKEv2 are valuable because they build on
widely implemented (at least in the case of TLS) and reviewed standards.
TLS is probably the most widely deployed one and it has been extended to
support multiple mechanisms including certificates, kerberos and pre-shared
key.  I would prefer to focus on the standard frameworks first. 

Joe

[email-masked] wrote:
>> Just because other methods use it doesn't mean it's the right thing 
>> to do in the PSK case.
> 
> Further, almost all methods use TLS to establish the channel. Where 
> the TLS-PSK will be used instead of full TLS, these methods will be 
> improved a lot (processing time, message flow, MitM attack, etc) and 
> this without decrease the security level. So I think that it is the 
> right think in our case when the majority of EAP methods use TLS.
> 
> That is true. But in TLS, the abbreviated handshake is already 
> specified and no text (in TLS1.0) prohibits us from using it for long 
> duration. Again, this may not decrease the security level. Anyway, the 
> TLS-PSK will soon move forward to proposed through the TLS WG.
> 
>> We obviously have a difference of opinion, and aren't going to change 
>> each others' mind.  The pros and cons can be argued from both 
>> directions.
> 
> [email-masked] http://mail.frascone.com/mailman/listinfo/eap