From bernard_aboba@hotmail.com Tue Nov 10 19:16:50 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 0A0A928C27F for ; Tue, 10 Nov 2009 19:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.313 X-Spam-Level: X-Spam-Status: No, score=-1.313 tagged_above=-999 required=5 tests=[AWL=1.285, 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 PQhdCPVwYN0U for ; Tue, 10 Nov 2009 19:16:39 -0800 (PST) Received: from blu0-omc3-s38.blu0.hotmail.com (blu0-omc3-s38.blu0.hotmail.com [65.55.116.113]) by core3.amsl.com (Postfix) with ESMTP id 8B3CC3A67D2 for ; Tue, 10 Nov 2009 19:16:39 -0800 (PST) Received: from BLU137-DS2 ([65.55.116.74]) by blu0-omc3-s38.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 10 Nov 2009 19:17:07 -0800 X-Originating-IP: [24.19.160.219] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 10 Nov 2009 19:17:15 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01CA623A.6A030B10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpicA6su24Zxn+bQ6KOYF92eTsy4wADWKJA Content-Language: en-us X-OriginalArrivalTime: 11 Nov 2009 03:17:07.0259 (UTC) FILETIME=[72F540B0:01CA627D] Subject: [Emu] Comments on Section 6 of draft-schulzrinne-ecrit-unauthenticated-access 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, 11 Nov 2009 03:16:50 -0000 ------=_NextPart_000_0032_01CA623A.6A030B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Section 6 " signalling allows an IEEE 802.1X to occur without exchanging cryptogrpahic keys" [BA] Not sure what this is saying. In IEEE 802.1X-2004, there is no encryption supported. However, EAP is still run. This can include methods that don't generate keys (e.g. EAP-MD5). But the issue here is client unauthenticated access, not key generation, right? Section 6.1 " In general, link layer emergency indications provide good integration into the actual network access procedure regarding the enabling of means to recognize and prioritize an emergency service request from an end host at a very early stage of the network attachment procedure. However, support in end hosts for such methods cannot be considered to be commonly available. " [BA] I'm not sure what this is referring to. If it's referring to QoS, those mechanisms are independent of emergency indications (e.g. WFA WMM). If it's talking about higher layer emergency service prioritization, that's also independent of the lower layer. So what exactly is a host expected to do at the lower layer to distinguish an emergency call? Section 6.2 "In normal operation, EAP related information will only be recognized in the NAS. Any entity residing between end host and NAS should not be expected to understand/parse EAP messages. " [BA] The EAP architecture requires the NAS to be EAP-method agnostic if it's acting as a pass-through. So even the NAS can't be depended upon to understand/parse EAP methods. But why would it need to? " 1.b) Emergency NAI: The NAI comes with a realm or username part indicating emergency (e.g. 'emergency@emergency.com'). An advantage of this method for NAA cases is that no new requirements are put on the involved signaling procedures. Only the identity used for network entry is impacted. Potential disadvantages include that different methods to indicate emergency for NAA cases and standard emergency network attachments may be required. Also, modifying the NAI itself (the username@realm part) may conflict with network selection and network entry procedures, depending on the actual access network. " [BA] There are two distinct ideas being presented here. One is to define an emergency user name (e.g. "emergency"); another is to define an emergency domain (e.g. "emergency.com"). The former concept may make sense, but the latter one is dangerous since existing systems not including the emergency realm in their routing tables may just return an error. So the question is what realm should be used, if any. The problem with including any realm is that it assumes realm reachability. If reachability doesn't exist, then the host will get an error. If there is no realm, then the local realm needs to recognize the emergency username, and utilize an appropriate EAP method that allows client unauthenticated access. " 2) Emergency EAP method An emergency indication can be given by using a dedicated EAP method that is reserved for emergency network attachment only. " [BA] Why is a dedicated EAP method needed for emergency access? EMU WG has already discussed this and come up with mechanisms that would allow client unauthenticated access from any TLS-based method (e.g. server side either doesn't ask for a client cert, or accepts the client not providing one). That mechanism is supported in RFC 5216, and can also be applied to existing methods such as EAP FAST, EAP TTLSv0, PEAP, etc. In effect, the only real constraint here is that a local network advertising support for emergency calling needs to support one or more of these methods. " 2.a) Existing EAP method with new type: An existing EAP method may be used. EAP methods themselves typically do not support emergency indication. One option would be to pick a common EAP method like EAP-TLS and allocate a new method type for the same method that is exclusively reserved to emergency use. Such EAP method should be chosen in a way that the same method can support NAA cases as well as standard emergency network attachment. " Given that RFC 5216 already supports client-unauthenticated anonymous access (see Sections 2.1.4 and 2.2), why is it necessary to request allocation of a new method type? " 2.b) Existing EAP method: Same as 2a), but without assigning a new EAP method type for emergency. In this case some implicit indication must be used. For example, in cases where EAP-TLS is used in network attachment in combination with client certificates, the absence of a client certificate could be interpreted by the network as a request for emergency network attachment. " [BA] The combination of an emergency NAI *and* the absence of a client certificate would be considered a request for emergency attachment. If an NAI corresponding to an existing account is used, then normal policies will apply (which would probably require authenticated access). " 2.c) Emergency EAP method: A new EAP method could be defined that is specifically designed for emergency network entry in NAA cases. Most likely, such EAP method would not be usable for standard emergency network attachment with an existing subscription. Such dedicated emergency EAP method should be key-generating in compliance with RFC3748 to enable the regular air interface security methods even in unauthenticated operation. " [BA] Since any TLS-based method can potentially support client-unauthenticated access, it's not clear to me that there is a good case for creating yet another method. Section 6.3 " Therefore, for network attachment that is by default based on EAP authentication it is desirable also for NAA network attachment to use a key-generating EAP method (that provides an MSK key to the authenticator to bootstrap further key derivation for protecting the wireless link). " [BA] Where key generation is required (e.g. WPA/WPA2 enterprise) you don't really have a choice. " 2) Null authentication: an EAP method is performed. However, no credentials specific to either the server or the device or subscription are used as part of the authentication exchange. An example for this would be an EAP-TLS exchange with using the TLS_DH_anon (anonymous) ciphersuite. Alternatively, a publicly available static key for emergency access could be used. In the latter case, the device would need to be provisioned with the appropriate emergency key for the IAP/ISP in advance. " [BA] WPA/WPA2 enterprise mode and PSK mode are distinct; PSK mode only uses the 4-way handshake, not EAP. " 3) Device authentication: This case extends the server-only authentication case. If the device is configured with a device certificate and the IAP/ISP EAP server can rely on a trusted root allowing the EAP server to verify the device certificate, at least the device identity (e.g. the MAC address) can be authenticated by the IAP/ISP in NAA cases. An example for this are WiMAX devices that are shipped with device certificates issued under the global WiMAX device public-key infrastructure. To perform unauthenticated emergency calls, if allowed by the IAP/ISP, such devices perform EAP- TLS based network attachment with client authentication based on the device certificate. " IEEE 802.1ar might also be an example of this. ------=_NextPart_000_0032_01CA623A.6A030B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 
Section =
6
 
“   =
signalling allows an IEEE 802.1X to occur without =
exchanging

   cryptogrpahic keys”

 

[BA] Not sure what this is saying.  In IEEE 802.1X-2004, there is no = encryption supported.  However, EAP is still run.  This can include = methods that don’t generate keys (e.g. EAP-MD5).  But the issue here is = client unauthenticated access, not key generation, right? =

 

Section 6.1

 

“   In general, link layer emergency indications =
provide good integration
   into the =
actual network access procedure regarding the enabling =
of
   means to recognize and prioritize =
an emergency service request from
   an =
end host at a very early stage of the network =
attachment
   procedure.  However, =
support in end hosts for such methods cannot =
be
   considered to be commonly =
available.

”

 

[BA] I’m not sure what this is referring to.  If it’s = referring to QoS, those mechanisms are independent of emergency indications (e.g. WFA = WMM).  If it’s talking about higher layer emergency service prioritization, = that’s also independent of the lower layer.  So what exactly is a host expected = to do at the lower layer to distinguish an emergency call? =  

 

Section 6.2

 

“In normal operation, EAP =
related
   information will only be =
recognized in the NAS.  Any entity =
residing
   between end host and NAS =
should not be expected to =
understand/parse
   EAP =
messages.

”

 

[BA] The EAP architecture requires the NAS to be EAP-method agnostic if = it’s acting as a pass-through.  So even the NAS can’t be depended upon to understand/parse EAP methods.  But why would it need to? =

 

“   1.b) Emergency NAI: The NAI comes with a realm =
or username part
   indicating emergency =
(e.g. 'emergency@emergency.com').  An =
advantage
   of this method for NAA cases =
is that no new requirements are put on
   =
the involved signaling procedures.  Only the identity used =
for
   network entry is impacted.  =
Potential disadvantages include that
   =
different methods to indicate emergency for NAA cases and =
standard
   emergency network attachments =
may be required.  Also, modifying =
the
   NAI itself (the username@realm =
part) may conflict with network
   =
selection and network entry procedures, depending on the =
actual
   access =
network.

”

 

[BA] There are two distinct ideas being presented here.  One is to = define an emergency user name (e.g. “emergency”); another is to define = an emergency domain (e.g. “emergency.com”).  The former concept may = make sense, but the latter one is dangerous since existing systems not including the = emergency realm in their routing tables may just return an error.  So the = question is what realm should be used, if any.  The problem with including = any realm is that it assumes realm reachability.  If reachability = doesn’t exist, then the host will get an error.  If there is no realm, then = the local realm needs to recognize the emergency username, and utilize an appropriate EAP method that allows client unauthenticated access. =

 

“   2) Emergency EAP =
method
 
   An =
