headers
Bernard Aboba | 1 Dec 2004 04:25

Re: Issue 281: Backward compatibility problem

I have now captured a trace of an Access Point using a NULL character
within the EAP-Request/Identity.  The dump below is in hex, the decode is
in decimal.  A JPG screen capture (from Airopeek) is available at:
http://www.drizzle.com/~aboba/EAP/eapreq.jpg

            01 37 00 36 01 00 6E 65 74 77 6F 72      .7.6..networ
6B 69 64 3D 4D 53 46 54 57 4C 41 4E 2C 6E 61 73  kid=MSFTWLAN,nas
69 64 3D 43 55 53 52 45 44 30 34 30 43 33 34 32  id=CUSRED040C342
30 2C 70 6F 72 74 69 64 3D 30 00 00 00 00        0,portid=0

Here is a decode of the above EAP packet:

Code: 1 (Request, one octet)
Identifier: 55 (one octet)
Length: 54 (two octets)
Type: 1 (Identity, one octet)
Type-Data:
NULL (one octet)
networkid=MSFTWLAN,nasid=CUSRED040C3420,portid=0
NULLs (4 octets)

There are a number of issues brought up by this trace:

a. Existing implementations place data after the NULL character
within the EAP-Request/Identity packet.
b. There can be multiple NULL characters in the
EAP-Request/Identity packet.  In this particular trace, there is one at
the beginning of the Type-Data field, and four NULLs at the end.
c. Existing access points place the networkid string first in the
packet, with the nasid and portid strings second and third.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mohamad Badra | 1 Dec 2004 18:03
Picon
Picon

Re: new methods drafts revisions

Hello,

Due to some typing errors, you may see the new revision of EAP Double 
TLS at http://www.ietf.org/internet-drafts/draft-badra-eap-double-tls-02.txt

Comments are welcom...

Best regards,
Badra

Jari Arkko wrote:

>
> Three new I-D revisions just came out from the
> secretariat:
>
> http://www.ietf.org/internet-drafts/draft-badra-eap-double-tls-01.txt
> http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-14.txt
> http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-15.txt
>
> _______________________________________________
> eap mailing list
> eap <at> frascone.com
> http://mail.frascone.com/mailman/listinfo/eap
>
>
Permalink | Reply | 0 comments |
headers
Adrangi, Farid | 1 Dec 2004 20:54
Picon
Favicon

RE: Re: Issue 281: Backward compatibility problem

Section 2.1 says:
"
   Some existing systems are known to use EAP-Request/Identity messages
   to send proprietary information to the peer.  This proprietary
   information is considered to be part of the displayable-string in the
   ABNF shown above.  In other words, the NUL character followed by the
   NAIRealms list MUST be placed at the end.
"

Please note the last sentence.  This means that the client can always
start at the end of the string and extract realms until it encounters a
"\0NAIRealms=".  Does this make sense?  Or am I missing your point here?
BR,
Farid

> -----Original Message-----
> From: eap-admin <at> frascone.com [mailto:eap-admin <at> frascone.com] 
> On Behalf Of Bernard Aboba
> Sent: Tuesday, November 30, 2004 7:25 PM
> To: eap <at> frascone.com
> Subject: [eap] Re: Issue 281: Backward compatibility problem
> 
> 
> I have now captured a trace of an Access Point using a NULL character
> within the EAP-Request/Identity.  The dump below is in hex, 
> the decode is
> in decimal.  A JPG screen capture (from Airopeek) is available at:
> http://www.drizzle.com/~aboba/EAP/eapreq.jpg
> 
>             01 37 00 36 01 00 6E 65 74 77 6F 72      .7.6..networ
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernard Aboba | 2 Dec 2004 04:40

RE: Re: Issue 281: Backward compatibility problem

> Section 2.1 says:
> "
>    Some existing systems are known to use EAP-Request/Identity messages
>    to send proprietary information to the peer.  This proprietary
>    information is considered to be part of the displayable-string in the
>    ABNF shown above.  In other words, the NUL character followed by the
>    NAIRealms list MUST be placed at the end.
> "
>
> Please note the last sentence.  This means that the client can always
> start at the end of the string and extract realms until it encounters a
> "\0NAIRealms=".  Does this make sense?  Or am I missing your point here?
> BR,
> Farid

