| RE: Eap-discovery -- issues 280 and 281 | <– Date –> <– Thread –> |
From: Bari, Farooq (Farooq.Bari cingular.com)
|
|
| Date: Wed, 22 Dec 2004 18:44:24 -0500 (EST) | |
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
-
Eap-discovery -- issues 280 and 281 Adrangi, Farid, December 22 2004
- Re: Eap-discovery -- issues 280 and 281 Bernard Aboba, December 23 2004
- RE: Eap-discovery -- issues 280 and 281 Bari, Farooq, December 22 2004
- RE: Eap-discovery -- issues 280 and 281 Adrangi, Farid, December 23 2004
- RE: Re: Eap-discovery -- issues 280 and 281 Bari, Farooq, December 23 2004
Results generated by Tiger Technologies using MHonArc.