headers
Narayanan, Vidya | 1 Jun 2006 02:36

EAP Extensions (EAPExt) BoF Proposal Discussion


Folks,
We have set up a mailing list to discuss next steps on EAP keying and
the work that needs to be done there. We invite people to subscribe to
the EAPExt mailing list at
https://www1.ietf.org/mailman/listinfo/eapext. 

The following drafts and other material are intended to stimulate
initial discussion. 

http://www.ietf.org/internet-drafts/draft-vidya-eap-keying-gap-analysis-
00.txt
http://www.ietf.org/internet-drafts/draft-salowey-eap-emsk-deriv-00.txt
http://www.geocities.com/hellovidya/EAPExt_motivation.txt
http://www.geocities.com/hellovidya/EAPExt_charter.txt
http://www.geocities.com/hellovidya/EAPExt_11r_kh.pdf

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

Arhives: http://lists.frascone.com/pipermail/eap
Permalink | Reply | 0 comments |
headers
Jari Arkko | 1 Jun 2006 11:52

Re: I-D ACTION:draft-vanderveen-eap-sake-02.txt

Internet-Drafts <at> ietf.org wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
>	Title		: Extensible Authentication Protocol Method for Shared-secret Authentication and Key
Establishment (EAP-SAKE)
>	Author(s)	: M. Vanderveen, H. Soliman
>	Filename	: draft-vanderveen-eap-sake-02.txt
>	Pages		: 41
>	Date		: 2006-5-19
>	
>  
>
Michaela, I have looked over the new revision and
it seems that all issues raised in the expert review
of the method have been corrected. Thanks! The
result of the expert review is now positive.

I believe your intention was to submit this as
an individual submission via the RFC Editor.
These can be made by sending e-mail to
rfc-editor <at> rfc-editor.org once you have been
convinced that any other improvements or
enhancements that you might yourself want
have been put to the document. The RFC
Editor process involves IANA allocation, and
when the IANA asks, we will inform them that
the Expert Review status is OK.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Cao Zhen | 1 Jun 2006 12:42
Picon

Re: Questions for draft-barany-eap-gee-01

Hello, Lakshminath and Peter

Thanks for your reply,
>> These questions seem very 3GPP2 specific, so I will ask folks
>> knowledgeable in 3GPP2 to respond to you offline.
please allow me to ask by following IETF style.

What kind of service here means, network access (MVNO) or any others
(SIP)?

If in the case of MVNO, here NAS2 means only for network access?

Many Thanks,

Zhen

-----Original Message-----
From: Lakshminath Dondeti caozhen <at> infosec.pku.edu.cn
Sent: 2006-05-31
To: Cao Zhen; eap <at> frascone.com
Subject: Re: [eap] Questions for draft-barany-eap-gee-01

These questions seem very 3GPP2 specific, so I will ask folks 
knowledgeable in 3GPP2 to respond to you offline.

regards,
Lakshminath

At 07:15 PM 5/25/2006, Cao Zhen wrote:
>Hi Peter,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Pascal Urien | 1 Jun 2006 23:15
Picon

Identity Protection in EAP-TLS

Hi Everybody,

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Identity Protection within EAP-TLS
	Author(s)	: P. Urien, M. Badra
	Filename	: draft-urien-badra-eap-tls-identity-protection-00.txt
	Pages		: 7
	Date		: 2006-5-31
	
This document defines a mechanism providing EAP-TLS identity
protection.

It defines new TLS extension, in order to negotiate the symmetric
encryption algorithm that is used to encrypt or decrypt the client's
certificate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-urien-badra-eap-tls-identity-protection-00.txt

Pascal

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

Arhives: http://lists.frascone.com/pipermail/eap
Permalink | Reply | 2 comments |
headers
Bernard Aboba | 4 Jun 2006 01:43
Picon
Favicon

AD Review of EAP POTP


---------- Forwarded message ----------
Date: Wed, 31 May 2006 00:48:39 +0300
From: Jari Arkko <jari.arkko <at> piuha.net>
To: magnus <at> rsasecurity.com
Subject: AD review of EAP POTP

Magnus,

I have done my AD review on your document.

Overall, I was quite happy with the document -- its well
written and seems clear. Some comments below, however.

I would suggest that you will revise the
document where necessary and resubmit, at which time we
can initiate the actual processing, and also call the document
into the attention of the IETF community (e.g. EAP/EMU folks).

Russ: it would be great if you too could review this, or organize
a review in the secdir. The most interesting focus for the review
would be the crypto parts.

----

>Even though the authenticator in practice may function as a client
>with respect to the backend authentication server, relaying
>authentication credentials et cetera as needed, both servers are,
>unless explicitly mentioned, collectively denoted as "the EAP server"
>here.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Aboba | 4 Jun 2006 03:16
Picon
Favicon

Proposed Resolution to Issue 367: Key Scope and Server Authorization

The text of Issue 367 is enclosed below.  The proposed resolution is to 
change Section 2.2 to the text enclosed below, as well as to add a new 
Section 2.2.1, as follows:

2.2.  Peer and Authenticator Architecture

   This specification does not impose constraints on the architecture of
   the EAP authenticator or peer. Any of the authenticator architectures
   described in [RFC4118] can be used. As a result, lower layers need to
   identify EAP peers and authenticators unambiguously, without
   incorporating implicit assumptions about peer and authenticator
   architectures.

   For example, it is possible for multiple base stations and a
   "controller" (e.g. WLAN switch) to comprise a single EAP
   authenticator.  In such a situation, the "base station identity" is
   irrelevant to the EAP method conversation, except perhaps as an
   opaque blob to be used in Channel Bindings. Many base stations can
   share the same authenticator identity.  It should be understood that
   an EAP authenticator or peer:

   [a] may contain one or more physical or logical ports;
   [b] may advertise itself as one or more "virtual"
       authenticators or peers;
   [c] may utilize multiple CPUs;
   [d] may support clustering services for load balancing or failover.

   Both the EAP peer and authenticator may have more than one physical
   or logical port.  A peer may simultaneously access the network via
   multiple authenticators, or via multiple physical or logical ports on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Aboba | 4 Jun 2006 03:40
