Subject: [eap] Fwd: I-D ACTION:draft-arkko-eap-service-identity-auth-01.txt

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Oct 2004 19:08:48 +0300

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Title		: Authenticated Service Identities for the Extensible Authentication Protocol (EAP)
> 	Author(s)	: J. Arkko, P. Eronen
> 	Filename	: draft-arkko-eap-service-identity-auth-01.txt
> 	Pages		: 21
> 	Date		: 2004-10-27
> 	
>    EAP is usually used in an arrangement where the actual service (such
>    as a wireless LAN access point) is separated from the authentication
>    server.  However, EAP itself does not have a concept of a service
>    identity or its parameters, and thus the client usually does not
>    authenticate any information about the service itself, even when a
>    mutually authenticating EAP method is used.  This document specifies
>    a backward compatible extension to popular EAP methods for
>    authenticating service related information, such as the identity and
>    type of the offered service.  A common parameter name space is
>    created in order to ensure that the same kinds of identifiers can be
>    authenticated independent of the choice of the EAP authentication
>    method.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-arkko-eap-service-identity-auth-01.txt
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Oct 2004 19:42:47 +0300

You may ask what has changed from the -00 version that was
discussed in the previous meeting. The main changes are:

- Hopefully a better explanation of what can be achieved
   through (1) what we call "channel binding" i.e. just ensuring
   that the three parties agree on the parameters or (2)
   additionally also authenticating this information. The
   former can be achieved without any configuration effort.
   The latter requires that someone -- maybe the auth server
   admin -- has explicitly stated that a particular parameter
   value is OK for a particular NAS.

   Can people take a look and say if the new explanation
   is clear to them?

- A significant simplification by providing only a server->
   client communication, and having the client be responsible
   for the verification.

- Reduction of the proposed parameter sets to something
   which we believe could easily be agreed upon in the
   near term. The rest could be pursued as additions in
   separate drafts.

--Jari