emergency indication can be given by using a dedicated EAP =
method
   that is reserved for emergency =
network attachment only.

”

 

[BA] Why is a dedicated EAP method needed for emergency access?  EMU WG = has already discussed this and come up with mechanisms that would allow = client unauthenticated access from any TLS-based method (e.g. server side = either doesn’t ask for a client cert, or accepts the client not providing = one).  That mechanism is supported in RFC 5216, and can also be applied to = existing methods such as EAP FAST, EAP TTLSv0, PEAP, etc.

 

In effect, the only real constraint here is that a local network = advertising support for emergency calling needs to support one or more of these = methods. 

 

“   2.a) Existing EAP method with new type: An =
existing EAP method may be
   used.  =
EAP methods themselves typically do not support =
emergency
   indication.  One option =
would be to pick a common EAP method =
like
   EAP-TLS and allocate a new method =
type for the same method that is
   =
exclusively reserved to emergency use.  Such EAP method should =
be
   chosen in a way that the same =
method can support NAA cases as well =
as
   standard emergency network =
attachment.
 

”

 

Given that RFC 5216 already supports client-unauthenticated anonymous access = (see Sections 2.1.4 and 2.2), why is it necessary to request allocation of a = new method type?

 

“   2.b) Existing EAP method: Same as 2a), but =
without assigning a new
   EAP method =
