From root@core3.amsl.com Mon Jul 6 11:15:02 2009 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0F2AD3A680A; Mon, 6 Jul 2009 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090706181502.0F2AD3A680A@core3.amsl.com> Date: Mon, 6 Jul 2009 11:15:01 -0700 (PDT) Cc: emu@ietf.org Subject: [Emu] I-D Action:draft-ietf-emu-eaptunnel-req-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : Requirements for a Tunnel Based EAP Method Author(s) : K. Hoeper, et al. Filename : draft-ietf-emu-eaptunnel-req-03.txt Pages : 24 Date : 2009-07-06 This memo defines the requirements for a tunnel-based Extensible Authentication Protocol (EAP) Method. This method will use Transport Layer Security (TLS) to establish a secure tunnel. The tunnel will provide support for password authentication, EAP authentication and the transport of additional data for other purposes. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-eaptunnel-req-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-emu-eaptunnel-req-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-06111230.I-D@ietf.org> --NextPart-- From jsalowey@cisco.com Mon Jul 6 11:28:45 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63FE23A6D5E for ; Mon, 6 Jul 2009 11:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swykz56J7Ttx for ; Mon, 6 Jul 2009 11:28:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 7351A3A6BA1 for ; Mon, 6 Jul 2009 11:28:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,358,1243814400"; d="scan'208";a="338538136" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 06 Jul 2009 18:27:51 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n66IRpEu029622 for ; Mon, 6 Jul 2009 11:27:51 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n66IRpiI006116 for ; Mon, 6 Jul 2009 18:27:51 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 11:27:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 6 Jul 2009 11:27:50 -0700 Message-ID: In-Reply-To: <20090706181502.0F2AD3A680A@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] I-D Action:draft-ietf-emu-eaptunnel-req-03.txt Thread-Index: Acn+ZdKALEaGbgvXT32j3vKiJ5pFQwAATlJQ References: <20090706181502.0F2AD3A680A@core3.amsl.com> From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 06 Jul 2009 18:27:51.0098 (UTC) FILETIME=[785961A0:01C9FE67] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1677; t=1246904871; x=1247768871; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20I-D=20Action=3Adraft-ietf-emu-e aptunnel-req-03.txt |Sender:=20; bh=CM/M3/Usp146CDDvFi5wrpTRG+FW7Y64Mr9u2f+4rvk=; b=CKN/P/4b+HWLe7EFSVbraVRp3gGIClxw6s6RfaEM5ccc+eQ0pMPWnTqBFi SU6TSie7SsuqvE4XdArpjeCrJ934jj1tMNL6HAIEz0XhfDGm3Vs6cN/ACKDo BqlRbc2zNE; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Emu] I-D Action:draft-ietf-emu-eaptunnel-req-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2009 18:28:45 -0000 I believe this revision addresses all outstanding comments, this should be ready for the IESG. Please review and indicate if the document is ready or if there are outstanding issues. =20 Thanks, Joe > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Internet-Drafts@ietf.org > Sent: Monday, July 06, 2009 11:15 AM > To: i-d-announce@ietf.org > Cc: emu@ietf.org > Subject: [Emu] I-D Action:draft-ietf-emu-eaptunnel-req-03.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the EAP Method Update Working=20 > Group of the IETF. >=20 >=20 > Title : Requirements for a Tunnel Based EAP Method > Author(s) : K. Hoeper, et al. > Filename : draft-ietf-emu-eaptunnel-req-03.txt > Pages : 24 > Date : 2009-07-06 >=20 > This memo defines the requirements for a tunnel-based=20 > Extensible Authentication Protocol (EAP) Method. This method=20 > will use Transport Layer Security (TLS) to establish a secure=20 > tunnel. The tunnel will provide support for password=20 > authentication, EAP authentication and the transport of=20 > additional data for other purposes. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-emu-eaptunnel-r > eq-03.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 From bernard_aboba@hotmail.com Wed Jul 8 16:50:06 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BAF83A6AAB for ; Wed, 8 Jul 2009 16:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ZSGmqPTklj4 for ; Wed, 8 Jul 2009 16:50:03 -0700 (PDT) Received: from blu0-omc3-s11.blu0.hotmail.com (blu0-omc3-s11.blu0.hotmail.com [65.55.116.86]) by core3.amsl.com (Postfix) with ESMTP id 5EAD53A686C for ; Wed, 8 Jul 2009 16:50:03 -0700 (PDT) Received: from BLU137-W19 ([65.55.116.74]) by blu0-omc3-s11.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 16:50:30 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_f268a121-4824-4059-baa2-b5e1e6e1f6b3_" X-Originating-IP: [131.107.0.83] From: Bernard Aboba To: Date: Wed, 8 Jul 2009 16:50:30 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jul 2009 23:50:30.0158 (UTC) FILETIME=[E01302E0:01CA0026] Subject: [Emu] Review of draft-ietf-emu-eaptunnel-req X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2009 23:50:06 -0000 --_f268a121-4824-4059-baa2-b5e1e6e1f6b3_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-emu-eaptunnel-req-03 =20 Here is my review of -03. There are still quite a few issues in this document=2C including vague or unnecessary requirements. As a result=2C the document isn't ready for the IESG yet. =20 Section 2 =20 " Because this specification is an informational specification (not able to directly use [RFC2119])=2C" =20 Since a large number of Informational RFCs reference RFC 2119 and use normative language=2C this statement seems odd. Perhaps what it is trying to say is that the terms don't mean the same thing in this document as they do in RFC 2119? If that is the case=2C language such as that from RFC 2989 Section 1.1 might make sense: =20 Please note that the requirements specified in this document are to be used in evaluating protocol submissions. As such=2C the requirements language refers to capabilities of these protocols=3B the protocol documents will specify whether these features are required=2C recommended=2C or optional. For example=2C requiring that a protocol support confidentiality is NOT the same thing as requiring that all protocol traffic be encrypted. A protocol submission is not compliant if it fails to satisfy one or more of the MUST or MUST NOT requirements for the capabilities that it implements. A protocol submission that satisfies all the MUST=2C MUST NOT=2C SHOULD and SHOULD NOT requirements for its capabilities is said to be "unconditionally compliant"=3B one that satisfies all the MUST and MUST NOT requirements but not all the SHOULD or SHOULD NOT requirements for its protocols is said to be "conditionally compliant." =20 As it is=2C the MUST=2C MUST NOT=2C SHOULD=2C SHOULD NOT=2C etc. definition= s are confusing.=20 =20 Section 3.1 Password Authentication =20 " Many legacy systems only support user authentication with passwords. Some of these systems require transport of the actual username and password to the authentication server. The tunnel method MUST support=20 this use case." =20 As currently worded=2C this statement is somewhat vague. =20 Is this statement implying that a tunnel method must support password-only authentication (e.g. no certificates)? If so=2C is there a requiremnent to support weak passwords or just pre-shared keys?=20 Would a tunnel method utilizing a server certificate to create a tunnel=2C and doing password authentication within the tunnel meet this requirement? What about a tunnel method utilizing a pre-shared key ciphersuite?=20 =20 " However=2C it MUST NOT expose the username and password to parties in the communication path between the peer and the EAP Server and it MUST provide protection against man-in-the-middle and dictionary attacks." =20 Does this requirement apply to provisioning or just to ongoing password authentication?=20 =20 Section 3.2 =20 " In particular=2C when weak methods are used=2C security policies enforcing that such methods can only be executed inside a tunnel but never outside one are required to mitigate the attack." =20 The requirement that methods only be executed within a tunnel is necessary even for strong methods=2C if crypto-binding isn't used. =20 =20 " On the other hand=2C a technical solution (so-called cryptographic bindings) can be used whenever the inner method is not susceptible to attacks outside a tunnel and derives keying material." =20 Cryptographic binding can be used whenever the inner method generates keys. If this isn't used=2C then even methods not susceptible to attack=20 outside the tunnel should be prohibited from use outside the tunnel=2C or else MiTM attacks would still be feasible. =20 Section 3.3 =20 " Several circumstances are best addressed by using chained EAP methods. For example=2C it may be desirable to authenticate the user and also authenticate the device that he or she is using." This requirement can be met by support for cryptographic binding=2C without chaining of EAP methods. For example=2C the combination of TLS and=20 an inner method can support user/device auth. Given that=2C why is support for chained methods a must=2C and not device/user auth support?=20 =20 Section 3.4 =20 " When performing an EAP authentication=2C the peer may want to protect its identity=2C only disclosing its identity to a trusted backend authentication server. This helps to maintain the privacy of the peer's identity." =20 Within tunneled authentication=2C there are a number of identities=20 involved. This includes the identity included in the EAP-Request/Identity= =2C identities used in TLS (subject and subjectAltName fields)=2C and identities used in the inner EAP method. To which identities does this requirement apply? =20 Section 3.5 =20 " When wireless VOIP service is provided=2C some regulations require any user to be able to gain access to the network to make an emergency telephone call." =20 Which regulations are being referred to? In a number of places=2C support for anonymous authentication is actually being removed=2C not added:=20 http://www.ietf.org/mail-archive/web/ecrit/current/msg06378.html =20 Section 4.1.1 =20 " The tunnel method MUST meet all the MUST and SHOULD requirements relevant to EAP methods contained in the EAP Key Management Framework [RFC5247] or its successor. The tunnel method MUST include MSK and EMSK generation. This will enable the tunnel method to properly fit into the EAP key management framework=2C maintaining all of the security properties and guarantees of that framework." =20 The primary aspects of [RFC5247] that apply to EAP methods is the generation of the Peer-Id=2C Server-Id and Session-Id. Why not just spell out those requirements specifically?=20 =20 " The tunnel method MUST meet the SHOULD and MUST requirements pertinent to EAP method contained in Section 3 of RFC 4962 [RFC4962]. This includes: cryptographic algorithm independence=3B strong=2C fresh session keys=3B replay detection=3B keying material confidentiality and integrity=3B confirm cipher suite selection=3B and uniquely named keys." =20 The key naming requirement is handled by generation of the Session-Id=2C so it needn't be mentioned specifically.=20 =20 With respect to some of these issues=2C NIST 800-120 provides more detailed and specific requirements. =20 =20 Section 4.1.2 =20 " Several existing tunnel methods are already in widespread usage: EAP- FAST [RFC4851]=2C EAP-TTLS [RFC5281]=2C and PEAP." =20 The definitive reference for the PEAP protocol is: http://msdn.microsoft.com/en-us/library/cc238354(PROT.10).aspx =20 Section 4.2.1 =20 " The tunnel based method MUST support TLS version 1.2 [RFC5246] and SHOULD support TLS version 1.0 [RFC2246] and version 1.1 [RFC4346] to enable the possibility of backwards compatibility with existing deployments." =20 I am not sure how to interpret this requirement. Is it sufficient for a proposal to enable negotiation of TLS 1.2 between a peer and server that support it? Or does the protocol actually have to require that both the peer and server implement TLS 1.2? If the former=2C is the requirement really just properly supporting TLS version negotiation?=20 =20 Section 4.2.1.1.2 =20 "See Part 1 of the NIST Recommendation for Key Management [NIST SP 800-57] for a discussion of the relative strengths of common algorithms." =20 Why not reference the NIST SP 800-120 requirements here?=20 =20 Section 4.2.1.1.3 =20 " A tunnel method MUST provide unidirectional authentication from authentication server to EAP peer or mutual authentication between authentication server and EAP peer." =20 Is this really an or? For example=2C would a tunnel method that only supports undirectional authentication satisfy the requirement?=20 =20 "o One-way key derivation o Cryptographically separated keys. o Cryptographically separated entities.=20 o Identity binding o Context binding o Key lifetime o Mutual implicit key authentication o Key freshness" =20 Given that this document assumes a TLS-based tunnel method=2C the text on requirements can be made considerably more specific and actionable based on TLS properties and the specific requirements of NIST 800-120. =20 As it stands=2C a number of these requirements either don't apply to=20 EAP methods at all (e.g. context binding=2C key lifetime) but rather to oth= er elements of the system=2C or are automatically provided by TLS (e.g. key freshness=2C Identity binding). =20 =20 So these requirements need to be made actionable and specific. The ones that don't apply to the problem at hand (e.g. TLS-based tunnel euth) should= be removed.=20 =20 Section 4.2.1.3 =20 " In order to meet the requirements in this document TLS extensions MAY be used. For example=2C TLS extensions may be useful in providing certificate revocation information via the TLS OCSP extension (thus meeting the requirement in Section 4.5.1.3)." =20 Why is it necessary to include optional requirements in this document? Presumably the selection will only be influenced by MUST and SHOULD requirements=2C right?=20 =20 Section 4.2.1.4 =20 " A tunnel protocol MUST support peer privacy. This requires that the username and other attributes associated with the peer are not transmitted in the clear or to an unauthenticated=2C unauthorized party. If applicable=2C the peer certificate is sent confidentially (i.e. encrypted)." =20 Does a username of "anonymous" need to be encrypted? Or does this requirement only apply to the tunnel method-specific identities? =20 Is there an issue with transmission of dientities to authenticated and authorized parties (e.g. the NAS)? In some regulatory jurisdictions this is also a concern. =20 Section 4.2.3 =20 "If modification of this information can cause vulnerabilities=2C the tunnel method MUST provide protection against modification of this data."=20 =20 This seems a bit vague. Why not just require secure confirmation of the protocol version and/or type code=2C either implicitly or explicitly?=20 =20 Section 4.3.3 =20 " The payload MUST support marking of mandatory and optional attributes=2C as well as an attribute used for rejecting mandatory attributes." =20 Why is it necessary for mandatory and optional attributes to be explicitly marked? Is it be sufficient for the attributes to be divided into standardized and vendor-specific spaces=2C with the latter optional?=20 =20 Section 4.3.6 =20 " The payload MAY provide a standard attribute format that supports international strings. This attribute format MUST support encoding strings in UTF-8 [RFC3629] format. Any strings sent by the server intended for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference." =20 If UTF-8 is supported=2C is it necessary to also mark the language?=20 Why is language negotiation a SHOULD?=20 =20 EAP methods such as Identity & Notification don't support this.=20 =20 Section 4.5 =20 "These typically require the password in its original text form in order to authenticate the peer=2C hence they require the peer to send the clear text user name and password to the EAP server." =20 One of the issues with support for cleartext passwords are the potential attacks against the AAA backend (e.g. User-Password attribute) in split authentication scenarios. Is it worth calling this out?=20 =20 Section 4.5.2 =20 " The password authentication exchange MUST support user names and passwords in international languages. It MUST support encoding of user name and password strings in UTF-8 [RFC3629] format. Any strings sent by the server during the password exchange and intended for display to the user MUST be sent in UTF-8 format and SHOULD be able to be marked with language information and adapted to the user's language preference. " Why is it useful to mark usernames and passwords with language information on the wire?=20 =20 Section 4.5.3 =20 " The password authentication exchange MUST support additional associated meta-data which can be used to indicate whether the authentication is for a user or a machine. This allows the EAP server and peer to request and negotiate authentication specifically for a user or machine. This is useful in the case of multiple inner authentications where the user and machine both need to be authenticated. " Why is it necessary to support meta-data to indicate whether authentication is for a user or machine? Few authentication protocols support this today and don't seem to miss it. For example=2C does Kerberos or PKI distinguish explicitly between user and machine credentials?=20 =20 Section 4.6.2 =20 " The tunnel method MUST support the chaining of multiple EAP methods. The tunnel method MUST allow for the communication of intermediate result and verification of compound binding between executed inner methods when chained methods are employed. "=20 =20 Given that the basic use case (machine + user auth) doesn't require chaining of EAP methods=2C why is this a MUST?=20 =20 Section 4.6.5 =20 " The tunnel method MUST allow for the communication of additional data associated with an EAP method. This can be used to indicate whether the authentication is for a user or a machine. This allows the EAP server and peer to request and negotiate authentication specifically for a user or machine. This is useful in the case of multiple inner EAP authentications where the user and machine both need to be authenticated. " Again=2C why is meta-data necessary? Can't the basic need for machine + us= er auth be met without this?=20 =20 Section 6.3 =20 " The tunnel method will use data that is outside the TLS tunnel such as the EAP type code or version numbers. If an attacker can compromise the protocol by modifying these values the tunnel method MUST protect this data from modification." =20 Why is it necessary to protect the data from modification in order to address the attacks? For example=2C if the key derivation is unique to an EAP type=2C then modifying the type would cause proof of key possession to fail. Wouldn't this be sufficient? =20 EMAILING FOR THE GREATER GOOD Join me= --_f268a121-4824-4059-baa2-b5e1e6e1f6b3_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Review of draft-ietf-emu-eaptunnel-req-03
 =3B
