Subject: RE: [eap] RE: FW: I-D ACTION:draft-adrangi-eap-network-discovery-11.txt

From: "Adrangi, Farid" <[email-masked]>
Date: Mon, 4 Apr 2005 21:52:34 -0700

Hi Glen,
The report was sent to IETF -- will send you a copy if I find it in my
archives.  I will let IESG interpret the report and decide whether not
it should be mentioned in the IESG applicability note!  So, Please
discard my e-mail. Brian made it clear to me that it is IESG's
responsibility to determine the need for the applicability note and its
content!
BR,
Farid

> -----Original Message-----
> From: Glen Zorn (gwz) [mailto:[email-masked]] 
> Sent: Monday, April 04, 2005 7:56 PM
> To: Adrangi, Farid; 'Bernard Aboba'
> Cc: [email-masked]; [email-masked]; 'Jari Arkko'; 
> [email-masked]; [email-masked]; 'Eugene Chang'
> Subject: RE: [eap] RE: FW: I-D 
> ACTION:draft-adrangi-eap-network-discovery-11.txt
> 
> 
> Adrangi, Farid <mailto:[email-masked]> supposedly
> scribbled:
> 
> > I don't recall talking about an IESG note on the mailing list! 
> > Anyhow, as to your strawman IESG note, it should be noted that the
> > draft was reviewed and accepted by IEEE 802.11 
> 
> I'm not sure what this means.  Does it mean accepted as in "whatever
> you want to do" or as in adopted as correct?  
> 
> > (WIEN? - 
> 
> Last time I checked, WIEN was just a study group (the 802.11
> equivalent of a BOF).  Has this changed?
> 
> > the WG has
> > sent an official review report to IETF.  
> 
> Did we receive a liaison from the 802.11 Working Group or a note
> from the WIEN Study Group?  There's a big difference...
> 
> > And also, I would remove the
> > last part of the note: "and it is not recommended for
> implementation
> > outside of 3GPP."  I think we should state the facts about the
> > solution 
> 
> Unless the draft has changed drastically for the better, the facts
> were pretty slim, certainly too slim for it to be called a
> "solution" (without volumes of supporting documentation).
> 
> > and let the implementer decided whether or not the solution
> > is suitable for their deployments outside 3GPP. 
> 
> If and when the RFC Editor becomes a vanity publisher for 3GPP, I
> will agree; until then, however, I think that we at least a right
> (if not a duty) to publish applicability statements that express the
> opinions of the IETF (regardless if those opinions coincide with
> those of the author(s)).
> 
> 
> > BR,      
> > Farid
> > 
> >> -----Original Message-----
> >> From: Bernard Aboba [mailto:[email-masked]]
> >> Sent: Saturday, April 02, 2005 5:08 PM
> >> To: Adrangi, Farid
> >> Cc: [email-masked]; [email-masked]; Jari Arkko; [email-masked];
> >> [email-masked]; [email-masked]; Eugene Chang
> >> Subject: RE: [eap] RE: FW: I-D
> >> ACTION:draft-adrangi-eap-network-discovery-11.txt
> >> 
> >> 
> >> I think we were talking about an IESG note in addition to
> material in
> >> the applicability statement, no?
> >> 
> >> For example, EAP SIM contains the following note:
> >> 
> >> IESG Note
> >> 
> >>    The EAP-SIM protocol was developed by 3GPP.  The documentation
> of
> >>    EAP-SIM is provided as information to the Internet community.
> >>    While the EAP WG has verified that EAP-SIM is compatible with
> EAP
> >>    as defined in RFC 3748, no other review has been done,
> including
> >>    validation of the security claims.
> >> 
> >> Here is a potential strawman note for the EAP Network Discovery
> >> document: 
> >> 
> >>    EAP Network Discovery was developed by 3GPP.  Documentation is
> >>    provided as information to the Internet community.  While the
> >>    EAP WG has verified that EAP Network Discovery is compatible
> with
> >>    EAP as defined in RFC 3748, no other review has been done,
> >>    including investigation of potential security issues.  There
> is
> >>    work underway in IEEE 802.11 which may provide similar
> >>    functionality, enabling an EAP peer to determine network
> >>    availability prior to handoff.  As a result, the approach
> >>    described in this document may be superceded by future
> standards,
> >>    and it is not recommended for implementation outside of 3GPP.
> >> 
> >> 
> >> On Thu, 31 Mar 2005, Adrangi, Farid wrote:
> >> 
> >>> Sorry, just to be clear, the link below contains the update we
> made
> >>> to the applicability section in -011 version, based on Glen's
> >>> comment on -10 version in the last WG meeting.
> >>> Thanks,
> >>> Farid
> >>> 
> >>> 
> >>>> -----Original Message-----
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of Adrangi, Farid Sent: Thursday, March 31, 2005 9:33 AM
> >>>> To: Bernard Aboba
> >>>> Cc: [email-masked]; [email-masked]; Jari Arkko; [email-masked];
> >>>> [email-masked]; [email-masked]; Eugene Chang
> >>>> Subject: [eap] RE: FW: I-D
> >>>> ACTION:draft-adrangi-eap-network-discovery-11.txt
> >>>> 
> >>>> 
> >>>> I think so! The applicability section was introduced in version
> >>>> -08. Since then we have made several updates to that section
> based
> >>>> on comments from Glen Zorn, Eugene Chang, Jari Arkko, and
> >>>> yourself.  The updates to this section was made based on Glen
> >>>> Zorn's comment during the last IETF meeting (relayed to me by
> >>>> Pasi) -- the exact change is captured in
> >>>> http://mng.ctgisp.com/IETF/EAP/Network%20Selection/issues-1.tx 
> >>>> t  -- see
> >>>> #3.  Please let me know if you have any questions.
> >>>> BR,
> >>>> Farid
> >>>> 
> >>>> 
> >>>> 
> >>>>> -----Original Message-----
> >>>>> From: Bernard Aboba [mailto:[email-masked]]
> >>>>> Sent: Thursday, March 31, 2005 9:08 AM
> >>>>> To: Adrangi, Farid
> >>>>> Cc: [email-masked]; [email-masked]; Jari Arkko;
> [email-masked];
> >>>>> [email-masked] Subject: Re: FW: I-D
> >>>> ACTION:draft-adrangi-eap-network-discovery-11.txt
> >>>>> 
> >>>>> 
> >>>>> As I recall there was a discussion relating to the appropriate
> >>>>> applicability statement that should be attached to this
> document.
> >>>>> 
> >>>>> Have we come to agreement on what the applicability statement
> >>>>> should be? 
> >>>>> 
> >>>>> On Mon, 28 Mar 2005, Adrangi, Farid wrote:
> >>>>> 
> >>>>>> Hi Everyone,
> >>>>>> In this version, we have done some editorial fixes through
> out
> >>>>>> the document and addressed issues brought up during IESG
> review.
> >>>>>> ** Editorial changes are summarized in
> >>>>>> 
> >>>>> http://mng.ctgisp.com/IETF/EAP/Network%20Selection/Editorial_c
> >>>>> hanges.txt
> >>>>>> ** List of issues with their resolutions are summarized in
> >>>>>> 
> >> http://mng.ctgisp.com/IETF/EAP/Network%20Selection/issues-1.txt
> >>>>>> Thanks,
> >>>>>> Farid
> >>>>>> 
> >>>>>>> -----Original Message-----
> >>>>>>> From: [email-masked]
> >>>>>>> [mailto:[email-masked]] On Behalf Of
> >>>>>>> [email-masked] Sent: Monday, March 28, 2005 8:04
> AM
> >>>>>>> To: [email-masked]
> >>>>>>> Subject: I-D
> >> ACTION:draft-adrangi-eap-network-discovery-11.txt
> >>>>>>> 
> >>>>>>> 
> >>>>>>> A New Internet-Draft is available from the on-line
> >>>>>>> Internet-Drafts directories.
> >>>>>>> 
> >>>>>>> 
> >>>>>>> 	Title		: Identity selection hints for
> >>>>>>> Extensible Authentication
> >>>>>>> 			  Protocol (EAP)
> >>>>>>> 	Author(s)	: F. Adrangi, et al.
> >>>>>>> 	Filename	:
> >>>> draft-adrangi-eap-network-discovery-11.txt
> >>>>>>> 	Pages		: 13
> >>>>>>> 	Date		: 2005-3-25
> >>>>>>> 
> >>>>>>> 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) when there is
> no
> >>>>>>>    direct roaming relationship between the access network
> and
> >>>>>>>    the peer's home network.  In this case, authentication is
> >>>>>>>    typically accomplished via a mediating network such as a
> >>>>>>> roaming consortium or broker. 
> >>>>>>> 
> >>>>>>> A URL for this Internet-Draft is:
> >>>>>>> 
> >> http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-
> >>>>>> discovery-11.txt
> >>>>>> 
> >>>>>> To remove yourself from the I-D Announcement list, send a
> >>>>>> message to [email-masked] with the word
> >>>>>> unsubscribe in the body of the message. You can also visit
> >>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce
> >>>>>> to change your subscription settings.
> >>>>>> 
> >>>>>> 
> >>>>>> Internet-Drafts are also available by anonymous FTP. Login
> with
> >>>>>> the username "anonymous" and a password of your e-mail
> address.
> >>>>>> After logging in, type "cd internet-drafts" and then
> >>>>>> 	"get draft-adrangi-eap-network-discovery-11.txt".
> >>>>>> 
> >>>>>> A list of Internet-Drafts directories can be found in
> >>>>>> http://www.ietf.org/shadow.html or
> >>>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >>>>>> 
> >>>>>> 
> >>>>>> Internet-Drafts can also be obtained by e-mail.
> >>>>>> 
> >>>>>> Send a message to:
> >>>>>> 	[email-masked].
> >>>>>> In the body type:
> >>>>>> 	"FILE
> >>>>>> /internet-drafts/draft-adrangi-eap-network-discovery-11.txt".
> >>>>>> 
> >>>>>> NOTE:	The mail server at ietf.org can return the document
> in
> >>>>>> 	MIME-encoded form by using the "mpack" utility.
> >>  To use this
> >>>>>> 	feature, insert the command "ENCODING mime" before the
> "FILE"
> >>>>>> 	command.  To decode the response(s), you will 
> need "munpack"
> or
> >>>>>> 	a MIME-compliant mail reader.  Different 
> MIME-compliant mail
> >>>>>> 	readers exhibit different behavior, especially 
> when dealing
> with
> >>>>>> 	"multipart" MIME messages (i.e. documents which 
> have been
> split
> >>>>>> 	up into multiple messages), so check your local
> documentation on
> >>>>>> 	how to manipulate these messages.
> >>>>>> 
> >>>>>> 
> >>>>>> Below is the data which will enable a MIME compliant mail
> reader
> >>>>>> implementation to automatically retrieve the ASCII version of
> >>>>>> the Internet-Draft. 
> >>>>>> 
> >>>>> 
> >>>> _______________________________________________
> >>>> eap mailing list
> >>>> [email-masked]
> >>>> http://mail.frascone.com/mailman/listinfo/eap
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by
> simply
>   listening to John Coltrane? -- Henry Gabriel
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Glen Zorn (gwz)" <[email-masked]>
Date: Tue, 5 Apr 2005 10:12:25 -0700