type for emergency.  In this case some implicit =
indication
   must be used.  For =
example, in cases where EAP-TLS is used in =
network
   attachment in combination with =
client certificates, the absence of a
   =
client certificate could be interpreted by the network as a =
request
   for emergency network =
attachment.

”

 

[BA] The combination of an emergency NAI *and* the absence of a client certificate would be considered a request for emergency = attachment.  If an NAI corresponding to an existing account is used, then normal policies = will apply (which would probably require authenticated access). =

 

“   2.c) Emergency EAP method: A new EAP method =
could be defined that is
   specifically =
designed for emergency network entry in NAA cases.  =
Most
   likely, such EAP method would not =
be usable for standard emergency
   =
network attachment with an existing subscription.  Such =
dedicated
   emergency EAP method should =
be key-generating in compliance with
   =
RFC3748 to enable the =
regular air interface security methods even =
in
   unauthenticated =
operation.

”

 

[BA] Since any TLS-based method can potentially support = client-unauthenticated access, it’s not clear to me that there is a good case for = creating yet another method.

 

Section 6.3

 

“   Therefore, for network attachment that is by =
default based on EAP
   authentication it =
is desirable also for NAA network attachment to =
use
   a key-generating EAP method (that =
provides an MSK key to the
   =
authenticator to bootstrap further key derivation for protecting =
the
   wireless link).

”

 

[BA] Where key generation is required (e.g. WPA/WPA2 enterprise) you = don’t really have a choice. 

 

“   2) Null authentication: an EAP method is =
performed.  However, no
   =
credentials specific to either the server or the device =
or
   subscription are used as part of =
the authentication exchange.  An
   =
example for this would be an EAP-TLS exchange with using =
the
   TLS_DH_anon (anonymous) =
ciphersuite.  Alternatively, a =
publicly
   available static key for =
emergency access could be used.  In =
the
   latter case, the device would need =
to be provisioned with the
   appropriate =
emergency key for the IAP/ISP in =
advance.
 

”

 

[BA] WPA/WPA2 enterprise mode and PSK mode are distinct; PSK mode only uses = the 4-way handshake, not EAP.

 

“   3) Device authentication: This case extends the =
server-only
   authentication case.  =
If the device is configured with a =
device
   certificate and the IAP/ISP EAP =
server can rely on a trusted root
   =
allowing the EAP server to verify the device certificate, at =
least
   the device identity (e.g. the =
MAC address) can be authenticated by
   =
the IAP/ISP in NAA cases.  An example for this are WiMAX devices =
that
   are shipped with device =
certificates issued under the global =
WiMAX
   device public-key =
infrastructure.  To perform =
unauthenticated
   emergency calls, if =