Picon
Favicon

Proposed Resolution to Issue 357: Channel Binding Definition

The text of Issue 357 is enclosed below.  The proposed resolution is to 
accept the definition proposed by Jari Arkko:

"Channel Binding

A secure mechanism for ensuring that a chosen set of channel
properties (such as endpoint identifiers) are agreed upon by the EAP
peer, authenticator and server."

------------------------------------------------------------------------------------------------
Issue 357: Channel Binding Definition
Submitter name: Vidya Narayanan
Submitter email address: vidyan <at> qualcomm.com
Date Submitted: May 1, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04227.html
Document: KEYING-12
Comment type: 'T'echnical
Priority: '1' Should fix
Section: 1.2
Rationale/Explanation of issue:
The document defines channel binding
as a communication within an EAP method - this seems a bit restrictive,
given that channel binding information could be carried out-of-band as
well. The only requirement is that the information be integrity
protected between the peer and server.

Requested change:
Change wording to:

"The communication of integrity-protected
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Aboba | 4 Jun 2006 04:40
Picon
Favicon

Proposed Resolution to Issue 365: Ambiguous Use of Identifier

The text of Issue 365 is enclosed below.   The proposed resolution is to 
rewrite Section 2.2.1 (now 2.2.2) as follows:

"2.2.2.  Authenticator and Peer Identification

   The EAP method conversation is between the EAP peer and server.
   The authenticator identity, if considered at all by the EAP method,
   is treated as an opaque blob for the purposes of Channel Bindings
   (see Section 5.12).  However, the authenticator identity is
   important in two other exchanges - the AAA protocol exchange
   and the Secure Association Protocol conversation.

   The AAA conversation is between the EAP authenticator and
   the backend authentication server.  From the point of view
   of the backend authentication server, EAP keying material
   and parameters are transported to the EAP authenticator
   identified by the NAS-Identifier attribute.  Since an
   EAP authenticator MUST NOT share EAP keying material or parameters
   with another party, if the EAP peer or backend authentication
   server detects use of EAP keying material and parameters outside
   the scope defined by the NAS-Identifier, the keying material MUST
   be considered compromised.

   The Secure Association Protocol  conversation is between the peer
   and the authenticator, and the authenticator and peer identities
   used within that exchange define the usage scope of the EAP
   keying material passed down to the lower layer.
   For lower layers which support key caching it is particularly
   important for the EAP peer, authenticator and backend server
   to have a consistent view of the usage scope of the transported
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bernard Aboba | 5 Jun 2006 02:27
Picon
Favicon

Proposed Resolution to Issue 356: Ciphersuite Independence

The text of Issue 356 is enclosed below.   The proposed resolution is to 
replace the first paragraph of Section 3.7 with the following:

3.7. Key Strength

As noted in Section 2.1, EAP lower layers determine TSKs in
different ways. Where EAP keying material is utilized in
the derivation, encryption or authentication of TSKs, it
is possible for EAP key generation to represent the weakest
link.

In order to ensure that EAP methods produce keying
material of an appropriate symmetric key strength,
it is RECOMMENDED that EAP methods utilizing public
key cryptography choose a public key that has a
cryptographic strength providing the required level
of attack resistance. This is typically provided by
configuring EAP methods, since there is
no coordination between the lower layer and EAP method
with respect to minimum required symmetric key strength."

------------------------------------------------------------------------------------------
Issue 356: Ciphersuite Independence
Submitter name: Joe Salowey
Submitter email address: jsalowey <at> cisco.com
Date Submitted: April 30, 2006
Reference: http://lists.frascone.com/pipermail/eap/msg04223.html
Document: KEYING-12
Comment type: 'E'ditorial
Priority: '2' May fix
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bernard Aboba | 5 Jun 2006 02:48
Picon
Favicon

Re: Proposed Resolution to Issue 365: Ambiguous Use of Identifier

Looking over the proposed resolution, I think we can make it moreclear that 
we are not talking about replacing endpoint addresses with names.  How about 
this?

"2.2.2. Authenticator and Peer Identification

The EAP method conversation is between the EAP peer and server. The
authenticator identity, if considered at all by the EAP method, is
treated as an opaque blob for the purposes of Channel Bindings (see
Section 5.12). However, the authenticator identity is important in
two other exchanges - the AAA protocol exchange and the Secure
Association Protocol conversation.

The AAA conversation is between the EAP authenticator and the backend
authentication server. From the point of view of the backend
authentication server, EAP keying material and parameters are
transported to the EAP authenticator identified by the NAS-Identifier
attribute. Since an EAP authenticator MUST NOT share EAP keying
material or parameters with another party, if the EAP peer or backend
authentication server detects use of EAP keying material and
parameters outside the scope defined by the NAS-Identifier, the
keying material MUST be considered compromised.

The Secure Association Protocol conversation is between the peer and
the authenticator. For lower layers which support key caching it
is particularly important for the EAP peer, authenticator and backend
server to have a consistent view of the usage scope of the transported
EAP keying material.  In order to enable this, it is RECOMMENDED
that the Secure Association Protocol explicitly communicate the
usage scope of the EAP keying material passed down to the lower
(Continue reading)

Permalink | Reply | 0 comments |

Gmane