Subject: RE: [eap] Re: Issue 251

From: "Congdon, Paul T (ProCurve)" <[email-masked]>
Date: Tue, 27 Jul 2004 11:26:52 -0700

The 'canned' messages are only send when the 802.1X port is
administratively forced authorized or unauthorized.   This is basically
when management turns off 802.1X and forces the port open or closed.
These message are also discussed in the text.

Paul 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Nick Petroni
> Sent: Tuesday, July 27, 2004 8:13 AM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [eap] Re: Issue 251
> 
> > 802.1X "canned" messages are encapsulated EAP packets.  So 
> an 802.1X 
> > packet containing an EAP Success is expressly forbidden under RFC 
> > 3748, even though I think it is still mentioned in IEEE 
> 802.1X-2004.  
> > Similarly, our discussion of whether "canned" EAP Failure 
> is illegal 
> > also applies to "canned" 802.1X packets.
> Ok, this was the source of my confusion. I guess I assumed 
> that since they were in another standard they were going to 
> be allowed for backwards compatibility or some other legacy 
> argument. They are, indeed, still in the latest version, 
> which was another source of my confusion. They are in the 
> 802.1X SM diagrams, not just the text.
> 
> Thanks,
> nick
> 
> >
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Nick Petroni <[email-masked]>
Date: Tue, 27 Jul 2004 14:38:22 -0400 (EDT)

Paul,

Thanks for jumping in. The way I understand these messages is, I think, as
you have described. Basically, if 802.1X is off, but the Peer comes in and
sends an EAPoL Start, then the authenticator will immediately respond with
an EAP Success or an EAP Fail without doing a run of the Identity method
or an actual authentication method. Is this correct? If so, I *think* this
would violate RFC3748 per Bernard's and Jari's comments. Any thoughts,
corrections, or clarifications to my assessment?

Thanks,
nick

Nick L. Petroni, Jr.
Graduate Student, Computer Science
Maryland Information Systems Security Lab
University of Maryland
http://www.cs.umd.edu/~npetroni

---

From: Jim Burns <[email-masked]>
Date: Tue, 27 Jul 2004 18:16:56 -0400

Hi folks,
 I was just reading up on 'Success/Fail' packets in rfc3748 
 and found two things:
 
 1.  I do not believe that the .1XRev machine's behavior in 
 the FORCE_AUTH and FORCE_UNAUTH will cause any 
 interoperability issues.  RFC
 3748 is clear what to do:  "By default, an EAP peer MUST 
 silently discard a "canned" Success packet (a Success packet 
 sent immediately upon connection). "  [second paragraph, page 
 23, rfc3748].  This is good since I believe it is too late to make
 changes on 802.1XRev.
 
 2.  I do have a question...later on in the same section in 
 RFC 3748 there is this text:
 "However, an authenticator MAY omit having the peer 
 authenticate to it in situations where limited access is 
 offered (e.g., guest access). In this case, the authenticator 
 MUST send a Success packet. "  [ second paragraph, page 24, 
 rfc3748]  Now...I probably missed something...but this seems 
 to contradict the sentence I indicated in #1 above.  It seems 
 to say that the authenticator *can* omit the authentication 
 to allow guest access and it must send a success 
 packet...which according to #1 
 would appear as a 'canned success' and be discarded by the peer.   If 
 this were true then you could say that FORCE_AUTH and 
 FORCE_UNAUTH states (in the 1XRev) implement this behavior 
 locally in the NAS.
 
 I am concerned about this contradiction though.  Did I miss 
 something in the doc?  
 Thanks,
 Jim B.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Jul 2004 10:55:54 -0400

Hi Jim,

> FORCE_UNAUTH states (in the 1XRev) implement this behavior 

I think the text points to a case where the authenticator can sends
Success message in response to Identity Response from the peer.  So
it would not appear as a canned success.

Yoshihiro Ohba

---

From: Nick Petroni <[email-masked]>
Date: Wed, 28 Jul 2004 11:00:30 -0400 (EDT)

Yoshihiro,

> it would not appear as a canned success.

Even if this were not canned, it seems to still violate the rule that a
higher-layer authentication method must be run. Furthermore, Identity is
always optional so what works with Identity should work without (IMHO).
Perhaps I am missing some subtleties.

Best,
nick

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 28 Jul 2004 11:18:47 -0400

> Perhaps I am missing some subtleties.

You are right.  I should have said "Success message in response to
Identity Response in a tunneling method".

Yoshihiro Ohba