From simon at josefsson.org Thu Mar 29 15:03:42 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu Mar 29 15:03:51 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: (Internet-Drafts@ietf.org's message of "Wed\, 28 Mar 2007 15\:50\:02 -0400") References: Message-ID: <87tzw4p5g1.fsf@mocca.josefsson.org> Hi all! The SASL WG discussed new password-based mechanisms, and there were some discussions at the last meeting to do this through a GSS-API mechanism instead. I mentioned on jabber that I had been working on a draft to do that, and while it is far from finished I thought I'd publish it early to gauge interest in the work. My idea is to specify a challenge/response protocol that is (somewhat) agnostic to the framework (GSS-API or SASL) and then specify how that protocol is used in these two frameworks. Since the wire protocol is highly influenced by GSS-API and SASL concepts, the mappings for how to use the protocol in GSS-API or SASL is just one page. The cryptographic primitive is right now HMAC-SHA-256 but the intention is that other MACs, including non-HMAC based approaches such as AES-CMAC (RFC 4493) can be supported easily. To make it easier to implement this as a SASL mechanism, I'm sure the document could say a lot more. I intend to include sample code for DER length encoding (it is only a few lines of C code), which is something some people consider complex. Providing an entire implementation of the GS2-YGZBCUXPNWNVHSI mechanism would be possible to include, I believe there is not a lot of code to do it. This might make it easier for IMAP/SMTP implementers to start using it quickly. The document is available from the IETF servers, see the announcement below. Comments? I'm cc:ing this to the password-auth mailing list that I created for discussion of the document. Some discussions of the document may be off-topic for the SASL/KITTEN lists, and the WG chairs may prefer to see it discussed elsewhere (let me know!), so consider dropping the IETF lists when starting such a thread. To subscribe to the list, and for other resources related to this effort, see: http://josefsson.org/password-auth/ Even if there isn't much uptake from the SASL community on this idea, I believe having a password-based GSS-API mechanism is an important contribution and I'll continue working on that. How much the document talks about SASL will depend on the interest. Through GS2, it will eventually be possible to use it in SASL anyway. /Simon Internet-Drafts@ietf.org writes: > Title : A Password-based Authentication Protocol > Author(s) : S. Josefsson > Filename : draft-josefsson-password-auth-00.txt > Pages : 16 > Date : 2007-3-28 > > There is a lack of a simple, standardized, secure and modern > password-based mechanism for user authentication in application > protocols. This document specify a challenge/response protocol that > provide password-based authentication services. We describe how the > protocol may be used as a GSS-API mechanism and, using the GS2 > framework, how it may be used as a SASL mechanism. The protocol > supports HMAC-SHA-256 as the mandatory to implement algorithm, and it > supports channel bindings. The intended use is by application > protocol that today use CRAM-MD5 or DIGEST-MD5 via SASL, or by GSS- > API applications that needs a password based method. The protocol is > applicable to other environments, such as EAP, should the need arise. > > See for more information. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-josefsson-password-auth-00.txt From simon at josefsson.org Thu Mar 29 15:16:57 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu Mar 29 15:17:03 2007 Subject: Looking for WG input: Password based method requirements In-Reply-To: <004d01c76122$9e512990$2f01a8c0@china.huawei.com> (Madjid Nakhjiri's message of "Wed\, 07 Mar 2007 17\:39\:30 -0800") References: <004d01c76122$9e512990$2f01a8c0@china.huawei.com> Message-ID: <87odmcp4ty.fsf@mocca.josefsson.org> Hi! I have not been following the EMU WG closely, but I noticed that you are working on password-based authentication. I'm gauging interest in an effort to do a password-based protocol that supports both GSS-API and SASL, see: http://www.ietf.org/internet-drafts/draft-josefsson-password-auth-00.txt http://yxa.extundo.com/pipermail/password-auth/2007-March/000000.html http://josefsson.org/password-auth/ One idea that occurred to me was to make this a triple GSS-API/SASL/EAP mechanism. I don't know whether it is feasible. Some of the requirements you mentioned may argue otherwise (e.g., supporting transmission of password). However, the document might change to accommodate new ideas. One thing that is required is someone with more EAP involvement than me to help make sure it works fine for EAP. Consider this a cross-WG fertilization plea. :) Comments appreciated, Simon From Nicolas.Williams at sun.com Thu Mar 29 15:17:16 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu Mar 29 15:21:59 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <87tzw4p5g1.fsf@mocca.josefsson.org> References: <87tzw4p5g1.fsf@mocca.josefsson.org> Message-ID: <20070329131715.GJ1666@Sun.COM> On Thu, Mar 29, 2007 at 03:03:42PM +0200, Simon Josefsson wrote: > My idea is to specify a challenge/response protocol that is (somewhat) > agnostic to the framework (GSS-API or SASL) and then specify how that > protocol is used in these two frameworks. Since the wire protocol is > highly influenced by GSS-API and SASL concepts, the mappings for how > to use the protocol in GSS-API or SASL is just one page. The I guess it can be one page, since for GSS challenge/response password- based mechs there won't be many name types available, thus not much discussion of naming. Right? Maybe not: presumably acceptor names are used to salt the password, in which case any name type goes and the mech has to specify the relevant mappings from generic name syntax to whatever the mech uses internally. And there's the exported name token format to consider also. But in any case, it needn't be much text, and I've volunteered to write that text. [...] > Comments? > > I'm cc:ing this to the password-auth mailing list that I created for > discussion of the document. Some discussions of the document may be > off-topic for the SASL/KITTEN lists, and the WG chairs may prefer to > see it discussed elsewhere (let me know!), so consider dropping the > IETF lists when starting such a thread. To subscribe to the list, and > for other resources related to this effort, see: Not another mailing list... :/ :) > http://josefsson.org/password-auth/ > > Even if there isn't much uptake from the SASL community on this idea, > I believe having a password-based GSS-API mechanism is an important > contribution and I'll continue working on that. How much the document > talks about SASL will depend on the interest. Through GS2, it will > eventually be possible to use it in SASL anyway. Agreed. Nico -- From simon at josefsson.org Thu Mar 29 15:33:33 2007 From: simon at josefsson.org (Simon Josefsson) Date: Thu Mar 29 15:33:40 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <20070329131715.GJ1666@Sun.COM> (Nicolas Williams's message of "Thu\, 29 Mar 2007 08\:17\:16 -0500") References: <87tzw4p5g1.fsf@mocca.josefsson.org> <20070329131715.GJ1666@Sun.COM> Message-ID: <87bqicp42a.fsf@mocca.josefsson.org> Nicolas Williams writes: > On Thu, Mar 29, 2007 at 03:03:42PM +0200, Simon Josefsson wrote: >> My idea is to specify a challenge/response protocol that is (somewhat) >> agnostic to the framework (GSS-API or SASL) and then specify how that >> protocol is used in these two frameworks. Since the wire protocol is >> highly influenced by GSS-API and SASL concepts, the mappings for how >> to use the protocol in GSS-API or SASL is just one page. The > > I guess it can be one page, since for GSS challenge/response password- > based mechs there won't be many name types available, thus not much > discussion of naming. Right? Maybe not: presumably acceptor names are > used to salt the password, in which case any name type goes and the mech > has to specify the relevant mappings from generic name syntax to > whatever the mech uses internally. And there's the exported name token > format to consider also. I'm not really that familiar with the naming corners of GSS-API... In any case, how to salt the password is an open question. Perhaps the exported name format can be used as the salt value with PKCS#5 PBKDF2? But then you'll need to transfer the PBKDF2 iteration counter, or (worse) fixate it. The iteration counter question is the main reason why I haven't used PBKDF2 yet. That, and I'm not sure PBKDF2 in this protocol actually protects against any valid security threats. > But in any case, it needn't be much text, and I've volunteered to write > that text. Excellent! /Simon From Nicolas.Williams at sun.com Thu Mar 29 15:42:56 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu Mar 29 15:43:56 2007 Subject: pw-based mech options (Re: draft-josefsson-password-auth-00.txt) In-Reply-To: <20070329131715.GJ1666@Sun.COM> References: <87tzw4p5g1.fsf@mocca.josefsson.org> <20070329131715.GJ1666@Sun.COM> Message-ID: <20070329134256.GN1666@Sun.COM> On Thu, Mar 29, 2007 at 08:17:16AM -0500, Nicolas Williams wrote: > Not another mailing list... :/ :) > > > http://josefsson.org/password-auth/ And moderated to boot. I'd rather we first seek consensus on the SASL list as to whether the WG should take on any new password-based mechanisms, and if so whether to proceed as Sam suggested (spec the mech as a SASL/GS2 mech without reference to the GSS-API and describe its GSS bindings in a separate section/document). Me, I'm all for doing this work in this WG. Of course, there were several options on the table, and we may want to pick one, or maybe two. I volunteered to help with the GSS bits regardless of which options we choose. BTW, about YAP, I get it now: it uses unique channel bindings as a standing for both, server challenge and client nonce. Also, during SAAG EKR suggested to me (via jabber) doing a password- based mechanism as a profile of TLS PSK. Of course, doing password auth in TLS PSK can work and it can even provide a measure of protection against off-line dictionary attacks, but it does not provide for privacy protection of the client identity. If we really want the latter then YAP seems like a good choice for SASL apps running over TLS, else a password-based profile of TLS PSK seems like a better approach. We'd still need a password-based GSS mechanism, but if we push the SASL mechanism to TLS then we effectively wash SASL's hands of a password-based GSS mech. Our options so far: - TLS PSK profile - YAP (which, incidentally, it seems it can't be a GS2 mech, though it can be a SASL mech and it can be a GSS mech) - Traditional challenge/response mechanisms (Simon's, Hexa, etc...) A TLS profile seems un-SASLish, but we (the IETF) could use that too. YAP is neat (one round-trip!), but absolutely depends on an underlying channel with unique channel bindings (else it's replayable). A traditional challenge/response design is needed to have a well rounded SASL/GSS mechanism story. So, my tentative position: - pursue a traditional challenge/response mechanism as a WG item - pursue YAP as a WG item IFF the privacy protection angle is deemed important - pursue a TLS PSK profile as an individual submission or let the TLS WG take it Comments? Nico -- From Nicolas.Williams at sun.com Thu Mar 29 15:57:43 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu Mar 29 15:58:51 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <87bqicp42a.fsf@mocca.josefsson.org> References: <87tzw4p5g1.fsf@mocca.josefsson.org> <20070329131715.GJ1666@Sun.COM> <87bqicp42a.fsf@mocca.josefsson.org> Message-ID: <20070329135743.GO1666@Sun.COM> On Thu, Mar 29, 2007 at 03:33:33PM +0200, Simon Josefsson wrote: > I'm not really that familiar with the naming corners of GSS-API... In You need to specify what name types the mech supports and how to convert from generic name syntaxes (, @) to mechanism- specific syntaxes (which for a password-based mechanism might be the identity function) and what mechanism-specific name types exist, their syntaxes and so on (there wouldn't be any for a password-based mech). And then there's the exported name token format, which for password-based mechs should also be trivial. > any case, how to salt the password is an open question. Perhaps the Well, you'd want to salt it with the server's name, so the verifier is different at each server. Then again, many sites might object. So you might want a two level verifier derivation where the first step is not salted with the server name and the second is -- then one could distribute the output of the first step as the verifier for all servers in a site. > exported name format can be used as the salt value with PKCS#5 PBKDF2? Yes. But there's two names: the client's and the server's. > But then you'll need to transfer the PBKDF2 iteration counter, or > (worse) fixate it. The iteration counter question is the main reason > why I haven't used PBKDF2 yet. That, and I'm not sure PBKDF2 in this > protocol actually protects against any valid security threats. Either negotiate the iteration count or make it part of the mechanism name/OID. Kerberos V uses PBKDF2. I see no reason why we couldn't use it here. Nico -- From Kurt.Zeilenga at Isode.com Thu Mar 29 16:13:03 2007 From: Kurt.Zeilenga at Isode.com (Kurt Zeilenga) Date: Thu Mar 29 16:21:52 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <87tzw4p5g1.fsf@mocca.josefsson.org> References: <87tzw4p5g1.fsf@mocca.josefsson.org> Message-ID: <1CB4ECB2-D903-4D75-97B1-B7ED11999691@Isode.com> On Mar 29, 2007, at 6:03 AM, Simon Josefsson wrote: > I'm cc:ing this to the password-auth mailing list that I created for > discussion of the document. Some discussions of the document may be > off-topic for the SASL/KITTEN lists, and the WG chairs may prefer to > see it discussed elsewhere (let me know!), so consider dropping the > IETF lists when starting such a thread. Given the SASL charter allows for the WG to review, as time permits, independently developed SASL mechanism specifications, and the SASL WG is currently discussing revision of our charter to include additional work item(s) in this area, I would prefer discussions related to password-based SASL mechanisms stay on the SASL WG list (at least for now). -- Kurt, SASL WG co-chair From martin.rex at sap.com Thu Mar 29 16:28:30 2007 From: martin.rex at sap.com (Martin Rex) Date: Thu Mar 29 16:35:22 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <20070329135743.GO1666@Sun.COM> from "Nicolas Williams" at Mar 29, 7 08:57:43 am Message-ID: <200703291428.l2TESVM2012931@fs4113.wdf.sap.corp> Nicolas Williams wrote: > > > any case, how to salt the password is an open question. Perhaps the > > Well, you'd want to salt it with the server's name, so the verifier is > different at each server. Then again, many sites might object. So you > might want a two level verifier derivation where the first step is not > salted with the server name and the second is -- then one could > distribute the output of the first step as the verifier for all servers > in a site. Most challenge-response protocols perform a unidirectional authentication of the client/initiator to the server/acceptor only, and for those the authentication scheme usually does not have a name for the acceptor. I know that the Kerberos gss-api mechanism is "slightly" broken in this respect since it requires a target name for gss_init_sec_context even for unidirectional-only authentication. This requirement is one of the reasons why in many Kerberos scenarios an end-point identification similar to what HTTPoverSSL/TLS does is used instead of a real mutual authentication. One example for a challenge-repsonse authentication with GSS-API style token exchange is Microsoft's NTLM SSP. My GSS-API wrapper for Microsoft's Kerberos SSP also includes a wrapper for Microsoft's NTLM SSP. -Martin From martin.rex at sap.com Thu Mar 29 16:48:50 2007 From: martin.rex at sap.com (Martin Rex) Date: Thu Mar 29 16:49:23 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <20070329135743.GO1666@Sun.COM> from "Nicolas Williams" at Mar 29, 7 08:57:43 am Message-ID: <200703291448.l2TEmonL014308@fs4113.wdf.sap.corp> Nicolas Williams wrote: > > > any case, how to salt the password is an open question. Perhaps the > > Well, you'd want to salt it with the server's name, so the verifier is > different at each server. Then again, many sites might object. So you > might want a two level verifier derivation where the first step is not > salted with the server name and the second is -- then one could > distribute the output of the first step as the verifier for all servers > in a site. What you seem to be looking/asking for sounds like "channel bindings" rather than name-based mutual authentication of the server (many password-based challenge-response authentication schemes do not provide mutual authentication). Keep in mind that it might be difficult for servers and clients to agree on the same name for the server. Take Microsoft Kerberos as an example: there the server usually doesn't know (and doesn't care) what target name the client is using -- the server will always try to open service tickets by "brute force" using his own secret key. With very few exceptions, service principals don't exist in Microsofts Kerberos, they're mere aliases known to the KDC/Active Directory and may be used by clients/initiators-- A Microsoft server/acceptor normally doesn't know or care what service pricipal aliases exist for his own account and which particular alias was used by a client, it will look at the realm on the service ticket to get the salting right, but entirely ignore the principal name on the ticket. (At least that is what happend with W2K Kerberos when I tested, and it can be verified by setting up two seperate user accounts "b" and "c" with the same password (both enabled for rfc-1964 authentication if W2K3 AD is used). A server started under "b" will then happily establish security contexts with clients that use "b" as the target name as well as clients that use "c" as the target name.) -Martin From Nicolas.Williams at sun.com Thu Mar 29 17:21:29 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu Mar 29 17:22:30 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <200703291428.l2TESVM2012931@fs4113.wdf.sap.corp> References: <20070329135743.GO1666@Sun.COM> <200703291428.l2TESVM2012931@fs4113.wdf.sap.corp> Message-ID: <20070329152128.GQ1666@Sun.COM> On Thu, Mar 29, 2007 at 04:28:30PM +0200, Martin Rex wrote: > Most challenge-response protocols perform a unidirectional > authentication of the client/initiator to the server/acceptor only, > and for those the authentication scheme usually does not have > a name for the acceptor. Understood. Perhaps then what I should have said is that when mutual authentication is requested then the password should be salted with the acceptor name. From Martin.Rex at sap.com Thu Mar 29 18:08:33 2007 From: Martin.Rex at sap.com (Martin Rex) Date: Thu Mar 29 18:09:17 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <20070329152128.GQ1666@Sun.COM> from "Nicolas Williams" at Mar 29, 7 10:21:29 am Message-ID: <200703291608.l2TG8XAi019364@fs4113.wdf.sap.corp> Nicolas Williams wrote: > > On Thu, Mar 29, 2007 at 04:28:30PM +0200, Martin Rex wrote: > > Most challenge-response protocols perform a unidirectional > > authentication of the client/initiator to the server/acceptor only, > > and for those the authentication scheme usually does not have > > a name for the acceptor. > > Understood. Perhaps then what I should have said is that when mutual > authentication is requested then the password should be salted with the > acceptor name. At first glance I think it should be OK if some kind of channel bindings are included in (hashed into) the challenge-response exchange. -Martin From Nicolas.Williams at sun.com Thu Mar 29 18:17:01 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu Mar 29 18:18:04 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <200703291608.l2TG8XAi019364@fs4113.wdf.sap.corp> References: <20070329152128.GQ1666@Sun.COM> <200703291608.l2TG8XAi019364@fs4113.wdf.sap.corp> Message-ID: <20070329161701.GA8252@Sun.COM> On Thu, Mar 29, 2007 at 06:08:33PM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > > > On Thu, Mar 29, 2007 at 04:28:30PM +0200, Martin Rex wrote: > > > Most challenge-response protocols perform a unidirectional > > > authentication of the client/initiator to the server/acceptor only, > > > and for those the authentication scheme usually does not have > > > a name for the acceptor. > > > > Understood. Perhaps then what I should have said is that when mutual > > authentication is requested then the password should be salted with the > > acceptor name. > > At first glance I think it should be OK if some kind of channel bindings > are included in (hashed into) the challenge-response exchange. Certainly, provided any are available. Last week Kurt proposed a mechanism that requires channel bindings, and called it YAP (yet another ...). It works in just one round-trip (in addition to however many the secure channel required to establish) because the channel binding acts as the server challenge (provided the channel binding is unique in time, else there's a replay attack). Nico -- From Nicolas.Williams at sun.com Thu Mar 29 18:28:40 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu Mar 29 18:29:43 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <20070329161701.GA8252@Sun.COM> References: <20070329152128.GQ1666@Sun.COM> <200703291608.l2TG8XAi019364@fs4113.wdf.sap.corp> <20070329161701.GA8252@Sun.COM> Message-ID: <20070329162839.GB8252@Sun.COM> A very general password-based challenge-response mechanism that provides optional channel binding and optional mutual authentication in one, one and a half and two round-trips should be feasible: - w/ unique channel bindings -> 1 rt - w/o unique channel bindings + uni-dir authen -> 1 and 1/2 rt - w/o unique channel bindings + mutual auth -> 2 rt Mutual authentication would work the acceptor name into the PBKDF inputs. Uni-directional authentication would not work the acceptor name into the PBKDF (only if no acceptor name was given? or always). I.e., we could merge YAP and the other proposals into one generic mechanism. Nico -- From Nicolas.Williams at sun.com Thu Mar 29 23:15:14 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu Mar 29 23:16:20 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <20070329162839.GB8252@Sun.COM> References: <20070329152128.GQ1666@Sun.COM> <200703291608.l2TG8XAi019364@fs4113.wdf.sap.corp> <20070329161701.GA8252@Sun.COM> <20070329162839.GB8252@Sun.COM> Message-ID: <20070329211513.GJ8252@Sun.COM> > I.e., we could merge YAP and the other proposals into one generic > mechanism. Very, very roughly, primarily to illustrate the context token exchanges: IDi = initiator name IDt = target acceptor name IDa = acceptor name (like IDt, but asserted by the acceptor) S = salt derived from IDt or IDa K = PBKDF2(password || S, iteration) R1 = response_function(K, [challenge] || channel bindings || [cnonce]) R2 = response_function2(K, R1) 1/2 rt ( channel bindings and no mutual auth) I -> A: IDi, [IDt,] R1 1 rt ( channel bindings and mutual auth) I -> A: IDi, IDt, R1 A -> I: R2 1 1/2 rt (no channel bindings and no mutual auth) I -> A: IDi, [IDt] A -> I: IDa, challenge I -> A: nonce, R1 2 rt (no channel bindings and mutual auth) I -> A: IDi A -> I: IDa, challenge I -> A: nonce, R1 A -> I: R2 A target name is needed so the acceptor's verifier can be a weak password equivalent (meaning it's a password equivalent only for authenticating to the same acceptor). Therefore it's useful to have a target name even when mutual auth is not requested. A target name is required for mutual auth, of course. The 1 1/2 rt version could add DH key agreement for PFS. And the 2 rt version could add DH key agreement for PFS and some privacy protection of IDi. That is probably not worthwhile for any SASL application, since they tend to have STARTTLS-type options, and for GSS one could always add PFS with stackable mechanisms. Nico -- From Martin.Rex at sap.com Fri Mar 30 00:11:16 2007 From: Martin.Rex at sap.com (Martin Rex) Date: Fri Mar 30 00:11:30 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <20070329211513.GJ8252@Sun.COM> from "Nicolas Williams" at Mar 29, 7 04:15:14 pm Message-ID: <200703292211.l2TMBGWS010580@fs4113.wdf.sap.corp> Nicolas Williams wrote: > > A target name is needed so the acceptor's verifier can be a weak > password equivalent (meaning it's a password equivalent only for > authenticating to the same acceptor). Therefore it's useful to > have a target name even when mutual auth is not requested. > > A target name is required for mutual auth, of course. To me that seems to be slightly inappropriate terminology. Which particular challenge-response scheme do you have in mind where the server actually performs a mutual authentication, i.e. provides a cryptographic proof of his identity? If the client derives the target name from the network endpoint address (i.e. fqdn-hostname plus service/tcp-port-no) and the server simply "asserts" this name, then this is really a channel binding based on a printable name instead of the low-level network address, but still a channel binding and not an authentication. -Martin From Nicolas.Williams at sun.com Fri Mar 30 00:37:56 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri Mar 30 00:39:01 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <200703292211.l2TMBGWS010580@fs4113.wdf.sap.corp> References: <20070329211513.GJ8252@Sun.COM> <200703292211.l2TMBGWS010580@fs4113.wdf.sap.corp> Message-ID: <20070329223756.GP8252@Sun.COM> On Fri, Mar 30, 2007 at 12:11:16AM +0200, Martin Rex wrote: > To me that seems to be slightly inappropriate terminology. > > Which particular challenge-response scheme do you have in mind > where the server actually performs a mutual authentication, > i.e. provides a cryptographic proof of his identity? Any where the server stores a secret verifier derived from the password salted with the server's name. If the server sends a response to the client's response that proves it knows the verifier then the client can consider the server to be authenticated to the client. > If the client derives the target name from the network endpoint > address (i.e. fqdn-hostname plus service/tcp-port-no) and > the server simply "asserts" this name, then this is really > a channel binding based on a printable name instead of You're misusing the term "channel binding" here. A server name not associated with some secure channel below the application layer is not a channel binding. > the low-level network address, but still a channel binding and > not an authentication. I really didn't want to talk about server name canonicalization. I wanted to sketch a generic password-based challenge/response mechanism that supports the optional use of channel binding and optional mutual authentication. Yes, I included in my sketch an acceptor-side assertion of its name. This has two purposes that I did not mention. One: when the client doesn't know the server's name the client can simply go ahead and use the asserted server name as the salt -- if the alternative is not to salt the password at all then this is clearly good and not harmful (the client provides material that can be attacked offline regardless of how the password is salted). The other: so the client can output the correct server name to the application which can then prompt the user, or for "fuzzy" server name canonicalization. (I know, you don't have to remind me that the GSS-APIv2u1's GSS_Canonicalize_name() is supposed to be able to canonicalize the given server (or whatever) name securely and out of band w.r.t. security context establishment. But we're talking here too about a mechanism usable outside the context of the GSS-API also, and anyways, that bit of GSS-APIv2u1 semantics is rather cumbersome.) From Martin.Rex at sap.com Fri Mar 30 00:50:43 2007 From: Martin.Rex at sap.com (Martin Rex) Date: Fri Mar 30 00:51:01 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <20070329223756.GP8252@Sun.COM> from "Nicolas Williams" at Mar 29, 7 05:37:56 pm Message-ID: <200703292250.l2TMohmQ013127@fs4113.wdf.sap.corp> Nicolas Williams wrote: > > On Fri, Mar 30, 2007 at 12:11:16AM +0200, Martin Rex wrote: > > To me that seems to be slightly inappropriate terminology. > > > > Which particular challenge-response scheme do you have in mind > > where the server actually performs a mutual authentication, > > i.e. provides a cryptographic proof of his identity? > > Any where the server stores a secret verifier derived from the password > salted with the server's name. If the server sends a response to the > client's response that proves it knows the verifier then the client can > consider the server to be authenticated to the client. Depending on the architecture of the challenge response scheme this may not be easily done. There are legacy systems where the (app)server actually possesses the shared secret and could therefore "prove he knows it". AFAIK, the NTLM authentication on windows differs here. The server doesn't have access to the shared secret, but has a secure channel to a domain controller where he can ask whether a particular combination of challenge and response is acceptable. > > > If the client derives the target name from the network endpoint > > address (i.e. fqdn-hostname plus service/tcp-port-no) and > > the server simply "asserts" this name, then this is really > > a channel binding based on a printable name instead of > > You're misusing the term "channel binding" here. A server name not > associated with some secure channel below the application layer is not a > channel binding. Sorry, but I have to disagree completely. GSS-API has a very "open" concept of channel bindings. You might want to turn your attention to RFC-2744 Section 3.11. which lists all types of channel bindings that "GSS-API v2" knows about. None of what I see there is what I recognize as "secure" channel bindings, but it does have the "GSS_C_AF_INET" type. -Martin From Nicolas.Williams at sun.com Fri Mar 30 00:59:00 2007 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri Mar 30 01:00:09 2007 Subject: draft-josefsson-password-auth-00.txt In-Reply-To: <200703292250.l2TMohmQ013127@fs4113.wdf.sap.corp> References: <20070329223756.GP8252@Sun.COM> <200703292250.l2TMohmQ013127@fs4113.wdf.sap.corp> Message-ID: <20070329225900.GR8252@Sun.COM> On Fri, Mar 30, 2007 at 12:50:43AM +0200, Martin Rex wrote: > Nicolas Williams wrote: > > Any where the server stores a secret verifier derived from the password > > salted with the server's name. If the server sends a response to the > > client's response that proves it knows the verifier then the client can > > consider the server to be authenticated to the client. > > Depending on the architecture of the challenge response scheme > this may not be easily done. > > There are legacy systems where the (app)server actually possesses > the shared secret and could therefore "prove he knows it". Indeed. But that doesn't mean that a generic mechanism in this area must not support salting passwords as I described. > AFAIK, the NTLM authentication on windows differs here. The > server doesn't have access to the shared secret, but has a > secure channel to a domain controller where he can ask whether > a particular combination of challenge and response is acceptable. Yes, proxying should be acceptable. > > You're misusing the term "channel binding" here. A server name not > > associated with some secure channel below the application layer is not a > > channel binding. > > Sorry, but I have to disagree completely. GSS-API has a very > "open" concept of channel bindings. Here we're talking about a mechanism more generic still than a GSS mechanism. Lately when we speak of channel binding we mostly mean it in the "transformed representations of encryption keys) of the underlying communications channel, of protection mechanisms applied to that communications channel," subset of the sense of RFC2743. You may want to comment on draft-williams-on-channel-binding-01.txt; it's in IETF Last Call. > You might want to turn your attention to RFC-2744 Section 3.11. The relevant text is in RFC2743, section 1.1.6, first paragraph. Nico --