From aland@deployingradius.com Tue Dec 1 02:03:38 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 26E283A63D3 for ; Tue, 1 Dec 2009 02:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.547 X-Spam-Level: X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599] 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 nHVyM7LKr5Wd for ; Tue, 1 Dec 2009 02:03:37 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 0CAF83A6A2B for ; Tue, 1 Dec 2009 02:03:36 -0800 (PST) Message-ID: <4B14E9F0.5050905@deployingradius.com> Date: Tue, 01 Dec 2009 11:03:28 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Harkins References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> In-Reply-To: <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 01 Dec 2009 10:03:38 -0000 Dan Harkins wrote: > 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. OK, but which attacks are we preventing? The current text says that the only parties who can see the plain-text password are EAP peer and server. i.e. the ones at either end of the TLS connection. Do you think that this is OK, or insecure? > 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. OK. > 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". The current text doesn't say that, but it is a property of the authentication method. We have two attack scenarios: peer and server. As peer, the attacker suggests a password, and the server either ACKs it or NAKs it. That is a single bit of data. As a server, the attacker must set up a TLS connection to the peer. Since the attacker is presumed to *not* be able to spoof the certificates, the peer will never send a password, and the attacker gains nothing. If we presume that the attacker can successfully attack TLS, then we have issues larger than exposing user passwords. If the peer does not properly validate TLS certificates (via user intervention or programmer error), then yes... the complete password can leak. Preventing attacks due to user error is hard. The only thing we can safely do here is suggest ways to minimize the attacks. e.g. The peer can request authentication for a realm (@example.com), and validate that the server certificate is "owned" by that realm. This practice is in wide-spread use today. Alan DeKok. From dharkins@lounge.org Tue Dec 1 02:44: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 AE2F73A684A for ; Tue, 1 Dec 2009 02:44:09 -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 UA5Ai7Og38HL for ; Tue, 1 Dec 2009 02:44:08 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 8ADE63A6824 for ; Tue, 1 Dec 2009 02:44:08 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6DB591022407E; Tue, 1 Dec 2009 02:44:00 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Dec 2009 02:44:00 -0800 (PST) Message-ID: <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> In-Reply-To: <4B14E9F0.5050905@deployingradius.com> References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> Date: Tue, 1 Dec 2009 02:44:00 -0800 (PST) From: "Dan Harkins" To: "Alan DeKok" 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: Tue, 01 Dec 2009 10:44:09 -0000 Hi Alan, On Tue, December 1, 2009 2:03 am, Alan DeKok wrote: > Dan Harkins wrote: >> 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. > > OK, but which attacks are we preventing? Don't think of it as "which attacks are we preventing", we're modeling the protocol and ascribing a desired property to the modeled protocol. What is that property? "Not exposed" is not a property. > The current text says that the only parties who can see the plain-text > password are EAP peer and server. i.e. the ones at either end of the > TLS connection. > > Do you think that this is OK, or insecure? If the world only consisted of EAP peers and servers then we would not have to worry. Sadly, that is not the case. The text says the method "MUST NOT expose" the username and password. The word "expose" is not defined and is very vague and open to interpretations that would result in an insecure protocol. I think there is a property in a properly modeled protocol that could replace that vague term. >> 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. > > OK. > >> 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". > > The current text doesn't say that, but it is a property of the > authentication method. We have two attack scenarios: peer and server. I know it doesn't say that! I'm proposing that it does! > As peer, the attacker suggests a password, and the server either ACKs > it or NAKs it. That is a single bit of data. Yes. > As a server, the attacker must set up a TLS connection to the peer. > Since the attacker is presumed to *not* be able to spoof the > certificates, the peer will never send a password, and the attacker > gains nothing. Yes. > If we presume that the attacker can successfully attack TLS, then we > have issues larger than exposing user passwords. If the peer does not > properly validate TLS certificates (via user intervention or programmer > error), then yes... the complete password can leak. Let's assume TLS is secure. > Preventing attacks due to user error is hard. The only thing we can > safely do here is suggest ways to minimize the attacks. e.g. The peer > can request authentication for a realm (@example.com), and validate that > the server certificate is "owned" by that realm. This practice is in > wide-spread use today. What I don't think you seem to realize is that the definition I proposed works for the 2 situations you came up with. I am offering a suggestion for a more accurate definition of what we want out of this protocol. I am not suggesting that TLS is insecure nor am I suggesting that the 2 apparent candidates for coronation as The New EMU-approved EAP Tunneling Method have flaws. I am saying that the current requirement is vague and may not be accurate for some reasonable definitions of "expose". I suggest a better, and more accurate description of this property. Is there a problem with my suggestion? Dan. From aland@deployingradius.com Tue Dec 1 02:52: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 9E1C63A6841 for ; Tue, 1 Dec 2009 02:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.701, BAYES_00=-2.599] 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 B-v1xen9dKP6 for ; Tue, 1 Dec 2009 02:52:09 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id D811F3A67FC for ; Tue, 1 Dec 2009 02:52:08 -0800 (PST) Message-ID: <4B14F550.80903@deployingradius.com> Date: Tue, 01 Dec 2009 11:52:00 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Harkins References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> In-Reply-To: <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Tue, 01 Dec 2009 10:52:09 -0000 Dan Harkins wrote: > The text says the method > "MUST NOT expose" the username and password. The word "expose" is not > defined and is very vague and open to interpretations that would result > in an insecure protocol. I think there is a property in a properly modeled > protocol that could replace that vague term. OK. > I am saying that the current requirement is > vague and may not be accurate for some reasonable definitions of "expose". > I suggest a better, and more accurate description of this property. Is > there a problem with my suggestion? No. I just want to be sure I understand what you're getting at. Can you propose specific modifications to the text? i.e. quote the current text, and then write what you think it should say. Alan DeKok. From dharkins@lounge.org Tue Dec 1 13:33: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 8B74D28C130 for ; Tue, 1 Dec 2009 13:33:31 -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=[AWL=-0.000, 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 u2QN8VM6laRB for ; Tue, 1 Dec 2009 13:33:30 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id CD7F228C106 for ; Tue, 1 Dec 2009 13:33:30 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 59ABCA88812E; Tue, 1 Dec 2009 13:33:23 -0800 (PST) Received: from 216.31.249.246 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Dec 2009 13:33:23 -0800 (PST) Message-ID: <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> In-Reply-To: <4B14F550.80903@deployingradius.com> References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> Date: Tue, 1 Dec 2009 13:33:23 -0800 (PST) From: "Dan Harkins" To: "Alan DeKok" 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: Tue, 01 Dec 2009 21:33:31 -0000 Alan, Yes, I can propose a specific modification. In fact, I did already. It just got truncated from the thread. What I suggest is that in section 3.1, in the middle of the first paragraph (the text that Joe was quoting originally), remove this: "The tunnel method MUST support transporting the username and password to the authentication server. 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." and put this in its stead: "The advantage any attacker gains against the tunneled method when employing a username and password for authentication MUST be through interaction and not computation". I believe that captures the property we want the tunnel method to have and is not so vague. It applies to active attacks against the authenticator, active attacks against the client, passive attacks between them and between the authenticator and any authentication server that may exist, and all forms of man-in-the-middle and dictionary attack that could be launched against the legitimate participants in this tunnel method. Dan. On Tue, December 1, 2009 2:52 am, Alan DeKok wrote: > Dan Harkins wrote: >> The text says the method >> "MUST NOT expose" the username and password. The word "expose" is not >> defined and is very vague and open to interpretations that would result >> in an insecure protocol. I think there is a property in a properly >> modeled >> protocol that could replace that vague term. > > OK. > >> I am saying that the current requirement is >> vague and may not be accurate for some reasonable definitions of >> "expose". >> I suggest a better, and more accurate description of this property. Is >> there a problem with my suggestion? > > No. I just want to be sure I understand what you're getting at. > > Can you propose specific modifications to the text? i.e. quote the > current text, and then write what you think it should say. > > Alan DeKok. > From aland@deployingradius.com Wed Dec 2 02:48:55 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 7CA633A6874 for ; Wed, 2 Dec 2009 02:48:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.073 X-Spam-Level: X-Spam-Status: No, score=-2.073 tagged_above=-999 required=5 tests=[AWL=0.526, BAYES_00=-2.599] 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 vFa91U3A-4C5 for ; Wed, 2 Dec 2009 02:48:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 7B3603A688E for ; Wed, 2 Dec 2009 02:48:54 -0800 (PST) Message-ID: <4B16460D.6050406@deployingradius.com> Date: Wed, 02 Dec 2009 11:48:45 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Harkins References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> In-Reply-To: <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Wed, 02 Dec 2009 10:48:55 -0000 Dan Harkins wrote: > Yes, I can propose a specific modification. In fact, I did already. It wasn't clear that the text was the suggested replacement. > It just got truncated from the thread. What I suggest is that in > section 3.1, in the middle of the first paragraph (the text that Joe > was quoting originally), remove this: > > "The tunnel method MUST support transporting the username > and password to the authentication server. 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." > > and put this in its stead: > > "The advantage any attacker gains against the tunneled method > when employing a username and password for authentication MUST > be through interaction and not computation". > > I believe that captures the property we want the tunnel method to > have and is not so vague. Except it *removes* the requirement that the tunneled method transport the username and password. Given the capabilities of widely deployed systems, I think that this requirement should be kept. > It applies to active attacks against the > authenticator, active attacks against the client, passive attacks > between them and between the authenticator and any authentication > server that may exist, and all forms of man-in-the-middle and > dictionary attack that could be launched against the legitimate > participants in this tunnel method. How about simply adding your text?: "The tunnel method MUST support transporting the username and password to the authentication server. 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. That is, the advantage any attacker gains against the tunneled method when employing a username and password for authentication MUST be through interaction and not computation". I think this addresses your concerns, while simultaneously stating clearly the specific requirements. Alan DeKok. From dharkins@lounge.org Wed Dec 2 12:08:25 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 72E9428C0EE for ; Wed, 2 Dec 2009 12:08:25 -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 UTxl1ACIcbQr for ; Wed, 2 Dec 2009 12:08:24 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 8431E28C0E4 for ; Wed, 2 Dec 2009 12:08:24 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id DAAD1102240AE; Wed, 2 Dec 2009 12:08:16 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 2 Dec 2009 12:08:16 -0800 (PST) Message-ID: <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> In-Reply-To: <4B16460D.6050406@deployingradius.com> References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> Date: Wed, 2 Dec 2009 12:08:16 -0800 (PST) From: "Dan Harkins" To: "Alan DeKok" 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: Wed, 02 Dec 2009 20:08:25 -0000 Hi Alan, My heartburn over the "MUST tranport the username and password" text is that it seems to be mandating some particular deployment and not mandating functionality. The introductory text talks about cases where the authentication server does not have cleartext access to, or a consistent transform of, the password. If the authentication server doesn't have cleartext access or a consistent transform of the password then what does requiring that the tunnel method transport the username and password to it solve? This requirement just seems to say that the tunnel method must be implemented in a way that it can separate the tunnel establishment stuff from the password authentication stuff and that is not a functional requirement. If the requirement is that the tunnel method MUST support username and password authentication where the authentication server doesn't have cleartext access to, or a consistent transform of, the password then why not just say it directly? You have added a "That is," as an introduction to my suggested text which implies that it's just a restatement of the previous text; it isn't. The existing text says the tunnel method "MUST NOT expose the username and password to parties in the communication path between the peer and the EAP server...." As I said, exposing password-derived data is a way to comply with this requirement but it is flawed and insecure. That text also doesn't state anything about protecting the username and password when it's transporting it to the authentication server (which come to think of it is quite odd). My text does. I think it is better to just state what property we want in a tunnel method without ambiguity. I think my suggested replacement text is better than your compromise. Dan. On Wed, December 2, 2009 2:48 am, Alan DeKok wrote: > Dan Harkins wrote: >> Yes, I can propose a specific modification. In fact, I did already. > > It wasn't clear that the text was the suggested replacement. > >> It just got truncated from the thread. What I suggest is that in >> section 3.1, in the middle of the first paragraph (the text that Joe >> was quoting originally), remove this: >> >> "The tunnel method MUST support transporting the username >> and password to the authentication server. 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." >> >> and put this in its stead: >> >> "The advantage any attacker gains against the tunneled method >> when employing a username and password for authentication MUST >> be through interaction and not computation". >> >> I believe that captures the property we want the tunnel method to >> have and is not so vague. > > Except it *removes* the requirement that the tunneled method transport > the username and password. Given the capabilities of widely deployed > systems, I think that this requirement should be kept. > >> It applies to active attacks against the >> authenticator, active attacks against the client, passive attacks >> between them and between the authenticator and any authentication >> server that may exist, and all forms of man-in-the-middle and >> dictionary attack that could be launched against the legitimate >> participants in this tunnel method. > > How about simply adding your text?: > > "The tunnel method MUST support transporting the username > and password to the authentication server. 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. That is, the advantage any attacker gains > against the tunneled method when employing a username and password > for authentication MUST be through interaction and not > computation". > > I think this addresses your concerns, while simultaneously stating > clearly the specific requirements. > > Alan DeKok. > From aland@deployingradius.com Wed Dec 2 13:35: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 C8A6928C0E2 for ; Wed, 2 Dec 2009 13:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.421, BAYES_00=-2.599] 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 3RovME1teGep for ; Wed, 2 Dec 2009 13:35:28 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 97E923A6943 for ; Wed, 2 Dec 2009 13:35:28 -0800 (PST) Message-ID: <4B16DD97.7040501@deployingradius.com> Date: Wed, 02 Dec 2009 22:35:19 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Harkins References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> In-Reply-To: <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Wed, 02 Dec 2009 21:35:29 -0000 Dan Harkins wrote: > My heartburn over the "MUST tranport the username and password" text > is that it seems to be mandating some particular deployment and not > mandating functionality. Any authentication system that stores passwords has a limited set of choices. They can store clear-text, or versions modified by a particular cryptographic algorithm (md5, unix crypt, salted, SRP, etc.). From the point of view of the client, the only authentication method which is *known* to be compatible with all possible storage mechanisms is to send clear-text passwords. I would wager that the majority of systems today store passwords in non-clear-text form. Unix crypt, Active Directory, etc. are all widely used examples of this. So no, I do not believe that the requirement is mandating a particular deployment. I believe it is mandating the lowest-common denominator, where clients can be sure that they will be authenticated everywhere that they have credentials stored. In any case, Section 4.5 of the draft discusses the reasons for transport of clear-text passwords in more detail. > The introductory text talks about cases where > the authentication server does not have cleartext access to, or a > consistent transform of, the password. If the authentication server > doesn't have cleartext access or a consistent transform of the password > then what does requiring that the tunnel method transport the username > and password to it solve? A huge number of real-world deployment problems. If the server has access to the clear-text password, it can implement the client side for *any* authentication method. It's not too much of stretch to believe that a server with access to password transform X can implement *both* the client and server side. > If the requirement is that the tunnel method MUST support username and > password authentication where the authentication server doesn't have > cleartext access to, or a consistent transform of, the password then why > not just say it directly? Because that's a *reason* for the requirement. It's not a requirement. The reasons are given earlier in the draft (Section 4.5), and do not need to be repeated here. > You have added a "That is," as an introduction to my suggested text > which implies that it's just a restatement of the previous text; it > isn't. The existing text says the tunnel method "MUST NOT expose the > username and password to parties in the communication path between the > peer and the EAP server...." Yes... > As I said, exposing password-derived data > is a way to comply with this requirement but it is flawed and insecure. We already discussed the security in a previous exchange. You had agreed that there were no *new* security problems from using this method. > That text also doesn't state anything about protecting the username and > password when it's transporting it to the authentication server (which > come to think of it is quite odd). My text does. Section 4.5.1.1 gives that requirement. There is no need to re-state it in other places. > I think it is better to just state what property we want in a tunnel > method without ambiguity. I think my suggested replacement text is better > than your compromise. The draft addresses your other concerns (historical reasons for using clear-text passwords, requirements on security of clear-text passwords, etc.). I find your suggested text vague, and would prefer to see specific requirements. My guess is that if you extend your text to describe the requirements for clear-text password security, you will be simply reproducing existing text from elsewhere in the document. Alan DeKok. From dharkins@lounge.org Wed Dec 2 15:10:04 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 CD3353A69BA for ; Wed, 2 Dec 2009 15:10:04 -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 VXIuZ5c41ryC for ; Wed, 2 Dec 2009 15:10:03 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 204303A69AD for ; Wed, 2 Dec 2009 15:10:03 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 5BC50102240AE; Wed, 2 Dec 2009 15:09:55 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 2 Dec 2009 15:09:55 -0800 (PST) Message-ID: In-Reply-To: <4B16DD97.7040501@deployingradius.com> References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> Date: Wed, 2 Dec 2009 15:09:55 -0800 (PST) From: "Dan Harkins" To: "Alan DeKok" 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: Wed, 02 Dec 2009 23:10:05 -0000 Alan, Slicing up my posts and building up a straw man army is very distracting. You attempted to help by adding my comment to the problematic text. That didn't help, thanks for the effort though. Joe, Katrin, Steve, my comment remains. There is a property we need in the tunnel method and the requirements at the beginning of 3.1 do not, in my opinion, adequately describe that property. My text does. Dan. On Wed, December 2, 2009 1:35 pm, Alan DeKok wrote: > Dan Harkins wrote: >> My heartburn over the "MUST tranport the username and password" text >> is that it seems to be mandating some particular deployment and not >> mandating functionality. > > Any authentication system that stores passwords has a limited set of > choices. They can store clear-text, or versions modified by a > particular cryptographic algorithm (md5, unix crypt, salted, SRP, etc.). > From the point of view of the client, the only authentication method > which is *known* to be compatible with all possible storage mechanisms > is to send clear-text passwords. > > I would wager that the majority of systems today store passwords in > non-clear-text form. Unix crypt, Active Directory, etc. are all widely > used examples of this. > > So no, I do not believe that the requirement is mandating a particular > deployment. I believe it is mandating the lowest-common denominator, > where clients can be sure that they will be authenticated everywhere > that they have credentials stored. > > In any case, Section 4.5 of the draft discusses the reasons for > transport of clear-text passwords in more detail. > >> The introductory text talks about cases where >> the authentication server does not have cleartext access to, or a >> consistent transform of, the password. If the authentication server >> doesn't have cleartext access or a consistent transform of the password >> then what does requiring that the tunnel method transport the username >> and password to it solve? > > A huge number of real-world deployment problems. > > If the server has access to the clear-text password, it can implement > the client side for *any* authentication method. It's not too much of > stretch to believe that a server with access to password transform X can > implement *both* the client and server side. > >> If the requirement is that the tunnel method MUST support username and >> password authentication where the authentication server doesn't have >> cleartext access to, or a consistent transform of, the password then why >> not just say it directly? > > Because that's a *reason* for the requirement. It's not a > requirement. The reasons are given earlier in the draft (Section 4.5), > and do not need to be repeated here. > >> You have added a "That is," as an introduction to my suggested text >> which implies that it's just a restatement of the previous text; it >> isn't. The existing text says the tunnel method "MUST NOT expose the >> username and password to parties in the communication path between the >> peer and the EAP server...." > > Yes... > >> As I said, exposing password-derived data >> is a way to comply with this requirement but it is flawed and insecure. > > We already discussed the security in a previous exchange. You had > agreed that there were no *new* security problems from using this method. > >> That text also doesn't state anything about protecting the username and >> password when it's transporting it to the authentication server (which >> come to think of it is quite odd). My text does. > > Section 4.5.1.1 gives that requirement. There is no need to re-state > it in other places. > >> I think it is better to just state what property we want in a tunnel >> method without ambiguity. I think my suggested replacement text is >> better >> than your compromise. > > The draft addresses your other concerns (historical reasons for using > clear-text passwords, requirements on security of clear-text passwords, > etc.). > > I find your suggested text vague, and would prefer to see specific > requirements. My guess is that if you extend your text to describe the > requirements for clear-text password security, you will be simply > reproducing existing text from elsewhere in the document. > > Alan DeKok. > From aland@deployingradius.com Wed Dec 2 22:50:28 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 228D63A69F5 for ; Wed, 2 Dec 2009 22:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] 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 Rd8lTtLFO5N8 for ; Wed, 2 Dec 2009 22:50:27 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 40B363A67E4 for ; Wed, 2 Dec 2009 22:50:27 -0800 (PST) Message-ID: <4B175FAA.7090804@deployingradius.com> Date: Thu, 03 Dec 2009 07:50:18 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Harkins References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Thu, 03 Dec 2009 06:50:28 -0000 Dan Harkins wrote: > Slicing up my posts and building up a straw man army is very > distracting. You attempted to help by adding my comment to the > problematic text. That didn't help, thanks for the effort though. You brought up specific concerns, and I pointed out that the document already addresses them. I asked for clarification on any concerns you had that *weren't* addressed by the document. We're back to: > ... There is a property we need > in the tunnel method and the requirements at the beginning of 3.1 do > not, in my opinion, adequately describe that property. My text does. I could ask for clarificiation again on what *exactly* do you mean by "a property", but that's how this "straw man army" got started. I think I understand what properties you want to be required. I think that you already agreed the properties are satisfied by the requirements as written. The main disagreement appears to be simply how best to phrase those requirements. Alan DeKok. From dharkins@lounge.org Thu Dec 3 00:59: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 A782D3A683D for ; Thu, 3 Dec 2009 00:59:06 -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 Tqj0gMcng1pM for ; Thu, 3 Dec 2009 00:58:59 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id E6BB63A6846 for ; Thu, 3 Dec 2009 00:58:59 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id AE26B102240AE; Thu, 3 Dec 2009 00:58:51 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 3 Dec 2009 00:58:51 -0800 (PST) Message-ID: <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> In-Reply-To: <4B175FAA.7090804@deployingradius.com> References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> Date: Thu, 3 Dec 2009 00:58:51 -0800 (PST) From: "Dan Harkins" To: "Alan DeKok" 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: Thu, 03 Dec 2009 08:59:06 -0000 You are wrong. But let me just give my best John Major impression from "Prime Minister's Question Time": I refer the right-honourable gentleman to the answer I gave some moments ago. On Wed, December 2, 2009 10:50 pm, Alan DeKok wrote: > Dan Harkins wrote: >> Slicing up my posts and building up a straw man army is very >> distracting. You attempted to help by adding my comment to the >> problematic text. That didn't help, thanks for the effort though. > > You brought up specific concerns, and I pointed out that the document > already addresses them. I asked for clarification on any concerns you > had that *weren't* addressed by the document. We're back to: > >> ... There is a property we need >> in the tunnel method and the requirements at the beginning of 3.1 do >> not, in my opinion, adequately describe that property. My text does. > > I could ask for clarificiation again on what *exactly* do you mean by > "a property", but that's how this "straw man army" got started. > > I think I understand what properties you want to be required. I think > that you already agreed the properties are satisfied by the requirements > as written. The main disagreement appears to be simply how best to > phrase those requirements. > > Alan DeKok. > From aland@deployingradius.com Thu Dec 3 02:53:24 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 8E1203A6860 for ; Thu, 3 Dec 2009 02:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599] 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 vUZYvKmbWcU3 for ; Thu, 3 Dec 2009 02:53:24 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id D24F23A63D3 for ; Thu, 3 Dec 2009 02:53:23 -0800 (PST) Message-ID: <4B17989A.3050204@deployingradius.com> Date: Thu, 03 Dec 2009 11:53:14 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Harkins References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> In-Reply-To: <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Thu, 03 Dec 2009 10:53:24 -0000 Dan Harkins wrote: > You are wrong. Are you opposed to sending clear-text passwords in the tunnel? Alan DeKok. From dharkins@lounge.org Thu Dec 3 09:41: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 2D28428C184 for ; Thu, 3 Dec 2009 09:41:23 -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 ZHzObqhZEDo7 for ; Thu, 3 Dec 2009 09:41:22 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 619AB28C150 for ; Thu, 3 Dec 2009 09:41:22 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A06E6102240AE; Thu, 3 Dec 2009 09:41:13 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 3 Dec 2009 09:41:13 -0800 (PST) Message-ID: <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> In-Reply-To: <4B17989A.3050204@deployingradius.com> References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> Date: Thu, 3 Dec 2009 09:41:13 -0800 (PST) From: "Dan Harkins" To: "Alan DeKok" 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: Thu, 03 Dec 2009 17:41:23 -0000 I refer the right-honourable gentleman to the answer I gave some moments ago. On Thu, December 3, 2009 2:53 am, Alan DeKok wrote: > Dan Harkins wrote: >> You are wrong. > > Are you opposed to sending clear-text passwords in the tunnel? > > Alan DeKok. > From aland@deployingradius.com Thu Dec 3 11:41:34 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 09CD228C183 for ; Thu, 3 Dec 2009 11:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599] 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 mZu4yjll7NG4 for ; Thu, 3 Dec 2009 11:41:33 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 425123A6911 for ; Thu, 3 Dec 2009 11:41:33 -0800 (PST) Message-ID: <4B181461.9020004@deployingradius.com> Date: Thu, 03 Dec 2009 20:41:21 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Harkins References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> In-Reply-To: <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Thu, 03 Dec 2009 19:41:34 -0000 Dan Harkins wrote: > > > I refer the right-honourable gentleman to the answer I gave > some moments ago. > > Since there has been no new information, I can only conclude that my previous summary was correct, and that you have no additional concerns with the document. Alan DeKok. From dharkins@lounge.org Thu Dec 3 12:02:49 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 BF85128C1B1 for ; Thu, 3 Dec 2009 12:02:49 -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 c04UqduL82kV for ; Thu, 3 Dec 2009 12:02:49 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 8FF5228C1C9 for ; Thu, 3 Dec 2009 12:02:27 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 3F6AE102240AE; Thu, 3 Dec 2009 12:02:19 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 3 Dec 2009 12:02:19 -0800 (PST) Message-ID: <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> In-Reply-To: <4B181461.9020004@deployingradius.com> References: <3fdd59d6b44f49b0f9899d42590370e5.squirrel@www.trepanning.net> <4A7B365D.50405@deployingradius.com> <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> <4B181461.9020004@deployingradius.com> Date: Thu, 3 Dec 2009 12:02:19 -0800 (PST) From: "Dan Harkins" To: "Alan DeKok" 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: Thu, 03 Dec 2009 20:02:49 -0000 Once again Alan, you are wrong. Your previous summary went off on tangents, made statements that were irrelevant and inferred things that I never said. Responding to it would not be productive. I have made my comments on the draft and stand by them. I refer you to my previous statements made on this list for my concerns with the document which are current and unaddressed. Dan. On Thu, December 3, 2009 11:41 am, Alan DeKok wrote: > Dan Harkins wrote: >> >> >> I refer the right-honourable gentleman to the answer I gave >> some moments ago. >> >> > > Since there has been no new information, I can only conclude that my > previous summary was correct, and that you have no additional concerns > with the document. > > Alan DeKok. > From aland@deployingradius.com Thu Dec 3 12:25:05 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 D83413A68EA for ; Thu, 3 Dec 2009 12:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599] 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 tQuDqZbGynF0 for ; Thu, 3 Dec 2009 12:25:05 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id E80293A63C9 for ; Thu, 3 Dec 2009 12:25:04 -0800 (PST) Message-ID: <4B181E97.6080000@deployingradius.com> Date: Thu, 03 Dec 2009 21:24:55 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Harkins References: <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> <4B181461.9020004@deployingradius.com> <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> In-Reply-To: <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Thu, 03 Dec 2009 20:25:05 -0000 Dan Harkins wrote: > I refer you to my previous statements made on this list for my > concerns with the document which are current and unaddressed. I asked for clarification, and you claim that my attempts to discuss those clarifications are "tangents" and "straw men". This doesn't make me believe that there are issues with the document. I suggest posting a detailed review of the document, explaining why the current text is inadequate, and which text you suggest as replacement. Simply replacing one paragraph out of context is insufficient. Your stated concerns with that paragraph are directly addressed by existing text elsewhere in the document. Alan DeKok. From dharkins@lounge.org Thu Dec 3 13:11: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 336BF28C1C7 for ; Thu, 3 Dec 2009 13:11:10 -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 jItnFSuAyluR for ; Thu, 3 Dec 2009 13:11:06 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 3474728C19D for ; Thu, 3 Dec 2009 13:11:06 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C55ACA88812E; Thu, 3 Dec 2009 13:10:57 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 3 Dec 2009 13:10:57 -0800 (PST) Message-ID: <875945fd7d4ca632e86c7aca7e4dd741.squirrel@www.trepanning.net> In-Reply-To: <4B181E97.6080000@deployingradius.com> References: <580360af66ea4cb304c1d377a6399e96.squirrel@www.trepanning.net> <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> <4B181461.9020004@deployingradius.com> <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> <4B181E97.6080000@deployingradius.com> Date: Thu, 3 Dec 2009 13:10:57 -0800 (PST) From: "Dan Harkins" To: "Alan DeKok" 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: Thu, 03 Dec 2009 21:11:11 -0000 On Thu, December 3, 2009 12:24 pm, Alan DeKok wrote: > Dan Harkins wrote: >> I refer you to my previous statements made on this list for my >> concerns with the document which are current and unaddressed. > > I asked for clarification, and you claim that my attempts to discuss > those clarifications are "tangents" and "straw men". Because they are, in fact, tangents and straw men. I have no desire to enter into those discussions. > This doesn't make me believe that there are issues with the document. So what? > I suggest posting a detailed review of the document, explaining why > the current text is inadequate, and which text you suggest as > replacement. Simply replacing one paragraph out of context is > insufficient. Your stated concerns with that paragraph are directly > addressed by existing text elsewhere in the document. I already said why the text is inadequate-- once again, I refer you to the statements I previously made on this list. And I even backed up my use of the word "vague" to describe the problematic text (which you did not when you, cutely, turned around and used that same term to describe my suggested text). My concerns are not addressed elsewhere in the document. Dan. From aland@deployingradius.com Thu Dec 3 13:20:53 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 9829C3A6973 for ; Thu, 3 Dec 2009 13:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599] 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 ZJKAj6Ro3v+O for ; Thu, 3 Dec 2009 13:20:52 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id B98313A6970 for ; Thu, 3 Dec 2009 13:20:52 -0800 (PST) Message-ID: <4B182BA8.4070608@deployingradius.com> Date: Thu, 03 Dec 2009 22:20:40 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Harkins References: <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> <4B181461.9020004@deployingradius.com> <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> <4B181E97.6080000@deployingradius.com> <875945fd7d4ca632e86c7aca7e4dd741.squirrel@www.trepanning.net> In-Reply-To: <875945fd7d4ca632e86c7aca7e4dd741.squirrel@www.trepanning.net> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Thu, 03 Dec 2009 21:20:53 -0000 The document states a clear requirement: the tunneled method MUST be capable of sending clear-text passwords in the tunnel. You agree that the attacks against this requirement are adequately covered by existing text in the document: http://www.ietf.org/mail-archive/web/emu/current/msg01327.html However, you then suggest your text as a "more accurate" definition of the requirements. I have asked for clarification as to why your text is better, and received (a) repetitions of the same text, and (b) suggestions to go read your previous messages. Your text removes the requirement to send a clear-text password in a tunnel. I am therefore opposed to it, for reasons I have outlined earlier. I understand that you find your text more specific than the current text in the document. I do not. Alan DeKok. From dharkins@lounge.org Thu Dec 3 14:25:14 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 7652828C1D6 for ; Thu, 3 Dec 2009 14:25:14 -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 zehx2+Fyu3hy for ; Thu, 3 Dec 2009 14:25:13 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 52FAC28C1BE for ; Thu, 3 Dec 2009 14:25:13 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1EEEE102240AE; Thu, 3 Dec 2009 14:25:05 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 3 Dec 2009 14:25:05 -0800 (PST) Message-ID: In-Reply-To: <4B182BA8.4070608@deployingradius.com> References: <4B14E9F0.5050905@deployingradius.com> <7e6c32908fe2770dd43681a648b82099.squirrel@www.trepanning.net> <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> <4B181461.9020004@deployingradius.com> <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> <4B181E97.6080000@deployingradius.com> <875945fd7d4ca632e86c7aca7e4dd741.squirrel@www.trepanning.net> <4B182BA8.4070608@deployingradius.com> Date: Thu, 3 Dec 2009 14:25:05 -0800 (PST) From: "Dan Harkins" To: "Alan DeKok" 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: Thu, 03 Dec 2009 22:25:14 -0000 Alan, You are misrepresenting my concerns with this draft and (intentionally) misunderstanding my post. On Thu, December 3, 2009 1:20 pm, Alan DeKok wrote: > The document states a clear requirement: the tunneled method MUST be > capable of sending clear-text passwords in the tunnel. A "clear-text" password will have to be sent "in the tunnel" because otherwise authentication would not be possible! I am not against a requirement to have an authentication protocol that is capable of authentication. In fact, I am very much opposed to an authentication protocol that would be incapable of authenticating. OK? Is this clear enough? My issue is with the text saying "[the tunnel method] MUST NOT expose the username and password to parties in the communication path between the peer and the EAP server...." As I have repeatedly stated, that is vague and a reasonable interpretation of that statement could end up with an insecure protocol by exposing password-derived data but not the password. I happen to think that this can be reworded to not be vague and in a way that concisely expresses the desired property we want the tunnel method to have. I later mentioned a side issue ("heartburn") in that requiring the password to be sent to an authentication server seems to be requiring a particular implementation and that is not appropriate for a protocol requirements draft since whether you have an authentication server or not is a deployment optimization. Now particular implementations may solve real-world deployment issues and that's great. That's a fine reason to implement a protocol in such a fashion. It's not a requirement of the protocol though, it's an implementation optimization. > You agree that the attacks against this requirement are adequately > covered by existing text in the document: > > http://www.ietf.org/mail-archive/web/emu/current/msg01327.html No, that is not what I said. You provided "two attack scenarios" and all I did was say that my suggested text covered them both. That was an effort on my part to demonstrate that we were not losing anything by going with my text. > However, you then suggest your text as a "more accurate" definition of > the requirements. I have asked for clarification as to why your text is > better, and received (a) repetitions of the same text, and (b) > suggestions to go read your previous messages. Your chronology is a bit off. I suggested my text was more accurate in my first post of this lamentable thread. You should: (b) go read my previous message. My first email on this topic, to Joe, explains why my text is better. Apparently you did not read that post very closely before slicing it up and responding to bits and pieces. That belief in confirmed by your subsequent statements: like how my suggested text is not in the draft-- no kidding, that's why it's suggested text, or asking what text it is replacing-- the text you removed from the post you obviously didn't fully read, that's what. So when you ask me why my text is more accurate when you obviously have failed to fully read a post I made where I explain why it's more accurate I tell you to go back and read the post. And I am telling you again: go back and read the post. Here it is: http://www.ietf.org/mail-archive/web/emu/current/msg01325.html > Your text removes the requirement to send a clear-text password in a > tunnel. I am therefore opposed to it, for reasons I have outlined > earlier. I understand that you find your text more specific than the > current text in the document. I do not. My text does not remove a requirement to send a clear-text password in a tunnel! You're opposed to a straw man of your own creation. Dan. From aland@deployingradius.com Thu Dec 3 23:36: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 A6C0E3A6850 for ; Thu, 3 Dec 2009 23:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599] 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 KVVTGiqOvbCY for ; Thu, 3 Dec 2009 23:36:29 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id D7DE33A6832 for ; Thu, 3 Dec 2009 23:36:28 -0800 (PST) Message-ID: <4B18BBEE.9030802@deployingradius.com> Date: Fri, 04 Dec 2009 08:36:14 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: Dan Harkins References: <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> <4B181461.9020004@deployingradius.com> <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> <4B181E97.6080000@deployingradius.com> <875945fd7d4ca632e86c7aca7e4dd741.squirrel@www.trepanning.net> <4B182BA8.4070608@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 04 Dec 2009 07:36:29 -0000 Dan Harkins wrote: > A "clear-text" password will have to be sent "in the tunnel" because > otherwise authentication would not be possible! There are many authentication protocols which do not require the sending of a clear-text password. CHAP, MS-CHAP, EKE, SRP, or your own proposal. So I'm a little surprised that you think authentication can happen only via sending a clear-text password. Your suggested text permits the tunneled protocol to support *only* one of these other methods, and to *not* support sending of a clear-text password. For reasons I gave before, we cannot standardize on a tunneled protocol that fails to support clear-text passwords. I welcome text to clarify the security requirements. But I am opposed to removing the stated requirement for clear-text passwords. Everything else we've discussed is secondary to that point. Alan DeKok. From jsalowey@cisco.com Fri Dec 4 08:44: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 3D7AC3A680D for ; Fri, 4 Dec 2009 08:44:41 -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=[AWL=0.000, 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 hP21ctMIEYoq for ; Fri, 4 Dec 2009 08:44:40 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 6D2863A6808 for ; Fri, 4 Dec 2009 08:44:40 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJbLGEurR7Hu/2dsb2JhbADAGIkPAwSOGYJQgWME X-IronPort-AV: E=Sophos;i="4.47,342,1257120000"; d="scan'208";a="57820581" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 04 Dec 2009 16:44:31 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nB4GiV4R028470; Fri, 4 Dec 2009 16:44:31 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); Fri, 4 Dec 2009 08:44:31 -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: Fri, 4 Dec 2009 08:44:30 -0800 Message-ID: In-Reply-To: <4B18BBEE.9030802@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue #7: Password Authentication Thread-Index: Acp0tHms9Pv/bQFiQ3SDNsmSkhR4mwASlhJw References: <4B14F550.80903@deployingradius.com> <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> <4B181461.9020004@deployingradius.com> <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> <4B181E97.6080000@deployingradius.com> <875945fd7d4ca632e86c7aca7e4dd741.squirrel@www.trepanning.net> <4B182BA8.4070608@deployingradius.com> <4B18BBEE.9030802@deployingradius.com> From: "Joseph Salowey (jsalowey)" To: "Alan DeKok" , "Dan Harkins" X-OriginalArrivalTime: 04 Dec 2009 16:44:31.0859 (UTC) FILETIME=[0DB0D430:01CA7501] 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: Fri, 04 Dec 2009 16:44:41 -0000 This section is about transporting clear text usernames and passwords within the tunnel, so password transport requirement needs to stay. I'm fine with more accurate text for describing the attacks. I propose the following text: "The tunnel method MUST support transporting clear text username and password to the authentication server. It MUST NOT reveal information about the username and password to parties in the communication path between the peer and the EAP Server. The advantage any attacker gains against the tunneled method when employing a username and password for authentication MUST be through interaction and not computation. " =20 Cheers, Joe > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Thursday, December 03, 2009 11:36 PM > To: Dan Harkins > Cc: Joseph Salowey (jsalowey); emu@ietf.org > Subject: Re: [Emu] Issue #7: Password Authentication >=20 > Dan Harkins wrote: > > A "clear-text" password will have to be sent "in the=20 > tunnel" because=20 > > otherwise authentication would not be possible! >=20 > There are many authentication protocols which do not=20 > require the sending of a clear-text password. CHAP, MS-CHAP,=20 > EKE, SRP, or your own proposal. So I'm a little surprised=20 > that you think authentication can happen only via sending a=20 > clear-text password. >=20 > Your suggested text permits the tunneled protocol to=20 > support *only* one of these other methods, and to *not*=20 > support sending of a clear-text password. For reasons I gave=20 > before, we cannot standardize on a tunneled protocol that=20 > fails to support clear-text passwords. >=20 > I welcome text to clarify the security requirements. But I=20 > am opposed to removing the stated requirement for clear-text=20 > passwords. Everything else we've discussed is secondary to=20 > that point. >=20 > Alan DeKok. >=20 From dharkins@lounge.org Fri Dec 4 09:50: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 2C0533A6955 for ; Fri, 4 Dec 2009 09:50:45 -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 XqOGk13NUwqk for ; Fri, 4 Dec 2009 09:50:42 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id A26403A6878 for ; Fri, 4 Dec 2009 09:50:42 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1C9F5102240AE; Fri, 4 Dec 2009 09:50:34 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 4 Dec 2009 09:50:34 -0800 (PST) Message-ID: <2a45acb35fcae1159c52a1e2e1ca68ff.squirrel@www.trepanning.net> In-Reply-To: References: <11a696054d4e923a0674ac6eeb7bdb4a.squirrel@www.trepanning.net> <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> <4B181461.9020004@deployingradius.com> <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> <4B181E97.6080000@deployingradius.com> <875945fd7d4ca632e86c7aca7e4dd741.squirrel@www.trepanning.net> <4B182BA8.4070608@deployingradius.com> <4B18BBEE.9030802@deployingradius.com> Date: Fri, 4 Dec 2009 09:50:34 -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: Fri, 04 Dec 2009 17:50:45 -0000 Hi Joe, An authentication server is an optional optimization. Do you agree that it should be possible to deploy "the tunnel method" without having such a thing? If that's the case then why the mention of this thing? If the section is about transporting clear text usernames and passwords then why not just say "The tunnel method MUST support clear text username and password authentication"? Like I said, this whole thing about transporting stuff to an authentication server sounds, to me at least, like it's mandating a particular deployment. (It's odd, I'm hung up on the words "authentication server", and there is insistence that that phrase remain to support clear text passwords. Authentication server...clear text passwords...no I don't see the connection). I should be able to implement "the tunnel method", including support for clear text passwords!, such that it does not support a stand-alone authentication server, which is how EAP has traditionally been defined. It may not be particularly useful for many "real-world deployments" but it might be very useful for some particular situation. And I don't know why such a thing should be disallowed if all you really want to say is that clear text passwords MUST be supported. Regarding the 2nd paragraph, "reveal information about" is certainly better text "expose" and I can live with this. And I appreciate the inclusion of my text. Thanks. regards, Dan. On Fri, December 4, 2009 8:44 am, Joseph Salowey (jsalowey) wrote: > This section is about transporting clear text usernames and passwords > within the tunnel, so password transport requirement needs to stay. I'm > fine with more accurate text for describing the attacks. I propose the > following text: > > "The tunnel method MUST support transporting clear text username and > password to the authentication server. It MUST NOT reveal information > about the username and password to parties in the communication path > between the peer and the EAP Server. The advantage any attacker gains > against the tunneled method when employing a username and password for > authentication MUST be through interaction and not computation. " > > Cheers, > > Joe > >> -----Original Message----- >> From: Alan DeKok [mailto:aland@deployingradius.com] >> Sent: Thursday, December 03, 2009 11:36 PM >> To: Dan Harkins >> Cc: Joseph Salowey (jsalowey); emu@ietf.org >> Subject: Re: [Emu] Issue #7: Password Authentication >> >> Dan Harkins wrote: >> > A "clear-text" password will have to be sent "in the >> tunnel" because >> > otherwise authentication would not be possible! >> >> There are many authentication protocols which do not >> require the sending of a clear-text password. CHAP, MS-CHAP, >> EKE, SRP, or your own proposal. So I'm a little surprised >> that you think authentication can happen only via sending a >> clear-text password. >> >> Your suggested text permits the tunneled protocol to >> support *only* one of these other methods, and to *not* >> support sending of a clear-text password. For reasons I gave >> before, we cannot standardize on a tunneled protocol that >> fails to support clear-text passwords. >> >> I welcome text to clarify the security requirements. But I >> am opposed to removing the stated requirement for clear-text >> passwords. Everything else we've discussed is secondary to >> that point. >> >> Alan DeKok. >> > From aland@deployingradius.com Fri Dec 4 10:00:17 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 96AFB3A6811 for ; Fri, 4 Dec 2009 10:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.356 X-Spam-Level: X-Spam-Status: No, score=-2.356 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599] 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 8SOd6Rcy9yKB for ; Fri, 4 Dec 2009 10:00:16 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id C5F6F3A6801 for ; Fri, 4 Dec 2009 10:00:16 -0800 (PST) Message-ID: <4B194E27.6070602@deployingradius.com> Date: Fri, 04 Dec 2009 19:00:07 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> <4B181461.9020004@deployingradius.com> <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> <4B181E97.6080000@deployingradius.com> <875945fd7d4ca632e86c7aca7e4dd741.squirrel@www.trepanning.net> <4B182BA8.4070608@deployingradius.com> <4B18BBEE.9030802@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Fri, 04 Dec 2009 18:00:17 -0000 Joseph Salowey (jsalowey) wrote: > This section is about transporting clear text usernames and passwords > within the tunnel, so password transport requirement needs to stay. I'm > fine with more accurate text for describing the attacks. I propose the > following text: > > "The tunnel method MUST support transporting clear text username and > password to the authentication server. It MUST NOT reveal information > about the username and password to parties in the communication path > between the peer and the EAP Server. The advantage any attacker gains > against the tunneled method when employing a username and password for > authentication MUST be through interaction and not computation. " The first sentence refers to "authentication server", while the second uses "EAP server". I suggest using "EAP server" for both, as it is used elsewhere in the document, too. Alan DeKok. From jsalowey@cisco.com Fri Dec 4 11:56:30 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 48B843A6A1F for ; Fri, 4 Dec 2009 11:56:30 -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 VjgdHfI4te5B for ; Fri, 4 Dec 2009 11:56:29 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 4CB5D3A68FD for ; Fri, 4 Dec 2009 11:56:29 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJf4GEurR7H+/2dsb2JhbAC/fIkPAwSOGoJQgWME X-IronPort-AV: E=Sophos;i="4.47,343,1257120000"; d="scan'208";a="72148769" Received: from sj-core-2.cisco.com ([171.71.177.254]) by rtp-iport-2.cisco.com with ESMTP; 04 Dec 2009 19:56:19 +0000 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 nB4JuJSa007112; Fri, 4 Dec 2009 19:56: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); Fri, 4 Dec 2009 11:56:19 -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: Fri, 4 Dec 2009 11:56:17 -0800 Message-ID: In-Reply-To: <4B194E27.6070602@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] Issue #7: Password Authentication Thread-Index: Acp1C55mla+deHxbQoSplA3iQkS7CAAD7c8w References: <4B16460D.6050406@deployingradius.com> <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> <4B181461.9020004@deployingradius.com> <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> <4B181E97.6080000@deployingradius.com> <875945fd7d4ca632e86c7aca7e4dd741.squirrel@www.trepanning.net> <4B182BA8.4070608@deployingradius.com> <4B18BBEE.9030802@deployingradius.com> <4B194E27.6070602@deployingradius.com> From: "Joseph Salowey (jsalowey)" To: "Alan DeKok" X-OriginalArrivalTime: 04 Dec 2009 19:56:19.0009 (UTC) FILETIME=[D87C9310:01CA751B] 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: Fri, 04 Dec 2009 19:56:30 -0000 OK good points. I can see the problem with the authentication server wording. I think EAP server is more correct in this case as it leaves deployment options open. Is the text OK if we change Authentication Server to EAP server in this paragraph? Joe > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Friday, December 04, 2009 10:00 AM > To: Joseph Salowey (jsalowey) > Cc: Dan Harkins; emu@ietf.org > Subject: Re: [Emu] Issue #7: Password Authentication >=20 > Joseph Salowey (jsalowey) wrote: > > This section is about transporting clear text usernames and=20 > passwords=20 > > within the tunnel, so password transport requirement needs=20 > to stay. =20 > > I'm fine with more accurate text for describing the attacks. I=20 > > propose the following text: > >=20 > > "The tunnel method MUST support transporting clear text=20 > username and=20 > > password to the authentication server. It MUST NOT reveal=20 > information=20 > > about the username and password to parties in the=20 > communication path=20 > > between the peer and the EAP Server. The advantage any=20 > attacker gains=20 > > against the tunneled method when employing a username and=20 > password for=20 > > authentication MUST be through interaction and not computation. " >=20 > The first sentence refers to "authentication server", while=20 > the second uses "EAP server". I suggest using "EAP server"=20 > for both, as it is used elsewhere in the document, too. >=20 > Alan DeKok. >=20 From jsalowey@cisco.com Fri Dec 4 12:12:43 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 990AE3A68AB for ; Fri, 4 Dec 2009 12:12:43 -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 R2AeGMLtV2BN for ; Fri, 4 Dec 2009 12:12:42 -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 F3D2E3A67FD for ; Fri, 4 Dec 2009 12:12:40 -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: ApoEAGH8GEurR7Hu/2dsb2JhbAC/eJcvhDME X-IronPort-AV: E=Sophos;i="4.47,344,1257120000"; d="scan'208";a="114314550" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 04 Dec 2009 20:12:32 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id nB4KCWpH013392 for ; Fri, 4 Dec 2009 20:12:32 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); Fri, 4 Dec 2009 12:12:31 -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: Fri, 4 Dec 2009 12:12:30 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Working Group Last Call for draft-ietf-emu-chbind-04.txt Thread-Index: Acp1HhukBbPRUDeVR1OLtSC+T36eHw== From: "Joseph Salowey (jsalowey)" To: X-OriginalArrivalTime: 04 Dec 2009 20:12:31.0865 (UTC) FILETIME=[1C5A9E90:01CA751E] Subject: [Emu] Working Group Last Call for draft-ietf-emu-chbind-04.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, 04 Dec 2009 20:12:43 -0000 This is an announcement of working group last call for the Channel Bindings draft: draft-ietf-emu-chbind-04. Please send comments to the list by December 18, 2009. When proposing changes to the document it is helpful to provide some sample text. Also if you have reviewed the document and found no issues it is appropriate to send a message to the list indicating your approval. =20 The URL for the document is http://www.ietf.org/id/draft-ietf-emu-chbind-04.txt Cheers, Joe From dharkins@lounge.org Fri Dec 4 13:11:37 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 BB8B93A68F3 for ; Fri, 4 Dec 2009 13:11:37 -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=[AWL=-0.000, 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 08tGN+maWfil for ; Fri, 4 Dec 2009 13:11:35 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id C35A53A6833 for ; Fri, 4 Dec 2009 13:11:34 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 1D5E3102240AE; Fri, 4 Dec 2009 13:11:26 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 4 Dec 2009 13:11:26 -0800 (PST) Message-ID: <356e783c475bc4bfd423f50e6b5a4302.squirrel@www.trepanning.net> In-Reply-To: References: <8ba4fd36cde2d8ce08c13a9923dbef48.squirrel@www.trepanning.net> <4B16DD97.7040501@deployingradius.com> <4B175FAA.7090804@deployingradius.com> <82592e8c21f30a4dfb6099680108fbea.squirrel@www.trepanning.net> <4B17989A.3050204@deployingradius.com> <792f2864df0ae6f5b6bca83fcd06d7d2.squirrel@www.trepanning.net> <4B181461.9020004@deployingradius.com> <924f310713e52b700155cf4e936bd835.squirrel@www.trepanning.net> <4B181E97.6080000@deployingradius.com> <875945fd7d4ca632e86c7aca7e4dd741.squirrel@www.trepanning.net> <4B182BA8.4070608@deployingradius.com> <4B18BBEE.9030802@deployingradius.com> <4B194E27.6070602@deployingradius.com> Date: Fri, 4 Dec 2009 13:11:26 -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: Fri, 04 Dec 2009 21:11:38 -0000 Hi Joe, I like your suggestion. Using "EAP server" would satisfy my concern. thanks, Dan. On Fri, December 4, 2009 11:56 am, Joseph Salowey (jsalowey) wrote: > OK good points. I can see the problem with the authentication server > wording. I think EAP server is more correct in this case as it leaves > deployment options open. Is the text OK if we change Authentication > Server to EAP server in this paragraph? > > Joe > >> -----Original Message----- >> From: Alan DeKok [mailto:aland@deployingradius.com] >> Sent: Friday, December 04, 2009 10:00 AM >> To: Joseph Salowey (jsalowey) >> Cc: Dan Harkins; emu@ietf.org >> Subject: Re: [Emu] Issue #7: Password Authentication >> >> Joseph Salowey (jsalowey) wrote: >> > This section is about transporting clear text usernames and >> passwords >> > within the tunnel, so password transport requirement needs >> to stay. >> > I'm fine with more accurate text for describing the attacks. I >> > propose the following text: >> > >> > "The tunnel method MUST support transporting clear text >> username and >> > password to the authentication server. It MUST NOT reveal >> information >> > about the username and password to parties in the >> communication path >> > between the peer and the EAP Server. The advantage any >> attacker gains >> > against the tunneled method when employing a username and >> password for >> > authentication MUST be through interaction and not computation. " >> >> The first sentence refers to "authentication server", while >> the second uses "EAP server". I suggest using "EAP server" >> for both, as it is used elsewhere in the document, too. >> >> Alan DeKok. >> > From gwz@net-zen.net Sat Dec 5 12:59:34 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 594A23A6782 for ; Sat, 5 Dec 2009 12:59:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[AWL=-0.528, BAYES_05=-1.11] 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 3KIE9fEtUxtn for ; Sat, 5 Dec 2009 12:59:33 -0800 (PST) Received: from smtpauth05.prod.mesa1.secureserver.net (smtpauth05.prod.mesa1.secureserver.net [64.202.165.99]) by core3.amsl.com (Postfix) with SMTP id 766013A672E for ; Sat, 5 Dec 2009 12:59:33 -0800 (PST) Received: (qmail 1644 invoked from network); 5 Dec 2009 20:59:23 -0000 Received: from unknown (24.22.129.187) by smtpauth05.prod.mesa1.secureserver.net (64.202.165.99) with ESMTP; 05 Dec 2009 20:59:23 -0000 From: "Glen Zorn" To: "'Joseph Salowey \(jsalowey\)'" Date: Sat, 5 Dec 2009 12:59:12 -0800 Organization: Network Zen Message-ID: <000001ca75ed$cc6c77c0$65456740$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp17cu0TD1oG4EdQoaVXcxu1Bh1ZQ== Content-Language: en-us Cc: emu@ietf.org Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-04.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: Sat, 05 Dec 2009 20:59:34 -0000 Joseph Salowey (jsalowey)" writes: > This is an announcement of working group last call for the Channel Bindings draft: draft-ietf-emu-chbind-04. Please send comments to the list by December 18, 2009. When proposing > changes to the document it is helpful to provide some sample text. Also if you have reviewed the document and found no issues it is appropriate to send a message to the list indicating > your approval. Not that I want to slow things down any further, but this seems like a particularly bad time to issue a WGLC. May I suggest either waiting until after the New Year or extending the Last Call period until the middle of January? From yaronf@checkpoint.com Sun Dec 6 02:02: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 04AC33A67AE for ; Sun, 6 Dec 2009 02:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.559 X-Spam-Level: X-Spam-Status: No, score=-3.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 QyEVzM2uC6ut for ; Sun, 6 Dec 2009 02:02:45 -0800 (PST) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id 7804A3A6403 for ; Sun, 6 Dec 2009 02:02:45 -0800 (PST) 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 nB6A2YGo011504 for ; Sun, 6 Dec 2009 12:02:34 +0200 (IST) Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 6 Dec 2009 12:02:44 +0200 From: Yaron Sheffer To: "emu@ietf.org" Date: Sun, 6 Dec 2009 12:02:31 +0200 Thread-Topic: Working Group Last Call for draft-ietf-emu-chbind-04.txt Thread-Index: Acp15ZmDxYsma/7oTkSCurGf4fvL7QAcZ0qQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BDF88E0C14@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-04.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: Sun, 06 Dec 2009 10:02:47 -0000 Hi, IMHO this document is not ready to be advanced, at least not as Standards T= rack. The document is extremely abstract: it defines the problem statement very w= ell, but then keep its options open when describing the solution. The fact = that the document has an empty IANA section is a strong hint that it is not= really defining a protocol. This can be resolved either of two ways: - Change it to Informational, and add text to clarify that the document is = *not* defining a protocol (despite the title of Sec. 5), but rather present= s the problem and proposes several alternative solution strategies. - Or extend it to really define a protocol. In which case you need to answe= r some simple questions like: * Is this taking place at the EAP level? The SAP level? Is it a new EAP me= thod? Should it be built into each and every new EAP method? * How does it apply to the few existing EAP methods that can accommodate i= t today? * How are the actual TLVs represented/encoded? BTW, just defining the TLV formats (and IANA numbers) for EAP methods would= serve the community well: looking at the IANA registry for EAP-GPSK, there= 's a "protected payload" defined (http://www.iana.org/assignments/eap-gpsk-= parameters/eap-gpsk-parameters.xhtml#eap-gpsk-parameters-2). But nobody eve= r bothered defining *any* specific payloads for channel bindings. Thanks, Yaron >=20 > ---------------------------------------------------------------------- >=20 > Date: Fri, 4 Dec 2009 12:12:30 -0800 > From: "Joseph Salowey (jsalowey)" > Subject: [Emu] Working Group Last Call for > draft-ietf-emu-chbind-04.txt > To: > Message-ID: > 225.amer.cisco.com> > Content-Type: text/plain; charset=3D"us-ascii" >=20 > This is an announcement of working group last call for the Channel > Bindings draft: draft-ietf-emu-chbind-04. Please send comments to the > list by December 18, 2009. When proposing changes to the document it is > helpful to provide some sample text. Also if you have reviewed the > document and found no issues it is appropriate to send a message to the > list indicating your approval. >=20 > The URL for the document is > http://www.ietf.org/id/draft-ietf-emu-chbind-04.txt >=20 > Cheers, >=20 > Joe >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Fri, 4 Dec 2009 13:11:26 -0800 (PST) > From: "Dan Harkins" > Subject: Re: [Emu] Issue #7: Password Authentication > To: "Joseph Salowey (jsalowey)" > Cc: emu@ietf.org > Message-ID: > <356e783c475bc4bfd423f50e6b5a4302.squirrel@www.trepanning.net> > Content-Type: text/plain;charset=3Diso-8859-1 >=20 >=20 > Hi Joe, >=20 > I like your suggestion. Using "EAP server" would satisfy my concern. >=20 > thanks, >=20 > Dan. >=20 > On Fri, December 4, 2009 11:56 am, Joseph Salowey (jsalowey) wrote: > > OK good points. I can see the problem with the authentication server > > wording. I think EAP server is more correct in this case as it leaves > > deployment options open. Is the text OK if we change Authentication > > Server to EAP server in this paragraph? > > > > Joe > > > >> -----Original Message----- > >> From: Alan DeKok [mailto:aland@deployingradius.com] > >> Sent: Friday, December 04, 2009 10:00 AM > >> To: Joseph Salowey (jsalowey) > >> Cc: Dan Harkins; emu@ietf.org > >> Subject: Re: [Emu] Issue #7: Password Authentication > >> > >> Joseph Salowey (jsalowey) wrote: > >> > This section is about transporting clear text usernames and > >> passwords > >> > within the tunnel, so password transport requirement needs > >> to stay. > >> > I'm fine with more accurate text for describing the attacks. I > >> > propose the following text: > >> > > >> > "The tunnel method MUST support transporting clear text > >> username and > >> > password to the authentication server. It MUST NOT reveal > >> information > >> > about the username and password to parties in the > >> communication path > >> > between the peer and the EAP Server. The advantage any > >> attacker gains > >> > against the tunneled method when employing a username and > >> password for > >> > authentication MUST be through interaction and not computation. " > >> > >> The first sentence refers to "authentication server", while > >> the second uses "EAP server". I suggest using "EAP server" > >> for both, as it is used elsewhere in the document, too. > >> > >> Alan DeKok. > >> > > >=20 >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu >=20 >=20 > End of Emu Digest, Vol 47, Issue 7 > ********************************** >=20 > Scanned by Check Point Total Security Gateway. From bernard_aboba@hotmail.com Mon Dec 7 19:12:34 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 6B04E3A6806 for ; Mon, 7 Dec 2009 19:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[AWL=-0.335, BAYES_50=0.001, 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 DzyJitrrP1Tr for ; Mon, 7 Dec 2009 19:12:31 -0800 (PST) Received: from blu0-omc3-s5.blu0.hotmail.com (blu0-omc3-s5.blu0.hotmail.com [65.55.116.80]) by core3.amsl.com (Postfix) with ESMTP id 1B0C13A677C for ; Mon, 7 Dec 2009 19:12:31 -0800 (PST) Received: from BLU137-W18 ([65.55.116.72]) by blu0-omc3-s5.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 19:12:17 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_ea8adb72-8b93-414b-aa09-d7f54fbc3cc7_" X-Originating-IP: [97.113.254.30] From: Bernard Aboba To: Date: Mon, 7 Dec 2009 19:12:17 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2009 03:12:17.0254 (UTC) FILETIME=[3F414060:01CA77B4] Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-04.txt (part 1) 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, 08 Dec 2009 03:12:34 -0000 --_ea8adb72-8b93-414b-aa09-d7f54fbc3cc7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Yaron that this document is not ready to be advanced.=20 Aside from whether the document is appropriate for publication on the Stand= ards Track (I believe that Informational would be a better choice)=2C I'd s= uggest that the document has a more basic problem in that it doesn't do a v= ery good job of defining the problem it is trying to solve or demonstrating= that the solution offered actually solves that problem or can be practical= ly implemented.=20 For example=2C early on the document makes the following statement:=20 This document defines and implements EAP channel bindings to solve the lying NAS and the lying provider problems=2C using a process in which the EAP peer provides information about the characteristics of the service provided by the authenticator to the AAA server protected within the EAP method. This allows the server to verify the authenticator is providing information to the peer that is consistent with the information received from this authenticator as well as the information stored about this authenticator. "AAA Payloads" defined in [I-D.clancy-emu-aaapay] proposes a mechanism to carry this information. However=2C as noted in Section 3: In service provider networks=2C global knowledge is infeasible due to indirection via roaming. When a peer is outside its home administrative domain=2C the goal is to ensure that the level of service received by the peer is consistent with the contractual agreement between the two service providers. Unfortunately the term "level of service" is not well enough defined here t= o give a good sense of what is possible and what is not. As noted above=2C in general the home AAA server= does not have=20 enough information to independently verify AAA attributes provided to it by= =20 roaming partners. The problem is not just lack of "global knowledge"=3B e= ven if it were possible for a home AAA server to have perfect global knowledge=2C if that knowledge= were obtained from the providers themselves (where else could it come from?) then if those provide= rs were untrustworthy=2C then how could it be used in channel binding verification? =20 As a result=2C I'd suggest that some careful analysis is needed to describe= in detail the threats that=20 the "lying provider" solution really can mitigate. As noted later: In other words=2C channel bindings enable the detection of inconsistencies in the information from a visited network=2C but cannot determine which entity is lying. =20 Given that it is not really possible to determine whether a provider is act= ually lying or not=2C how does the offered solution actually solve the "lying provider" problem?=20 The service provider attacks described in Section 3=2C which attempt to mak= e the case for the utility of channel bindings are not very convincing:=20 a. Inappropriate billing. In this scenario=2C it's not clear to me how C= hannel Bindings would be helpful Today rates are not advertised in Beacons=2C and if accountin= g fraud is suspected=2C wouldn't this be best verified by computing the expected billed amount= s against the actual ones=2C based on RADIUS accounting data? =20 b. Transmit power boost. Detecting inappropriate levels of transmit powe= r seems like something beyond the capability of channel bindings (and more in the jurisdictio= n of regulatory agencies like the FCC). Even if the geolocation were to be transmitted along w= ith the power measurement=2C detecting an inappropriate transmit power level would involve some fai= rly complex modeling with lots of variables (e.g. precise tower location=2C absorption along the= line of sight=2C etc.).=20 At a minimum=2C I'd suggest that the document needs to come up with some mo= re plausible service provider scenarios.=20 = --_ea8adb72-8b93-414b-aa09-d7f54fbc3cc7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree with Yaron that this document is not ready to be advanced.