Here is my review of -03. =3B There are still quite a few issues in thi= s
document=2C including vague or unnecessary requirements. =3B As a = result=2C
the document isn't ready for the IESG yet.
 =3B
Section 2
 =3B
" =3B =3B Because this specification is an informational specificat= ion (not
 =3B =3B able to directly use [RFC2119])=2C"
 =3B
Since a large number of Informational RFCs reference RFC 2119 and use
no= rmative language=2C this statement seems odd. =3B Perhaps what it
is= trying to say is that the terms don't mean the same
thing in this docum= ent as they do in RFC 2119? =3B =3B If that is the
case=2C langu= age such as that from RFC 2989 Section 1.1 might make
sense:
 =3B
 =3B =3B Please note that the requirements specified in this docume= nt are to
 =3B =3B be used in evaluating protocol submissions.&n= bsp=3B As such=2C the
 =3B =3B requirements language refers to c= apabilities of these protocols=3B the
 =3B =3B protocol document= s will specify whether these features are required=2C
 =3B =3B r= ecommended=2C or optional. =3B For example=2C requiring that a protocol=
 =3B =3B support confidentiality is NOT the same thing as requi= ring that all
 =3B =3B protocol traffic be encrypted.
 =3B =3B A protocol submission is not compliant if it fails to sati= sfy one or
 =3B =3B more of the MUST or MUST NOT requirements fo= r the capabilities that
 =3B =3B it implements. =3B A protoc= ol submission that satisfies all the MUST=2C
 =3B =3B MUST NOT= =2C SHOULD and SHOULD NOT requirements for its capabilities is
 =3B&= nbsp=3B said to be "unconditionally compliant"=3B one that satisfies all th= e
 =3B =3B MUST and MUST NOT requirements but not all the SHOULD= or SHOULD NOT
 =3B =3B requirements for its protocols is said t= o be "conditionally
 =3B =3B compliant."
 =3B
As it is=2C the MUST=2C MUST NOT=2C SHOULD=2C SHOULD NOT=2C etc. definition= s are
confusing.
 =3B
Section 3.1 Password Authentication
 =3B
" =3B Many legacy systems only support user authentication with passwor= ds.
 =3B =3B Some of these systems require transport of the actu= al username and
 =3B =3B password to the authentication server.&= nbsp=3B The tunnel method MUST support
 =3B =3B this use case."=
 =3B
As currently worded=2C this statement is somewhat vague. =3B =3B Is this statement implying that a tunnel method must support
password-on= ly authentication (e.g. no certificates)? =3B If so=2C is there
a re= quiremnent to support weak passwords or just pre-shared keys?
Would a tunnel method utilizing a server certificate to
create a tunnel= =2C and doing password authentication within the tunnel
meet this requir= ement? =3B What about a tunnel method utilizing a
pre-shared key cip= hersuite?
 =3B
" =3B However=2C it MUST NOT expose the username and password to partie= s in
 =3B =3B the communication path between the peer and the EA= P Server and it
 =3B =3B MUST provide protection against man-in-= the-middle and dictionary
 =3B =3B attacks."
 =3B
Does this requirement apply to provisioning or just to ongoing password
= authentication?
 =3B
Section 3.2
 =3B
" =3B In
 =3B =3B particular=2C when weak methods are used= =2C security policies enforcing
 =3B =3B that such methods can o= nly be executed inside a tunnel but never
 =3B =3B outside one a= re required to mitigate the attack."
 =3B
The requirement that methods only be executed within a tunnel is necessary<= BR>even for strong methods=2C if crypto-binding isn't used. =3B =3B=
 =3B
" =3B On the other hand=2C
 =3B =3B a technical solution (so= -called cryptographic bindings) can be used
 =3B =3B whenever th= e inner method is not susceptible to attacks outside a
 =3B =3B = tunnel and derives keying material."
 =3B
Cryptographic binding can be used whenever the inner method generates
ke= ys. =3B If this isn't used=2C then even methods not susceptible to atta= ck
outside the tunnel should be prohibited from use outside the tunnel= =2C or
else MiTM attacks would still be feasible.
 =3B
Section 3.3
 =3B
" =3B Several circumstances are best addressed by using chained EAP
=  =3B =3B methods. =3B For example=2C it may be desirable to aut= henticate the user
 =3B =3B and also authenticate the device tha= t he or she is using."
This requirement can be met by support for cryptographic binding=2C without=
chaining of EAP methods. =3B For example=2C the combination of TLS = and
an inner method can support user/device auth. =3B Given that=2C= why is
support for chained methods a must=2C and not device/user authsupport?
 =3B