scribbled:

> Hi Glen,
> The report was sent to IETF -- will send you a copy if I find it
in
> my archives.  

OK, cool.  I must admit to some confusion on this issue: a cursory
search of IETF liaisons @
https://datatracker.ietf.org/public/liaisons.cgi didn't turn up
anything; furthermore, since Bernard is listed as the IETF liaison
to IEEE 802, I would think that he would be aware of said document.
I'm not doubting your veracity in the least: it's just a bit weird.

> I will let IESG interpret the report and decide whether
> not it should be mentioned in the IESG applicability note!  So,
> Please discard my e-mail. Brian made it clear to me that it is
IESG's
> responsibility to determine the need for the applicability note
and
> its content! BR,    
from
>> the WIEN Study Group?  There's a big difference...
>> 
implementation
>> were pretty slim, certainly too slim for it to be called a
"solution"
>> (without volumes of supporting documentation).
>> 
>>> and let the implementer decided whether or not the solution is
>>> suitable for their deployments outside 3GPP.
>> 
material
>>>> in the applicability statement, no?
>>>> 
>>>>    of EAP-SIM is provided as information to the Internet
community.
>>>>    including validation of the security claims.
>>>> 
>>>>    with EAP as defined in RFC 3748, no other review has been
done,
is
>>>>    standards, and it is not recommended for implementation
outside
>>>> of 3GPP. 
>>>>> made to the applicability section in -011 version, based on
Glen's
>>>>>> To: Bernard Aboba Cc: [email-masked]; [email-masked]; Jari
>>>>>> Arkko; [email-masked]; [email-masked];
[email-masked];
>>>>>> Eugene Chang Subject: [eap] RE: FW: I-D
>>>>>> based on comments from Glen Zorn, Eugene Chang, Jari Arkko,
and
>>>>>> Pasi) -- the exact change is captured in
http://mng.ctgisp.com/IETF/EAP/Network%20Selection/issues-1.tx t
>>>>>> -- see #3.  Please let me know if you have any questions.
>>>>>> BR,
>>>>>> Farid
>>>>>> 
>>>>>> 
>>>>>> 
[email-masked];
out
>>>>>>>> review. ** Editorial changes are summarized in
>>>>>>>> 
>>>>>>>
AM
>>>>>>>>> To: [email-masked] Subject: I-D
RFC
>>>>>>>>>    EAP peer.  The purpose is to assist the EAP peer in
>>>>>>>>>    selecting an appropriate Network Access Identifier
(NAI)
>>>>>>>>>    when there is no direct roaming relationship between
the
>>>>>>>>>    access network and the peer's home network.  In this
case,
>>>>>>>>>    authentication is typically accomplished via a
mediating
>>>>>>>>> network such as a roaming consortium or broker. 
>>>>>>>>> 
with
address.
in
>>>>>>>> 	feature, insert the command "ENCODING mime" before
the "FILE"
MIME-compliant mail
>>>>>>>> 	up into multiple messages), so check your local
documentation
>>>>>>>> 	on how to manipulate these messages.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> reader implementation to automatically retrieve the ASCII
>>>>>>>> version of the Internet-Draft. 
>>>>>>>> 
>>>>>>> 
simply