I think you're proposing that a NULL be used as a separator.  Given
current practice, I'm not sure why this is necessary.  Is there a reason
why an implementation couldn't just parse the data after a NULL and look
for "NAIRealms=" and then check whether the previous character was a NULL
or a comma?  This seems simple enough, and it would be interoperable with
existing implementations.
Permalink | Reply | 0 comments |
headers
Adrangi, Farid | 2 Dec 2004 20:08
Picon
Favicon

RE: Re: Issue 281: Backward compatibility problem

Bernard, all

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba <at> internaut.com] 
> Sent: Wednesday, December 01, 2004 7:40 PM
> To: Adrangi, Farid
> Cc: eap <at> frascone.com
> Subject: RE: [eap] Re: Issue 281: Backward compatibility problem
> 
> 
> > Section 2.1 says:
> > "
> >    Some existing systems are known to use 
> EAP-Request/Identity messages
> >    to send proprietary information to the peer.  This proprietary
> >    information is considered to be part of the 
> displayable-string in the
> >    ABNF shown above.  In other words, the NUL character 
> followed by the
> >    NAIRealms list MUST be placed at the end.
> > "
> >
> > Please note the last sentence.  This means that the client 
> can always
> > start at the end of the string and extract realms until it 
> encounters a
> > "\0NAIRealms=".  Does this make sense?  Or am I missing 
> your point here?
> > BR,
> > Farid
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernard Aboba | 3 Dec 2004 08:37

RE: Re: Issue 281: Backward compatibility problem

> I agree with you that the current restriction of placing NAIRealms at
> the end is not necessary.  At the same time, I am not clear what
> practical benefit your suggested grammar brings.

The "suggested grammar" is already in use, so this isn't a
greenfield design.  Unless there is a good reason, why are we
changing the separator from a comma to a NULL character?  It seems quite
unusual to use the NULL character this way.

> advantage of the current grammar is that it provides an unambiguous way
> to handle the case where the proprietary data for some reason includes
> the string "\0NAIRealms=".

To my knowledge, no existing implementation utilizes the "NAIRealms"
string, so I'm not sure why an ambiguity would exist, except perhaps
that the existing "networkid" string already serves a similar function.
However, since this is typically used to advertise a flat name such as an
SSID rather than an FQDN, I don't think this overlaps with the proposed
"NAIRealms" functionality.

> Anyhow, going forward, I see two options:
>
> 1) Leave the ABNF as it is, and make the following clarification
> (enclosed in **) to the last paragraph in 2.1:
>
> Some existing systems are known to use EAP-Request/Identity messages to
> send proprietary information to the peer.  This proprietary information
> is considered to be part of the displayable-string *(which can contain
> any octets including NULs)* in the ABNF shown above.  In other words,
> the NUL character followed by the NAIRealms list MUST be placed at the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jouni Malinen | 4 Dec 2004 18:28
Picon
Picon

draft-ietf-eap-statemachine-05.txt and Identifier in EAP-Success

The Peer State Machine in draft-ietf-eap-statemachine-05.txt requires
that reqId == lastId when processing EAP-Success packet. However, I do
not see such requirement in RFC 3748. In addition, most (if not all)
existing RADIUS servers seem to implement EAP in a way that Identifier
in EAP-Success is actually incremented by one from the last EAP-Request.

draft-ietf-eap-statemachine-05.txt state machines for EAP authenticator
are indeed not incrementing Identifier for EAP-Success, but again, this
is not specified in RFC 3748. The only requirement for Identifier in
RFC 3748 seems to be that each EAP-Request is sent with different
Identifier than the previous EAP-Request. As far as I can tell, this
leaves it open to the implementation to decide which Identifier is used
in EAP-Success.

Should the (reqId == lastId) requirement be removed from the peer state
machine?

--