Section 3.4
 =3B
" =3B When performing an EAP authentication=2C the peer may want to pro= tect
 =3B =3B its identity=2C only disclosing its identity to a = trusted backend
 =3B =3B authentication server. =3B This hel= ps to maintain the privacy of the
 =3B =3B peer's identity."
 =3B
Within tunneled authentication=2C there are a number of identities
invo= lved. =3B This includes the identity included in the EAP-Request/Identi= ty=2C
identities used in TLS (subject and subjectAltName fields)=2C and<= BR>identities used in the inner EAP method. =3B To which identities doe= s
this requirement apply?
 =3B
Section 3.5
 =3B
" =3B When wireless VOIP service is provided=2C some regulations requir= e any
 =3B =3B user to be able to gain access to the network to = make an emergency
 =3B =3B telephone call."
 =3B
Which regulations are being referred to? =3B In a number of places=2C s= upport
for anonymous authentication is actually being removed=2C not add= ed:
http://www.ietf.org/mail-archive/web/ecrit/current/msg06378.html<= /A>
 =3B
Section 4.1.1
 =3B
" =3B The tunnel method MUST meet all the MUST and SHOULD requirements<= BR> =3B =3B relevant to EAP methods contained in the EAP Key Manage= ment Framework
 =3B =3B [RFC5247] or its successor. =3B The = tunnel method MUST include MSK and
 =3B =3B EMSK generation.&nbs= p=3B This will enable the tunnel method to properly fit
 =3B =3B= into the EAP key management framework=2C maintaining all of the
 = =3B =3B security properties and guarantees of that framework."
 =3B
The primary aspects of [RFC5247] that apply to EAP methods is the
genera= tion of the Peer-Id=2C Server-Id and Session-Id. =3B Why not just
sp= ell out those requirements specifically?
 =3B
" =3B The tunnel method MUST meet the SHOULD and MUST requirements
&= nbsp=3B =3B pertinent to EAP method contained in Section 3 of RFC 4962 = [RFC4962].
 =3B =3B This includes: cryptographic algorithm indep= endence=3B strong=2C fresh
 =3B =3B session keys=3B replay detec= tion=3B keying material confidentiality and
 =3B =3B integrity= =3B confirm cipher suite selection=3B and uniquely named keys."
 =3B
The key naming requirement is handled by generation of the Session-Id=2Cso it needn't be mentioned specifically.
 =3B
With respect to some of these issues=2C NIST 800-120 provides more
detai= led and specific requirements. =3B
 =3B
Section 4.1.2
 =3B
" =3B =3B Several existing tunnel methods are already in widespread= usage: EAP-
 =3B =3B FAST [RFC4851]=2C EAP-TTLS [RFC5281]=2C an= d PEAP."
 =3B
The definitive reference for the PEAP protocol is:
http://msdn.microsoft= .com/en-us/library/cc238354(PROT.10).aspx
 =3B
Section 4.2.1
 =3B
" =3B The tunnel based method MUST support TLS version 1.2 [RFC5246] an= d
 =3B =3B SHOULD support TLS version 1.0 [RFC2246] and version = 1.1 [RFC4346] to
 =3B =3B enable the possibility of backwards co= mpatibility with existing
 =3B =3B deployments."
 =3B
I am not sure how to interpret this requirement. =3B Is it sufficient f= or
a proposal to enable negotiation of TLS 1.2 between a peer and server=
that support it? =3B Or does the protocol actually have to require = that
both the peer and server implement TLS 1.2? =3B If the former= =2C is the
requirement really =3B just properly supporting TLS versi= on negotiation?
 =3B
Section 4.2.1.1.2
 =3B
"See Part 1 of the NIST Recommendation for
 =3B =3B Key Manageme= nt [NIST SP 800-57] for a discussion of the relative
 =3B =3B st= rengths of common algorithms."
 =3B
Why not reference the NIST SP 800-120 requirements here?
 =3B
Section 4.2.1.1.3
 =3B
" =3B =3B A tunnel method MUST provide unidirectional authenticatio= n from
 =3B =3B authentication server to EAP peer or mutual auth= entication between
 =3B =3B authentication server and EAP peer."=
 =3B
Is this really an or? =3B For example=2C would a tunnel method that onl= y
supports undirectional authentication satisfy the requirement?
 =3B
"o One-way key derivation
 =3Bo Cryptographically separated keys. =3Bo Cryptographically separated entities.
 =3Bo Identity bin= ding
 =3Bo Context binding
 =3Bo Key lifetime
 =3Bo Mu= tual implicit key authentication
 =3Bo Key freshness"
 =3B
Given that this document assumes a TLS-based tunnel method=2C the text
o= n requirements can be made considerably more specific and actionable
bas= ed on TLS properties and the specific requirements of NIST 800-120. =3B=
As it stands=2C a number of these requirements either don't apply to
EA= P methods at all (e.g. context binding=2C key lifetime) but rather to other=
elements of the system=2C or are automatically provided by TLS
(e.g.= key freshness=2C Identity binding). =3B
 =3B
So these requirements need to be made actionable and specific. =3B The = ones
that don't apply to the problem at hand (e.g. TLS-based tunnel euth) should= be
removed.
 =3B
Section 4.2.1.3
 =3B
" =3B In order to meet the requirements in this document TLS extensions= MAY
 =3B =3B be used. =3B For example=2C TLS extensions may= be useful in providing
 =3B =3B certificate revocation informat= ion via the TLS OCSP extension (thus
 =3B =3B meeting the requir= ement in Section 4.5.1.3)."
 =3B
Why is it necessary to include optional requirements in this document?
P= resumably the selection will only be influenced by MUST and SHOULD
requi= rements=2C right?
 =3B
Section 4.2.1.4
 =3B
" =3B A tunnel protocol MUST support peer privacy. =3B This require= s that the
 =3B =3B username and other attributes associated wit= h the peer are not
 =3B =3B transmitted in the clear or to an un= authenticated=2C unauthorized
 =3B =3B party. =3B If applica= ble=2C the peer certificate is sent confidentially
 =3B =3B (i.e= . encrypted)."
 =3B
Does a username of "anonymous" need to be encrypted? =3B Or does thisrequirement only apply to the tunnel method-specific identities? =3B =
Is there an issue with transmission of dientities to authenticated
a= nd authorized parties (e.g. the NAS)? =3B In some regulatory jurisdicti= ons
this is also a concern.
 =3B
Section 4.2.3
 =3B
"If modification of this information can cause
 =3B =3B vulnerab= ilities=2C the tunnel method MUST provide protection against
 =3B&nb= sp=3B modification of this data."
 =3B
This seems a bit vague. =3B Why not just require secure confirmation of= the
protocol version and/or type code=2C either implicitly or explicitl= y?
 =3B
Section 4.3.3
 =3B
" =3B =3B The payload MUST support marking of mandatory and optiona= l
 =3B =3B attributes=2C as well as an attribute used for reject= ing mandatory
 =3B =3B attributes."
 =3B
Why is it necessary for mandatory and optional attributes to be explicitly<= BR>marked? =3B Is it be sufficient for the attributes to be divided int= o
standardized and vendor-specific spaces=2C with the latter optional?&n= bsp=3B
 =3B
Section 4.3.6
 =3B
" =3B The payload MAY provide a standard attribute format that supports=
 =3B =3B international strings. =3B This attribute format M= UST support encoding
 =3B =3B strings in UTF-8 [RFC3629] format.=  =3B Any strings sent by the server
 =3B =3B intended for di= splay to the user MUST be sent in UTF-8 format and
 =3B =3B SHOU= LD be able to be marked with language information and adapted to
 = =3B =3B the user's language preference."
 =3B
If UTF-8 is supported=2C is it necessary to also mark the language?
Why= is language negotiation a SHOULD?
 =3B
EAP methods such as Identity &=3B Notification don't support this.
 =3B
Section 4.5
 =3B
"These typically
 =3B =3B require the password in its original t= ext form in order to
 =3B =3B authenticate the peer=2C hence the= y require the peer to send the clear
 =3B =3B text user name and= password to the EAP server."
 =3B
One of the issues with support for cleartext passwords are the potentialattacks against the AAA backend (e.g. User-Password attribute) in splitauthentication scenarios. =3B Is it worth calling this out?
 =3B
Section 4.5.2
 =3B
" =3B The password authentication exchange MUST support user names and<= BR> =3B =3B passwords in international languages. =3B It MUST s= upport encoding of
 =3B =3B user name and password strings in UT= F-8 [RFC3629] format. =3B Any
 =3B =3B strings sent by the s= erver during the password exchange and intended
 =3B =3B for dis= play to the user MUST be sent in UTF-8 format and SHOULD be
 =3B&nbs= p=3B able to be marked with language information and adapted to the user's<= BR> =3B =3B language preference.
"
Why is it useful to mark usernames and passwords with language
informati= on on the wire?
 =3B
Section 4.5.3
 =3B
" =3B =3B The password authentication exchange MUST support additio= nal
 =3B =3B associated meta-data which can be used to indicate = whether the
 =3B =3B authentication is for a user or a machine.&= nbsp=3B This allows the EAP
 =3B =3B server and peer to request = and negotiate authentication specifically
 =3B =3B for a user or= machine. =3B This is useful in the case of multiple inner
 =3B&= nbsp=3B authentications where the user and machine both need to be
 = =3B =3B authenticated.
"
Why is it necessary to support meta-data to indicate whether authentication=
is for a user or machine? =3B Few authentication protocols support = this today
and don't seem to miss it. =3B For example=2C does Kerber= os or PKI distinguish
explicitly between user and machine credentials? <= BR>  =3B
Section 4.6.2
 =3B
" =3B =3B The tunnel method MUST support the chaining of multiple E= AP methods.
 =3B =3B The tunnel method MUST allow for the commun= ication of intermediate
 =3B =3B result and verification of comp= ound binding between executed inner
 =3B =3B methods when chaine= d methods are employed.
"
 =3B
Given that the basic use case (machine + user auth) doesn't require
chai= ning of EAP methods=2C why is this a MUST? =3B
 =3B
Section 4.6.5
 =3B
" =3B =3B The tunnel method MUST allow for the communication of add= itional data
 =3B =3B associated with an EAP method. =3B Thi= s can be used to indicate whether
 =3B =3B the authentication is= for a user or a machine. =3B This allows the EAP
 =3B =3B s= erver and peer to request and negotiate authentication specifically
&nbs= p=3B =3B for a user or machine. =3B This is useful in the case of m= ultiple inner
 =3B =3B EAP authentications where the user and ma= chine both need to be
 =3B =3B authenticated.
"
Again=2C why is meta-data necessary? =3B Can't the basic need for machi= ne + user
auth be met without this?
 =3B
Section 6.3
 =3B
" =3B The tunnel method will use data that is outside the TLS tunnel su= ch
 =3B =3B as the EAP type code or version numbers. =3B If = an attacker can
 =3B =3B compromise the protocol by modifying th= ese values the tunnel method
 =3B =3B MUST protect this data fro= m modification."
 =3B
Why is it necessary to protect the data from modification in order to
ad= dress the attacks? =3B For example=2C if the key derivation is unique t= o
an EAP type=2C then modifying the type would cause proof of key posses= sion
to fail. =3B Wouldn't this be sufficient? =3B


<= BR>

3D"i'm" EMAILING FOR THE GREATER GOOD<= BR>Join me
= --_f268a121-4824-4059-baa2-b5e1e6e1f6b3_-- From bernard_aboba@hotmail.com Wed Jul 8 17:02:58 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C466328C515 for ; Wed, 8 Jul 2009 17:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iK-swG47dZVN for ; Wed, 8 Jul 2009 17:02:57 -0700 (PDT) Received: from blu0-omc3-s23.blu0.hotmail.com (blu0-omc3-s23.blu0.hotmail.com [65.55.116.98]) by core3.amsl.com (Postfix) with ESMTP id 46E3428C4E7 for ; Wed, 8 Jul 2009 17:02:57 -0700 (PDT) Received: from BLU137-W33 ([65.55.116.74]) by blu0-omc3-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 17:03:25 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_fbecad32-d48e-4905-a406-b03fd8b61f3f_" X-Originating-IP: [131.107.0.83] From: Bernard Aboba To: Date: Wed, 8 Jul 2009 17:03:24 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 09 Jul 2009 00:03:25.0066 (UTC) FILETIME=[ADF496A0:01CA0028] Subject: Re: [Emu] draft-ietf-emu-chbind-02 and AAA interaction X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 00:02:58 -0000 --_fbecad32-d48e-4905-a406-b03fd8b61f3f_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable There are two issues that arise in dealing with the "Lying NAS problem": =20 a. Whether the NAS is telling the same thing to the AAA server and to the E= AP peer=3B b. Whether the information that the NAS provides to either party is actuall= y correct.=20 While the AAA protocol info is useful for problem a)=2C it isn't that helpf= ul for problem b)=2C since as you point out=2C the authenticator may not be truste= d by the AAA server. So the NAS could be telling the same lie to both the AAA se= rver and the EAP peer. =20 =20 So overall=2C my take is that you are suggesting that the draft focus more = on problem b).=20 =20 I would agree that it is important for the document to make the distinction between a) and b) and for it to point out the relatively value (and cost) of solving each of these problems. =20 =20 However=2C I do think that there are sound reasons to retain an interest in problem a=2C so long as that interest is not carried to an extreme (e.g.= =20 defining more and more AAA attributes that wouldn't be needed for any=20 other purpose=2C such as the IEEE 802.11 RSN IE). =20 =20 To my mind=2C the primary reason for tackling problem a) is as a quick "sanity check" on NAS behavior=2C in situations where assembling an appropr= iate database for dealing with problem b) is prohibitively expensive. =20 =20 However=2C for such a "sanity check" to work reasonably well=2C it is neces= sary for the data formats for the channel bindings and AAA to be well aligned so that they can be mechanically compared. This issue isn't currently dealt with = in the=20 draft.=20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D After reviewing recent comments from Klaas on the list on Channel bindings there is one issue I would like to try to resolve before bringing this draft to last call. =20 In section 5.1=2C the draft defines a message i2=2C which is the message carrying AAA attributes from the authenticator to the server using a AAA protocol. While=2C this message does occur in the protocol interactions=2C it is actually not that important in the channel binding interactions because the server does not completely trust the authenticator and must know what is valid through some other mechanism=2C such as the local database defined in the draft. I think this section is a bit misleading and needs to emphasize this point. This is further confused by the fact that in some sections the draft focuses entirely on AAA attributes to carry channel-binding information. While AAA attributes are undoubtedly important to carry it does not appear that they should be the only type of data allowed especially since the AAA protocol is not required to be directly involved other than to carry EAP. This is demonstrated by the "TODO" 7.3 which suggests we need to add a way to carry the 802.11 RSN-IE. Since AAA protocols haven't needed to carry this information to date=2C it is not clear that adding this information to them would be helpful. Given this I would suggest the following modifications to the draft: 1. In sections 5.1 and 5.2 clarify the role of message i2 with respect to channel bindings. 2. In section 6.1 define channel binding data as a superset of AAA attributes. In particular the last paragraph needs work and seems inconsistent with 7.1 which allows for the inclusion of Diameter attributes without the exclusion of other attributes.=20 3. Sections 7.1=2C 7.2=2C 7.3 only recommend comparing information with wha= t is received from the NAS and not about comparing with local information 4. Section 8 is about AAA validation and is not channel bindings=2C is this section necessary? =20 If the working group agrees with this direction I can provide text for the changes. =20 Please send comments to the list. Thanks=2C Joe=20 EMAILING FOR THE GREATER GOOD Join me= --_fbecad32-d48e-4905-a406-b03fd8b61f3f_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
There are two issues that arise in dealing with the "Lying NAS problem"= :
 =3B
a. Whether the NAS is telling the same thing to the AAA server and to the E= AP peer=3B

b. Whether the information that the NAS provides to either party is act= ually correct.
While the AAA protocol info is useful for problem a)=2C it isn't that helpf= ul for
problem b)=2C since as you point out=2C the authenticator may not= be trusted by
the AAA server. So the NAS could be telling the same lie = to both the AAA server
and the EAP peer. =3B
 =3B
So overall=2C my take is that you are suggesting that the draft focus more = on
problem b).
 =3B
I would agree that it is important for the document to make the distinction=
between a) and b) and for it to point out the relatively value (and cos= t)
of solving each of these problems. =3B
 =3B
However=2C I do think that there are sound reasons to retain an interestin problem a=2C so long as that interest is not carried to an extreme (e.g= .
defining =3B more and more AAA attributes that wouldn't be needed= for any
other purpose=2C such as the IEEE 802.11 RSN IE). =3B
 =3B
To my mind=2C the primary reason for tackling problem a) is as a quick
"= sanity check" on NAS behavior=2C in situations where assembling an appropri= ate
database for dealing with problem b) is prohibitively expensive.&nbs= p=3B
 =3B
However=2C for such a "sanity check" to work reasonably well=2C it is neces= sary for the
data formats for the channel bindings and AAA to be well al= igned so that
they can be mechanically compared. =3B =3B This is= sue isn't currently dealt with in the
draft.
 =3B
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
After revie= wing recent comments from Klaas on the list on Channel
bindings there is= one issue I would like to try to resolve before
bringing this draft to = last call. =3B
In section 5.1=2C the draft defines a message i2=2C which is the messagecarrying AAA attributes from the authenticator to the server using a AAAprotocol. =3B While=2C this message does occur in the protocol intera= ctions=2C
it is actually not that important in the channel binding inter= actions
because the server does not completely trust the authenticator a= nd must
know what is valid through some other mechanism=2C such as the l= ocal
database defined in the draft. =3B I think this section is a bi= t misleading
and needs to emphasize this point. =3B This is further = confused by the fact
that in some sections the draft focuses entirely on= AAA attributes to
carry channel-binding information. =3B While AAA = attributes are undoubtedly
important to carry it does not appear that th= ey should be the only type
of data allowed especially since the AAA prot= ocol is not required to be
directly involved other than to carry EAP.&nb= sp=3B This is demonstrated by the
"TODO" 7.3 which suggests we need to a= dd a way to carry the 802.11
RSN-IE. =3B Since AAA protocols haven't= needed to carry this information to
date=2C it is not clear that adding= this information to them would be
helpful. =3B Given this I would s= uggest the following modifications to the
draft:
1. In sections 5.1 and 5.2 clarify the role of message i2 with respect
t= o channel bindings.
2. In section 6.1 define channel binding data as a s= uperset of AAA
attributes. =3B In particular the last paragraph need= s work and seems
inconsistent with 7.1 which allows for the inclusion of= Diameter
attributes without the exclusion of other attributes.
3. S= ections 7.1=2C 7.2=2C 7.3 only recommend comparing information with whatis received from the NAS and not about comparing with local information4. Section 8 is about AAA validation and is not channel bindings=2C is
= this section necessary? =3B
If the working group agrees with this direction I can provide text for
t= he changes. =3B
Please send comments to the list.
Thanks=2C
Joe