Hope this helps,

~gwz

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 5 Apr 2005 17:44:19 -0700 (PDT)

> I'm not doubting your veracity in the least: it's just a bit weird.

I've dug through my email and IEEE 802 document archive.

It appears that some of the liaison communications were not cc:'d to
[email-masked], which may explain why they didn't end up on the
liaisons page.  In any case, they are now available on the web at the
following links:

http://www.drizzle.com/~aboba/IEEE/stuart1.txt
http://www.drizzle.com/~aboba/IEEE/11-04-1109-01-0000-input-to-ietf-from-wien-ad-hoc-september-2004.doc
http://www.drizzle.com/~aboba/IEEE/11-04-xxxx-00-0000-input-to-ietf-from-WIEN-Ad-Hoc-November-2004.doc

Below find the text of the Network Discovery review (the September 2004
document).  Note the reference to potential future standards work in
802.11 (now chartered as 802.11u).

---------------------------------------------------------------------------------------------
From: Stuart J.Kerry, Chair IEEE 802.11 Working Group
To:  Harald Alvestrand, IETF Chair
CC:  Bernard Aboba, IETF to IEEE 802 liaison

Title: Review IETF EAP draft documents, September 2004
Purpose: Review of IETF draft-adrangi-eap-network-discovery-03

Dear Harald,

As mentioned in our earlier liaison, the IEEE 802.11 Wireless Interworking
with External Networks Study Group (WIEN SG) is investigating the changes
needed to the IEEE 802.11 specification to support interworking with
external non-IEEE 802.11 networks.

Attached are comments regarding the document "Identity selection hints for
Extensible Authentication Protocol (EAP)"
(draft-adrangi-eap-network-discovery-03), for IETF consideration.

The draft provides an effective solution for network identity selection at
the EAP level, minimizing the impact on the existing EAP messages, with
very little impact on access points and associated infrastructure.  It is
noted that this solution applies to EAP enabled hotspot deployments only;
it does not apply to those that utilize the web based access methods, such
as the WiFi Alliance Universal Access Method (UAM), mode of
authentication.

Within option 3, network hints are only received when the authentication
attempt cannot be successfully routed to the home network.  This
information may be useful even for a successful attempt, providing similar
functionality to options 1 and 2.

The draft is a reasonable approach for a solution using EAP.  IEEE 802.11
intends to investigate network identity selection solutions that occur at
an earlier stage, prior to association and the subsequent use of EAP.  It
appears that the EAP solution can co-exist with future IEEE 802.11 link
layer solutions.

Potential characteristics of the IEEE 802.11 link layer solution are:

"	It is applicable to both the UAM and IEEE 802.11i based solutions
"	An EAP exchange is not required to receive network information
"	Association attempts with invalid networks are avoided
"	Passive network selection is possible
"	It reduces the message overhead for roaming

We look forward to continued dialogue on network discovery topics.

For IETF reference, ANSI/IEEE Std 802.11 -1999 (2003 Reaffirmation)
edition as amended by IEEE Std 802.11g-2003 and IEEE Std. 802.11h-2003 is
the current version of the IEEE 802.11 Standard.

Please contact Stuart J.Kerry, IEEE 802.11 Working Group Chair together
with Stephen McCann, IEEE 802.11 WIEN SG chair and Dorothy Stanley, IEEE
802.11/IETF Liaison with any questions, and to discuss further IETF
follow-up.

Best Regards,

Stuart J. Kerry

Contact information:
Stuart J Kerry
[email-masked]
+1 408 474 7356

Stephen McCann
[email-masked]
+44 1794 833341

Dorothy Stanley
[email-masked]
+1 630 979 1572