allowed by the IAP/ISP, such devices perform =
EAP-
   TLS based network attachment with =
client authentication based on the
   =
device certificate.

”

 

IEEE 802.1ar might also be an example of this.

------=_NextPart_000_0032_01CA623A.6A030B10-- From jsalowey@cisco.com Sun Nov 22 21:30:10 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 E92843A699D for ; Sun, 22 Nov 2009 21:30:10 -0800 (PST) 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=[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 ZOtKBn3rQame for ; Sun, 22 Nov 2009 21:30:10 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 4A96B3A6992 for ; Sun, 22 Nov 2009 21:30:10 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB6tCUurRN+K/2dsb2JhbAC8TpZLhDwE X-IronPort-AV: E=Sophos;i="4.47,269,1257120000"; d="scan'208";a="108035967" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 23 Nov 2009 05:30:06 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id nAN5U6BD001499 for ; Mon, 23 Nov 2009 05:30:06 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); Sun, 22 Nov 2009 21:30:06 -0800 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: Sun, 22 Nov 2009 21:30:05 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minutes from IETF-76 Thread-Index: Acpr/gNg+QW7uzR2S0aXr8nO7920Fg== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 23 Nov 2009 05:30:06.0723 (UTC) FILETIME=[040BD530:01CA6BFE] Subject: [Emu] Minutes from IETF-76 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, 23 Nov 2009 05:30:11 -0000 I posted draft minutes from IETF-76 at http://www.ietf.org/proceedings/09nov/minutes/emu.txt. Please send any revisions by December 9, 2009. Thanks to Paul Hoffman, Bernard Aboba and Nancy Cam-Winget for taking notes. =20 Cheers, Joe From dharkins@lounge.org Mon Nov 30 12:56:39 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 0B73A3A69B5 for ; Mon, 30 Nov 2009 12:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[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 kFNuRJkFDhsq for ; Mon, 30 Nov 2009 12:56:38 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 017943A69A6 for ; Mon, 30 Nov 2009 12:56:38 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 299B81022407E for ; Mon, 30 Nov 2009 12:56:30 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 30 Nov 2009 12:56:30 -0800 (PST) Message-ID: <70e5fb878f73a83d4ba7702e4dc46132.squirrel@www.trepanning.net> Date: Mon, 30 Nov 2009 12:56:30 -0800 (PST) From: "Dan Harkins" To: emu@ietf.org 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 Subject: [Emu] review of draft-ietf-emu-eaptunnel-req-04 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, 30 Nov 2009 20:56:39 -0000 Hello, I made some of these comments at the mic in Hiroshima but was asked to submit them to the list. - I get the feeling that this document is being written to ensure some end-game and not simply as a protocol requirements document. I mentioned that it would be nice if the tunneled method described a way to establish an EAP-TLS -style connection, either anonymous or server-side-auth-only, and then allow for subsequent authentication using another EAP method (or using specific TLVs for some password authentication) or EAP methods chained together by the tunnel. Pasi said that is the intention but it sure doesn't seem that way. - section 3.4 states that the tunnel method MUST ensure "that peer identity is not disclosed to the authenticator and any other intermediaries before the server that terminates the tunnel method." EAP is supposed to be a 2 party protocol that, for optimization, can have functionality split between a pass-thru authenticator and a EAP method-terminating server. But it seems wrong to put forth the optimization as if it's a requirement for the tunnel method. Please change this to something like "the identity of the peer used for authentication purposes MUST NOT be obtainable by any entity other than the EAP server terminating the tunnel method." - 3.6 seems somewhat pointless. "The tunnel method SHOULD support carrying of NEA protocols" and "these protocols may be required to be carried in an EAP method." Since the tunneled EAP method can tunnel EAP methods then this "requirement" should just naturally flow out of another requirement. Please remove section 3.6. - 3.7 describes "credentials [that] may only partially authenticate the identity of the peer". Huh? What kind of credentials are these? Please describe these credentials. Additionally, "the tunnel may be used to communicate additional data". This is so vague as to be meaningless. A nonce could satisfy this "requirement", and so could 8 bits of RESERVED-- set to zero before transmitting and ignored upon receipt-- for that matter. Please remove this. - 3.8 mentions a use of "extensibility is support for authentication frameworks other than EAP." That seems like a huge stretch of the work we are chartered to do. I suggest that line be removed. - 4.1.2 is inappropriate. It is not the purpose of a document describing the requirements for a protocol to direct the working group how to evaluate potential protocols against those requirements. When I brought this up in Hiroshima a response was (I paraphrase), "that the working group had consensus to use existing work and so this is just a restatement of that consensus." Which raises another interesting point without addressing my comment. That other point is that if there is working group consensus then it is not necessary to have section 4.1.2 then. The fact that 4.1.2 is in the document leads one to believe that perhaps there is a fear that such support might have evaporated. The working group does not need to be constrained in its decision- making process. The process is defined and understood and it is inappropriate for a _protocol requirements document_ to say, "hey remember way back when a sample of active participants seemed to agree on a vague concept, well now you SHOULD select one of the two candidates here." Please remove 4.1.2. - 4.2.1.1.1 if TLS is required and "[a]ll versions of TLS meet [cipher suite negotiation] requirements" then what's the point of this section? Please remove section 4.2.1.1.1. - 4.2.1.1.3 begins saying "A tunnel method MUST provide unidirectional authentication from authentication server to EAP peer and mutual authentication between authentication server and EAP peer." This is a nonsense statement. Either it's unidirectional or it's mutual, it can't be both. Additionally, it says "mandatory to implement cipher suites MUST NOT include...mutually anonymous authentication...." Seeing as how this subsection is under 4.2.1 and 4.2.1.1.1 describes these as TLS cipher suites then I really think this should be changed. An anonymous TLS cipher suite negotiated by the EAP tunnel method will be extremely valuable when combined with something like EAP-pwd as the inner method. That would provide a way to securely satisfy the credential provisioning requirement (which is a MUST by the way). Please restate the requirement to say something along the lines of "if an anonymous TLS ciphersuite is used by the outer tunnel then an inner method providing mutual authentication MUST be used." - 4.2.1.2 requires replay protection and then goes on to say that TLS (which is required by 4.2.1) satisfies this requirement. Please remove 4.2.1.2 since it does not add a new requirement. regards, Dan. From dharkins@lounge.org Mon Nov 30 14:09:00 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 E59453A69D5 for ; Mon, 30 Nov 2009 14:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[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 dXQIGy+SWVNq for ; Mon, 30 Nov 2009 14:09:00 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 13ACF3A69EB for ; Mon, 30 Nov 2009 14:09:00 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id DAB0D1022407E; Mon, 30 Nov 2009 14:08:52 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 30 Nov 2009 14:08:53 -0800 (PST) Message-ID: <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> In-Reply-To: References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> Date: Mon, 30 Nov 2009 14:08:53 -0800 (PST) From: "Dan Harkins" To: "Joseph Salowey (jsalowey)" 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] Issue #7: Password Authentication 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, 30 Nov 2009 22:09:01 -0000 Hi Joe, Sorry for the tardy reply.... I guess it depends on what you mean by "expose". If it means a kind of flashing-- here's the username and password!-- then no this is not sufficient. Such an exposure is certainly a problem but popular ways to get around this exposure are not satisfactory. What I'm saying is that Jeff Schiller's old maxim of "NO PLAINTEXT PASSWORDS!" is necessary but not sufficient. Password-derived data-- "I'll hash in the password and a couple of nonces so it's not a plaintext password anymore"-- also poses a problem. So to answer your question of whether any modification is needed, yes it is. Password-based authentication methods are flawed by definition because the attacker can always be wildly lucky and guess the password at any time-- whether the attack is on-line or off-line. Therefore the definition should say _exactly_ what kind of property is desired in a tunneled method that employs username and password for authentication. What needs to be said is that when using password-based authentication, each attack MUST NOT leak more than a single bit of information-- that single bit being whether a singular guess is correct or not. I suggest using the canonical definition of "dictionary attack" from the cryptographic literature: "The advantage any attacker gains against the tunneled method when employing a username and password for authentication MUST be through interaction and not computation". regards, Dan. On Thu, August 6, 2009 12:41 pm, Joseph Salowey (jsalowey) wrote: > Section 3.1 already states: > > " ... The tunnel method MUST support this use case. > However, 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. The combination of the tunnel authentication and password > authentication MUST enable mutual authentication." > > Is there any modification necessary? > > Joe > >> -----Original Message----- >> From: Alan DeKok [mailto:aland@deployingradius.com] >> Sent: Thursday, August 06, 2009 1:00 PM >> To: Dan Harkins >> Cc: Joseph Salowey (jsalowey); emu@ietf.org >> Subject: Re: [Emu] Issue #7: Password Authentication >> >> Dan Harkins wrote: >> > Perhaps it would be a good idea to mandate that the >> method used to >> > authenticate the tunnel (outer method, whatever you want to call >> > it) MUST NOT be susceptible to a dictionary attack if it is >> going to >> > be used to transport a username and plaintext password to the >> > authentication server. >> >> That is reasonable. >> >> Alan DeKok. >> >