Liaison statement from IEEE 802.11u on "EAP emergency method"

The liaison statement from the IEEE 802.11u on "EAP emergency Method" is
now available at https://datatracker.ietf.org/public/liaisons.cgi.  

One of the documents on requirements appears to be missing on the
liaison page (the requirements presentation).  I will work on getting
this updated. 

Joe

Conclusion of "last look": EAP Network Selection Problem Statement Document

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

I-D ACTION:draft-ietf-eap-netsel-problem-08.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Extensible Authentication Protocol Working Group of the IETF.

	Title		: Network Discovery and Selection Problem
	Author(s)	: J. Arkko, et al.
	Filename	: draft-ietf-eap-netsel-problem-08.txt
	Pages		: 40
	Date		: 2007-6-5
	
When multiple access networks are available, users may have
   difficulty in selecting which network to connect to, and how to
   authenticate with that network.  This document defines the network
   discovery and selection problem, dividing it into multiple sub-
   problems.  Some constraints on potential solutions are outlined, and
   the limitations of several solutions (including existing ones) are
   discussed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-08.txt

To remove yourself from the I-D Announcement list, send a message to 
i-d-announce-request <at> ietf.org 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-ietf-eap-netsel-problem-08.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:
	mailserv <at> ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-eap-netsel-problem-08.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.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Identifier Wrap-around

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Re: Identifier Wrap-around

Mahesh Dantakale wrote:
> 
> The Identifier is one ocetet field and unique for each EAP-Request.
> What happens, if the number of Requests exceeds 255 in an
> EAP-Conversation?
> 
> Will the Identifier wrap-aroud to zero after 255?  If yes, then
> wouldnt EAP regard this as duplicate packet, as the Identifier field
> in new Request packet is less than the previous Request packet ?

The identifier doesn't have to be unique for each EAP-Request:

   In order to avoid confusion between new Requests and
   retransmissions, the Identifier value chosen for each new Request
   need only be different from the previous Request, but need not be
   unique within the conversation.

and it's not necessary even an increasing sequence:

   EAP does not require the Identifier to be monotonically increasing,

So identifier sequence 0,1,0,1,0,1 would be equally acceptable
as 253,254,255,0,1,2 ...

Best regards,
Pasi
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Re: Identifier Wrap-around

Indeed.
You may even be suprised to discover that some tunneling protocols 
don't even use the same ID on one side of the tunnel that was supplied 
on the other side.

I discovered this issue when we attempted a crypto binding including 
the ID and it failed in certain circumstances.

Dave.

----Original Message----
From: Pasi.Eronen <at> nokia.com
Date: Jun 8, 2007 7:13 
To: <mahesh.dantakale <at> hotmail.com>, <eap <at> frascone.com>
Subj: Re: [eap] Identifier Wrap-around

Mahesh Dantakale wrote:
> 
> The Identifier is one ocetet field and unique for each EAP-Request.
> What happens, if the number of Requests exceeds 255 in an
> EAP-Conversation?
> 
> Will the Identifier wrap-aroud to zero after 255?  If yes, then
> wouldnt EAP regard this as duplicate packet, as the Identifier field
> in new Request packet is less than the previous Request packet ?

The identifier doesn't have to be unique for each EAP-Request:

   In order to avoid confusion between new Requests and
   retransmissions, the Identifier value chosen for each new Request
   need only be different from the previous Request, but need not be
   unique within the conversation.

and it's not necessary even an increasing sequence:

   EAP does not require the Identifier to be monotonically increasing,

So identifier sequence 0,1,0,1,0,1 would be equally acceptable
as 253,254,255,0,1,2 ...

Best regards,
Pasi

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Fwd: I-D ACTION:draft-nir-tls-eap-00.txt

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap

Server Authentication in EAp-TLS/802.11i

Hello,

When EAP-TLS is in effect how is the 802.11i client
expected to authenticate the Server certificate? The
client does not access to "internet". I thought one
way is for the client it is a safe TLS - Server and go
ahead and finish the key generation ... and once the
"internet" access is available - to validate the
server certificate. But this does not work if it is a
closed network - please help. Your insight into this
matter is appreciated sincerely. I read the most
recent draft regarding EAP-TLS  I did not see any
recommendation being made.
Regards
Abhi

      ____________________________________________________________________________________
Shape Yahoo! in your own image.  Join our Network Research Panel today!  
http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/eap

Arhives: http://lists.frascone.com/pipermail/eap