-- 
Jouni Malinen                                            PGP id EFC895FA
Permalink | Reply | 2 comments |
headers
Nick Petroni | 5 Dec 2004 01:59
Picon
Favicon

Re: draft-ietf-eap-statemachine-05.txt and Identifier in EAP-Success

Jouni,

This question revisits one from November 2003. The original diagrams did
not include it, but Joe Salowey (correctly, I think) pointed out that this
check was missing from the Peer diagram. Here is Joe's original mail:

http://mail.frascone.com/pipermail/public/eap/2003-November/001869.html

Take a look at his fifth point. There were a couple of follow-up threads,
the most notable here:

http://mail.frascone.com/pipermail/eap/2003-December/001987.html
http://mail.frascone.com/pipermail/eap/2003-December/001993.html
http://mail.frascone.com/pipermail/eap/2003-December/001998.html
http://mail.frascone.com/pipermail/eap/2003-December/002004.html

I remember running to my set of sniffs and for the first time realizing
the Success identifier was the same as the last Response identifier. I know
this was true for FreeRadius at the time, I assume it still is.

Finally, from RFC3748 here is some text from section 4.1. Note that it
says that the identifier is changed on *new Requests* and should match the
value of "the currently outstanding Request". If implementations do not
work this way, we will need to revisit this conversation. I know of at
least one other thing that will break in the diagrams if this statement is
removed.

Thanks,
nick
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jouni Malinen | 5 Dec 2004 03:43
Picon
Picon

Re: draft-ietf-eap-statemachine-05.txt and Identifier in EAP-Success

On Sat, Dec 04, 2004 at 07:59:10PM -0500, Nick Petroni wrote:

> I remember running to my set of sniffs and for the first time realizing
> the Success identifier was the same as the last Response identifier. I know
> this was true for FreeRadius at the time, I assume it still is.

I implemented the peer statemachine first with the verification. After
finding out that this does not interoperate with many RADIUS servers, I
had to remove this verification.. In other words, I cannot implement the
current statemachine draft as-is without causing major interoperability
issues.

Based on the source code comment about this, I seem to have noticed this
first when testing against IAS. I did some quick testing with couple of
RADIUS servers:

FreeRADIUS: same Id
Radiator: same Id
Meetinghouse Aegis: lastId + 1
Microsoft IAS: lastId + 1

> Finally, from RFC3748 here is some text from section 4.1. Note that it
> says that the identifier is changed on *new Requests* and should match the
> value of "the currently outstanding Request". If implementations do not
> work this way, we will need to revisit this conversation. I know of at
> least one other thing that will break in the diagrams if this statement is
> removed.

Section 4.1 is about Requests and Responses, it does not cover
EAP-Success. However, now that I looked again more closely, there is
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Aboba | 5 Dec 2004 19:23

Re: draft-ietf-eap-statemachine-05.txt and Identifier in EAP-Success

> Based on the source code comment about this, I seem to have noticed this
> first when testing against IAS. I did some quick testing with couple of
> RADIUS servers:
>
> FreeRADIUS: same Id
> Radiator: same Id
> Meetinghouse Aegis: lastId + 1
> Microsoft IAS: lastId + 1
>
> In other words, there are existing EAP authenticators that do not match
> the behavior defined in RFC 3748 and draft-ietf-eap-statemachine-05.txt.
> RFC 2284 seemed to have the same text, so this is not even a new
> requirement.
>
> It looks like draft-ietf-eap-statemachine-05.txt is correct on this
> part. However, this is not going to help with the interoperability
> issue. I don't see any security issues with skipping this test and as
> such, I will leave the workaround in my implementation. Adding some kind
> of note about this issue in the draft could be useful, though.

I'd be ok with a note, but since this is a MUST in RFC 3748, the note
shouldn't imply that existing behavior is correct.  Not requiring an
Identifier match does make it somewhat easier to spoof EAP-Failure
or Success messages, so it seems like there are some security
implications.

One of the reasons for completing work on RFC 3748 and the State Machine
document was to enable the development of conformance tests.  Hopefully
once the draft is published we will have more testing and some of these
issues will be resolved.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane