From jehan.marmottard@gmail.com Thu Sep 1 12:45:01 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8709E21F96AF for ; Thu, 1 Sep 2011 12:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCedNCNCHw3w for ; Thu, 1 Sep 2011 12:45:01 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D85E121F96AB for ; Thu, 1 Sep 2011 12:45:00 -0700 (PDT) Received: by wwf5 with SMTP id 5so1559935wwf.13 for ; Thu, 01 Sep 2011 12:46:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding; bh=XwKP9rH1+IuPtqp+qbiw2Mva5ix/LiBWkEmkGWL5TYk=; b=izNaiaPsb1kr9SmP0paFXRAgnaG2v7OChvJ2FvAxaS1OETLwqJD5UG0qh/PLO/iHEu 9OXI/rWfDSmZ83cYAwarjCDErO+W14vjfu1bTeq4/pp6wkxazk8N0BfKmmW/Y71zwqKo Th76Lp+4t1aV/kTE/UzjesDb8WDa8jGUNSKCA= Received: by 10.216.156.202 with SMTP id m52mr585330wek.21.1314906394091; Thu, 01 Sep 2011 12:46:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.21.8 with HTTP; Thu, 1 Sep 2011 12:46:13 -0700 (PDT) From: =?UTF-8?B?SmVoYW4gUGFnw6hz?= Date: Fri, 2 Sep 2011 04:46:13 +0900 Message-ID: To: "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [kitten] RFC-5802 (SCRAM): authorization identity passed through stringprep X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 19:45:01 -0000 Hi, I just noticed that the SCRAM RFC does not ask that the authorization identity (a=3D) if present be prepared by the SASLprep profile of the stringprep algorithm. I would think though that it should follow the same preparation as the authentication identity (n=3D). Unless there was a reason to this which I am willing to read, I would like to propose an errata which updates: =C2=AB The syntax of this field is the same as that of the "n" field with respect to quoting of '=3D' and ','. =C2=BB into: =C2=AB The syntax of this field is the same as that of the "n" field with respect to preparing the username using the "SASLprep" profile of the "stringprep" algorithm and to quoting of '=3D' and ','. =C2=BB May I propose this errata? Thanks. Jehan From alexey.melnikov@isode.com Thu Sep 1 14:20:32 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B472021F96EF for ; Thu, 1 Sep 2011 14:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAuZcQbl7MeB for ; Thu, 1 Sep 2011 14:20:32 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id ED24A21F95F9 for ; Thu, 1 Sep 2011 14:20:31 -0700 (PDT) Received: from [188.29.206.230] (188.29.206.230.threembb.co.uk [188.29.206.230]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 1 Sep 2011 22:22:03 +0100 Message-ID: <4E5FF775.9010207@isode.com> Date: Thu, 01 Sep 2011 22:21:57 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: =?UTF-8?B?SmVoYW4gUGFnw6hz?= References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC-5802 (SCRAM): authorization identity passed through stringprep X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2011 21:20:32 -0000 Jehan Pag=C3=A8s wrote: >Hi, > =20 > Hi Jehan, >I just noticed that the SCRAM RFC does not ask that the authorization >identity (a=3D) if present be prepared by the SASLprep profile of the >stringprep algorithm. I would think though that it should follow the >same preparation as the authentication identity (n=3D). > >Unless there was a reason to this which I am willing to read, I would >like to propose an errata which updates: >=C2=AB >The syntax of this field is the same as that of the "n" field >with respect to quoting of '=3D' and ','. >=C2=BB >into: >=C2=AB >The syntax of this field is the same as that of the "n" field >with respect to preparing the username using the "SASLprep" profile of >the "stringprep" algorithm and to quoting of '=3D' and ','. >=C2=BB > =20 > Per RFC 4422 syntax and normalization of authorization identities is=20 controlled by protocol spec, not SASL mechanism specs. So if, for=20 example, XMPP spec says that all authorization identities need to be=20 SASLpreped, then this would apply to SCRAM as well. >May I propose this errata? > =20 > As per above, I think the document is correct in this respect. >Thanks. > =20 > From jehan.marmottard@gmail.com Mon Sep 5 06:55:35 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B1A321F8B6D for ; Mon, 5 Sep 2011 06:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id al+Ku4e3LiFE for ; Mon, 5 Sep 2011 06:55:35 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D203F21F8B68 for ; Mon, 5 Sep 2011 06:55:34 -0700 (PDT) Received: by wyg8 with SMTP id 8so4428075wyg.31 for ; Mon, 05 Sep 2011 06:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=5Orb+JEf428/FASU3CzmHgVJemekQzZDxsnHcuKG12A=; b=LNwzF58j3S9wiWocm+qidYmW+JmAeQz10SAXIcj4Lp70xPGuY2zI91ERiwAcm6/1HO NoQ3jCawPKZAXSG9eh5o5RxToY239hCRoHC+fb77ERhh7xOWBLhhGRwAKeEWFCvkWNyJ IGzoNu/jnKGyE3Yk0LQA2OMC3hJTVCsTcUzXU= Received: by 10.216.229.149 with SMTP id h21mr445421weq.47.1315230622247; Mon, 05 Sep 2011 06:50:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.23.66 with HTTP; Mon, 5 Sep 2011 06:46:16 -0700 (PDT) In-Reply-To: <4E5FF775.9010207@isode.com> References: <4E5FF775.9010207@isode.com> From: =?UTF-8?B?SmVoYW4gUGFnw6hz?= Date: Mon, 5 Sep 2011 22:46:16 +0900 Message-ID: To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC-5802 (SCRAM): authorization identity passed through stringprep X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 13:55:35 -0000 Hi, 2011/9/2 Alexey Melnikov : > Jehan Pag=C3=A8s wrote: > >> Hi, >> > > Hi Jehan, > >> I just noticed that the SCRAM RFC does not ask that the authorization >> identity (a=3D) if present be prepared by the SASLprep profile of the >> stringprep algorithm. I would think though that it should follow the >> same preparation as the authentication identity (n=3D). >> >> Unless there was a reason to this which I am willing to read, I would >> like to propose an errata which updates: >> =C2=AB >> The syntax of this field is the same as that of the "n" field >> with respect to quoting of '=3D' and ','. >> =C2=BB >> into: >> =C2=AB >> The syntax of this field is the same as that of the "n" field >> with respect to preparing the username using the "SASLprep" profile of >> the "stringprep" algorithm and to quoting of '=3D' and ','. >> =C2=BB >> > > Per RFC 4422 syntax and normalization of authorization identities is > controlled by protocol spec, not SASL mechanism specs. So if, for example= , > XMPP spec says that all authorization identities need to be SASLpreped, t= hen > this would apply to SCRAM as well. Indeed it seems that you are right. It is said in various places in RFC-4422 that this is protocol specific. In any case, I find a little annoying that authentication and authorization identity are processed differently. Actually I now see the have the opposite bother: I don't see why we pass the authcid through stringprep. Why didn't we stop to ',' and '=3D' escaping there too and let the protocol (XMPP for instance) enforce this on its side? I don't understand the double standard here. Keeping the XMPP example, the server will also process authcid through stringprep (but Nodeprep profile now, so the authcid would be stringprep-ed both to Nodeprep and SASLprep) and work is going on passing away from stringprep in RFC-6122. I think then we should have released this stringprep processing on authcid. Is there a reason we make this processing? Moreover it is written in RFC-5802: =C2=ABthe client SHOULD prepare the username using the "SASLprep" profile=C2=BB. If we really wanted to do this, why isn't it a MUST? We might get into cases where the same authentication identity can be transferred in 2 forms by 2 clients, whether it has been stringprep-ed or not. Isn't there even more lack of consistency here? >> May I propose this errata? >> > > As per above, I think the document is correct in this respect. I think you are right. Now, as you read, I would rather propose the opposite change by releasing away this stringprep processing from authcid (rather than adding it on authzid) for consistency. Doesn't it make sense? Thanks. Jehan From nico@cryptonector.com Tue Sep 6 10:34:11 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A23421F8C5F for ; Tue, 6 Sep 2011 10:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[AWL=-1.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mCesA-KP374 for ; Tue, 6 Sep 2011 10:34:10 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id B07BE21F8C60 for ; Tue, 6 Sep 2011 10:34:10 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id AD83E2F406D for ; Tue, 6 Sep 2011 10:35:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=RzdvX7ajLuKb11jS3WwhmJq79S9Z1gn8pno1NnldUWk9 7TQEYRXrjzTHYEH9YejmaBqY1H8C6waE/N6wPVB0hZJOnLBdDEuX8LbgiEpl71dx c5rKzWWcB3GtJ6+7fR7SlZKsNpuNJB/JUFfhkIxmkqJc3YUEu3OISkmVzLPCgKI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=wFdSuf42SOP1zvTJP+b8HBqMYIs=; b=P2cdSm40Ej/ T12NnD6HEf2huNK8Q9carOqPf9OzFwSrKFZj1CdhyUl6r9oUTwTYRsMyXoQZnmkV ZR3RXU9dIvU7RqiYBhiUTV1CL9nH/dzSW5DVm8VZZAHfo1JFEbjBW3cCfHP3mbNZ Aydvq2BOBun3Zj6teKJO9iRhQWGZX8iQ= Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 8B9E72F4076 for ; Tue, 6 Sep 2011 10:35:57 -0700 (PDT) Received: by yxj17 with SMTP id 17so3634743yxj.31 for ; Tue, 06 Sep 2011 10:35:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.33.164 with SMTP id s4mr1627961pbi.265.1315330556516; Tue, 06 Sep 2011 10:35:56 -0700 (PDT) Received: by 10.68.66.163 with HTTP; Tue, 6 Sep 2011 10:35:56 -0700 (PDT) In-Reply-To: References: <4E5FF775.9010207@isode.com> Date: Tue, 6 Sep 2011 12:35:56 -0500 Message-ID: From: Nico Williams To: =?UTF-8?B?SmVoYW4gUGFnw6hz?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC-5802 (SCRAM): authorization identity passed through stringprep X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 17:34:11 -0000 On Mon, Sep 5, 2011 at 8:46 AM, Jehan Pag=C3=A8s wrote: > 2011/9/2 Alexey Melnikov : >> Per RFC 4422 syntax and normalization of authorization identities is >> controlled by protocol spec, not SASL mechanism specs. So if, for exampl= e, >> XMPP spec says that all authorization identities need to be SASLpreped, = then >> this would apply to SCRAM as well. > > Indeed it seems that you are right. It is said in various places in > RFC-4422 that this is protocol specific. > > In any case, I find a little annoying that authentication and > authorization identity are processed differently. Actually I now see > the have the opposite bother: I don't see why we pass the authcid > through stringprep. Why didn't we stop to ',' and '=3D' escaping there > too and let the protocol (XMPP for instance) enforce this on its side? > I don't understand the double standard here. Authcid and authzid belong to different and unrelated entities (mechanism and application, respectively). Therefore they will necessarily have different treatments (unless all mechs and all apps were to have the same treatment). SCRAM is a mechanism, therefore SCRAM gets to specify how authcids for it are handled. SCRAM is not an application, therefore it doesn't get to say anything about authzid -- authzid is opaque to SCRAM. > Keeping the XMPP example, the server will also process authcid through > stringprep (but Nodeprep profile now, so the authcid would be > stringprep-ed both to Nodeprep and SASLprep) and work is going on > passing away from stringprep in RFC-6122. > I think then we should have released this stringprep processing on > authcid. Is there a reason we make this processing? Yes: we have to do something to make it possible to handle Unicode normalization. We could have specified that the server does matching however it likes provided that authcid is effectively normalization insensitive, and that certain characters are mapped in such and such ways, and so on. But here's the thing: that can only work for authcid, nor for passwords. We could also have said that passwords must be ASCII, but we'd not have had consensus for that, not then anyways. > I think you are right. Now, as you read, I would rather propose the > opposite change by releasing away this stringprep processing from > authcid (rather than adding it on authzid) for consistency. > Doesn't it make sense? No, not to me. See above. Nico -- From stpeter@stpeter.im Tue Sep 6 11:57:32 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAD121F8CE7 for ; Tue, 6 Sep 2011 11:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikZ1tUK7KIth for ; Tue, 6 Sep 2011 11:57:32 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id ECEB721F8C1D for ; Tue, 6 Sep 2011 11:57:31 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 13337418BB; Tue, 6 Sep 2011 13:02:12 -0600 (MDT) Message-ID: <4E666D85.7000500@stpeter.im> Date: Tue, 06 Sep 2011 12:59:17 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Nico Williams References: <4E5FF775.9010207@isode.com> In-Reply-To: X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC-5802 (SCRAM): authorization identity passed through stringprep X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 18:57:33 -0000 On 9/6/11 11:35 AM, Nico Williams wrote: > We could also have said that passwords must be ASCII, but > we'd not have had consensus for that, not then anyways. That reminds me, I need to post to the saag@ietf.org list about the handling of non-ASCII characters in passwords (in relation to the PRECIS WG, see draft-ietf-precis-framework). Peter -- Peter Saint-Andre https://stpeter.im/ From jehan.marmottard@gmail.com Tue Sep 6 12:28:59 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CA521F8E08 for ; Tue, 6 Sep 2011 12:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOXBmboxzcNe for ; Tue, 6 Sep 2011 12:28:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBDD121F8E07 for ; Tue, 6 Sep 2011 12:28:58 -0700 (PDT) Received: by wwf5 with SMTP id 5so4332487wwf.13 for ; Tue, 06 Sep 2011 12:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=0Umeh+izC2tn07J+UrqXnQFxBFUMOKzYSCR8LtfjJjA=; b=x6aZcaGO10ThxXZ1l9Iw3DHRoffBc78a16MF9JtijhlcxvaPHRDBD6YYs1lx23/SCT TXp0BiYZYQtKxrWa7qOwR0vb5od56p1O5Xb7D1FdA5LEX+ujMAgr0P80zbHdyseLF4Ns PYdI34sUvA8lZVX8bBPatm7NECWdmziJIowH0= Received: by 10.216.207.230 with SMTP id n80mr372822weo.2.1315337445190; Tue, 06 Sep 2011 12:30:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.23.66 with HTTP; Tue, 6 Sep 2011 12:30:25 -0700 (PDT) In-Reply-To: References: <4E5FF775.9010207@isode.com> From: =?UTF-8?B?SmVoYW4gUGFnw6hz?= Date: Wed, 7 Sep 2011 04:30:25 +0900 Message-ID: To: Nico Williams Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC-5802 (SCRAM): authorization identity passed through stringprep X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 19:29:00 -0000 Hi, 2011/9/7 Nico Williams : > On Mon, Sep 5, 2011 at 8:46 AM, Jehan Pag=C3=A8s wrote: >> 2011/9/2 Alexey Melnikov : >>> Per RFC 4422 syntax and normalization of authorization identities is >>> controlled by protocol spec, not SASL mechanism specs. So if, for examp= le, >>> XMPP spec says that all authorization identities need to be SASLpreped,= then >>> this would apply to SCRAM as well. >> >> Indeed it seems that you are right. It is said in various places in >> RFC-4422 that this is protocol specific. >> >> In any case, I find a little annoying that authentication and >> authorization identity are processed differently. Actually I now see >> the have the opposite bother: I don't see why we pass the authcid >> through stringprep. Why didn't we stop to ',' and '=3D' escaping there >> too and let the protocol (XMPP for instance) enforce this on its side? >> I don't understand the double standard here. > > Authcid and authzid belong to different and unrelated entities > (mechanism and application, respectively). =C2=A0Therefore they will > necessarily have different treatments (unless all mechs and all apps > were to have the same treatment). =C2=A0SCRAM is a mechanism, therefore > SCRAM gets to specify how authcids for it are handled. =C2=A0SCRAM is not > an application, therefore it doesn't get to say anything about authzid > -- authzid is opaque to SCRAM. > >> Keeping the XMPP example, the server will also process authcid through >> stringprep (but Nodeprep profile now, so the authcid would be >> stringprep-ed both to Nodeprep and SASLprep) and work is going on >> passing away from stringprep in RFC-6122. >> I think then we should have released this stringprep processing on >> authcid. Is there a reason we make this processing? > > Yes: we have to do something to make it possible to handle Unicode > normalization. > > We could have specified that the server does matching however it likes > provided that authcid is effectively normalization insensitive, and > that certain characters are mapped in such and such ways, and so on. > But here's the thing: that can only work for authcid, nor for > passwords. =C2=A0We could also have said that passwords must be ASCII, bu= t > we'd not have had consensus for that, not then anyways. I agree. That's why I only propose it for authcid and not for the normalization made on the password which should probably stay. That's more authcid (usually the "login" part of a protocol, visually provided to users), whose syntax *in a general point of view* should be defined *only* in the protocol, not in SASL or the mechanisms in my opinion, because every protocol has its own view about what its login should look like (for instance XMPP and emails have similarly looking syntax but in reality are quite different) though they may all use SASL for authentication. Also you did not answer about the part where I was wondering why this normalization is a SHOULD on authcid, which has the bad consequence of maybe authenticating different authcid depending on the implementation you enter them. I think that if we want to do this normalization on SASL side (before it reaches the application), at least make it a MUST, not a SHOULD, which basically is some kind of "random". Finally I wont' insist too must on this all anyway. I am in particular interested in XMPP myself, and I have just compared Nodeprep from XMPP and SASLprep. Apparently there can't be too much harm in this specific case at least (whether or not the SASL client did the SASLprep or not). So if nobody agrees with me now, that's not that annoying for now. I'll have a look later again when we go away from stringprep (in the RFC which will replace RFC-6122) but that's probably in a long time for now. Thanks for the answer. Jehan >> I think you are right. Now, as you read, I would rather propose the >> opposite change by releasing away this stringprep processing from >> authcid (rather than adding it on authzid) for consistency. >> Doesn't it make sense? > > No, not to me. =C2=A0See above. > > Nico > -- > From shawn.emery@oracle.com Tue Sep 6 13:46:24 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3352421F8EA1 for ; Tue, 6 Sep 2011 13:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.764 X-Spam-Level: X-Spam-Status: No, score=-4.764 tagged_above=-999 required=5 tests=[AWL=1.834, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 521GVX59fxjJ for ; Tue, 6 Sep 2011 13:46:23 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2BE21F8E9E for ; Tue, 6 Sep 2011 13:46:16 -0700 (PDT) Received: from rtcsinet21.oracle.com (rtcsinet21.oracle.com [66.248.204.29]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p86Km1Ix024093 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 6 Sep 2011 20:48:03 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by rtcsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p86Km0xO020570 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Sep 2011 20:48:01 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p86Kltnr025252 for ; Tue, 6 Sep 2011 15:47:55 -0500 Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Sep 2011 13:47:55 -0700 Message-ID: <4E6686DE.2070502@oracle.com> Date: Tue, 06 Sep 2011 14:47:26 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.18) Gecko/20110729 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary="------------020405010002040406000909" X-Source-IP: rtcsinet21.oracle.com [66.248.204.29] X-CT-RefId: str=0001.0A090203.4E668703.00A7,ss=1,re=0.000,fgs=0 Subject: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 20:46:24 -0000 This is a multi-part message in MIME format. --------------020405010002040406000909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit During the kitten WG session at IETF 81 there were a number of consensus calls made in the room. To the benefit of those that were not there physically or virtually, there are a number consensus calls to be made on the list. Please respond to me individually or on the list depending on the circumstances. The calls end in two weeks - 9/20/11. Please refer to the session notes and slides for back ground information: 1. In regards to replay cache issues do you believe that this should be resolved by any/all of the following: (Please refer to http://www.ietf.org/proceedings/81/slides/kitten-1.pdf) (slides 2 & 3) 1.1.1 Increase replay cache performance? 1.1.2 Do not increase replay cache performance? (slide 4) 1.2.1 Use implicit 3rd leg initial security context exchange? 1.2.2 Do not useimplicit 3rd leg initial security context exchange? (slide 5) 1.3.1 Use explicit 3rd leg initial security context exchange? 1.3.2 Do not use explicit 3rd leg initial security context exchange? (slides 9 & 10) 2. In regards to exporting partially established security contexts: 2.1 Should create a utility function to export partial security contexts? 2.2 Should not create a utility function to export partial security contexts? 3. In regards to issues with GSS-APIu2v1: (Please refer to http://www.ietf.org/proceedings/81/slides/kitten-2.pdf) (slide 2) 3.1 Who believe that memory management is an issue and should be fixed? 3.1 Who do not believe that memory management is an issue and should be fixed? Shawn. -- --------------020405010002040406000909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
During the kitten WG session at IETF 81 there were a number of consensus calls made in the room.  To the benefit of those that were not there physically or virtually, there are a number consensus calls to be made on the list.  Please respond to me individually or on the list depending on the circumstances.  The calls end in two weeks - 9/20/11.  Please refer to the session notes and slides for back ground information:

1. In regards to replay cache issues do you believe that this should be resolved by any/all of the following:

(Please refer to http://www.ietf.org/proceedings/81/slides/kitten-1.pdf)
(slides 2 & 3)
1.1.1 Increase replay cache performance?
1.1.2 Do not increase replay cache performance?

(slide 4)
1.2.1 Use implicit 3rd leg initial security context exchange?
1.2.2 Do not use implicit 3rd leg initial security context exchange?

(slide 5)
1.3.1 Use explicit 3rd leg initial security context exchange?
1.3.2 Do not use explicit 3rd leg initial security context exchange?

(slides 9 & 10)
2. In regards to exporting partially established security contexts:

2.1 Should create a utility function to export partial security contexts?
2.2 Should not create a utility function to export partial security contexts?

3. In regards to issues with GSS-APIu2v1:
(Please refer to http://www.ietf.org/proceedings/81/slides/kitten-2.pdf)
(slide 2)
3.1 Who believe that memory management is an issue and should be fixed?
 3.1 Who do not believe that memory management is an issue and should be fixed?

Shawn.
--
--------------020405010002040406000909-- From jehan.marmottard@gmail.com Tue Sep 6 14:02:12 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A87521F8DC3 for ; Tue, 6 Sep 2011 14:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IGAOLfNeFFwK for ; Tue, 6 Sep 2011 14:02:11 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 925AD21F8D9E for ; Tue, 6 Sep 2011 14:02:11 -0700 (PDT) Received: by wyg8 with SMTP id 8so5657048wyg.31 for ; Tue, 06 Sep 2011 14:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=dYwkHvOvNW2aT39NG/zasuoSsuOGymuWR3RbWKtrLOA=; b=ZIE8gVTdhSLBGguFdpeEvN4YBtxNwaaVDbK2/CBQC/atsnUOqgi5lt/cXzBFUds1Vs vnbXNDfjTlneq8aCpA4vpFJA7WVvTpEX0H98kZF+4dAuB4h0CASgcZRSAwkFpmupmA22 Lf/K8IKLZmTiTJY7tZTydy9g6pETup2igvFP0= Received: by 10.216.207.230 with SMTP id n80mr449073weo.2.1315343038083; Tue, 06 Sep 2011 14:03:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.23.66 with HTTP; Tue, 6 Sep 2011 14:03:38 -0700 (PDT) From: =?UTF-8?B?SmVoYW4gUGFnw6hz?= Date: Wed, 7 Sep 2011 06:03:38 +0900 Message-ID: To: "kitten@ietf.org" Content-Type: text/plain; charset=UTF-8 Subject: [kitten] SCRAM-*-PLUS examples and running servers? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 21:02:12 -0000 Hello, I have 2 clients SASL SCRAM implementations (in Objective Caml, and recently I added the support to the PHP Pear Auth_SASL package). I'd like to add the channel binding support. I think that should be more or less straightforward from reading the RFCs but what I miss are specific examples to compare with and/or a server to test with (ideally both!). The example in section 5 of RFC5802 has no channel binding, nor has the one in section 9.1.2 of RFC6120. Is there any other place with a detailed example (whatever, a RFC, a blog post, or simply an answer to this email! :-). And would you know any Free software server implementation (preferably XMPP because I already have code to test with this, but some other protocols may do the part) which supports channel binding on SCRAM? The only I seem to find is M-Link from Isode, but it is not Free Software so I cannot install it. Alternatively if you have an already installed server with channel binding and you would be willing to provide me a test account (hence letting me do authentication tests on it), that would do it as well, of course! (that's for a good cause, 2 Free Software implementations!) Sorry for asking this on this standards list, but I did not know where I could get these information otherwise, after searching quite a bit. Thanks. Jehan From dave@cridland.net Tue Sep 6 15:13:14 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F55321F8F63 for ; Tue, 6 Sep 2011 15:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.357 X-Spam-Level: X-Spam-Status: No, score=-2.357 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgtOZvKrDNXB for ; Tue, 6 Sep 2011 15:13:14 -0700 (PDT) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id 0E27521F8DAC for ; Tue, 6 Sep 2011 15:13:14 -0700 (PDT) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 00DD31168087; Tue, 6 Sep 2011 23:15:01 +0100 (BST) X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8JOqiomYICJ; Tue, 6 Sep 2011 23:14:58 +0100 (BST) Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 090011168067; Tue, 6 Sep 2011 23:14:58 +0100 (BST) References: In-Reply-To: MIME-Version: 1.0 Message-Id: <12536.1315347298.035913@puncture> Date: Tue, 06 Sep 2011 23:14:58 +0100 From: Dave Cridland To: =?UTF-8?B?SmVoYW4gUGFnw6hz?= , Common Authentication Technologies - Next Generation Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-Transfer-Encoding: 8Bit Subject: Re: [kitten] SCRAM-*-PLUS examples and running servers? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 22:13:14 -0000 On Tue Sep 6 22:03:38 2011, Jehan Pagès wrote: > And would you know any Free software server implementation > (preferably > XMPP because I already have code to test with this, but some other > protocols may do the part) which supports channel binding on SCRAM? > The only I seem to find is M-Link from Isode, but it is not Free > Software so I cannot install it. I can certainly get you a test account, though, I've done so for other SCRAM implementors. Also, Simon Josefsson has an IMAP server stood up before, and Polymer's been tested against that, and M-Link/M-Box, so they're all known to interoperate. Finally, I believe that all the code Isode uses is directly from its use in Cyrus SASL, so in principle a recent Cyrus IMAP should support channel binding, I'd imagine. I think M-Link might still be the only SCRAM-*-PLUS XMPP server, but you might want to check Prosody, too. > Sorry for asking this on this standards list, but I did not know > where > I could get these information otherwise, after searching quite a > bit. No, this is a good place to ask, but you might also want to ask on the XSF's jdev and/or XSF's standards list. Dave. -- Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade From tmarkmann@googlemail.com Tue Sep 6 15:25:50 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA3A221F8F82 for ; Tue, 6 Sep 2011 15:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EwATAcljzWvp for ; Tue, 6 Sep 2011 15:25:50 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6934521F8F80 for ; Tue, 6 Sep 2011 15:25:47 -0700 (PDT) Received: by pzk33 with SMTP id 33so17178954pzk.18 for ; Tue, 06 Sep 2011 15:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=T5Ype2VsLP3k0rLvmwPqaI8UuhIVCCMmI62Dfs4WhEA=; b=OJWse1ex0KwxR1cBINPrIVNKGsplnhpTtKf+Wnghj3+CFAEeBHqL8FVLEEPRdDYfA+ AGMqWvp9eAIukGh4kOy+1mxaSmGJcQOwDGOLF5zQLyPvHdSl9c4WtQhNsyTNK+iGUF3W 61kiSewZavAyToPB3d/US3MNXmR94KjjjuvwA= Received: by 10.68.48.132 with SMTP id l4mr853800pbn.78.1315348055082; Tue, 06 Sep 2011 15:27:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.64.168 with HTTP; Tue, 6 Sep 2011 15:27:15 -0700 (PDT) In-Reply-To: References: <12536.1315347298.035913@puncture> From: Tobias Markmann Date: Wed, 7 Sep 2011 00:27:15 +0200 Message-ID: To: =?UTF-8?B?SmVoYW4gUGFnw6hz?= , Common Authentication Technologies - Next Generation Content-Type: text/plain; charset=UTF-8 Subject: [kitten] SCRAM-*-PLUS examples and running servers? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 22:25:51 -0000 And to the list. Hit "Reply" instead of "Reply to all". ---------- Forwarded message ---------- From: Tobias Markmann Date: Wed, Sep 7, 2011 at 00:24 Subject: Re: [kitten] SCRAM-*-PLUS examples and running servers? To: Dave Cridland On Wed, Sep 7, 2011 at 00:14, Dave Cridland wrote: > I think M-Link might still be the only SCRAM-*-PLUS XMPP server, but you > might want to check Prosody, too. Code exists for SCRAM-*-PLUS for Prosody however it's not publicly released yet since it requires a patched LuaSec (opeenssl binding). However it has been tested against *some* version of Swift. Tobi From nico@cryptonector.com Wed Sep 7 15:37:43 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E8C21F8D54 for ; Wed, 7 Sep 2011 15:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.747 X-Spam-Level: X-Spam-Status: No, score=-2.747 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vAXX6d-ol5oZ for ; Wed, 7 Sep 2011 15:37:42 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id D18C621F8D47 for ; Wed, 7 Sep 2011 15:37:42 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 664802C806E for ; Wed, 7 Sep 2011 15:39:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=XfaA8+ioubYE+lv9Jk96i cb3kqwWw3qc4CIrDcfehuDZZ15wu6CtenYRfkNJ3l+Lr89lSSzFujUJ9rB88DBdk rFq8sEFySmi7fiunVK67qNgGyBkMvNSiii27Q3IAeViNEf/9+FrAHMY5gmpD/I+T hP+DoA+3tujJ/pZDqjwQYE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=c3ImGv2K+Uz2QmfGP6Pb Ekd+oFQ=; b=MEiExgwkLT4qjxmX5Avq+ciV/eln3+AsooQOYRu3TCSBgIRvLeOk +bIlclozdlNZZHj1hNAhkuYoWGSKIN4rWA0XZ0VwcIpEM+tnA/XX8rC3wWMD9QM/ KlSsIRZ4MrUGmTe7Xi3YzBBraGBSL1QwziDReSQxfE7l7bj2LKRyd0U= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 34C9D2C806C for ; Wed, 7 Sep 2011 15:39:33 -0700 (PDT) Received: by vxi29 with SMTP id 29so153737vxi.31 for ; Wed, 07 Sep 2011 15:39:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.36 with SMTP id bl4mr3013947vdb.10.1315435172489; Wed, 07 Sep 2011 15:39:32 -0700 (PDT) Received: by 10.220.27.68 with HTTP; Wed, 7 Sep 2011 15:39:32 -0700 (PDT) In-Reply-To: <4E6686DE.2070502@oracle.com> References: <4E6686DE.2070502@oracle.com> Date: Wed, 7 Sep 2011 17:39:32 -0500 Message-ID: From: Nico Williams To: Shawn Emery Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 22:37:43 -0000 On Tue, Sep 6, 2011 at 3:47 PM, Shawn Emery wrote: > 1. In regards to replay cache issues do you believe that this should be > resolved by any/all of the following: > > (Please refer to http://www.ietf.org/proceedings/81/slides/kitten-1.pdf) > (slides 2 & 3) > 1.1.1 Increase replay cache performance? > 1.1.2 Do not increase replay cache performance? This can be entirely a local implementation issue, therefore the only consensus issue would be whether to go for an FYI describing some fast rcache designs. I would be happy with such an FYI and would contribute text, but could not edit. > (slide 4) > 1.2.1 Use implicit 3rd leg initial security context exchange? > 1.2.2 Do not use implicit 3rd leg initial security context exchange? I believe a req_flag denoting implicit 3rd leg in GSS sec context token exchanges could be generally useful, but I've become very skeptical of implicit 3rd leg for Kerberos -- because the flag would have to be critical in GSS mech contexts and non-critical in raw krb5 contexts I just don't see how to make this work reliably. (If inserting an entry into the rcache but not checking for dups were significantly faster than doing both, then implicit 3rd leg would have some value for Kerberos, but most of the time there will be no such significant performance difference.) Count me as a no to implied 3rd leg then (i.e., "yes" to 1.2.2). > (slide 5) > 1.3.1 Use explicit 3rd leg initial security context exchange? > 1.3.2 Do not use explicit 3rd leg initial security context exchange? I would very much like this, so count me as supporting this (yes to 1.3.1). I would also like to add another consensus call, though this one would fall squarely in KRB-WG's purview: whether to allow probabilistic rcaches only (i.e., ones that have zero false negatives but a non-zero false positive rate). Combined with a "retriable" AP exchange feature for the krb5 GSS mech this would work quite well. (Specifically I have a Scalable Bloom filter in mind as a probabilistic rcache.) > (slides 9 & 10) > 2. In regards to exporting partially established security contexts: > > 2.1 Should create a utility function to export partial security contexts? We should add a utility function to create *encrypted* partially exported security context tokens. Separately we should also agree that GSS_Export_sec_context() should be allowed to export partially-established security contexts (with no guarantee that they can be re-imported). > 3. In regards to issues with GSS-APIu2v1: > > (Please refer to http://www.ietf.org/proceedings/81/slides/kitten-2.pdf) > (slide 2) > 3.1 Who believe that memory management is an issue and should be fixed? > 3.1 Who do not believe that memory management is an issue and should be > fixed? I think it's too soon to tell. We need to hear from Sam as to whether he's found a way to make the mechglue and providers share a single allocator irrespective of other allocators that might be in use in the application on *all* major operating systems. There were other issues, however, that might lead us to wanting either a significant update of GSS-API v2u1 or else into a completely new version of the API. But here too I think it's too soon to establish consensus. Nico -- From ghudson@mit.edu Wed Sep 7 22:05:40 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C1621F8C28 for ; Wed, 7 Sep 2011 22:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.979 X-Spam-Level: X-Spam-Status: No, score=-4.979 tagged_above=-999 required=5 tests=[AWL=-1.380, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz-S0CuhlOXK for ; Wed, 7 Sep 2011 22:05:40 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (DMZ-MAILSEC-SCANNER-8.MIT.EDU [18.7.68.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3695821F8C13 for ; Wed, 7 Sep 2011 22:05:39 -0700 (PDT) X-AuditID: 12074425-b7bf1ae000000a2a-66-4e684d58fa15 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 59.41.02602.85D486E4; Thu, 8 Sep 2011 01:06:32 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id p8857TVW005614; Thu, 8 Sep 2011 01:07:30 -0400 Received: from [192.168.1.4] (pool-173-48-218-114.bstnma.fios.verizon.net [173.48.218.114]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p8857PFF003592 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Sep 2011 01:07:26 -0400 (EDT) From: Greg Hudson To: Nico Williams In-Reply-To: References: <4E6686DE.2070502@oracle.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 08 Sep 2011 01:07:24 -0400 Message-ID: <1315458444.718.32.camel@t410> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUixG6nohvhm+FncGmNiMXRzatYLE5dO8Jm 0ff6ELsDs8fLU+cYPZYs+cnk8fHpLZYA5igum5TUnMyy1CJ9uwSujBWnFrEVzGWv2Dv1DGMD 43vWLkZODgkBE4mOn2/ZIWwxiQv31rN1MXJxCAnsY5Q43bSfDSQhJLCeUeLf03II+y6TxO42 YxBbWEBVon3ZYhYQm01AWeLg2W9gtoiApsT1eUvBepkF/CU27G9iBLE5BQIlLn8+zQwxp1Di +oHTTBA1mhKt238DHcHBwQI0c0c3WDmvgJbE4s23mEHCvAKCEn93CEOcKS0xu+cfVKe8xPa3 c5gnMArOQjJoFkLHLCRVCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFula6OVmluilppRuYgQH s4vqDsYJh5QOMQpwMCrx8DJMTfcTYk0sK67MPcQoycGkJMq72zPDT4gvKT+lMiOxOCO+qDQn tfgQowQHs5IIr+9doHLelMTKqtSifJiUNAeLkjjv6x0OfkIC6YklqdmpqQWpRTBZGQ4OJQle J2DUCgkWpaanVqRl5pQgpJk4OEGG8wANd/YBquEtLkjMLc5Mh8ifYlSUEucVAGkWAElklObB 9cKSzStGcaBXhHmZQKp4gIkKrvsV0GAmoMGH8lNBBpckIqSkGhj7nr1xt57M1FXx5XPvB+6d +xJOhpQotGlfPeFXr9M3/8SMu4pCxe9VXZ4Ghp967iKSNT2w+NsM68VXI46+zT8368MVJZ86 K2OnTSobjQX5Z73+lWz7ZJZ+th6buv7EyXOkz6xe9/KjX1eivhMz26aNGSrfZPWu3Q8UM/M7 6ZY9e9Ej62ABWV8lluKMREMt5qLiRACldiY5EQMAAA== Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 05:05:40 -0000 On Wed, 2011-09-07 at 18:39 -0400, Nico Williams wrote: > I've become very skeptical of implicit 3rd leg for Kerberos I think I agree, for two reasons: 1. It's the acceptor who has to say whether an implicit third leg will be expected (the initiator's promise is not really interesting), but gss_accept_sec_context has no req_flags argument, so there's no easy way for the acceptor to speak. 2. (Rephrasing Nico here:) You want to make sure that authenticators aren't used with other protocols which aren't replay-proof. For instance, ssh gssapi-with-mic is replay-proof, but if the ssh authenticator isn't replay-cached, an attacker could conceivably steal the ssh authenticator and replay it against auth-only rlogin. > > 1.3.1 Use explicit 3rd leg initial security context exchange? At this point I don't know exactly how this would work, and I don't know if it solves the criticality issue. From nico@cryptonector.com Wed Sep 7 22:11:46 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D48821F8AF7 for ; Wed, 7 Sep 2011 22:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.733 X-Spam-Level: X-Spam-Status: No, score=-2.733 tagged_above=-999 required=5 tests=[AWL=-0.756, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoYUR25Tai5T for ; Wed, 7 Sep 2011 22:11:45 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id D7B7321F8AE1 for ; Wed, 7 Sep 2011 22:11:45 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 18A682F4057 for ; Wed, 7 Sep 2011 22:13:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=MZel/mhWTbO1ivMbe1ERI f/zrFXa97P+Hr7VEXupY29BLmRNZfP4Qw8uuhWHwIQTi3MLbmkz+fVNyGmqDerb/ C6UGbhpCqul+L3AHJ/VE48/XfjPeFE1UZjSguFwKq/VYUYQhP5UN2XOm0VIfzHoq a6wGgyEcnGDBKdC2dO5kuk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=2dcFIrN9/7HRoMJUoL3K QFhinQg=; b=u9P5RRPizdVRwyzGuzPiqmGSvKJV55B/Vn0p7Kc1slSZGNGS7QFH Oqy18/vlBJ/zNGL72wa5l79hPDYqOHorsb1xMxwlqHLJzAKD/TgCj3aW1vdS5zBh UkWilpUktN1uQUidOFHf8XTcGgN1DJsS0g1HXOFz3Oe2cf+JoxsyQlM= Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id F33DE2F401C for ; Wed, 7 Sep 2011 22:13:36 -0700 (PDT) Received: by pzk33 with SMTP id 33so2302145pzk.18 for ; Wed, 07 Sep 2011 22:13:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.32.227 with SMTP id m3mr434626pbi.332.1315458816672; Wed, 07 Sep 2011 22:13:36 -0700 (PDT) Received: by 10.68.66.163 with HTTP; Wed, 7 Sep 2011 22:13:36 -0700 (PDT) In-Reply-To: <1315458444.718.32.camel@t410> References: <4E6686DE.2070502@oracle.com> <1315458444.718.32.camel@t410> Date: Thu, 8 Sep 2011 00:13:36 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 05:11:46 -0000 On Thu, Sep 8, 2011 at 12:07 AM, Greg Hudson wrote: > On Wed, 2011-09-07 at 18:39 -0400, Nico Williams wrote: >> I've become very skeptical of implicit 3rd leg for Kerberos >> > 1.3.1 Use explicit 3rd leg initial security context exchange? > > At this point I don't know exactly how this would work, and I don't know > if it solves the criticality issue. You can make the explicit 3rd leg flag critical in all cases. Well, right, authz-data in Kerberos are supposed to be critical, but that's not how it's widely implemented, so if you have old libraries... yeah. We're stuck. The good news is that clusters can probably be made to use implicit 3rd leg (with no negotiation needed) in all clusterable application protocols, so that perhaps for clusters there's nothing special to be done, and for non-clusters we can just rely on fast rcache techniques. Nico -- From prvs=12320f2700=jaltman@secure-endpoints.com Wed Sep 7 23:37:31 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B59121F8C56 for ; Wed, 7 Sep 2011 23:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dS0rV-MQkqi for ; Wed, 7 Sep 2011 23:37:30 -0700 (PDT) Received: from www.secure-endpoints.com (peju.ad.secure-endpoints.com [208.125.0.227]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE9A21F8781 for ; Wed, 7 Sep 2011 23:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1315463960; x=1316068760; q=dns/txt; h=DomainKey-Signature:Received:Message-ID:Date:From: Organization:User-Agent:MIME-Version:To:Subject:References: In-Reply-To:OpenPGP:Content-Type:Reply-To; bh=qDqFcOnxeIiHywLysu btJVjnas4iyd1KIgwDHpaH2es=; b=P5q9a+g2LIi4FDL8pGsGa0g73G93delz04 wIUrLNROz0dNzXNPNGQub+PB3/KVVUBt1KXUbJkl8VEKIaKd5t/OUhEP88Hhnitl wEw9oN6iiixiVzXQz/9ZcvdBQXTCXivXS2mBVwMTWv0xhuPuoh2I/Gb30l12Ih2t h45f44Bmc= DomainKey-Signature: a=rsa-sha1; s=MDaemon; d=secure-endpoints.com; c=simple; q=dns; h=message-id:from; b=GQm4R7rn/Kk4HIQR6M998dpK94bxg3DM9/GrKxv/eUsvtavI/ABkS4gVHWri GSzS5Z3n30JV8KuVeOG+S4LgrUFv5RXPLzFbSSDBgO6KR3HBnPaBU24qf etByoF/GjOkcVDYAIT5RmMpFR+l7NWoyImFj4kXGfOvhGXMejE9Uig=; X-MDAV-Processed: www.secure-endpoints.com, Thu, 08 Sep 2011 02:39:20 -0400 Received: from [172.16.16.54] by secure-endpoints.com (Cipher TLSv1:-SHA:128) (MDaemon PRO v12.0.4) with ESMTP id md50000164461.msg for ; Thu, 08 Sep 2011 02:39:20 -0400 X-Spam-Processed: www.secure-endpoints.com, Thu, 08 Sep 2011 02:39:20 -0400 (not processed: message from trusted or authenticated source) X-Authenticated-Sender: jaltman@secure-endpoints.com X-HashCash: 1:22:110908:md50000164461::CgV+LnElx3UgCIg6:00009yEw X-MDRemoteIP: 208.125.0.246 X-Return-Path: prvs=12320f2700=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <4E686314.9090102@secure-endpoints.com> Date: Thu, 08 Sep 2011 02:39:16 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.22) Gecko/20110902 Lightning/1.0b3pre Thunderbird/3.1.14 MIME-Version: 1.0 To: kitten@ietf.org References: <4E6686DE.2070502@oracle.com> In-Reply-To: <4E6686DE.2070502@oracle.com> X-Enigmail-Version: 1.1.1 OpenPGP: url=http://pgp.mit.edu Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2DEAE5C95111FA3551838721" Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: jaltman@secure-endpoints.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 06:37:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2DEAE5C95111FA3551838721 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 9/6/2011 4:47 PM, Shawn Emery wrote: > 1. In regards to replay cache issues do you believe that this should be= > resolved by any/all of the following: >=20 > (Please refer to http://www.ietf.org/proceedings/81/slides/kitten-1.pdf= ) > (slides 2 & 3) > 1.1.1 Increase replay cache performance? > 1.1.2 Do not increase replay cache performance? I believe that replay caches need to be avoided. > (slide 4) > 1.2.1 Use implicit 3rd leg initial security context exchange? > 1.2.2 Do not useimplicit 3rd leg initial security context exchange? Do not use implicit 3rd leg. > (slide 5) > 1.3.1 Use explicit 3rd leg initial security context exchange? > 1.3.2 Do not use explicit 3rd leg initial security context exchange? Use explicit 3rd leg > (slides 9 & 10) > 2. In regards to exporting partially established security contexts: >=20 > 2.1 Should create a utility function to export partial security context= s? > 2.2 Should not create a utility function to export partial security > contexts? I am not opposed but do not have a strong opinion in favor either. > 3. In regards to issues with GSS-APIu2v1: >=20 > (Please refer to http://www.ietf.org/proceedings/81/slides/kitten-2.pdf= ) > (slide 2) > 3.1 Who believe that memory management is an issue and should be fixed?= > 3.1 Who do not believe that memory management is an issue and should be= > fixed? I believe that memory management is an issue and should be fixed. When memory is allocated by a module it should be freed by that same module. It is not going to be possible for an allocator in one module to be dictated by another module. Jeffrey Altman --------------enig2DEAE5C95111FA3551838721 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) iQEcBAEBAgAGBQJOaGMWAAoJENxm1CNJffh4VRYH/j/oCtddgPdkaxquEPd2gxMk dDUWFsNs6jqcAsbtVkYjfdwBMPHIIGeXKRoZtMhRQiJoQ2FEZnuFOCrbaHk5eyzQ v1aTESBcanbQFwuyTuAW+w34aLIgxLUDpBsY4s3sQnP1W8fGq9D8dNVVbZJggLUS 16n1sXWLtgpvbDaGcZ/WaxAwQuVOH4A5DEDcHUTLTsF4hkUIxdLBxlCH1PJ5PkqZ kDkvIbxDsvRmVdO+hloaeU6B64lQpyQV33fyZ4y0Ufc9ibEVdRJDe0O35w9SC8Wi gkvVEi9ITneNuCD3GluPktq0Ch+Sqvk50FmJm7G1vV8WacgS4i7jjn9fcUHGOFM= =z4S4 -----END PGP SIGNATURE----- --------------enig2DEAE5C95111FA3551838721-- From Thomas.Maslen@quest.com Thu Sep 8 13:11:58 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B675C21F8ADE for ; Thu, 8 Sep 2011 13:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLF3EYtp0hP8 for ; Thu, 8 Sep 2011 13:11:58 -0700 (PDT) Received: from alvetxw01.quest.com (alvetxw01.quest.com [12.106.87.93]) by ietfa.amsl.com (Postfix) with ESMTP id 336E221F8AB0 for ; Thu, 8 Sep 2011 13:11:57 -0700 (PDT) Received: from ALVHTXW03.prod.quest.corp (10.1.135.19) by alvetxw01.quest.com (10.1.100.93) with Microsoft SMTP Server (TLS) id 14.1.255.0; Thu, 8 Sep 2011 13:08:12 -0700 Received: from ALVMBXW01.prod.quest.corp ([fe80::48dd:e065:86b3:9cee]) by ALVHTXW03.prod.quest.corp ([::1]) with mapi id 14.01.0255.000; Thu, 8 Sep 2011 13:13:50 -0700 From: Thomas Maslen To: "kitten@ietf.org" Thread-Topic: Feature creep in GSS mechanisms? [was Re: Consensus calls] Thread-Index: AQHMbmPSSWK9qevKSkm+o9qxbrzEjQ== Date: Thu, 8 Sep 2011 20:13:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [kitten] Feature creep in GSS mechanisms? [was Re: Consensus calls] X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 20:11:58 -0000 This is probably half-baked, but:=0A= =0A= =0A= I agree that obviating replay caches would be a fine thing and I think the = explicit third leg is a fine idea (even though it won't help for the GSS us= es that I mostly deal with, e.g. HTTP Negotiate authentication).=0A= =0A= However, I am suspicious of trying to shoehorn more and more goodies into t= he existing GSS KRB5 mech (1.2.840.113554.1.2.2).=0A= =0A= I agree with the approach that draft-swift-win2k-krb-user2user took: it wa= s doing something substantially new / different, so it used a new mechanism= (1.2.840.113554.1.2.2.3) rather than adding to the existing one.=0A= =0A= So, rather than trying to fit explicit-third-leg etc etc into the venerable= and rather crufty existing GSS KRB5 mech, is it time to define a new mecha= nism?=0A= =0A= I understand that naive application of the "use a new mechanism" approach c= ould lead to a combinatorial explosion of mechanism OIDs and that would be = absurd... so don't do that. Instead, for GSS KRB5, maybe just define one = new mechanism for all the proposed tasty new stuff, including explicit-thir= d-leg. I haven't thought about non-KRB5 mechanisms.=0A= =0A= =0A= That having been said, I'm going to disappear on an E-mail-free vacation fo= r a week.=0A= From nico@cryptonector.com Thu Sep 8 14:37:10 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532D821F8ACE for ; Thu, 8 Sep 2011 14:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.684 X-Spam-Level: X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.707, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FzMGf1skJVH9 for ; Thu, 8 Sep 2011 14:37:09 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3303021F8715 for ; Thu, 8 Sep 2011 14:37:09 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 68109508084 for ; Thu, 8 Sep 2011 14:39:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=VjuZpgroVKIUoPCvIPP2M xoWnczRGh54jO6I6WmV6uBy47KyeXgfBQ/9U2GJ3pdRaYJAGatjZrdLf7NQzUaiV 4lZ+kllo/+DW9pSy6xy0y/emUhTiaer52ajb1m65OKZJ9K1bP+bnGdRBOvbdU5eK l/cL/mdLgPbbJtRc0XGxlE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=D1Aw1h6kDhZU35Jv53Wg WiFB7Z8=; b=k+PkRbyrCNUgh1n48ixX9+xGwjX9nBCGHYbC4IzWnk4q56O6OR+p JF8XSpite8F/kHYKWIDtjX87b13jBnMr6KpflDgvSzVTx+tGwhWLiEHv17kQ8XnQ tWpYYQdz2fbCIce83peB67WqS7lcNnFRLdBbJb2tnqqBf6gaRo7J8ek= Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 37A3D50805F for ; Thu, 8 Sep 2011 14:39:02 -0700 (PDT) Received: by yie12 with SMTP id 12so333784yie.31 for ; Thu, 08 Sep 2011 14:39:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.6.33 with SMTP id x1mr1771584pbx.268.1315517941083; Thu, 08 Sep 2011 14:39:01 -0700 (PDT) Received: by 10.68.66.163 with HTTP; Thu, 8 Sep 2011 14:39:01 -0700 (PDT) In-Reply-To: References: Date: Thu, 8 Sep 2011 16:39:01 -0500 Message-ID: From: Nico Williams To: Thomas Maslen Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Feature creep in GSS mechanisms? [was Re: Consensus calls] X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 21:37:10 -0000 I would rather extend the mech we have than add new mechs. The reason is that mechanism negotiation tends to bleed into UIs, and negotiating from variants of mechanisms where the credentials and technology are substantively the same is not something that users should have to see at all unless there's a downgrade attack that we can't protect against without user intervention. Think of SSL/TLS version radio buttons in various apps that use TLS. If, OTOH, we didn't have this UI bleed issue and all the GSS apps we care about were to transparently handle mechanism negotiation without additional user intervention (via configuration, say), then I'd agree that adding new mechanisms would be preferable to extending existing ones. Nico -- From shawn.emery@oracle.com Mon Sep 19 06:54:28 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D9421F8BEF for ; Mon, 19 Sep 2011 06:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.785 X-Spam-Level: X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[AWL=1.813, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gX++qpXYl354 for ; Mon, 19 Sep 2011 06:54:27 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id C5C5221F8BE8 for ; Mon, 19 Sep 2011 06:54:27 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p8JDulph024407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 19 Sep 2011 13:56:49 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p8JDulbL026193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Sep 2011 13:56:47 GMT Received: from abhmt105.oracle.com (abhmt105.oracle.com [141.146.116.57]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p8JDufux012626 for ; Mon, 19 Sep 2011 08:56:41 -0500 Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 19 Sep 2011 06:56:41 -0700 Message-ID: <4E7749FB.8030409@oracle.com> Date: Mon, 19 Sep 2011 07:56:11 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <4E73C3E5.2080703@oracle.com> In-Reply-To: <4E73C3E5.2080703@oracle.com> X-Forwarded-Message-Id: <4E73C3E5.2080703@oracle.com> Content-Type: multipart/alternative; boundary="------------040203000000050309080407" X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090205.4E774A22.007B:SCFMA922111,ss=1,re=-3.482,fgs=0 Subject: [kitten] IETF 82 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 13:54:28 -0000 This is a multi-part message in MIME format. --------------040203000000050309080407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please let us know by Friday (9/23/11) if there are any topics you would like to discuss for the Taipei conference. Shawn. kitten co-chair -- --------------040203000000050309080407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Please let us know by Friday (9/23/11) if there are any topics you would like to discuss for the Taipei conference.

Shawn.
kitten co-chair
--
--------------040203000000050309080407-- From hartmans@mit.edu Fri Sep 23 13:32:56 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B9521F8BB3 for ; Fri, 23 Sep 2011 13:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+YGbl3-b-+Q for ; Fri, 23 Sep 2011 13:32:56 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBAB21F8BAE for ; Fri, 23 Sep 2011 13:32:56 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 77E73204BA; Fri, 23 Sep 2011 16:37:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5B9444234; Fri, 23 Sep 2011 16:35:08 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <4E6686DE.2070502@oracle.com> Date: Fri, 23 Sep 2011 16:35:08 -0400 In-Reply-To: (Nico Williams's message of "Wed, 7 Sep 2011 17:39:32 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 20:32:56 -0000 Nico, to the extent that some of these issues affect the Kerberos mechanism, would it make sense to discuss in a krb-wg session at IETF 82? This assumes that kitten permits the generic feature. From hartmans@mit.edu Fri Sep 23 13:41:45 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52ACE21F84D2 for ; Fri, 23 Sep 2011 13:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.268 X-Spam-Level: X-Spam-Status: No, score=-103.268 tagged_above=-999 required=5 tests=[AWL=-1.303, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9oCyhHKYK79 for ; Fri, 23 Sep 2011 13:41:44 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id AB48021F851F for ; Fri, 23 Sep 2011 13:41:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E0D8220184; Fri, 23 Sep 2011 16:46:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A5CC04234; Fri, 23 Sep 2011 16:43:56 -0400 (EDT) From: Sam Hartman To: Jehan =?iso-8859-1?Q?Pag=E8s?= References: <4E5FF775.9010207@isode.com> Date: Fri, 23 Sep 2011 16:43:56 -0400 In-Reply-To: ("Jehan =?iso-8859-1?Q?Pag=E8s=22's?= message of "Wed, 7 Sep 2011 04:30:25 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC-5802 (SCRAM): authorization identity passed through stringprep X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 20:41:45 -0000 >>>>> "Jehan" == Jehan Pagès writes: >>>>> "Jehan" == Jehan Pagès writes: Jehan> I agree. That's why I only propose it for authcid and not for Jehan> the normalization made on the password which should probably Jehan> stay. That's more authcid (usually the "login" part of a Jehan> protocol, visually provided to users), whose syntax *in a Jehan> general point of view* should be defined *only* in the Jehan> protocol, not in SASL or the mechanisms in my opinion, Jehan> because every protocol has its own view about what its login Jehan> should look like (for instance XMPP and emails have similarly Jehan> looking syntax but in reality are quite different) though Jehan> they may all use SASL for authentication. Both the SASL framework and I disagree with you. One of the major points of SASL in a platform context is that you can reuse authentication across protocols. Your AUTHCID is *not* your email address or your jid. IIt's a scram-specific identifier not a protocol specific identifier. Your authorization ID is a JID or email address. The application (or hopefully the platform) needs to map your authcid into the protocol specific authzid. This mapping may be simple or very complex. To understand why this is important consider a platform like Active Directory where authentication identifiers are global and independent of any application. So, the form of AUTHCIDs very is much is not a matter for a protocol. I do not support a change in this handling. From nico@cryptonector.com Fri Sep 23 14:11:48 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0CB21F877F for ; Fri, 23 Sep 2011 14:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=-0.668, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ue+4LSoXvKuZ for ; Fri, 23 Sep 2011 14:11:48 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 281AB21F862F for ; Fri, 23 Sep 2011 14:11:48 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 5720C202022 for ; Fri, 23 Sep 2011 14:14:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=Q+o+UtgSrNt89vke+gkwN 6iVqG7MljHnLvRdrMcsSyET1FO97Nlj3dZTWBod4qqM9FRcUSioob1uC/A2C5FT0 Md66xBJH2yml8v5i59/SVPSrSgVzJm+/FiifDYCQQ22RUo5Lq41M6joDjA10iPzJ WxFEdqgHo6nZN7kMOlqzAo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=KeiYen6rM2E8eTh/tyGS E/1JdOA=; b=qdQ0Wzc+uu5+2AyLKgBuFYYURRuAR7ShIB5ExIdeItf+VhgCrgHC bf/aoc+cB0W8suiRaDaIaJ1C/Rzzw39PRauteteZCG+bdRO6dwgCBCB1eQzKX6t8 WRpX9hFj09npi03OzL+RYY1v2VUBhp4MOR1dB4eOC/nfps/vbnZfSvQ= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id EF665202017 for ; Fri, 23 Sep 2011 14:14:22 -0700 (PDT) Received: by ywa6 with SMTP id 6so3673450ywa.31 for ; Fri, 23 Sep 2011 14:14:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.14.202 with SMTP id r10mr12234468pbc.24.1316812462040; Fri, 23 Sep 2011 14:14:22 -0700 (PDT) Received: by 10.68.71.138 with HTTP; Fri, 23 Sep 2011 14:14:21 -0700 (PDT) In-Reply-To: References: <4E6686DE.2070502@oracle.com> Date: Fri, 23 Sep 2011 16:14:21 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 21:11:48 -0000 On Fri, Sep 23, 2011 at 3:35 PM, Sam Hartman wrote: > Nico, to the extent that some of these issues affect the Kerberos > mechanism, would it make sense to discuss in a krb-wg session at IETF > 82? > This assumes that kitten permits the generic feature. Yes. BTW, I'm also coming around to the idea that implicit 3rd leg works because where it doesn't, you have bigger problems anyways. Nico -- From jehan.marmottard@gmail.com Sat Sep 24 23:29:14 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA88C21F8B2F for ; Sat, 24 Sep 2011 23:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oBAmKW94FlM9 for ; Sat, 24 Sep 2011 23:29:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF2FD21F8B2D for ; Sat, 24 Sep 2011 23:29:13 -0700 (PDT) Received: by wyh21 with SMTP id 21so3130699wyh.31 for ; Sat, 24 Sep 2011 23:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=lxzBIyOwkkXonfe+SQylEbWA4pi7LizRa6Cz84FTWe4=; b=Kpldc3AFRjzkXhbA52x7srAOKu0ZYH4Xj74SK6DPhyIG7oMGqrA4e1QvTLaFZ5FPh+ EBhgnOAYIApFruxvkPpaNaW7OKPBHMP4P3a3D1Go4EZ+4t0FNT7AnkArp+gPxAJaRfSp W4S3vTvrBcGzAvQpydhYm3yH5m4X4QercWXvo= Received: by 10.216.173.198 with SMTP id v48mr2775253wel.30.1316932312147; Sat, 24 Sep 2011 23:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.11.10 with HTTP; Sat, 24 Sep 2011 23:31:32 -0700 (PDT) In-Reply-To: References: <4E5FF775.9010207@isode.com> From: =?UTF-8?B?SmVoYW4gUGFnw6hz?= Date: Sun, 25 Sep 2011 15:31:32 +0900 Message-ID: To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC-5802 (SCRAM): authorization identity passed through stringprep X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Sep 2011 06:29:14 -0000 Hi, On Sat, Sep 24, 2011 at 5:43 AM, Sam Hartman wrote: >>>>>> "Jehan" =3D=3D Jehan Pag=C4=8Ds writes: >>>>>> "Jehan" =3D=3D Jehan Pag=C4=8Ds writes: > > =C2=A0 =C2=A0Jehan> I agree. That's why I only propose it for authcid and= not for > =C2=A0 =C2=A0Jehan> the normalization made on the password which should p= robably > =C2=A0 =C2=A0Jehan> stay. That's more authcid (usually the "login" part o= f a > =C2=A0 =C2=A0Jehan> protocol, visually provided to users), whose syntax *= in a > =C2=A0 =C2=A0Jehan> general point of view* should be defined *only* in th= e > =C2=A0 =C2=A0Jehan> protocol, not in SASL or the mechanisms in my opinion= , > =C2=A0 =C2=A0Jehan> because every protocol has its own view about what it= s login > =C2=A0 =C2=A0Jehan> should look like (for instance XMPP and emails have s= imilarly > =C2=A0 =C2=A0Jehan> looking syntax but in reality are quite different) th= ough > =C2=A0 =C2=A0Jehan> they may all use SASL for authentication. > > Both the SASL framework and I disagree with you. =C2=A0One of the major > points of SASL in a platform context is that you can reuse > authentication across protocols. =C2=A0Your AUTHCID is *not* your email > address or your jid. IIt's a scram-specific identifier not a protocol > specific identifier. =C2=A0Your authorization ID is a JID or email addres= s. > The application (or hopefully the platform) needs to map your authcid > into the protocol specific authzid. > This mapping may be simple or very complex. > > To understand why this is important consider a platform like Active > Directory where authentication identifiers are global and independent of > any application. =C2=A0So, the form of AUTHCIDs very is much is not a mat= ter > for a protocol. > > I do not support a change in this handling. > Hmmm... Ok. I see your point. Also I don't really know what to think about this anymore and I don't see much problem in this current use case. So that's good for me to let it be (that was already good 2 messages before in fact ;-). Thanks. Jehan From simo@redhat.com Fri Sep 23 13:53:36 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A8121F8B9D for ; Fri, 23 Sep 2011 13:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.527 X-Spam-Level: X-Spam-Status: No, score=-108.527 tagged_above=-999 required=5 tests=[AWL=2.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yNedKFhgTRG for ; Fri, 23 Sep 2011 13:53:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7517621F8B84 for ; Fri, 23 Sep 2011 13:53:35 -0700 (PDT) Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8NKu8px030709 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 23 Sep 2011 16:56:08 -0400 Received: from [10.3.113.19] ([10.3.113.19]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8NKu74a009576; Fri, 23 Sep 2011 16:56:08 -0400 From: Simo Sorce To: Sam Hartman In-Reply-To: References: <4E5FF775.9010207@isode.com> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Fri, 23 Sep 2011 16:56:06 -0400 Message-ID: <1316811366.2684.645.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Mailman-Approved-At: Sun, 25 Sep 2011 22:23:44 -0700 Cc: "kitten@ietf.org" Subject: Re: [kitten] RFC-5802 (SCRAM): authorization identity passed through stringprep X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 20:54:04 -0000 On Fri, 2011-09-23 at 16:43 -0400, Sam Hartman wrote: > >>>>> "Jehan" == Jehan Pagès writes: > >>>>> "Jehan" == Jehan Pagès writes: > > Jehan> I agree. That's why I only propose it for authcid and not for > Jehan> the normalization made on the password which should probably > Jehan> stay. That's more authcid (usually the "login" part of a > Jehan> protocol, visually provided to users), whose syntax *in a > Jehan> general point of view* should be defined *only* in the > Jehan> protocol, not in SASL or the mechanisms in my opinion, > Jehan> because every protocol has its own view about what its login > Jehan> should look like (for instance XMPP and emails have similarly > Jehan> looking syntax but in reality are quite different) though > Jehan> they may all use SASL for authentication. > > Both the SASL framework and I disagree with you. One of the major > points of SASL in a platform context is that you can reuse > authentication across protocols. Your AUTHCID is *not* your email > address or your jid. IIt's a scram-specific identifier not a protocol > specific identifier. Your authorization ID is a JID or email address. > The application (or hopefully the platform) needs to map your authcid > into the protocol specific authzid. > This mapping may be simple or very complex. > > To understand why this is important consider a platform like Active > Directory where authentication identifiers are global and independent of > any application. So, the form of AUTHCIDs very is much is not a matter > for a protocol. > > I do not support a change in this handling. FWIW I strongly support Sam's position. Simo. -- Simo Sorce * Red Hat, Inc * New York From internet-drafts@ietf.org Mon Sep 26 04:49:23 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BE721F8C06; Mon, 26 Sep 2011 04:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leTRtZLZXq98; Mon, 26 Sep 2011 04:49:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB1421F8B8D; Mon, 26 Sep 2011 04:49:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110926114922.16142.40990.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2011 04:49:22 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-openid-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 11:49:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : A SASL & GSS-API Mechanism for OpenID Author(s) : Eliot Lear Hannes Tschofenig Henry Mauldin Simon Josefsson Filename : draft-ietf-kitten-sasl-openid-05.txt Pages : 25 Date : 2011-09-26 OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-05.txt From lear@cisco.com Mon Sep 26 04:50:07 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 970C521F8C1C for ; Mon, 26 Sep 2011 04:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.601 X-Spam-Level: X-Spam-Status: No, score=-110.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQ2IFBjVm+fL for ; Mon, 26 Sep 2011 04:50:07 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id DBAC621F8BEF for ; Mon, 26 Sep 2011 04:50:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=3875; q=dns/txt; s=iport; t=1317037969; x=1318247569; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=0zg378Begp+Fj8+rEy80qp88TNWhLsQD1Vmu4E606qw=; b=XnECSfF4/lNQu7kxngu6U1gNP0fM7eI1Y9FCZ1AyyPx1I10pC0geP7Lz yPbaAQRKU6Z+gvRmslO2AIuUo0z8iP9lIGQZEgeBK6Fo78RPYgN/Wn7VU BTevDGtgYhovWoNQK7MlUBSoib0zxvv6zeiSn+3UBjiE+LVeKsia2NtmC E=; X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKZmgE6Q/khL/2dsb2JhbAA4CYRioyx4gVQBAQQSARBUAREsFgsCAgkDAgECATsKBg0IAQEeo3YBjEORHYNighiBEQSTUpE1 X-IronPort-AV: E=Sophos;i="4.68,443,1312156800"; d="eml'208?scan'208,208";a="117249812" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 26 Sep 2011 11:52:48 +0000 Received: from dhcp-10-61-101-197.cisco.com (dhcp-10-61-101-197.cisco.com [10.61.101.197]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p8QBqm5g004852 for ; Mon, 26 Sep 2011 11:52:48 GMT Message-ID: <4E80674C.5050103@cisco.com> Date: Mon, 26 Sep 2011 13:51:40 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20110926114922.16142.27577.idtracker@ietfa.amsl.com> In-Reply-To: <20110926114922.16142.27577.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.2 X-Forwarded-Message-Id: <20110926114922.16142.27577.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------070705010903060904020001" Subject: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-openid-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2011 11:50:07 -0000 This is a multi-part message in MIME format. --------------070705010903060904020001 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This new draft addresses AD comments. --------------070705010903060904020001 Content-Type: message/rfc822; name="New Version Notification for draft-ietf-kitten-sasl-openid-05_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="New Version Notification for draft-ietf-kitten-sasl-openid-0"; filename*1="5_txt.eml" Received: from xbh-ams-201.cisco.com ([144.254.75.7]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 13:52:07 +0200 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 13:52:07 +0200 Received: from rcdn-iport-5.cisco.com ([173.37.86.76]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 26 Sep 2011 06:52:06 -0500 Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 26 Sep 2011 11:52:06 +0000 Received: from rcdn-inbound-d.cisco.com (rcdn-inbound-d.cisco.com [72.163.7.173]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p8QBq3kb006656; Mon, 26 Sep 2011 11:52:06 GMT Authentication-Results: rcdn-inbound-d.cisco.com; dkim=neutral (message not signed) header.i=none X-from-outside-Cisco: 12.22.58.30 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8BAGpmgE4MFjoemWdsb2JhbAA4CYRilGgBAY5CFAEBAQEBCAsLBxQmgWwBEFQCNQImAklLo3UBjEORGoEsgjaCGIERBIdyi2CRUw X-IronPort-AV: E=Sophos;i="4.68,443,1312156800"; d="scan'208";a="5602141" Received: from mail.ietf.org ([12.22.58.30]) by rcdn-inbound-d.cisco.com with ESMTP; 26 Sep 2011 11:52:06 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754A621F8BF7; Mon, 26 Sep 2011 04:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDrefgonx5lp; Mon, 26 Sep 2011 04:49:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D4C21F8BFB; Mon, 26 Sep 2011 04:49:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: lear@cisco.com Cc: hmauldin@cisco.com, simon@josefsson.org, hannes.tschofenig@gmx.net, lear@cisco.com Subject: New Version Notification for draft-ietf-kitten-sasl-openid-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110926114922.16142.27577.idtracker@ietfa.amsl.com> Date: Mon, 26 Sep 2011 04:49:22 -0700 Return-Path: internet-drafts@ietf.org X-OriginalArrivalTime: 26 Sep 2011 11:52:06.0655 (UTC) FILETIME=[B6FBE8F0:01CC7C42] A new version of I-D, draft-ietf-kitten-sasl-openid-05.txt has been success= fully submitted by Eliot Lear and posted to the IETF repository. Filename: draft-ietf-kitten-sasl-openid Revision: 05 Title: A SASL & GSS-API Mechanism for OpenID Creation date: 2011-09-23 WG ID: kitten Number of pages: 25 Abstract: OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. = = The IETF Secretariat --------------070705010903060904020001-- From internet-drafts@ietf.org Wed Sep 28 05:49:36 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04C721F8D80; Wed, 28 Sep 2011 05:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJwGHLOTR9Wt; Wed, 28 Sep 2011 05:49:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8145F21F8C15; Wed, 28 Sep 2011 05:49:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110928124936.15609.62699.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2011 05:49:36 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-openid-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 12:49:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : A SASL & GSS-API Mechanism for OpenID Author(s) : Eliot Lear Hannes Tschofenig Henry Mauldin Simon Josefsson Filename : draft-ietf-kitten-sasl-openid-06.txt Pages : 25 Date : 2011-09-28 OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-openid-06.txt From lear@cisco.com Wed Sep 28 05:50:45 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE1B21F8D7A for ; Wed, 28 Sep 2011 05:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.601 X-Spam-Level: X-Spam-Status: No, score=-110.601 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCyjpZ5YIVIA for ; Wed, 28 Sep 2011 05:50:44 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0C1A721F8D79 for ; Wed, 28 Sep 2011 05:50:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=lear@cisco.com; l=3932; q=dns/txt; s=iport; t=1317214412; x=1318424012; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=bpcASyN6zHN0M6vc10d2m1f8x/hS0mqZOrv2YPnv40U=; b=EtBnd3aeq6+iBRcY8ecZ1p2wz4I8fHKjW4t7L29D3AcVcNNWNC7i8nJg VRqKD42Dpk/93BmdGxYHvcaCL/bDkeReQxKt+iuzcNfJe6ys3ud/NUhAm U98BN5GXY0yDsnkc9Fp2YKTrsqRJ1z+TG2KvYlD3PmT0bfbu+wcSLVDeG w=; X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACIYg06Q/khM/2dsb2JhbAA5CYRloyF4gVQBAQQSARBUAREsFgsCAgkDAgECATsKBg0IAQEeoT0BjEWRboNighiBEgSTVZE3 X-IronPort-AV: E=Sophos;i="4.68,455,1312156800"; d="eml'208?scan'208,208";a="56568182" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 28 Sep 2011 12:53:31 +0000 Received: from ams3-vpn-dhcp6461.cisco.com (ams3-vpn-dhcp6461.cisco.com [10.61.89.60]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8SCrVGY014664 for ; Wed, 28 Sep 2011 12:53:31 GMT Message-ID: <4E831885.8060808@cisco.com> Date: Wed, 28 Sep 2011 14:52:21 +0200 From: Eliot Lear User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20110928124936.15609.25694.idtracker@ietfa.amsl.com> In-Reply-To: <20110928124936.15609.25694.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.2 X-Forwarded-Message-Id: <20110928124936.15609.25694.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------070807090404070202090809" Subject: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-openid-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Sep 2011 12:50:45 -0000 This is a multi-part message in MIME format. --------------070807090404070202090809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit This draft version contains a single change to address a significant Typo. Thanks, Alexi! --------------070807090404070202090809 Content-Type: message/rfc822; name="New Version Notification for draft-ietf-kitten-sasl-openid-06_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="New Version Notification for draft-ietf-kitten-sasl-openid-0"; filename*1="6_txt.eml" Received: from xbh-ams-201.cisco.com ([144.254.75.7]) by xmb-ams-105.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Sep 2011 14:52:33 +0200 Received: from xbh-rcd-101.cisco.com ([72.163.62.138]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Sep 2011 14:52:33 +0200 Received: from rcdn-iport-1.cisco.com ([173.37.86.72]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 28 Sep 2011 07:52:30 -0500 Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 28 Sep 2011 12:52:30 +0000 Received: from rcdn-inbound-c.cisco.com (rcdn-inbound-c.cisco.com [72.163.7.172]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p8SCqTYQ023287; Wed, 28 Sep 2011 12:52:30 GMT Authentication-Results: rcdn-inbound-c.cisco.com; dkim=neutral (message not signed) header.i=none X-from-outside-Cisco: 12.22.58.30 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8BACIYg04MFjoemWdsb2JhbAA5CYRllGIBAY49FAEBAQEBCAsLBxQmgWwBEFQCNQImAklLoT0BjEWRboEsgjaCGIESBIdyi2ORVQ X-IronPort-AV: E=Sophos;i="4.68,455,1312156800"; d="scan'208";a="5980975" Received: from mail.ietf.org ([12.22.58.30]) by rcdn-inbound-c.cisco.com with ESMTP; 28 Sep 2011 12:52:26 +0000 Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD3C21F8D7C; Wed, 28 Sep 2011 05:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpJWHul7bJtV; Wed, 28 Sep 2011 05:49:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A909C21F8D7E; Wed, 28 Sep 2011 05:49:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: lear@cisco.com Cc: hmauldin@cisco.com, simon@josefsson.org, hannes.tschofenig@gmx.net, lear@cisco.com Subject: New Version Notification for draft-ietf-kitten-sasl-openid-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110928124936.15609.25694.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2011 05:49:36 -0700 Return-Path: internet-drafts@ietf.org X-OriginalArrivalTime: 28 Sep 2011 12:52:30.0894 (UTC) FILETIME=[7C0664E0:01CC7DDD] A new version of I-D, draft-ietf-kitten-sasl-openid-06.txt has been success= fully submitted by Eliot Lear and posted to the IETF repository. Filename: draft-ietf-kitten-sasl-openid Revision: 06 Title: A SASL & GSS-API Mechanism for OpenID Creation date: 2011-09-27 WG ID: kitten Number of pages: 25 Abstract: OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. = = The IETF Secretariat --------------070807090404070202090809--