3D"i'm" EMAILING FOR THE GREATER GOOD<= BR>Join me
= --_fbecad32-d48e-4905-a406-b03fd8b61f3f_-- From khoeper@motorola.com Thu Jul 9 11:07:03 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C38528C268 for ; Thu, 9 Jul 2009 11:07:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYb17Yj3IlkI for ; Thu, 9 Jul 2009 11:07:02 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id 2783D3A6C96 for ; Thu, 9 Jul 2009 11:07:02 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-12.tower-128.messagelabs.com!1247162843!15867089!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 14252 invoked from network); 9 Jul 2009 18:07:24 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-12.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Jul 2009 18:07:24 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id n69I7IrT011727 for ; Thu, 9 Jul 2009 11:07:23 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n69I7Fmd024785 for ; Thu, 9 Jul 2009 13:07:15 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n69I73Tu024692 for ; Thu, 9 Jul 2009 13:07:03 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Jul 2009 14:06:41 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F06355970@de01exm68.ds.mot.com> In-Reply-To: <4A4A42B9.8060402@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Call for agenda items for IETF 75 thread-index: Acn5pIBF2Z5NaLKQTPCS6hjLi1bHzAHG1j0A References: <4A4A42B9.8060402@deployingradius.com> From: "Hoeper Katrin-QWKN37" To: "Alan DeKok" , X-CFilter-Loop: Reflected Subject: Re: [Emu] Call for agenda items for IETF 75 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2009 18:07:03 -0000 Hi, I would like to request a 20 min slot to discuss the current status of the channel binding draft (draft-clancy-emu-chbind-04). Thanks, Katrin > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of Alan > DeKok > Sent: Tuesday, June 30, 2009 11:52 AM > To: emu@ietf.org > Subject: [Emu] Call for agenda items for IETF 75 >=20 >=20 > We currently have a 2 hour slot on Monday afternoon. Please submit > agenda requests to the chairs as soon as possible. >=20 > Alan DeKok. > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu From root@core3.amsl.com Fri Jul 10 09:30:01 2009 Return-Path: X-Original-To: emu@ietf.org Delivered-To: emu@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7C1BE28C29B; Fri, 10 Jul 2009 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090710163001.7C1BE28C29B@core3.amsl.com> Date: Fri, 10 Jul 2009 09:30:01 -0700 (PDT) Cc: emu@ietf.org Subject: [Emu] I-D Action:draft-ietf-emu-chbind-03.txt X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 16:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF. Title : Channel Binding Support for EAP Methods Author(s) : C. Clancy, K. Hoeper Filename : draft-ietf-emu-chbind-03.txt Pages : 24 Date : 2009-07-10 This document defines how to implement channel bindings for Extensible Authentication Protocol (EAP) methods to address the lying NAS as well as the lying provider problem. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-emu-chbind-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-10092908.I-D@ietf.org> --NextPart-- From khoeper@motorola.com Fri Jul 10 11:10:41 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7D5B28C36A for ; Fri, 10 Jul 2009 11:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xWYNipHg3RLN for ; Fri, 10 Jul 2009 11:10:41 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id A601628C361 for ; Fri, 10 Jul 2009 11:10:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: khoeper@motorola.com X-Msg-Ref: server-10.tower-55.messagelabs.com!1247249467!97888605!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 23465 invoked from network); 10 Jul 2009 18:11:07 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jul 2009 18:11:07 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n6AIB7Zo007149 for ; Fri, 10 Jul 2009 11:11:07 -0700 (MST) Received: from il06vts04.mot.com (il06vts04.mot.com [129.188.137.144]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id n6AIB7Rd004019 for ; Fri, 10 Jul 2009 13:11:07 -0500 (CDT) Received: from de01exm68.ds.mot.com (de01exm68.am.mot.com [10.176.8.24]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id n6AIB605004016 for ; Fri, 10 Jul 2009 13:11:06 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0189.BE5F68C8" Date: Fri, 10 Jul 2009 14:10:44 -0400 Message-ID: <3A241A6B234BE948B8B474D261FEBC2F0638E06C@de01exm68.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: new channel binding draft thread-index: AcoBib5caFKH+AoCQ8KNc25CaMQHzg== From: "Hoeper Katrin-QWKN37" To: X-CFilter-Loop: Reflected Subject: [Emu] new channel binding draft X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2009 18:10:41 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0189.BE5F68C8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, =20 I just posted a new version of the channel binding draft (http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-03.txt). =20 Joe helped me to address the recent discussions on the list. Some parts of the document are restructured and quite a bit of clarifying text has been added (mostly Sections 5-7). The content of the draft is basically the same; it is (hopefully) just more comprehensible. =20 Please review this draft before Stockholm, so we can discuss if the recent comments & discussions on the list have been sufficiently addressed and the document is ready for WGLC. =20 Thank you, Katrin ------_=_NextPart_001_01CA0189.BE5F68C8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

I just posted a new version of the channel binding = draft (http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-03.txt).

 

Joe helped me to address the recent discussions on = the list.

Some parts of the document are restructured and quite = a bit of clarifying text has been added (mostly Sections 5-7). The content of = the draft is basically the same; it is (hopefully) just more = comprehensible.

 

Please review this draft before Stockholm, so we can discuss if the = recent comments & discussions on the list have been sufficiently addressed = and the document is ready for WGLC.

 

Thank you,

Katrin

------_=_NextPart_001_01CA0189.BE5F68C8-- From jsalowey@cisco.com Wed Jul 15 11:14:47 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AE9B3A67A3 for ; Wed, 15 Jul 2009 11:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zvom-hK+r4mi for ; Wed, 15 Jul 2009 11:14:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 72B623A6B57 for ; Wed, 15 Jul 2009 11:13:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANC4XUqrR7O6/2dsb2JhbAC6C4gjkRgFhAk X-IronPort-AV: E=Sophos;i="4.42,405,1243814400"; d="scan'208";a="214445901" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2009 18:13:35 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6FIDZYQ023716 for ; Wed, 15 Jul 2009 11:13:35 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6FIDZu8028265 for ; Wed, 15 Jul 2009 18:13:35 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 11:13:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jul 2009 11:13:33 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft EMU Agenda Thread-Index: AcoFd/cVDLX8e7hTQUG36Pp1aGNhqg== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 15 Jul 2009 18:13:35.0103 (UTC) FILETIME=[F7DAA8F0:01CA0577] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=164; t=1247681615; x=1248545615; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Draft=20EMU=20Agenda=20 |Sender:=20; bh=WIQVxiOdcu7BoomPWd/EG5Z2Rx7SnP/6YVm+pXHerq0=; b=N+dmWgHQiveFvo2hCJf7/8HbiVAewXwzRilDpAYinXY8NvE4HhyInh9HYg hr1/6coXkCmAHlgNlHNPRK6aOr9rwdwfJCBYghwY+ffjXk5fvIya+7EGu3CK yAZSLMeA9k; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Emu] Draft EMU Agenda X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2009 18:14:47 -0000 Draft EMU agenda is available at: http://www.ietf.org/proceedings/09jul/agenda/emu.txt Let the chairs know if you have and additions or comments. =20 Joe From jsalowey@cisco.com Mon Jul 20 15:14:20 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 756933A6BC5 for ; Mon, 20 Jul 2009 15:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4IsinaQsO3S for ; Mon, 20 Jul 2009 15:14:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 6F1DF3A68DC for ; Mon, 20 Jul 2009 15:14:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAH+JZEqrR7O6/2dsb2JhbAC5ZIgjOI4eBYJRgTs X-IronPort-AV: E=Sophos;i="4.43,236,1246838400"; d="scan'208";a="350428881" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2009 22:14:11 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6KMEBqh000374 for ; Mon, 20 Jul 2009 15:14:11 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n6KMEBRc027155 for ; Mon, 20 Jul 2009 22:14:11 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 15:14:11 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 20 Jul 2009 15:14:10 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only APassword) to Informational RFC Thread-Index: AcoDm39j9bOy3+McR6+qfgQbyJN/fQF6+ALQ From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 20 Jul 2009 22:14:11.0211 (UTC) FILETIME=[6882ADB0:01CA0987] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1261; t=1248128051; x=1248992051; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20FW=3A=20Last=20Call=3A=20draft-harkins-emu-eap- pwd=20(EAP=20Authentication=20Using=20Only=20APassword)=20to =20Informational=20RFC |Sender:=20; bh=4UCyHlk4JskJt4lu4HDFSq1jLEWpQ5bOIHA5ohws9js=; b=ArmXRq55OlCNiG56iugHvKFeVGaWapjXBDu+qw4dVjf27pQHbIE0kx+iex 8i3X26qEyTYVLyTZovBALuk/sT9uuwwIJMU9N2aPyovlaRV2oRTttxhEyaXR Ur6SnazIDT; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [Emu] FW: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only APassword) to Informational RFC X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2009 22:14:20 -0000 =20 -----Original Message----- From: ietf-announce-bounces@ietf.org [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG Sent: Monday, July 13, 2009 2:22 AM To: IETF-Announce Subject: Last Call: draft-harkins-emu-eap-pwd (EAP Authentication Using Only APassword) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'EAP Authentication Using Only A Password ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-08-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-harkins-emu-eap-pwd-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D 16914&rfc_flag=3D0 _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From mccann.stephen@googlemail.com Tue Jul 21 07:31:23 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EA473A6E61 for ; Tue, 21 Jul 2009 07:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.847 X-Spam-Level: X-Spam-Status: No, score=-0.847 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fId8Xxprf-09 for ; Tue, 21 Jul 2009 07:31:22 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 2242B3A6E5F for ; Tue, 21 Jul 2009 07:31:21 -0700 (PDT) Received: by ewy26 with SMTP id 26so3084539ewy.37 for ; Tue, 21 Jul 2009 07:30:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=U1lKf+hM4gmtai4YVUdkttuPOCJThcEGVjnNy7djGeo=; b=UGwTbQRTRThGH3BzrNfEBygsOOc3TUY7TvunCaEEx9boyoaPj0EO5boNp++TsrhQZG 3wbyDWNPtFuEty2uBXztUXum+ma4nbfpIjShxyupUWuIw6cBSHc+8+UguaMLQF8HLpHS hV7xVkHcaqWtQp2HZj73xLjx7F1UoR5loKvNo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=MeGg3fjL4Uf/9LIxPMDogke5GIqacQdqgdvCfQmfN11bwNtp2LOCNdEfa4sQa5oxes O3QTTy3nuwnm6FanxrWNuf/4GmELpMG6p1tZYp5o6AizUtVnaGARTwKbwq4I8PMWO1zL ibxo/XD1uQNigFr75Fd9/lS5aSNGPy7b0K4Uk= MIME-Version: 1.0 Received: by 10.216.11.213 with SMTP id 63mr1519694wex.176.1248186638161; Tue, 21 Jul 2009 07:30:38 -0700 (PDT) Date: Tue, 21 Jul 2009 15:30:38 +0100 Message-ID: From: Stephen McCann To: emu@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Emu] Last Call: draft-harkins-emu-eap-pwd (EAP AuthenticationUsing Only APassword) to Informational RFC X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 14:59:00 -0000 Joe, Hi, I noticed in passing that this last call is for an Informational RFC, whereas the draft status is Standards Track. Can anyone clarify its status please? Kind regards Stephen McCann From jsalowey@cisco.com Tue Jul 21 10:38:58 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8016B28C211 for ; Tue, 21 Jul 2009 10:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.034 X-Spam-Level: X-Spam-Status: No, score=-6.034 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZkglKSpxvdg for ; Tue, 21 Jul 2009 10:38:57 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 466873A6965 for ; Tue, 21 Jul 2009 10:38:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAN2ZZUqrR7O6/2dsb2JhbAC6bogjkAIFhAw X-IronPort-AV: E=Sophos;i="4.43,241,1246838400"; d="scan'208";a="217046329" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 21 Jul 2009 17:38:19 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6LHcJgn030583; Tue, 21 Jul 2009 10:38:19 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6LHcJ5o020484; Tue, 21 Jul 2009 17:38:19 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 10:38:19 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 21 Jul 2009 10:38:18 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Last Call: draft-harkins-emu-eap-pwd (EAPAuthenticationUsing Only APassword) to Informational RFC Thread-Index: AcoKE8kOwtEy9tS5RXeViRDskZXTlQAC3PiA References: From: "Joseph Salowey (jsalowey)" To: "Stephen McCann" , X-OriginalArrivalTime: 21 Jul 2009 17:38:19.0229 (UTC) FILETIME=[092C68D0:01CA0A2A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1065; t=1248197899; x=1249061899; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20RE=3A=20[Emu]=20Last=20Call=3A=20draft-harkins- emu-eap-pwd=20(EAPAuthenticationUsing=20Only=20APassword)=20 to=20Informational=20RFC |Sender:=20; bh=5SIE/1THK6sO6ztusVb0UhZKrovd3DI+JnmBBKObaTI=; b=pWWlM1z8n4wNnGty24Vx08LnaphxgxpiQ2pBQa/fZhPsFiKIgch7wNJYLB Zmo4GHSPXIQOS4ybJiY1VjLJlmkuLT4hjC2TOd2TYmQBNurc51VskC/3F0g5 TsOWO5pZ4C; Authentication-Results: sj-dkim-2; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [Emu] Last Call: draft-harkins-emu-eap-pwd (EAPAuthenticationUsing Only APassword) to Informational RFC X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2009 17:38:58 -0000 The announcement indicates that the draft will be published as informational, however Glen Zorn (one of the authors) has requested that this be changed to standards track so the status is currently under discussion. Since the document is in IETF last call comments on the draft including its standards status should be sent to the ietf@ietf.org list. =20 Joe > -----Original Message----- > From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On=20 > Behalf Of Stephen McCann > Sent: Tuesday, July 21, 2009 7:31 AM > To: emu@ietf.org > Subject: Re: [Emu] Last Call: draft-harkins-emu-eap-pwd=20 > (EAPAuthenticationUsing Only APassword) to Informational RFC >=20 > Joe, > Hi, >=20 > I noticed in passing that this last call is for an=20 > Informational RFC, whereas the draft status is Standards Track. >=20 > Can anyone clarify its status please? >=20 > Kind regards >=20 > Stephen McCann > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20 From jsalowey@cisco.com Sat Jul 25 15:47:31 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E4973A69E5 for ; Sat, 25 Jul 2009 15:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KqyAeVNRaYM for ; Sat, 25 Jul 2009 15:47:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 448433A69DD for ; Sat, 25 Jul 2009 15:47:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALooa0qrR7MV/2dsb2JhbAC3RIgojwwFhA0 X-IronPort-AV: E=Sophos;i="4.43,270,1246838400"; d="scan'208";a="219141911" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 25 Jul 2009 22:47:31 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6PMlVIJ015173 for ; Sat, 25 Jul 2009 15:47:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6PMlVEU005231 for ; Sat, 25 Jul 2009 22:47:31 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 25 Jul 2009 15:47:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 25 Jul 2009 15:47:27 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Slides for meeting Thread-Index: AcoNeeKV4nKqNXfaQp6T0XlvxoR7tw== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 25 Jul 2009 22:47:31.0151 (UTC) FILETIME=[E4A20DF0:01CA0D79] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=148; t=1248562051; x=1249426051; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20(jsalowey)=22=20 |Subject:=20Slides=20for=20meeting |Sender:=20; bh=iF5KzYMNnY6OZorJ/OxdraBRA9ILPoikCxYV8jPxptc=; b=Ghlc/kwmClk0Y5WK2+D3lQ1XbdFpAZ9X3W2ZgjpuriTt+viKRVDZd4JV6B 8ijq5I8EOVxSTtJq0Dz2nxGJPAAD884nKDJDXt9hbeOQWuEeDi8XLylTX3Rr fhQrieLwA1S1S+q5plW3C8WYOsbCENkkt+m3emwbdrdOs1dt4DQt8=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [Emu] Slides for meeting X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2009 22:47:31 -0000 If you are on the agenda to present in the meeting please send your slides to the chairs so they can be uploaded to the server. Thanks, Joe From rishyang@gmail.com Mon Jul 27 07:54:15 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31F4A3A6ADB for ; Mon, 27 Jul 2009 07:54:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sE96AhOi+G00 for ; Mon, 27 Jul 2009 07:54:14 -0700 (PDT) Received: from mail-yx0-f183.google.com (mail-yx0-f183.google.com [209.85.210.183]) by core3.amsl.com (Postfix) with ESMTP id DFB7C3A68E8 for ; Mon, 27 Jul 2009 07:54:13 -0700 (PDT) Received: by yxe13 with SMTP id 13so2379307yxe.29 for ; Mon, 27 Jul 2009 07:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Mbp0MF3D8I30QVml8TddpPrJ9N9BdZICxoC7soi3a44=; b=X5HC8A1gvITiDAWcpZDKs40IUwNS2h7SI3r3MbzkfZIGhusrOP5pop9jdfcN0B88f4 DKdNUMnmy2uVuv2OJ1HczXIFqaA4wNQYyNO07NQyuSY0r+vw4GPMimL6n3zKCX0iRPYY ZY0zoU10btPp0b562ecAQZ9xwchCPamCHYgiA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qJ9pSZ+ZoJ3uvnEWtOxjfEe1TFgon8MsvdXyF233ZTAQSmLWE32rva2NE8ZH2UtEUx mbBPRoXx3xUYJQfoD4aLYOL2alSsSgcJ9BRqanoiefvh0su4EQ93EJzOoQ+Mxj39C+R5 b17ynwBSQkOB/ClPDtiBYkdD9+pdqFVbiS2Mk= MIME-Version: 1.0 Received: by 10.100.41.9 with SMTP id o9mr8374484ano.155.1248706448722; Mon, 27 Jul 2009 07:54:08 -0700 (PDT) Date: Mon, 27 Jul 2009 22:54:07 +0800 Message-ID: <8556013e0907270754l5d1d746fvac668e077e0a9144@mail.gmail.com> From: Richard To: "Joseph Salowey (jsalowey)" , emu@ietf.org Content-Type: multipart/alternative; boundary=0016e644033a4e2a97046fb12003 Subject: [Emu] If we use the Radius property extension X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 14:54:15 -0000 --0016e644033a4e2a97046fb12003 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, all: The link to the slide: http://www.ietf.org/proceedings/75/slides/emu-10.ppt Thanks for your comments in the EMU session. Yes, the Radius property extension could be one solution. The problem to it is: The Radius has to handle the WAPI packet (Certificate authentication response), it would lead to the tight coupling between Radius and WAPI (ASE). Compared to it, the EAP solution is simple and make it loose coupling with WAPI. Radius server need not check things going on with WAPI. (EAP-WAI). There is a standard interface to let Radius to know the result of authentication (EAP-SUCCESS or EAP-FAILURE). >From the AAA server perspective, there is no any special for EAP-WAI to the other authentication methods such as EAP-TLS. The loose coupling for EAP solution is a main advantage to the Radius extension method. Yes, the EAP framework is to authenticate the station (supplicant). I guess the main reason is that most authentication methods are to authenticate the supplicant, and the behavior of Authenticator is pass-through. Now, WAPI is a use case of authenticating the authenticator (the behavior of Authenticator is not Pass-through). And it may have more protocols which have similar behavior (use cases) like the WAPI. Could we allow the EAP method behavior like the WAI over EAP instead of forbidding it? Any way, the problem I am trying to resolve is to reuse the AAA and avoid the tight coupling between Radius and WAPI (ASE). Do you have any better solution to it? Regards Richard --0016e644033a4e2a97046fb12003 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, all:
=A0
The link to the slide:
Thanks for your comments in the EMU session.
=A0
Yes, the Radius property extension could be one solution.
The problem to it is:
The Radius has to handle the WAPI packet (Certificate authentication r= esponse),
it would lead to the tight coupling between Radius and WAPI (ASE).
=A0
Compared to it, the EAP solution is simple and make it loose coupling = with WAPI.
Radius server need not check things going on with WAPI. (EAP-WAI).
There is a standard interface to let Radius to know the result
of authentication (EAP-SUCCESS or EAP-FAILURE).
From the=A0AAA server perspective, there is no any special for EAP-WAI=
=A0to the other authentication methods such as EAP-TLS.
The loose coupling for EAP solution is a main advantage to the Radius = extension
method.
=A0
Yes, the EAP framework is to authenticate the station (supplicant). I = guess the
main reason is that most authentication methods are to authenticate th= e supplicant,
and the behavior of Authenticator is pass-through.
Now,=A0WAPI is a=A0use case of authenticating the authenticator (the b= ehavior of Authenticator
=A0is not Pass-through). And it may have more protocols which have sim= ilar behavior
(use cases) like the WAPI.
Could we allow the EAP method behavior like the WAI over EAP instead o= f forbidding it?
=A0
Any way, the problem I am trying to resolve is to reuse the AAA and
avoid the tight coupling between Radius and WAPI (ASE).
=A0
Do you have any better solution to it?
=A0
Regards
Richard
--0016e644033a4e2a97046fb12003-- From dharkins@lounge.org Mon Jul 27 09:13:09 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26DC3A6C6E for ; Mon, 27 Jul 2009 09:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.969 X-Spam-Level: X-Spam-Status: No, score=-5.969 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZQ0L-cnR6uH for ; Mon, 27 Jul 2009 09:13:09 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id F339C3A6C49 for ; Mon, 27 Jul 2009 09:13:08 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 05C4310224074; Mon, 27 Jul 2009 09:13:10 -0700 (PDT) Received: from 130.129.20.145 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 27 Jul 2009 09:13:10 -0700 (PDT) Message-ID: In-Reply-To: <8556013e0907270754l5d1d746fvac668e077e0a9144@mail.gmail.com> References: <8556013e0907270754l5d1d746fvac668e077e0a9144@mail.gmail.com> Date: Mon, 27 Jul 2009 09:13:10 -0700 (PDT) From: "Dan Harkins" To: "Richard" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: emu@ietf.org Subject: Re: [Emu] If we use the Radius property extension X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 16:13:09 -0000 Hi Richard, On slide 11 you say you want to reuse the AAA architecture. But EAP is not a AAA protocol. RADIUS is but you don't want to use RADIUS. So I don't understand what reuse you're hoping to take advantage of. Since EAP doesn't have a transport how do you propose to send EAP packets from the AP to the server? Over UDP port 3810? The same port you send WAI packets to now? If that's the case then all EAP is doing is providing a needless encapsulation of your WAI packet. You gain nothing by encapsulating your WAI packet with an EAP header. I do have a suggestion to fix this problem. Just get rid of the "certificate authentication" exchange and have the client validate the AP's certificate and the AP validate the client's certificate. It is not necessary to have a central authority to approve of certificates, that's the whole point in using certificates. regards, Dan. On Mon, July 27, 2009 7:54 am, Richard wrote: > Hi, all: > > The link to the slide: > http://www.ietf.org/proceedings/75/slides/emu-10.ppt > Thanks for your comments in the EMU session. > > Yes, the Radius property extension could be one solution. > The problem to it is: > The Radius has to handle the WAPI packet (Certificate authentication > response), > it would lead to the tight coupling between Radius and WAPI (ASE). > > Compared to it, the EAP solution is simple and make it loose coupling with > WAPI. > Radius server need not check things going on with WAPI. (EAP-WAI). > There is a standard interface to let Radius to know the result > of authentication (EAP-SUCCESS or EAP-FAILURE). > From the AAA server perspective, there is no any special for EAP-WAI > to the other authentication methods such as EAP-TLS. > The loose coupling for EAP solution is a main advantage to the Radius > extension > method. > > Yes, the EAP framework is to authenticate the station (supplicant). I > guess > the > main reason is that most authentication methods are to authenticate the > supplicant, > and the behavior of Authenticator is pass-through. > Now, WAPI is a use case of authenticating the authenticator (the behavior > of > Authenticator > is not Pass-through). And it may have more protocols which have similar > behavior > (use cases) like the WAPI. > Could we allow the EAP method behavior like the WAI over EAP instead of > forbidding it? > > Any way, the problem I am trying to resolve is to reuse the AAA and > avoid the tight coupling between Radius and WAPI (ASE). > > Do you have any better solution to it? > > Regards > Richard > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From yaronf@checkpoint.com Mon Jul 27 12:20:51 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1D733A6CAD for ; Mon, 27 Jul 2009 12:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLKjNzjr7yBp for ; Mon, 27 Jul 2009 12:20:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 83A8F3A691D for ; Mon, 27 Jul 2009 12:20:47 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 0E77529C005; Mon, 27 Jul 2009 22:21:05 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id B9E3429C002 for ; Mon, 27 Jul 2009 22:21:04 +0300 (IDT) X-CheckPoint: {4A6DFCC4-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n6RJKk3d011539 for ; Mon, 27 Jul 2009 22:20:47 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Mon, 27 Jul 2009 22:20:46 +0300 From: Yaron Sheffer To: "emu@ietf.org" Date: Mon, 27 Jul 2009 22:20:44 +0300 Thread-Topic: Proposed EMU charter item on password auth Thread-Index: AcoO71aia8J13IssRZic8h3GWso4lg== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557C7EE@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0014_01CA0F00.1A326F50" MIME-Version: 1.0 Subject: [Emu] Proposed EMU charter item on password auth X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 19:20:52 -0000 ------=_NextPart_000_0014_01CA0F00.1A326F50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0015_01CA0F00.1A326F50" ------=_NextPart_001_0015_01CA0F00.1A326F50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Pasi asked that we propose a charter item for password-based authentication, so here's a first shot, for your review. Thanks, Yaron The working group will develop a single standards-track EAP method for authenticating users using short, memorable passwords but with no use of public key certificates. The protocol should be secure against both passive and active attackers, specifically it should not be vulnerable to dictionary attacks in both of these attack scenarios. Possible starting points for this work are , and the expired . The document should include a requirements section, copying "by value" the relevant subset of , but not having normative dependence on that draft. ------=_NextPart_001_0015_01CA0F00.1A326F50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Pasi asked that we propose a charter item for = password-based authentication, so here’s a first shot, for your = review.

 

Thanks,

         =    Yaron

 

 

The working group will develop a single = standards-track EAP method for authenticating users using short, memorable passwords but = with no use of public key certificates. The protocol should be secure against = both passive and active attackers, specifically it should not be vulnerable = to dictionary attacks in both of these attack scenarios. Possible starting = points for this work are <EAP-EKE>, <EAP-PWD> and the expired <EAP-SRP>. The document should include a requirements section, = copying “by value” the relevant subset of <tunnel = requirements>, but not having normative dependence on that draft.

 

------=_NextPart_001_0015_01CA0F00.1A326F50-- ------=_NextPart_000_0014_01CA0F00.1A326F50 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDcyNzE5MjA0NFowIwYJKoZIhvcNAQkEMRYEFKi/ZKTibPo9 XQT60JmTiEOWNwKMMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA ZPRAbrFQV4WZHn01ujRQ9B22KXSkX31jiw8dasvjGNdd2TZFCo1idN0A35mtbJYxi+eNR1tBUAG3 GOttF1o3z6J+yrQ83nNs8gI+S2lCAOqpdwSQR5Yx1ymrUNmkzvuIfVvF6/Z1L+ZmQL1Lv2IWwN21 SRznAAznXYRUE706Gt9mBvaC1BqufIL7E4yns5knWLNAmrW9IS0EuSiP3c0bRJ8XgO33iHjYhqzd o7t3uVlh3yAgSDiqJ96leKIbg15NsVodOKaAsWQ6TO9W8jXuKhqIN2YAxh+Gc4aHAhqD7R15aWCd VLExv/ihiJSYJ9218qUF/Z05TWXQRQSWvfTQBAAAAAAAAA== ------=_NextPart_000_0014_01CA0F00.1A326F50-- From rishyang@gmail.com Mon Jul 27 15:04:29 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53F813A685C for ; Mon, 27 Jul 2009 15:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ydgJaSkKKhyG for ; Mon, 27 Jul 2009 15:04:27 -0700 (PDT) Received: from mail-yx0-f183.google.com (mail-yx0-f183.google.com [209.85.210.183]) by core3.amsl.com (Postfix) with ESMTP id 52E753A67FD for ; Mon, 27 Jul 2009 15:04:27 -0700 (PDT) Received: by yxe13 with SMTP id 13so2847205yxe.29 for ; Mon, 27 Jul 2009 15:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GS1Kj/rJZ7dbkMGs8bkLu01AcYYLUgLLgSOYOBsYa94=; b=C/Fn8WPjrJLJZmMiEOUMXvgg2LbA9/eVwnm/9Mefrn5auyrJQ+53ixSbSwy1UQUsom 775XSVCLhDBZzWbL2/iXq0xCCl0iM8Y7d2jcPwj7U0pCP4wpyMXoye8Ipv6o6SH9ux/f LyNm6W4rRoyY1vnubihhKLB7V67Rut83AZUXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DR47Klz5kGdqMN6huxWwjcUPM1bXuC4SM8SMy1Bx7bANpUdBAJTmd+xGQW2MfXOG0j lxpM8AD3QNOefA1dHhBmf/r9h7xgFiV/Pxne2IiJdYWCxnbazbn8NFoRPO4SWU1VvGHS ECs8ArXVp9af708xRKB8eLsQIvqGq1x3Kr1pY= MIME-Version: 1.0 Received: by 10.100.126.13 with SMTP id y13mr8945742anc.71.1248731849190; Mon, 27 Jul 2009 14:57:29 -0700 (PDT) In-Reply-To: References: <8556013e0907270754l5d1d746fvac668e077e0a9144@mail.gmail.com> Date: Tue, 28 Jul 2009 05:57:29 +0800 Message-ID: <8556013e0907271457q13581d51s93096777402cc483@mail.gmail.com> From: Richard To: Dan Harkins Content-Type: multipart/alternative; boundary=0016e645b72e4a6cf4046fb70a3f Cc: emu@ietf.org, dstanley@arubanetworks.com Subject: Re: [Emu] If we use the Radius property extension X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jul 2009 22:04:29 -0000 --0016e645b72e4a6cf4046fb70a3f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, Dan: Thanks for your comments. Please check my comments inline which is identified by [Richard]. 2009/7/28 Dan Harkins > > Hi Richard, > > [Dan] On slide 11 you say you want to reuse the AAA architecture. > But EAP is not a AAA protocol. RADIUS is but you don't want to > use RADIUS. So I don't understand what reuse you're hoping to > take advantage of. ////////////////////////////////////////////////////////////////////////// [Richard] Yes, I want to reuse the AAA architecture. This is a main objective and the reason for it is described on the slide 9. For the reusing, there are two methods. One is the Radius property extension and it is a direct way to reuse the AAA; Another way is to make the WAI over EAP. As the Radius has a EAP property, so WAI over EAP establish a bridge to reuse the AAA. > > [Dan]Since EAP doesn't have a transport how do you propose to send > EAP packets from the AP to the server? Over UDP port 3810? The > same port you send WAI packets to now? If that's the case then > all EAP is doing is providing a needless encapsulation of your > WAI packet. You gain nothing by encapsulating your WAI packet > with an EAP header. //////////////////////////////////////////////////////////////////////// > [ Richard] When using the WAI over EAP, the AP would transport EAP packet (contains WAI) over Radius. Also, Please check my last email: It compares the solutions of the Radius Property extension with the WAI over EAP. The main advantage of WAI over EAP is to keep the loose coupling between the AAA and the WAPI. The reason is: Radius server need not check things going on with WAPI. (EAP-WAI). There is a standard interface (EAP-SUCCESS or EAP-FAILURE) to let Radius know the result of the authentication. From the AAA server perspective, like the other authentication methods such as EAP- TLS, there is no any special handle required for EAP-WAI. [Dan] I do have a suggestion to fix this problem. Just get rid of the "certificate authentication" exchange and have the client validate the AP's certificate and the AP validate the client's certificate. It is not necessary to have a central authority to approve of certificates, that's the whole point in using certificates. /////////////////////////////////////////////////////////////////// [ Richard] Yes, your suggestion could work well without a a central authority involved. While the current problem I try to resolve is: The WAPI protocol already exist (it needs a central authority to valide the certificate), to support (follow) it and enable it work well under the AAA architecture, I brougt forward the method of WAI over EAP. To avoid the change of the station, and minimize the influnce to the customers, the solution would only change the packet between AP (authenticator) and AAA server. To achieve this objective and avoid the influnce to the AAA, the AP should minic the station. For the WAPI protocol, please see the slide 7. > > > regards, > > Dan. > > On Mon, July 27, 2009 7:54 am, Richard wrote: > > Hi, all: > > > > The link to the slide: > > http://www.ietf.org/proceedings/75/slides/emu-10.ppt > > Thanks for your comments in the EMU session. > > > > Yes, the Radius property extension could be one solution. > > The problem to it is: > > The Radius has to handle the WAPI packet (Certificate authentication > > response), > > it would lead to the tight coupling between Radius and WAPI (ASE). > > > > Compared to it, the EAP solution is simple and make it loose coupling > with > > WAPI. > > Radius server need not check things going on with WAPI. (EAP-WAI). > > There is a standard interface to let Radius to know the result > > of authentication (EAP-SUCCESS or EAP-FAILURE). > > From the AAA server perspective, there is no any special for EAP-WAI > > to the other authentication methods such as EAP-TLS. > > The loose coupling for EAP solution is a main advantage to the Radius > > extension > > method. > > > > Yes, the EAP framework is to authenticate the station (supplicant). I > > guess > > the > > main reason is that most authentication methods are to authenticate the > > supplicant, > > and the behavior of Authenticator is pass-through. > > Now, WAPI is a use case of authenticating the authenticator (the behavior > > of > > Authenticator > > is not Pass-through). And it may have more protocols which have similar > > behavior > > (use cases) like the WAPI. > > Could we allow the EAP method behavior like the WAI over EAP instead of > > forbidding it? > > > > Any way, the problem I am trying to resolve is to reuse the AAA and > > avoid the tight coupling between Radius and WAPI (ASE). > > > > Do you have any better solution to it? > > > > Regards > > Richard > > _______________________________________________ > > Emu mailing list > > Emu@ietf.org > > https://www.ietf.org/mailman/listinfo/emu > > > > > --0016e645b72e4a6cf4046fb70a3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, Dan:
=A0
Thanks for your comments. Please check my comments inline which is ide= ntified by
[Richard].

2009/7/28 Dan Harkins <dharkins@lounge.org>

=A0Hi Richard,

[Dan]= =A0On slide 11 you say you want to reuse the AAA architecture.
But EAP i= s not a AAA protocol. RADIUS is but you don't want to
use RADIUS. So I don't understand what reuse you're hoping to
ta= ke advantage of.
=A0=A0 ///////////////////////////////////////////////////////////////= ///////////
=A0=A0 [Richard] Yes, I want to reuse the AAA architecture. This is a = main objective
=A0 =A0and the reason for it is described on the slide 9. =A0For the r= eusing,
=A0=A0 there are two methods. One is the Radius property extension and= it is a direct
=A0=A0 way to reuse the AAA; Another way is to make the WAI over EAP. = As the Radius
=A0=A0 has a EAP property, so WAI over EAP establish a bridge to reuse= the AAA.

[Dan]Since EAP = doesn't have a transport how do you propose to send
EAP packets from= the AP to the server? Over UDP port 3810? The
same port you send WAI packets to now? If that's the case then
all E= AP is doing is providing a needless encapsulation of your
WAI packet. Yo= u gain nothing by encapsulating your WAI packet
with an EAP header.
=A0=A0 ///////////////////////////////////////////////////////////////= /////////
[ Richard]=A0When using the WAI = over EAP, the AP would transport EAP packet
(contains WAI) over= Radius.
=A0=A0 Also, Please check my last email: It=A0compares the solutions o= f
=A0=A0 the Radius Property extension with the WAI over EAP.
=A0=A0=A0The main advantage of WAI over EAP=A0is to keep the loose cou= pling
=A0=A0 between the AAA and the WAPI.
=A0=A0 The reason is:
=A0 Radius server need not check things going on with WAPI. (EAP-WAI).=
=A0 There is a standard interface=A0 (EAP-SUCCESS or EAP-FAILURE)
=A0 to let Radius know the result of the authentication.
=A0 From t= he AAA server perspective, like the other authentication methods
=A0such as EAP- TLS,=A0 there is no any special handle required for EA= P-WAI.
=A0[Dan] I do have a suggestion to fix this problem. Just get rid of t= he
"certificate authentication" exchange and have the client v= alidate
the AP's certificate and the AP validate the client's ce= rtificate.
It is not necessary to have a central authority to approve of
certificat= es, that's the whole point in using certificates.
///////////////////////////////////////////////////////////////////
[ Richard] Yes, your suggestion could work well without a a central au= thority=A0involved.
While the current problem I try to resolve is: The WAPI protocol alrea= dy exist (it needs a central=A0authority=A0to valide the certificate), to s= upport (follow)=A0it and enable it work well
under the AAA architecture, I brougt forward the method of WAI over EA= P.
To avoid the change of the station, and minimize the influnce to the c= ustomers,
the solution would only change the packet between AP (authenticator) a= nd AAA server.
To achieve this objective and avoid the influnce to the AAA,
the AP should minic the station.
For the WAPI protocol, please see the slide 7.
=A0


=A0regards,=

=A0Dan.

On Mon, July 27, 2009 7:54 am, Richard wrote:
>= Hi, all:
>
> The link to the slide:
> http://www= .ietf.org/proceedings/75/slides/emu-10.ppt
> Thanks for your comments in the EMU session.
>
> Yes, the = Radius property extension could be one solution.
> The problem to it = is:
> The Radius has to handle the WAPI packet (Certificate authentic= ation
> response),
> it would lead to the tight coupling between Radius = and WAPI (ASE).
>
> Compared to it, the EAP solution is simple = and make it loose coupling with
> WAPI.
> Radius server need no= t check things going on with WAPI. (EAP-WAI).
> There is a standard interface to let Radius to know the result
>= of authentication (EAP-SUCCESS or EAP-FAILURE).
> From the AAA serve= r perspective, there is no any special for EAP-WAI
> =A0to the other = authentication methods such as EAP-TLS.
> The loose coupling for EAP solution is a main advantage to the Radius<= br>> extension
> method.
>
> Yes, the EAP framework is= to authenticate the station (supplicant). I
> guess
> the
> main reason is that most authentication methods are to authenticate th= e
> supplicant,
> and the behavior of Authenticator is pass-thr= ough.
> Now, WAPI is a use case of authenticating the authenticator (= the behavior
> of
> Authenticator
> =A0is not Pass-through). And it may h= ave more protocols which have similar
> behavior
> (use cases) = like the WAPI.
> Could we allow the EAP method behavior like the WAI = over EAP instead of
> forbidding it?
>
> Any way, the problem I am trying to res= olve is to reuse the AAA and
> avoid the tight coupling between Radiu= s and WAPI (ASE).
>
> Do you have any better solution to it? >
> Regards
> Richard
> __________________= _____________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/list= info/emu
>



--0016e645b72e4a6cf4046fb70a3f-- From yaronf@checkpoint.com Thu Jul 30 02:50:47 2009 Return-Path: X-Original-To: emu@core3.amsl.com Delivered-To: emu@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C9C3A6908 for ; Thu, 30 Jul 2009 02:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGWsidMlnfdR for ; Thu, 30 Jul 2009 02:50:43 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id D80013A6814 for ; Thu, 30 Jul 2009 02:50:39 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 2842529C00C; Thu, 30 Jul 2009 12:50:58 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id EE5BF29C007 for ; Thu, 30 Jul 2009 12:50:57 +0300 (IDT) X-CheckPoint: {4A716B84-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n6U9od3d025997 for ; Thu, 30 Jul 2009 12:50:39 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 30 Jul 2009 12:50:38 +0300 From: Yaron Sheffer To: "emu@ietf.org" Date: Thu, 30 Jul 2009 12:50:35 +0300 Thread-Topic: Tunnel requirements: a few comments Thread-Index: AcoQ+y9h9jyzDqXYR4CbmYZuPZjFug== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC80133E557CC5A@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00AE_01CA110B.F2F18F30" MIME-Version: 1.0 Subject: [Emu] Tunnel requirements: a few comments X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jul 2009 09:50:47 -0000 ------=_NextPart_000_00AE_01CA110B.F2F18F30 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00AF_01CA110B.F2F18F30" ------=_NextPart_001_00AF_01CA110B.F2F18F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Referring to Sec. 3.5 of http://tools.ietf.org/html/draft-ietf-emu-eaptunnel-req-03, there should be an indication to the application that is using EAP that such "strange" authentication took place. For example, the VoIP server may than make sure that only calls to 911 or 112 are allowed. Otherwise there is no way to authorize the user without some backchannel into the AAA. So I propose to add: "The tunnel method, if it supports emergency services, MUST provide an indication at the EAP or EAP-method level that such authentication took place; the indication MUST be unencrypted but integrity protected". Sec. 4.1.1 has requirements on algorithm agility. They are important, but insufficient. I propose to mention that when the tunnel method uses certificates, it MUST be possible to migrate to new algorithms for such certificates as well. (This possibly belongs in 4.2.1). 4.5.1: I suggest to mention that even in cases where passwords are *not* sent in the clear (e.g. challenge-response methods), server authentication is still a MUST. Sec. 4.5.4 mentioned "housekeeping functions". It would be useful to add some detail here. Thanks, Yaron ------=_NextPart_001_00AF_01CA110B.F2F18F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Referring to Sec. 3.5 of http:= //tools.ietf.org/html/draft-ietf-emu-eaptunnel-req-03, there should be an indication to the application that is using EAP that such = “strange” authentication took place. For example, the VoIP server may than make = sure that only calls to 911 or 112 are allowed. Otherwise there is no way to = authorize the user without some backchannel into the = AAA.

 

So I propose to add:

 

“The tunnel method, if it supports emergency = services, MUST provide an indication at the EAP or EAP-method level that such authentication = took place; the indication MUST be unencrypted but integrity = protected”.

 

Sec. 4.1.1 has requirements on algorithm agility. = They are important, but insufficient. I propose to mention that when the tunnel = method uses certificates, it MUST be possible to migrate to new algorithms for = such certificates as well. (This possibly belongs in = 4.2.1).

 

4.5.1: I suggest to mention that even in cases where passwords are *not* sent = in the clear (e.g. challenge-response methods), server authentication is still = a MUST.

 

Sec. 4.5.4 mentioned “housekeeping = functions”. It would be useful to add some detail here.

 

Thanks,

         =    Yaron

------=_NextPart_001_00AF_01CA110B.F2F18F30-- ------=_NextPart_000_00AE_01CA110B.F2F18F30 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDczMDA5NTAzNVowIwYJKoZIhvcNAQkEMRYEFN9TTePXH67H g9A01HZmDj2xX3t6MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA EZbPD7QdTtSnHK8b9OfV4Hgt4kr3jhpoWw1nDgRH1oP1FfO5tEsf7cAaKreegNtVtVkOdEgEgos1 odnLXS+B2tzjAL9IYbOHro1zwPZzNZFdBJdrY+zYPR2aZuFhgTixdNDahT4NhTenYnFj3pBStB4W gypLwof0lBRXUQMe+pi6u/WJ5o2iA8TGO18k4FhXzpiZnHFA6xzR1qU17jFeNy5JwjLioFqgl3Nb isrt47IDcGlXhEsWuze2XKafaQT2Gy7zSVQ6RDHtnIBTwiAJIKw0gfFb1cUpWAFv42VEQBgkzBPP DCMiHdKyBCqoY86mAm5a9GJOh0uXr7b3DA9TSgAAAAAAAA== ------=_NextPart_000_00AE_01CA110B.F2F18F30--