= Aside from whether the document is appropriate for publication on the Stand= ards Track (I believe that Informational would be a better choice)=2C I'd s= uggest that the document has a more basic problem in that it doesn't do a v= ery good job of defining the problem it is trying to solve or demonstrating= that the solution offered actually solves that problem or can be practical= ly
implemented.

For example=2C early on the document makes the f= ollowing statement: 
   This document defines and implements EAP ch=
annel bindings to solve
   the lying NAS and the lying provider problems=
=2C using a process in
   which the EAP peer provides information about =
the characteristics of
   the service provided by the authenticator to t=
he AAA server protected
   within the EAP method.  This allows the serve=
r to verify the
   authenticator is providing information to the peer th=
at is consistent
   with the information received from this authenticato=
r as well as the
   information stored about this authenticator.  "AAA P=
ayloads" defined
   in [I-D.clancy-emu-aaapay] proposes a mechanism to c=
arry this
   information.

However=2C as noted in Section 3:
   In service provider networks=2C global knowledge is
   infeasible d=
ue to indirection via roaming.  When a peer is outside
   its home admin=
istrative domain=2C the goal is to ensure that the level
   of service r=
eceived by the peer is consistent with the contractual
   agreement betw=
een the two service providers.

Unfortunately the term "level of serv=
ice" is not well enough defined here to give a good sense of what is
pos=
sible and what is not.  As noted above=2C in general the home AAA server do=
es not have 
enough information to independently verify AAA attributes p=
rovided to it by 
roaming partners.  The problem is not just lack of "gl=
obal knowledge"=3B  even if it were possible
for a home AAA server to ha=
ve perfect global knowledge=2C if that knowledge were obtained from the
=
providers themselves (where else could it come from?) then if those provide=
rs were untrustworthy=2C
then how could it be used in channel binding ve=
rification?  

As a result=2C I'd suggest that some careful analysis =
is needed to describe in detail the threats that 
the "lying provider" s=
olution really can mitigate.  As noted later:

      In other words=
=2C channel bindings enable the
      detection of inconsistencies in th=
e information from a visited
      network=2C but cannot determine which=
 entity is lying.  

Given that it is not really possible to determin=
e whether a provider is actually lying or not=2C how
does the offered so=
lution actually solve the "lying provider" problem? 

The service pro=
vider attacks described in Section 3=2C which attempt to make the case for =
the
utility of channel bindings are not very convincing: 

  a. In=
appropriate billing.  In this scenario=2C it's not clear to me how Channel =
Bindings would be
     helpful  Today rates are not advertised in Beacon=
s=2C and if accounting fraud is suspected=2C
     wouldn't this be best =
verified by computing the expected billed amounts against the actual
   =
  ones=2C based on RADIUS accounting data?  

  b. Transmit power boo=
st.  Detecting inappropriate levels of transmit power seems like something<=
br>     beyond the capability of channel bindings (and more in the jurisdic=
tion of regulatory agencies
     like the FCC).  Even if the geolocation=
 were to be transmitted along with the power measurement=2C
     detecti=
ng an inappropriate transmit power level would involve some fairly complex =
modeling with
     lots of variables (e.g. precise tower location=2C abs=
orption along the line of sight=2C etc.). 

At a minimum=2C I'd sugge=
st that the document needs to come up with some more plausible service prov=
ider
scenarios.













= = --_ea8adb72-8b93-414b-aa09-d7f54fbc3cc7_-- From bernard_aboba@hotmail.com Mon Dec 7 22:11:55 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 C658428C19F for ; Mon, 7 Dec 2009 22:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.626 X-Spam-Level: X-Spam-Status: No, score=-1.626 tagged_above=-999 required=5 tests=[AWL=0.972, 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 qQHIc45jRNMW for ; Mon, 7 Dec 2009 22:11:49 -0800 (PST) Received: from blu0-omc3-s27.blu0.hotmail.com (blu0-omc3-s27.blu0.hotmail.com [65.55.116.102]) by core3.amsl.com (Postfix) with ESMTP id 2669328C134 for ; Mon, 7 Dec 2009 22:11:47 -0800 (PST) Received: from BLU137-W36 ([65.55.116.74]) by blu0-omc3-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 22:11:37 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_2a39902b-164b-4604-b58c-6fc4c7c72a72_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Mon, 7 Dec 2009 22:11:37 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2009 06:11:37.0460 (UTC) FILETIME=[4CD66340:01CA77CD] Subject: Re: [Emu] Working Group Last Call for draft-ietf-emu-chbind-04.txt (part 2) 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, 08 Dec 2009 06:11:55 -0000 --_2a39902b-164b-4604-b58c-6fc4c7c72a72_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Section 5.1 The local database is perhaps the most important part of this system. In order for the EAP server or AAA server to know whether i1 and i2 are correct=2C they need access to trustworthy information=2C since an authenticator could include false information in both i1 and i2. Additional reasons why such a database is necessary for channel bindings to work are discussed in the next subsection. The information contained within the database could involve wildcards. For example=2C this could be used to check whether WiFi access points on a particular IP subnet all use a specific SSID. The exact IP address is immaterial=2C provided it is on the correct subnet. [BA] Is it really true that the IP address of the NAS is always immaterial?= For example=2C couldn't a=20 NAS lie about its IP address in order to impersonate another NAS?=20 During an EAP method execution with channel bindings=2C the goal is to transport i1 from the peer to the EAP server=2C and allow the system to verify the consistency of i1 provided by the peer=2C i2 provided by the authenticator=2C and the information in the local database. Upon the check=2C the EAP server sends a message to the peer indicating whether the channel binding validation check succeeded or failed and optionally includes all or some of the information that was used in the check. The message flow is illustrated in Figure 1. [BA] Is it always necessary for the EAP server to provide information to th= e peer=20 about why the channel binding check succeeded or failed? While this info m= ight be helpful for debugging=2C it seems like there could be situations in which the AAA serve= r just returns an Accept/Reject indication.=20 If the compliance of i1 or i2 information with the authoritative policy source is mandatory and a consistency check failed=2C then after sending a protected indication of failed consistency=2C the EAP server MUST send an EAP-Failure message to terminate the session. If the EAP server is otherwise configured=2C it MUST allow the EAP session to complete normally=2C and leave the decision about network access up to the peer's policy. [BA] I would suggest that normative language is not appropriate here. For = one thing=2C an EAP-Failure does not actually result in the host being denied access to the network -- = an Access-Reject is what accomplishes this. Also=2C since an EAP-Failure (or EAP-Success) may not b= e delivered=2C it doesn't make sense to rely on it. Furthermore=2C couldn't there be situations where rat= her than denying access=20 some other action is taken=2C such as putting up a warning message=2C isola= ting the host in some way (e.g. filters or VLAN setting=2C etc.)? =20 Section 5.2 These checks enable the EAP server to detect lying NAS/authenticator in enterprise networks and lying providers in service provider [BA] As noted in the previous message=2C these checks do not actually enabl= e the determination of whether a provider is lying.=20 Checking the consistency of i1 and i2 is nontrivial=2C as has been pointed out already in [HC07]. First=2C i1 can contain any type of information propagated by the authenticator=2C whereas i2 is restricted to information that can be carried in AAA attributes. =20 [BA] Actually=2C i1 can only contain information that is both propagated by= the authenticator *and* passed up by the host in the proper format. This requires coordination bet= ween the driver implemented on the host and the EAP method. In practice=2C this ha= s been a major impediment to implementation of Channel Bindings=2C because without driver changes=2C = many of the parameters desired by channel binding implementations will not be available.=20 Similarly=2C the database referred to in this section also requires a non-t= rivial effort to put together=2C comparable to the "wire map" required to support geographic location or eme= rgency services calling.=20 For example=2C if the EAP MTU is 1020 octets=2C and EAP-GPSK is used as the authentication method=2C and maximal-length identities are used=2C a maximum of 384 octets are available for conveying channel binding. [BA] This is an important point -- and one that indicates that the ability = to implement channel bindings is limited on EAP methods that don't support fragmentation. =20 Section 6.3 If transporting data within a lower-layer's secure association protocol (SAP)=2C this protocol MUST support transport of integrity protected data using a key known only by the EAP peer and EAP server=2C and not known to the authenticator. There must be mechanism whereby the authenticator can transport the protected payloads to the EAP server=2C either via a AAA protocol or some other means=2C and receive a protected result. [BA] This paragraph does not make sense=2C because by definition the SAP exchange occurs between the authenticator and the peer=2C and therefore any keys derived in the process need to be known by the authenticator and the peer. In a number of cases (such as IKEv2)=2C the EAP server only doesn't know the key used by the SAP=2C but it is an explicit design requirement that this not be possible. =20 This protocol MUST support exporting channel binding data to the AAA subsystem on the EAP server for validation. The SAP must have access to channel binding data required for transport to the EAP server. [BA] The last sentence also doesn't make sense. Elsewhere in the document it says that the authenticator is not supposed to have access to the channel bindings data=2C but here it implies that it must have access=2C since the SAP is run between the peer and authenticator.=20 Section 7.1 7.1. Requirements for Lower-Layer Bindings Lower-layer protocols MUST support EAP in order to support EAP channel bindings. These lower layers MUST support EAP methods that derive keying material=2C as otherwise no integrity-protected channel would be available to execute the channel bindings protocol. Lower- layer protocols need not support traffic encryption=2C since this is independent of the authentication phase. [BA] Channel Bindings can still be used even on lower layers that don't use= keying material. For example=2C an EAP method supporting channel bindings could be used with a w= ired network supporting IEEE 802.1X-2004. Since the EAP server/AAA server will still obtain i1/i2 i= n this situation=2C why should it matter whether an integrity-protected channel is in place? =20 =20 = --_2a39902b-164b-4604-b58c-6fc4c7c72a72_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Section 5.1

   The local database is perhaps the most important=
 part of this system.
   In order for the EAP server or AAA server to kn=
ow whether i1 and i2
   are correct=2C they need access to trustworthy i=
nformation=2C since an
   authenticator could include false information =
in both i1 and i2.
   Additional reasons why such a database is necessar=
y for channel
   bindings to work are discussed in the next subsection. =
 The
   information contained within the database could involve wildcard=
s.
   For example=2C this could be used to check whether WiFi access poi=
nts
   on a particular IP subnet all use a specific SSID.  The exact IP<=
br>   address is immaterial=2C provided it is on the correct subnet.
[BA] Is it really true that the IP address of the NAS is always immaterial=
?  For example=2C couldn't a 
NAS lie about its IP address in order to i=
mpersonate another NAS? 

   During an EAP method execution with chan=
nel bindings=2C the goal is to
   transport i1 from the peer to the EAP =
server=2C and allow the system to
   verify the consistency of i1 provid=
ed by the peer=2C i2 provided by the
   authenticator=2C and the informa=
tion in the local database.  Upon the
   check=2C the EAP server sends a=
 message to the peer indicating whether
   the channel binding validatio=
n check succeeded or failed and
   optionally includes all or some of th=
e information that was used in
   the check.  The message flow is illust=
rated in Figure 1.

[BA] Is it always necessary for the EAP server to=
 provide information to the peer 
about why the channel binding check su=
cceeded or failed?  While this info might be helpful for
debugging=2C it=
 seems like there could be situations in which the AAA server just returns =
an
Accept/Reject indication. 

   If the compliance of i1 or i2 in=
formation with the authoritative
   policy source is mandatory and a con=
sistency check failed=2C then after
   sending a protected indication of=
 failed consistency=2C the EAP server
   MUST send an EAP-Failure messag=
e to terminate the session.  If the
   EAP server is otherwise configure=
d=2C it MUST allow the EAP session to
   complete normally=2C and leave =
the decision about network access up to
   the peer's policy.

[BA=
] I would suggest that normative language is not appropriate here.  For one=
 thing=2C an EAP-Failure
does not actually result in the host being deni=
ed access to the network -- an Access-Reject is what
accomplishes this. =
 Also=2C since an EAP-Failure (or EAP-Success) may not be delivered=2C it d=
oesn't make
sense to rely on it.  Furthermore=2C couldn't there be situa=
tions where rather than denying access 
some other action is taken=2C su=
ch as putting up a warning message=2C isolating the host in some way
(e.=
g. filters or VLAN setting=2C etc.)?  

Section 5.2

   These c=
hecks enable the EAP server to detect lying NAS/authenticator
   in ente=
rprise networks and lying providers in service provider

[BA] As note=
d in the previous message=2C these checks do not actually enable the determ=
ination of whether
a provider is lying. 

   Checking the consiste=
ncy of i1 and i2 is nontrivial=2C as has been
   pointed out already in =
[HC07].  First=2C i1 can contain any type of
   information propagated b=
y the authenticator=2C whereas i2 is restricted
   to information that c=
an be carried in AAA attributes.  

[BA] Actually=2C i1 can only cont=
ain information that is both propagated by the authenticator *and*
passe=
d up by the host in the proper format.  This requires coordination between =
the
driver implemented on the host and the EAP method.   In practice=2C =
this has been a major impediment
to implementation of Channel Bindings=
=2C because without driver changes=2C many of the parameters desired
by =
channel binding implementations will not be available. 

Similarly=2C=
 the database referred to in this section also requires a non-trivial effor=
t to put together=2C
comparable to the "wire map" required to support ge=
ographic location or emergency services calling. 

   For example=2C =
if the EAP MTU is 1020 octets=2C and EAP-GPSK is used as
   the authenti=
cation method=2C and maximal-length identities are used=2C a
   maximum =
of 384 octets are available for conveying channel binding.

[BA] This=
 is an important point -- and one that indicates that the ability to implem=
ent channel
bindings is limited on EAP methods that don't support fragme=
ntation.  

Section 6.3

   If transporting data within a lower=
-layer's secure association
   protocol (SAP)=2C this protocol MUST supp=
ort transport of integrity
   protected data using a key known only by t=
he EAP peer and EAP server=2C
   and not known to the authenticator.  Th=
ere must be mechanism whereby
   the authenticator can transport the pro=
tected payloads to the EAP
   server=2C either via a AAA protocol or som=
e other means=2C and receive a
   protected result.

[BA] This par=
agraph does not make sense=2C because by definition the SAP
exchange occ=
urs between the authenticator and the peer=2C and therefore
any keys der=
ived in the process need to be known by the authenticator
and the peer. =
 In a number of cases (such as IKEv2)=2C the EAP server
only doesn't kno=
w the key used by the SAP=2C but it is an explicit
design requirement th=
at this not be possible.  

   This protocol MUST support exporting c=
hannel binding data to the AAA
   subsystem on the EAP server for valida=
tion.  The SAP must have access
   to channel binding data required for =
transport to the EAP server.

[BA] The last sentence also doesn't mak=
e sense.  Elsewhere in the document
it says that the authenticator is no=
t supposed to have access to the
channel bindings data=2C but here it im=
plies that it must have access=2C
since the SAP is run between the peer =
and authenticator. 

Section 7.1

7.1.  Requirements for Lower-=
Layer Bindings

   Lower-layer protocols MUST support EAP in order to=
 support EAP
   channel bindings.  These lower layers MUST support EAP m=
ethods that
   derive keying material=2C as otherwise no integrity-prote=
cted channel
   would be available to execute the channel bindings proto=
col.  Lower-
   layer protocols need not support traffic encryption=2C s=
ince this is
   independent of the authentication phase.

[BA] Cha=
nnel Bindings can still be used even on lower layers that don't use keying =
material.  For
example=2C an EAP method supporting channel bindings coul=
d be used with a wired network supporting
IEEE 802.1X-2004. Since the EA=
P server/AAA server will still obtain i1/i2 in this situation=2C why
sho=
uld it matter whether an integrity-protected channel is in place?  

=



= --_2a39902b-164b-4604-b58c-6fc4c7c72a72_-- From bernard_aboba@hotmail.com Mon Dec 7 22:33:12 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 B61FF3A683F for ; Mon, 7 Dec 2009 22:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.289 X-Spam-Level: X-Spam-Status: No, score=-0.289 tagged_above=-999 required=5 tests=[AWL=-0.405, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 Uq-RT2jdTjj4 for ; Mon, 7 Dec 2009 22:33:08 -0800 (PST) Received: from blu0-omc3-s18.blu0.hotmail.com (blu0-omc3-s18.blu0.hotmail.com [65.55.116.93]) by core3.amsl.com (Postfix) with ESMTP id EEAFE28C0FF for ; Mon, 7 Dec 2009 22:33:05 -0800 (PST) Received: from BLU137-W22 ([65.55.116.72]) by blu0-omc3-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Dec 2009 22:32:55 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_a9fbc4d6-6a57-4358-82a7-6942fa2873bf_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: Date: Mon, 7 Dec 2009 22:32:55 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 08 Dec 2009 06:32:55.0879 (UTC) FILETIME=[46D5A570:01CA77D0] Subject: Re: [Emu] =?windows-1256?q?Working_Group_Last_Call_for_draft-ietf-emu?= =?windows-1256?q?-chbind-04=2Etxt_=28part_3=29=FE?= 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, 08 Dec 2009 06:33:12 -0000 --_a9fbc4d6-6a57-4358-82a7-6942fa2873bf_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: 8bit Section 9.2 Additional network entities (such as proxies) might be on the communication path between peer and server and may attempt to manipulate the channel binding protocol. If these entities do not possess the keying material used for integrity protection of the channel binding messages, the same threat analysis applies as for the dishonest authenticators. Hence, such entities can neither manipulate single channel binding messages nor the outcome. On the other hand, entities with access to the keying material must be treated like a server in a threat analysis. Hence such entities are able to manipulate the channel binding protocol without being detected. However, the required knowledge of keying material is unlikely since channel binding is executed before the EAP method is completed, and thus before keying material is typically transported to other entities. [BA] Unless the transient EAP keys used for integrity protection are derivable from the MSK, possession of the MSK would not be sufficient to enable an authenticator to modify the channel bindings. As a result, the only entities relevant to the threat analysis are those that possess the TEKs, not just those that possess the MSK or other derived keys. --_a9fbc4d6-6a57-4358-82a7-6942fa2873bf_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: 8bit Section 9.2


   Additional network entities (such as proxies) might be on the
   communication path between peer and server and may attempt to
   manipulate the channel binding protocol.  If these entities do not
   possess the keying material used for integrity protection of the
   channel binding messages, the same threat analysis applies as for the
   dishonest authenticators.  Hence, such entities can neither
   manipulate single channel binding messages nor the outcome.  On the
   other hand, entities with access to the keying material must be
   treated like a server in a threat analysis.  Hence such entities are
   able to manipulate the channel binding protocol without being
   detected.  However, the required knowledge of keying material is
   unlikely since channel binding is executed before the EAP method is
   completed, and thus before keying material is typically transported
   to other entities.

[BA]
  Unless the transient EAP keys used for integrity protection are derivable from the 
MSK, possession of the MSK would not be sufficient to enable an authenticator to modify 
the channel bindings.  As a result, the only entities relevant to the threat analysis 
are those that possess the TEKs, not just those that possess the MSK or other derived keys.




--_a9fbc4d6-6a57-4358-82a7-6942fa2873bf_-- From bernard_aboba@hotmail.com Wed Dec 9 14:01: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 64C863A6997 for ; Wed, 9 Dec 2009 14:01:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.325 X-Spam-Level: X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_50=0.001, 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 KN+T2ChqWFJj for ; Wed, 9 Dec 2009 14:01:01 -0800 (PST) Received: from blu0-omc3-s28.blu0.hotmail.com (blu0-omc3-s28.blu0.hotmail.com [65.55.116.103]) by core3.amsl.com (Postfix) with ESMTP id DF6A43A6A31 for ; Wed, 9 Dec 2009 14:01:00 -0800 (PST) Received: from BLU137-DS2 ([65.55.116.72]) by blu0-omc3-s28.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 14:00:50 -0800 X-Originating-IP: [131.107.0.104] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 9 Dec 2009 14:00:49 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_081F_01CA78D8.038B4B90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acp5GxFx2SgX03ncQ3ebSEQXGXXdYQ== Content-Language: en-us X-OriginalArrivalTime: 09 Dec 2009 22:00:50.0140 (UTC) FILETIME=[11B171C0:01CA791B] Subject: Re: [Emu] New Liaison Statement, "Draft revised Recommendation ITU-T X.1034, Guideline on extensible authentication protocol based authentication and key management in a data communication network" 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, 09 Dec 2009 22:01:06 -0000 ------=_NextPart_000_081F_01CA78D8.038B4B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is a review of ITU Study Group 17, TD 0495, which represents a revision of ITU-T X.1034. For details, see: https://datatracker.ietf.org/documents/LIAISON/file714.pdf General Observations Looking at this document, I don't see much evidence that the ITU-T has made an effort to incorporate the feedback that EMU provided during the last review: https://datatracker.ietf.org/liaison/470/ This document is out of date, given that it doesn't reflect EAP developments over the last 5+ years. Looking through the reference section, there are still references to RFC 2284 (instead of RFC 3748), and no references to later EAP-related documents including RFC 4851, RFC 5247, RFC 5296, etc. Those references that are provided are frequently out of date, represent expired or incorrect versions, etc. Even the references to IEEE 802.11 are years out of date. The problem goes deeper than just the references, though. In the past 5 years, we have seen development of quite a few new EAP methods, new approaches to key management, new applications lower layers incorporating EAP, etc. We have also see organizations such as NIST (with 800-120) providing in-depth security analyses. Given all of this new activity, the most basic question that this document raises for me is "What unique value is this document attempting to provide above and beyond what the IETF, IEEE 802, NIST and other groups are already doing?" After reading this document, I still didn't have a clear idea of the goals and objectives. One possible answer to the question lies in Table 1, which attempts to classify EAP methods in terms of their "levels of security" (fundamental, middle-level, high-level). However, I'm not clear what value this table adds beyond what is already in NIST 800-120, RFC 4017 or other documents. In fact, one might argue that it muddies the waters since a number of fundamental security properties such as Authorization and Unique Naming are not listed as only recommended or optional, whereas these are treated as not as method properties but as fundamental properties of the EAP/AAA system as described in RFC 3748, 4296 and RFC 5247. Another possibility lies in the general description of the security properties of EAP. However, in the last five years we have seen many, many studies of this published none of which are referenced in the document. This includes formal analyses (e.g. The Stanford analysis of IEEE 802.11 security, by John Mitchell's team, work in Bill Arbaugh's group, etc.), NIST 800-120, RFC 4296, 5247, etc. Of course, we have also seen extensions to the EAP model introduced in RFC 5296. This is also not described in the document. Not only are all these aspects not referenced or described, but in numerous places the document uses terminology specific to IEEE 802. For example, the document discusses "types of PTK", and "group key handshake". Non-IEEE 802 technologies typically don't use the term "PTK", and IEEE 802.1X-REV does not include a "group key handshake". Moreover the "general flow of key management" described in Section 8.4 is not general at all, since this does not describe the lower layer key management used in IKEv2 or IEEE 802.16. Moving on to Table I.1, the document evaluates EAP MD5 (does anyone care about this anymore?), EAP SRP (long abandoned) against a series of critieria. If this table is worth including at all, it's worth making the effort to bring it up to date. ------=_NextPart_000_081F_01CA78D8.038B4B90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a review of ITU Study Group 17, TD 0495, = which represents a revision of ITU-T X.1034.  For details, = see:

https= ://datatracker.ietf.org/documents/LIAISON/file714.pdf

 

General Observations

 

Looking at this document, I don’t see much = evidence that the ITU-T has made an effort to incorporate the

feedback that EMU provided during the last = review:

https://datatracker.ie= tf.org/liaison/470/

 

 

This document is out of date, given that it = doesn’t reflect EAP developments over the last 5+ years.  = Looking

through the reference section, there are still = references to RFC 2284 (instead of RFC 3748),  and no references to = later

EAP-related documents including RFC 4851,  RFC = 5247, RFC 5296, etc.    Those references that are provided are = frequently

out of date, represent expired or incorrect = versions, etc.   Even the references to IEEE 802.11 are years out of date.

 

The problem goes deeper than just the references, though.  In the past 5 years, we have seen development of quite a =

few new EAP methods, new approaches to key = management, new applications lower layers incorporating EAP, etc.

We have also see organizations such as NIST (with = 800-120) providing in-depth security analyses. 

 

Given all of this new activity, the most basic = question that this document raises for me is “What unique value is = this

document attempting to provide above and beyond = what the IETF, IEEE 802, NIST and other groups are already

doing?”

 

After reading this document, I still didn’t = have a clear idea of the goals and objectives.

 

One possible answer to the question lies in Table = 1, which attempts to classify EAP methods in terms of their “levels of = security”

(fundamental, middle-level, high-level).  =

 

However, I’m not clear what value this table = adds beyond what is already in NIST 800-120, RFC 4017 or other documents. =

In fact, one might argue that it muddies the waters = since a number of  fundamental security properties such as Authorization =

and Unique Naming are not listed as only = recommended or optional, whereas these are treated as not as method properties =

but as fundamental properties of the EAP/AAA system = as described in RFC 3748, 4296 and RFC 5247.   

 

Another possibility lies in the general description = of the security properties of EAP.  However, in the last five years we = have

seen many, many studies of this published none of = which are referenced in the document.  This includes formal analyses

(e.g. The Stanford analysis of IEEE 802.11 = security, by John Mitchell’s team, work in Bill Arbaugh’s group, etc.), =  NIST

800-120, RFC 4296, 5247, etc. 

 

Of course, we have also seen extensions to the EAP = model introduced in RFC 5296.  This is also not described in = the

document.

 

Not only are all these aspects not referenced or = described, but in numerous places the document uses terminology

specific to IEEE 802.   For example, the = document discusses “types of PTK”, and “group key = handshake”.    Non-IEEE 802

technologies typically don’t use the term = “PTK”, and IEEE 802.1X-REV does not include a “group key = handshake”.

Moreover the “general flow of key = management” described in Section 8.4 is not general at all, since this does = not

describe the lower layer key management used in = IKEv2 or IEEE 802.16.

 

Moving on to Table I.1, the document evaluates EAP = MD5 (does anyone care about this anymore?),  EAP SRP (long = abandoned)

against a series of critieria.  If this table = is worth including at all, it’s worth making the effort to bring it up to date. 

 

------=_NextPart_000_081F_01CA78D8.038B4B90-- From hannes.tschofenig@nsn.com Thu Dec 10 02:47:56 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 14F3B3A6814 for ; Thu, 10 Dec 2009 02:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 vEqrWwdJyjaI for ; Thu, 10 Dec 2009 02:47:55 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 31F093A6774 for ; Thu, 10 Dec 2009 02:47:53 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id nBAAlc3K020125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 10 Dec 2009 11:47:38 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id nBAAlcrb023837; Thu, 10 Dec 2009 11:47:38 +0100 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 11:47:38 +0100 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, 10 Dec 2009 12:51:14 +0200 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4501F85EA9@FIESEXC015.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] New Liaison Statement, "Draft revised Recommendation ITU-T X.1034, Guideline on extensible authentication protocol based authenticationand key management in a data communication network" Thread-Index: Acp5GxFx2SgX03ncQ3ebSEQXGXXdYQAaJPrA References: From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Bernard Aboba" , X-OriginalArrivalTime: 10 Dec 2009 10:47:38.0376 (UTC) FILETIME=[30BD2080:01CA7986] Subject: Re: [Emu] New Liaison Statement, "Draft revised Recommendation ITU-T X.1034, Guideline on extensible authentication protocol based authenticationand key management in a data communication network" 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, 10 Dec 2009 10:47:56 -0000 Hi Bernard,=20 =20 here is my guess of the background of all this work.=20 =20 Imagine a company has worked on strong password based authentication and key exchange protocols. That company might also believe that they have some IPRs in this field.=20 =20 Now, some folks in that company would like to get their work standardized and they seem to think that the precondition to deployment is a standardized solution. =20 So far, everything is (sort of) fine.=20 =20 Then, a few "mistakes" seem to have happened.=20 =20 The authors believe that they need a deeper justification for publishing a new EAP method. (This is of course is wrong since everyone can write an EAP method and publish it as an Informational RFC.) =20 They do an analysis that points into the direction that such a new method is needed. They are probably not really interested in the analysis activity itself (and it really takes a long time to produce a serious analysis that might even conclude that no additional work is needed...) because they are only interested in a particular solution, namely their own solution. So, they produce a document and, for whatever reason, they forget to look at most of the EAP methods that would be relevant. =20 Then, they go to the ITU-T to do the analysis work. Why? Maybe they think that a standard in the area of strong password based authentication in the ITU-T would lead to some deployment or so. Hard to guess the real reason. Now, you (and others in EMU) have to review their document and provide feedback.=20 Did this answer all your questions? =20 Ciao Hannes ________________________________ From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of ext Bernard Aboba Sent: 10 December, 2009 00:01 To: emu@ietf.org Subject: Re: [Emu] New Liaison Statement,"Draft revised Recommendation ITU-T X.1034,Guideline on extensible authentication protocol based authenticationand key management in a data communication network" =09 =09 This is a review of ITU Study Group 17, TD 0495, which represents a revision of ITU-T X.1034. For details, see: https://datatracker.ietf.org/documents/LIAISON/file714.pdf =20 General Observations =20 Looking at this document, I don't see much evidence that the ITU-T has made an effort to incorporate the feedback that EMU provided during the last review: https://datatracker.ietf.org/liaison/470/ =20 =20 This document is out of date, given that it doesn't reflect EAP developments over the last 5+ years. Looking through the reference section, there are still references to RFC 2284 (instead of RFC 3748), and no references to later EAP-related documents including RFC 4851, RFC 5247, RFC 5296, etc. Those references that are provided are frequently out of date, represent expired or incorrect versions, etc. Even the references to IEEE 802.11 are years out of date.=20 =20 The problem goes deeper than just the references, though. In the past 5 years, we have seen development of quite a=20 few new EAP methods, new approaches to key management, new applications lower layers incorporating EAP, etc.=20 We have also see organizations such as NIST (with 800-120) providing in-depth security analyses. =20 =20 Given all of this new activity, the most basic question that this document raises for me is "What unique value is this document attempting to provide above and beyond what the IETF, IEEE 802, NIST and other groups are already doing?" =20 After reading this document, I still didn't have a clear idea of the goals and objectives.=20 =20 One possible answer to the question lies in Table 1, which attempts to classify EAP methods in terms of their "levels of security"=20 (fundamental, middle-level, high-level). =20 =20 However, I'm not clear what value this table adds beyond what is already in NIST 800-120, RFC 4017 or other documents.=20 In fact, one might argue that it muddies the waters since a number of fundamental security properties such as Authorization=20 and Unique Naming are not listed as only recommended or optional, whereas these are treated as not as method properties=20 but as fundamental properties of the EAP/AAA system as described in RFC 3748, 4296 and RFC 5247. =20 =20 Another possibility lies in the general description of the security properties of EAP. However, in the last five years we have seen many, many studies of this published none of which are referenced in the document. This includes formal analyses (e.g. The Stanford analysis of IEEE 802.11 security, by John Mitchell's team, work in Bill Arbaugh's group, etc.), NIST 800-120, RFC 4296, 5247, etc. =20 =20 Of course, we have also seen extensions to the EAP model introduced in RFC 5296. This is also not described in the document.=20 =20 Not only are all these aspects not referenced or described, but in numerous places the document uses terminology specific to IEEE 802. For example, the document discusses "types of PTK", and "group key handshake". Non-IEEE 802 technologies typically don't use the term "PTK", and IEEE 802.1X-REV does not include a "group key handshake".=20 Moreover the "general flow of key management" described in Section 8.4 is not general at all, since this does not describe the lower layer key management used in IKEv2 or IEEE 802.16.=20 =20 Moving on to Table I.1, the document evaluates EAP MD5 (does anyone care about this anymore?), EAP SRP (long abandoned) against a series of critieria. If this table is worth including at all, it's worth making the effort to bring it up to date. =20 =20 From aland@deployingradius.com Thu Dec 10 03:14:05 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 76A013A6AFE for ; Thu, 10 Dec 2009 03:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] 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 e5IPN+r77aUw for ; Thu, 10 Dec 2009 03:14:03 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id CCA013A6B0B for ; Thu, 10 Dec 2009 03:14:02 -0800 (PST) Message-ID: <4B20D7EE.8010507@deployingradius.com> Date: Thu, 10 Dec 2009 12:13:50 +0100 From: Alan DeKok User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: emu@ietf.org References: <3D3C75174CB95F42AD6BCC56E5555B4501F85EA9@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501F85EA9@FIESEXC015.nsn-intra.net> X-Enigmail-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Emu] New Liaison Statement, "Draft revised Recommendation ITU-T X.1034, Guideline on extensible authentication protocol based authenticationand key management in a data communication network" 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, 10 Dec 2009 11:14:05 -0000 On 09-12-10 11:51 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > Then, they go to the ITU-T to do the analysis work. Why? Maybe they > think that a standard in the area of strong password based > authentication in the ITU-T would lead to some deployment or so. Hard to > guess the real reason. Who are the expected consumers of the document? Anyone can read the ITU document, but who will be paying attention to it, and following its recommendations? Alan DeKok. From bernard_aboba@hotmail.com Thu Dec 10 05:45:21 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 8E11A3A6977 for ; Thu, 10 Dec 2009 05:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.707 X-Spam-Level: X-Spam-Status: No, score=-0.707 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_20=-0.74, 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 nBfgkGTUHK7L for ; Thu, 10 Dec 2009 05:45:20 -0800 (PST) Received: from blu0-omc3-s26.blu0.hotmail.com (blu0-omc3-s26.blu0.hotmail.com [65.55.116.101]) by core3.amsl.com (Postfix) with ESMTP id EF6C23A6934 for ; Thu, 10 Dec 2009 05:45:19 -0800 (PST) Received: from BLU137-W31 ([65.55.116.72]) by blu0-omc3-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Dec 2009 05:45:08 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_24ba7b7d-d8ae-4e22-b238-ce20ab91aae6_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , Date: Thu, 10 Dec 2009 05:45:08 -0800 Importance: Normal In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B4501F85EA9@FIESEXC015.nsn-intra.net> References: , <3D3C75174CB95F42AD6BCC56E5555B4501F85EA9@FIESEXC015.nsn-intra.net> MIME-Version: 1.0 X-OriginalArrivalTime: 10 Dec 2009 13:45:08.0811 (UTC) FILETIME=[FCE489B0:01CA799E] Subject: Re: [Emu] New Liaison Statement, "Draft revised Recommendation ITU-T X.1034, Guideline on extensible authentication protocol based authenticationand key management in a data communication network" 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, 10 Dec 2009 13:45:21 -0000 --_24ba7b7d-d8ae-4e22-b238-ce20ab91aae6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you=2C Hannes. =20 The motivation is now very clear -- we should interpret this document as a = "requirements statement" for chartering of an ITU group devoted to "standar= dization" of (preferrably highly encumbered) zero knowledge based EAP metho= d(s). = --_24ba7b7d-d8ae-4e22-b238-ce20ab91aae6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you=2C Hannes. =3B

The motivation is now very clear -- we= should interpret this document as a "requirements statement" for charterin= g of an ITU group devoted to "standardization" of (preferrably highly encum= bered) zero knowledge based EAP method(s).
= --_24ba7b7d-d8ae-4e22-b238-ce20ab91aae6_--