eap Mailing List: RE: Eap-discovery -- issues 280 and 281

[Adrangi, Farid (farid.adrangi]

Bernard,
Please see below where Farooq listed your issue 280 and marked each
sub-issue that was addressed (the way you wanted) in the latest draft.
If you think that "many changes" weren't made, please indicate which
sub-issues below weren't addressed.  Perhaps we are missing something
here -- thanks for your help.
BR,
Farid

> -----Original Message-----
> From: Bernard Aboba [mailto:aboba [at] internaut.com] 
> Sent: Thursday, December 23, 2004 9:10 AM
> To: Adrangi, Farid
> Cc: eap [at] frascone.com; jari.arkko [at] piuha.net; 
> Pasi.Eronen [at] nokia.com; Lortz, Victor
> Subject: Re: Eap-discovery -- issues 280 and 281
> 
> 
> I've marked Issue 281 as closed.  However, I've looked at 
> Issue 280, and
> it appears that many of the changes weren't made.



> -----Original Message-----
> From: Bari, Farooq [mailto:Farooq.Bari [at] cingular.com] 
> Sent: Wednesday, December 22, 2004 3:44 PM
> To: Adrangi, Farid; Bernard Aboba
> Cc: eap [at] frascone.com; jari.arkko [at] piuha.net; 
> Pasi.Eronen [at] nokia.com; Lortz, Victor
> Subject: RE: [eap] Eap-discovery -- issues 280 and 281
> 
> 
> Hi Bernard,
> 
> As a confirmation I have listed below issue 280 and 281 and 
> pointed out
> by using the term [DONE] for all the changes in the draft we did to
> resolve these two issues. I have gone through issue 280 and 281 and
> could not find anything that was not addressed by us in the new draft.
> Please advise asap what if anything from these issues that 
> remains to be
> fixed.
> 
> BR,
> 
> Farooq
> 
> ----------------------------------
> Issue 280: Nits on Identity Selection-05
> Submitter name: Bernard Aboba
> Submitter email address: aboba [at] internaut.com
> Date first submitted: 11/16/2004
> Reference: 
> Document: IDSEL-05
> Comment type: E
> Priority: S
> Section: Various
> Rationale/Explanation of issue
> 
> Abstract:
> 
> " This document defines a mechanism that allows an access network to
> provide identity selection hints to an EAP client. The purpose is to
> help the client in selecting the most appropriate identity and NAI
> decoration to use. This is especially useful when the access network
> does not have a direct roaming relationship with the client's home
> network, so that a mediating network, such as a roaming consortium or
> broker, is used."
> 
> ->
> 
> "The Extensible Authentication Protocol (EAP) is defined in RFC 3748. 
> This document defines a mechanism that allows an access network to
> provide identity selection hints to an EAP peer. 
> The purpose is to assist the EAP peer in selecting an appropriate 
> Network Access Identifier (NAI). This is especially useful when 
> the access network does not have a direct roaming relationship with 
> the peer's home network, so that a mediating network, such as a 
> roaming consortium or broker, is used."
> 
> [DONE]
> 
> Table of Contents
> 
> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
> 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
> 2. Implementation requirements . . . . . . . . . . . . . . . . . 3
> 2.1 Packet format . . . . . . . . . . . . . . . . . . . . . . 4
> 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
> 4. Security considerations . . . . . . . . . . . . . . . . . . . 5
> 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
> 6. Appendix (informative) - Delivery Options . . . . . . . . . . 6
> 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
> 7.1 Normative references . . . . . . . . . . . . . . . . . . . . 9
> 7.2 Informative references . . . . . . . . . . . . . . . . . . . 10
> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
> Intellectual Property and Copyright Statements . . . . . . . . 12
> 
> Please indent Section 7.1. and 7.2. Also Intellectual Property, 
> Disclaimer of Validity, Copyright, etc. are separate sections. 
> 
> 1. Introduction
> 
> "This document defines a mechanism that allows the access network to
> provide identity selection hints, and more specifically information
> about its roaming relationships, to an EAP peer."
> 
> ->
> 
> "The Extensible Authentication Protocol (EAP) is defined in 
> [RFC3748]. 
> This document defines a mechanism that allows the access network to
> provide identity selection hints, including information
> about its roaming relationships, to an EAP peer."
> 
> [DONE]
> 
> " In many roaming situations, an access network can have several
> roaming relationships, either with several home networks, or
> mediating networks such as roaming consortiums and brokers, or both."
> 
> -> 
> 
> " In many roaming situations, an access network can have several
> roaming relationships, either with several home networks, or with
> mediating networks such as roaming consortiums and brokers, or both."
> 
> [DONE]
> 
> " One possible application for this mechanism is to help in selecting
> what kind of NAI decoration [rfc2486bis] must be applied to allow
> proper routing of AAA messages to the home AAA server. If there are
> several possible mediating networks, the peer can choose which one to
> use. However, exactly how the selection is made is beyond the scope
> of this document. See [netsel-problem] for more detailed discussion
> about this problem space."
> 
> The terms NAI, NAI decoration and NAI realm are not defined in the
> document. 
> I think you need to define these terms or reference a definition
> somewhere
> else. Perhaps in a terminology section?
> 
> [DONE]
> 
> " The appendix in
> section 6 describes the delivery options that can be implemented by
> an access network to deliver identity hint information to an EAP
> peer."
> 
> -> 
> 
> " Appendix A describes the delivery options that can be implemented by
> an access network to deliver identity hint information to an EAP
> peer."
> 
> [DONE]
> 
> 
> Section 2
> 
> Delete the extra line break prior to Section 2.
> 
> [DONE]
> 
> Change "EAP Identity/Request" to "EAP-Request/Identity" and
> "EAP IdentityResponse" to "EAP-Response/Identity" everywhere in the
> document. 
> 
> [DONE]
> 
> " If after the EAP server sends an EAP Identity/Request containing an
> identity hint, the peer responds with an EAP Identity/Response
> containing an unacceptable NAI Realm, then the EAP server MAY respond
> immediately with an EAP Failure packet, or it MAY first send an
> EAP-Notification providing information on the reason for the failure."
> 
> ->
> 
> " If after the EAP server sends an EAP-Request/Identity containing an
> identity hint, the peer responds with an EAP-Response/Identity
> containing an unacceptable NAI realm, then the EAP server MAY respond
> immediately with an EAP Failure packet, or it MAY first send an
> EAP-Notification providing the reason for the failure."
> 
> [DONE]
> 
> " EAP does not support fragmentation for Identity/Request messages, so
> the size of identity hint information is limited by the link MTU.
> The exact limit depends on the lower layer in question, but it is at
> least 1020 octets."
> 
> ->
> 
> "As noted in [RFC3748], Section 3.1, the minimum EAP MTU size is 1020 
> octets. EAP does not support fragmentation of EAP-Request/Identity
> messages, so
> that the maximum length of the identity hint information is limited
> by the link MTU."
> 
> [DONE]
> 
> Section 2.1
> 
> "defines a "NAIRealms" attribute" -> "defines an NAIRealms attribute"
> 
> [DONE]
> 
> Section 4
> 
> " Identity hint information is delivered inside an EAP 
> Identity Request
> before the user authenticates to the network, and before the network
> is authenticated to the user. This information can be modified by an
> attacker. Therefore, it MUST be considered an unauthenticated hint."
> 
> -> 
> 
> " Identity hint information is delivered inside an 
> EAP-Request/Identity
> before the authentication conversation begins, and therefore can 
> be modified by an attacker. The NAIRealms attribute therefore MUST
> be treated as a hint by the peer. 
> 
> [DONE]
> 
> " Unauthenticated hints may result in peers inadvertently revealing
> other or additional identities than they intended to, leading to a
> privacy vulnerability. Note that in EAP, the identity the peer wants
> to use is in general carried in a cleartext message, so this is only
> a variation of an existing vulnerability. Method-specific identity
> protection is one of the ways that this vulnerability can be
> addressed.
> 
> Similarly, in a situation where the peer has multiple identities to
> choose from, an unauthenticated hint can lead to a situation where an
> attacker convinces the peer to choose an identifier that is bound to
> the weakest EAP method. To guard against this vulnerability, the use
> of as strong EAP methods as possible is recommended. Note that this
> vulnerability is similar to an existing vulnerability where link
> layers advertise network names (such as 802.11 SSIDs) without
> authenticating these advertisements either at all or only at the end
> of the authentication process.
> 
> In case the identity hint information is used to select a mediating
> network for NAI decoration, it should be noted that at least with
> some EAP methods, there is no way for the home network AAA server to
> verify that the mediating network used was actually the same one that
> the peer had requested."
> 
> ->
> 
> " Unauthenticated hints may result in peers inadvertently revealing
> additional identities, compromising privacy. Since the EAP-Response/
> Identity is sent in the clear, this vulnerability already exists. 
> This vulnerability can be addressed via method-specific identity
> exchanges.
> 
> Similarly, in a situation where the peer has multiple identities to
> choose from, an attacker can use a forged hint to convince the 
> peer to choose an identity bound to a weak EAP method. Requiring
> the use of strong EAP methods can protect against this. A similar
> issue already exists with respect to unprotected link layer
> advertisements such as 802.11 SSIDs. 
> 
> Where the identity hint is used to select a mediating
> network, with existing EAP methods there may not be a way for the 
> home AAA server to verify that the mediating network selected by
> the peer was actually used."
> 
> [DONE]
> 
> Proposed Resolution: Discuss
> Issue 281: Backward compatibility problem
> Submitter name: Bernard Aboba
> Submitter email address: aboba [at] internaut.com
> Date first submitted: 11/16/2004
> Reference: 
> Document: IDSEL-05
> Comment type: T
> Priority: S
> Section: 2.1
> Rationale/Explanation of issue
> I think that there is a problem with the ABNF defined in Section 2.1.
>     identity-request-data = [ displayable-string ]
>                               [ %x00 "NAIRealms=" realm-list  ]
>       displayable-string    = *OCTET
>       realm-list            = realm /
>                               ( realm-list ";" realm )
> Section 2.1 states: 
> "Some existing systems are known to use EAP Identity/Request 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."
> 
> Actually, existing implementations may send information such as the
> NAS-Identity
> *after* the NUL character. Requiring the NAIRealms list to be sent 
> first is therefore not backward compatible with existing
> implementations. 
> I'd suggest that you need to change the ABNF to enable the NAI-Realms
> attribute to be 
> separated from the NUL character by text other than the attribute
> separator 
> used by existing implementations. 
> [BA] Actually, I've rechecked the traces of existing implementations,
> and in
> the cases I've looked at there is no NUL character. So this may not be
> an
> issue after all.
> 
> Can vendors who send info in the EAP-Request/Identity verify 
> that a NUL
> character is never sent?
> [BA] 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.
> d. The comma is used as a field separator. 
> [Farid Adrangi] 
> 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=3D".  Does this make sense?  Or am I missing your point =
> here?
> [Bernard Aboba] 
> 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.
> [Farid Adrangi] 
> 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.  And also, I am not
> clear why the current grammar breaks interoperability with existing
> implementation, and why it is not simple enough!   Please 
> note that one
> 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=3D".  =20
> 
> 
> 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
> end.  =20
> 
> 2) Modify the grammar to allow the NAIRealms to be placed 
> anywhere after
> displayable message.
> 
> My preference is (1).  It would also be nice to know other people's
> opinion on this. 
> [Bernard Aboba] 
> > 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
> > end.
> 
> I think this part of the spec is in conflict with RFC 3748 
> Section 5.1:
> 
>       This field MAY contain a displayable message in the Request,
>       containing UTF-8 encoded ISO 10646 characters [RFC2279].  Where
>       the Request contains a null, only the portion of the field prior
>       to the null is displayed.
> 
> So RFC 3748 seems to imply that the "displayable string" is 
> the portion
> prior to the first null, not that portion prior to the last null.
> That's
> how current implementations operate anyway, and I don't think it's
> appropriate for this specification to modify that.
> 
> > 2) Modify the grammar to allow the NAIRealms to be placed anywhere
> after
> > displayable message.
> 
> I'd prefer this.  It's more consistent with RFC 3748, as well as
> existing
> implementations.
> [Jari Arkko] 
> >> 2) Modify the grammar to allow the NAIRealms to be placed 
> >>    anywhere after displayable message.
> >
> > I'd prefer this.  It's more consistent with RFC 3748, as well 
> > as existing implementations.
> 
> I would prefer #2 as well.
> 
> > identity-request-data = [ displayable-string ] %0x00 [ 
> Network-Info ]
> 
> > 
> > displayable-string    = *CHAR
> > 
> > Network-Info          = *OCTET ["," "NAIRealms=" realm-list "," ]
> *OCTET
> 
> The general approach is correct, but I'd prefer making the
> NAIRealms data start with either directly after the NUL character
> or after a comma -- not always with a comma. How about this:
> 
> Network-Info     =   "NAIRealms=" realm-list
> Network-Info     =/  1*OCTET ",NAIRealms=" realm-list
> Network-Info     =/  "NAIRealms=" realm-list "," 1*OCTET
> Network-Info     =/  1*OCTET ",NAIRealms=" realm-list "," 1*OCTET
> 
> Note that this still allows multiple %0x00's to be present
> at various places. For instance, the following would all be
> legal
> 
>      foo\0NAIRealms=snaap.com
>      bar\0NAIRealms=fryyp.com\0\0\0\0
>      foobar\0\0\0\0,NAIRealms=example.com
>      \0APQuality=0,NAIRealms=arkko.com
> 
> > realm-list            = realm /
> >                         ( realm-list ";" realm )
> > 
> > The "OCTET" and "CHAR" rules are defined in [RFC2234] and 
> the "realm"
> > rule is defined in [rfc2486bis].
> > 
> > A sample hex dump of an EAP-Request/Identity packet is shown below.
> > 
> >       01                        ; Code: Request
> >       00                        ; Identifier: 0
> >       00 43                     ; Length: 67 octets
> >       01                        ; Type: Identity
> >       48 65 6c 6c 6f 00 2C 4e   ;
> "Hello\0,NAIRealms=example.com;mnc014.
> >       41 49 52 65 61 6c 6d 73   ; mcc310.3gppnetwork.org,"
> >       3d 69 73 70 2e 65 78 61
> >       6d 70 6c 65 2e 63 6f 6d
> >       3b 6d 6e 63 30 31 34 2e
> >       6d 63 63 33 31 30 2e 33
> >       67 70 70 6e 65 74 77 6f
> >       72 6b 2e 6f 72 67 2C
> 
> Ok otherwise but I'd prefer getting rid of the "," after
> "\0".
> 
> > The Network-Info can contain NAIRealms list in addition to 
> proprietary
> > information. The proprietary information can be placed 
> before or after
> > NAIRealms list.  To extract NAIRelams list, an implementation can
> parse
> > the data after a NUL and look for "NAIRealms=" and then 
> check whether
> > the previous character was a comma.  Once "NAIRealms=" immediately
> > followed by a comma is found, the implementation can read the realms
> > until it encounters a comma character.
> 
> Slightly revised:
> 
>    The Network-Info can contain NAIRealms list in addition to
> proprietary
>    information. The proprietary information can be placed before or
> after
>    NAIRealms list.  To extract NAIRelams list, an 
> implementation either
>    finds the "NAIRealms=" immediately after the NUL or seeks 
> forward to
>    find ",NAIRealms" somewhere in the string. The realms data ends
> either
>    at first "," or at the end of the string, whichever comes first.
> Proposed Resolution: Accept
> 
> [DONE]
> 
> 
> -----Original Message-----
> From: eap-admin [at] frascone.com [mailto:eap-admin [at] frascone.com] On 
> Behalf
> Of Adrangi, Farid
> Sent: Wednesday, December 22, 2004 10:26 AM
> To: Bernard Aboba
> Cc: eap [at] frascone.com; jari.arkko [at] piuha.net; Pasi.Eronen [at] 
> nokia.com;
> Lortz, Victor
> Subject: [eap] Eap-discovery -- issues 280 and 281
> 
> Hi Bernard,
> Version -07
> (http://www.ietf.org/internet-drafts/draft-adrangi-eap-network
-discovery
-07.txt) includes resolutions for issues 280 and 281.  These issues have
not yet been closed in http://www.drizzle.com/~aboba/EAP/eapissues.html.
Please confirm the resolutions and close these issues so we can proceed
with this draft.  If you think the issues have not been completely
addressed in version -07, please let us know ASAP.   Your prompt
response is appreciated.
BR,
Farid
_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap