From wmills@yahoo-inc.com Wed Feb 2 13:17:24 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781433A6DDF for ; Wed, 2 Feb 2011 13:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.537 X-Spam-Level: X-Spam-Status: No, score=-17.537 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, NO_RDNS_DOTCOM_HELO=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtiNty6cKPLm for ; Wed, 2 Feb 2011 13:17:23 -0800 (PST) Received: from mrout2.yahoo.com (mrout2.yahoo.com [216.145.54.172]) by core3.amsl.com (Postfix) with ESMTP id 7B2643A6DDE for ; Wed, 2 Feb 2011 13:17:23 -0800 (PST) Received: from SP2-EX07CAS02.ds.corp.yahoo.com (sp2-ex07cas02.corp.sp2.yahoo.com [98.137.59.38]) by mrout2.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id p12LKIj9001159; Wed, 2 Feb 2011 13:20:18 -0800 (PST) Received: from SP2-EX07VS06.ds.corp.yahoo.com ([98.137.59.24]) by SP2-EX07CAS02.ds.corp.yahoo.com ([98.137.59.38]) with mapi; Wed, 2 Feb 2011 13:20:18 -0800 From: William Mills To: "kitten@ietf.org" Date: Wed, 2 Feb 2011 13:20:18 -0800 Thread-Topic: OAuth mechanism and multiple auth types Thread-Index: AcstUAyAGGo4uxgdTuyWHcH1YEQLeCVqoqRQ Message-ID: References: <4C4DF58A.5090800@isode.com> In-Reply-To: <4C4DF58A.5090800@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tim Showalter , Hannes Tschofenig Subject: [kitten] OAuth mechanism and multiple auth types X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 21:17:24 -0000 OAuth 2.0 has morphed somewhat, and now we have the OAuth 2.0 framework for= authenticating and fetching credentials, and separate specs for different = kinds of credentials and methods for accessing services, i.e. bearer tokens= and MAC tokens. These access methods are stand-alone and independent of t= he way they are obtained (OAuth) from the server perspective. =20 Should each of these access types have a separate mechanism (I think so), o= r should I define a mechanism that accepts multiple types of authentication= /authorization within the OAuth framework? I am expecting to return OAuth = specific endpoint discovery information, so that clients can determine the = correct OAuth endpoint to use to access the service. If we have multiple mechanisms, is a separate draft spec preferred for each= one, or can I go ahead and put them together in the same document? Thanks, -bill From jhutz@cmu.edu Sun Feb 6 18:07:55 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F061F3A6BD9 for ; Sun, 6 Feb 2011 18:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+C+Rir9EtXv for ; Sun, 6 Feb 2011 18:07:54 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id EA08F3A6BD8 for ; Sun, 6 Feb 2011 18:07:53 -0800 (PST) Received: from [128.2.184.181] (JHUTZ-DYN4.PC.CS.CMU.EDU [128.2.184.181]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p1727sUb027653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Feb 2011 21:07:54 -0500 (EST) From: Jeffrey Hutzelman To: Greg Hudson In-Reply-To: <18764_1295585334_p0L4mruB001267_1295585323.2456.527.camel@ray> References: <4CF66B03.7030601@ieca.com> <7FCA3014207EFF8878A7FC5D__1181.61178329519$1291243077$gmane$org@96B2F16665FF96BAE59E9B90> <87bp54gdbi.fsf@latte.josefsson.org> <87lj47e60k.fsf@latte.josefsson.org> <87zkqv7vh1.fsf@latte.josefsson.org> <1295541460.2456.520.camel__32776.0457214483$1295541484$gmane$org@ray> <87oc7b1eq5.fsf@latte.josefsson.org> <18764_1295585334_p0L4mruB001267_1295585323.2456.527.camel@ray> Content-Type: text/plain; charset="UTF-8" Date: Sun, 06 Feb 2011 21:07:52 -0500 Message-ID: <1297044472.2332.21.camel@destiny> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: "kitten@ietf.org" , Simon Josefsson , jhutz@cmu.edu Subject: Re: [kitten] Fwd: [Technical Errata Reported] RFC5802 (2652) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 02:07:55 -0000 On Thu, 2011-01-20 at 23:48 -0500, Greg Hudson wrote: > On Thu, 2011-01-20 at 15:50 -0500, Simon Josefsson wrote: > > > If you can only interoperate by using salts above a certain length, then > > > it seems like that should be part of the syntactic or semantic > > > constraints of the actual standard section describing salts. > > > > I don't think that conclusion follows -- there are many things permitted > > by syntax rules that are forbidden by semantic rules. Pushing all > > semantic rules down into syntax rules is not always a good thing. I > > wouldn't oppose doing so if others feel it is a better way. > > I said "syntactic or semantic constraints"; I wasn't advocating one or > the other. I was just arguing that interoperability constraints should > be documented in the appropriate section of the main RFC, not in > security considerations text. The security considerations text _is_ part of the main RFC. This becomes clear if we stop thinking of security as an add-on. Particularly in this case, where we are talking about a security protocol. RFC2119 requirements language is not limited to cases in which interoperability is the purpose of the requirement. In the present case, Simon proposes a requirement for security reasons, and it is certainly appropriate to use RFC2119 language in such a case. In any case, I think this is starting to get a bit silly. One thing we should _not_ do is encourage implementations to impose arbitrary limits on things in the name of "security", when in fact doing so reduces both security and interoperability. Suppose a client implementation, following Simon's proposed advice, imposes a minimum salt length. For the sake of argument and without loss of generality, let's call the selected length 16. Then that client will fail to interoperate with a server which uses a randomly-generated salt of length 15. In practice, what that means is that a user using a service provided by such a server will sometimes be able to log in and sometimes not, depending on which client he uses, and neither the user nor the server operator has a prayer of figuring out why. Of course, this problem does not arise when using a server which always generates salts of at least 16. However, in that case security has been reduced, because there are strictly fewer possible salts. Of course, this difference may be insignificant if the maximum salt length used is high, but a deployment which uses salts of length 0-16 has considerably more salts available than one which uses salts only of length 16! Also, I would remind everyone that we are talking about an erratum, and so making a change to the protocol is inappropriate. The purpose of an erratum is to correct an error in the _document_, not to redesign the protocol. -- Jeff From info@gerd-stolpmann.de Sun Feb 6 07:49:07 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB83A3A6935 for ; Sun, 6 Feb 2011 07:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLHrhUScsSNU for ; Sun, 6 Feb 2011 07:49:06 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by core3.amsl.com (Postfix) with ESMTP id 862C73A6900 for ; Sun, 6 Feb 2011 07:49:06 -0800 (PST) Received: from office1.lan.sumadev.de (dslb-188-097-000-224.pools.arcor-ip.net [188.97.0.224]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MdqQ5-1PVqco1uxx-00QJ4s; Sun, 06 Feb 2011 16:49:07 +0100 Received: from [192.168.1.111] (546BE640.cm-12-4d.dynamic.ziggo.nl [84.107.230.64]) by office1.lan.sumadev.de (Postfix) with ESMTPA id 0FA7A5F702 for ; Sun, 6 Feb 2011 16:49:07 +0100 (CET) From: Gerd Stolpmann To: kitten@ietf.org Content-Type: text/plain; charset="UTF-8" Date: Sun, 06 Feb 2011 16:49:05 +0100 Message-ID: <1297007345.24058.228.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:YtI5te+Om/PgwDhq1M+vZtOQG/oHTWU57TCiOatNK1b YIV09taxZq50D4KM8+61uF5rvZ3iOAJZSX59mr8T1NHHaWdU0/ TUcs1utDloXi43tGhjaXQ+go2MHocrkDk4+nh3ZuoUw1ywRXQw /C8RhljjIu1d6XSA5tJDS3bVKdXsB/fRS5VG/TQPA+CcmTAv7s 7LTZhtxhZ+l8HNlgex1Og== Subject: [kitten] SCRAM for GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 12:31:26 -0000 Hello, I'm implementing SCRAM (RFC 5802) for GSS-API. In my opinion, the text has a few imprecise statements, and I'd like to clarify on them. In particular, the question is how to interpret section 8, which reads "The messages are the same, but a) the GS2 header on the client's first message and channel binding data is excluded when SCRAM is used as a GSS-API mechanism, and b) the RFC2743 section 3.1 initial context token header is prefixed to the client's first authentication message (context token)." The exclusion (removal?) of the GS2 header probably means that the production for gs2-header should read gs2-header = epsilon which is also compatible with RFC 5801 (GS2). However, the wording is not really precise. Another problem is the removal of the channel binding data (the sentence is quite strange English in this respect). This occurs in client-final-message-without-proof, which is defined as client-final-message-without-proof = channel-binding "," nonce ["," extensions] So, how to remove channel binding data here? It needs to be removed, because it is essentially a copy of the channel binding that might be in gs2-header. I've interpreted this as client-final-message-without-proof = nonce ["," extensions] but this is pure speculation. It is quite important that this is non-ambiguous because the client messages are input for the client proof, and the authentication will fail for each misinterpreted comma. If you are interested, my (still incomplete) code is in https://godirepo.camlcity.org/svn/lib-ocamlnet2/trunk/code/src/netmech-scram/netmech_scram.ml Are there any other implementations of SCRAM for GSS-API? Gerd -- ------------------------------------------------------------ Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------ From lukeh@padl.com Mon Feb 7 14:32:25 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242CF3A6FB4 for ; Mon, 7 Feb 2011 14:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZSz4Ln1If01 for ; Mon, 7 Feb 2011 14:32:24 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by core3.amsl.com (Postfix) with ESMTP id 207723A6C87 for ; Mon, 7 Feb 2011 14:32:23 -0800 (PST) Received: by us.padl.com with ESMTP id p17MWC63005865; Mon, 7 Feb 2011 17:32:17 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: <1297007345.24058.228.camel@thinkpad> Date: Tue, 8 Feb 2011 09:32:18 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <99A631BF-B777-418E-AD5B-4D0C55749207@padl.com> References: <1297007345.24058.228.camel@thinkpad> To: Gerd Stolpmann X-Mailer: Apple Mail (2.1082) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00 X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -0.5 Cc: kitten@ietf.org Subject: Re: [kitten] SCRAM for GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 22:32:25 -0000 > Are there any other implementations of SCRAM for GSS-API? This might help: = http://www.project-moonshot.org/gitweb/?p=3Dcyrus-sasl.git;a=3Dblob;f=3Dpl= ugins/gs2.c -- Luke= From Ron.Williams@us.ibm.com Mon Feb 7 15:04:25 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34D963A6F49 for ; Mon, 7 Feb 2011 15:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnySA+vCVnYh for ; Mon, 7 Feb 2011 15:04:24 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by core3.amsl.com (Postfix) with ESMTP id 591273A6E5B for ; Mon, 7 Feb 2011 15:04:23 -0800 (PST) Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p17IkMqZ031882 for ; Mon, 7 Feb 2011 13:46:24 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 5F0804DE803B for ; Mon, 7 Feb 2011 18:03:41 -0500 (EST) Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p17N4OGd190748 for ; Mon, 7 Feb 2011 18:04:27 -0500 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p17N4Oj6003068 for ; Mon, 7 Feb 2011 16:04:24 -0700 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p17N4O0g003048 for ; Mon, 7 Feb 2011 16:04:24 -0700 Auto-Submitted: auto-generated From: Ron Williams To: kitten@ietf.org Message-ID: Date: Mon, 7 Feb 2011 16:04:23 -0700 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 02/07/2011 16:04:23 MIME-Version: 1.0 Content-type: multipart/alternative; Boundary="0__=08BBF2A3DFED383C8f9e8a93df938690918c08BBF2A3DFED383C" Content-Disposition: inline X-Content-Scanned: Fidelis XPS MAILER Subject: [kitten] AUTO: Ron Williams is out of the office (returning 02/11/2011) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:04:25 -0000 --0__=08BBF2A3DFED383C8f9e8a93df938690918c08BBF2A3DFED383C Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable I am out of the office until 02/11/2011. Note: This is an automated response to your message "Kitten Digest, Vo= l 75, Issue 2" sent on 2/7/11 13:00:14. This is the only notification you will receive while this person is awa= y.= --0__=08BBF2A3DFED383C8f9e8a93df938690918c08BBF2A3DFED383C Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

I am out of the office until 02/11/2011.




Note: This is an automated re= sponse to your message "Kitten Digest,= Vol 75, Issue 2" se= nt on 2/7/11 13:00:14.

This is the only notification= you will receive while this person is away.= --0__=08BBF2A3DFED383C8f9e8a93df938690918c08BBF2A3DFED383C-- From jhutz@cmu.edu Mon Feb 7 15:20:08 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BBA43A6FD0 for ; Mon, 7 Feb 2011 15:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mp84kfRhzXwo for ; Mon, 7 Feb 2011 15:20:07 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 85BE53A6FC9 for ; Mon, 7 Feb 2011 15:20:07 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p17NK6po024984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Feb 2011 18:20:06 -0500 (EST) Date: Mon, 07 Feb 2011 18:20:06 -0500 From: Jeffrey Hutzelman To: Gerd Stolpmann , kitten@ietf.org Message-ID: <15DB15AD8A1365B107FD88B5@minbar.fac.cs.cmu.edu> In-Reply-To: <20443_1297081892_p17CVV4b014766_1297007345.24058.228.camel@thinkpad> References: <20443_1297081892_p17CVV4b014766_1297007345.24058.228.camel@thinkpad> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: jhutz@cmu.edu Subject: Re: [kitten] SCRAM for GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 23:20:08 -0000 --On Sunday, February 06, 2011 04:49:05 PM +0100 Gerd Stolpmann wrote: > Hello, > > I'm implementing SCRAM (RFC 5802) for GSS-API. In my opinion, the text > has a few imprecise statements, and I'd like to clarify on them. > > In particular, the question is how to interpret section 8, which reads > > "The messages are the > same, but a) the GS2 header on the client's first message and channel > binding data is excluded when SCRAM is used as a GSS-API mechanism, > and b) the RFC2743 section 3.1 initial context token header is > prefixed to the client's first authentication message (context > token)." It may help to work backwards. SCRAM-as-SASL is exactly GS2 with SCRAM-as-GSSAPI as the GSS mech. So, all the bits of SCRAM-as-SASL that come from GS2 are not present in SCRAM-as-GSSAPI. The idea is that if I take your GSSAPI mechanism implementation and plug it into a generic GS2 implementation, what I get out is interoperable with a straight SCRAM-as-SASL. > The exclusion (removal?) of the GS2 header probably means that the > production for gs2-header should read > > gs2-header = epsilon > > which is also compatible with RFC 5801 (GS2). There are two places where the ABNF for SCRAM-as-SASL refers to the gs2-header production. Ths production provides bits that actually come from GS2, rather than from the SCRAM mechanism itself. When you are implementing as a GSSAPI mechansim, the entire gs2-header production is omitted. > However, the wording is > not really precise. Another problem is the removal of the channel > binding data (the sentence is quite strange English in this respect). > This occurs in client-final-message-without-proof, which is defined as > > client-final-message-without-proof = > channel-binding "," nonce ["," extensions] > > So, how to remove channel binding data here? It needs to be removed, > because it is essentially a copy of the channel binding that might be in > gs2-header. No, you don't remove the channel binding data. You remove gs2-header from the CB data. Of course, if you got channel bindings from the application (cbind-data), you still include that. -- Jeffrey T. Hutzelman (N3NHS) Carnegie Mellon University - Pittsburgh, PA From hartmans@mit.edu Mon Feb 7 17:53:21 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9457A3A6FE4 for ; Mon, 7 Feb 2011 17:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jhvOVJtstT7a for ; Mon, 7 Feb 2011 17:53:20 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id D8BEC3A6A32 for ; Mon, 7 Feb 2011 17:53:20 -0800 (PST) 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 5286D20239 for ; Mon, 7 Feb 2011 20:51:19 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 193164307; Mon, 7 Feb 2011 20:53:25 -0500 (EST) From: Sam Hartman To: kitten@ietf.org Date: Mon, 07 Feb 2011 20:53:25 -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 Subject: [kitten] Naming Extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 01:53:21 -0000 At IETF 78, I agreed to work on resolving some issues I brought up with draft-ietf-kitten-gssapi-naming-exts. I believe I did that; I believe Leif will be posting a proposed revision within the next day or so. There's one area that Leif was surprised by in my changes. I thought we had agreed to it at IETF 78, but I want to specifically call it out here. I'm proposing to remove the details of how names work for Kerberos, SAML and PKIX mechanisms. My rationale is that when I tried to put together draft-ietf-abfab-gss-eap-naming (naming of SAML attributes for ABFAB), I found it was much more complex than I had previously expected. I believe the existing text will lead to problems for the reasons I gave at IETF 78. For example, I think the Kerberos names will have dependencies on exactly what KDC issued container is in use for authenticated names. See the ongoing discussion of trust in the Kerberos group. I'm not at all sure that draft-ietf-abfab-gss-eap-naming would be generic to use of SAML say inside Kerberos or certificates. I definitely think the PKIX stuff needs some work. So, I propose that we remove all these specific details from the core spec. We should let ABFAB tackle SAML at least so far as it is within ABFAB's scope. I suspect that once we've done that and once the current PAC discussions in krb-wg move forward a bit, we'll know what to say about naming extensions for Kerberos. I think saying it in krb-wg would be fine, although we could say it here if we like. I'd definitely like to get more PKIX involvement before we saying anything about their named objects. How do people feel about this direction? From info@gerd-stolpmann.de Tue Feb 8 06:18:34 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BCC43A715A for ; Tue, 8 Feb 2011 06:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=0.684, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EROtZaLUd2Eg for ; Tue, 8 Feb 2011 06:18:33 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by core3.amsl.com (Postfix) with ESMTP id C42E23A715D for ; Tue, 8 Feb 2011 06:18:32 -0800 (PST) Received: from office1.lan.sumadev.de (dslb-094-219-214-016.pools.arcor-ip.net [94.219.214.16]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0M8opw-1PyxTK1HKO-00CeX1; Tue, 08 Feb 2011 15:18:34 +0100 Received: from [192.168.1.111] (546BE640.cm-12-4d.dynamic.ziggo.nl [84.107.230.64]) by office1.lan.sumadev.de (Postfix) with ESMTPA id CB7015F702; Tue, 8 Feb 2011 15:18:33 +0100 (CET) From: Gerd Stolpmann To: Jeffrey Hutzelman In-Reply-To: <15DB15AD8A1365B107FD88B5@minbar.fac.cs.cmu.edu> References: <20443_1297081892_p17CVV4b014766_1297007345.24058.228.camel@thinkpad> <15DB15AD8A1365B107FD88B5@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Feb 2011 15:18:32 +0100 Message-ID: <1297174712.24058.284.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:f48CWblfqlVPRvPWcPNpBjgRh0xZ27Jfta8BTGx7g+T lZRpZ+9+0PwFvH5G1eSJ+tyOMtUuuwci5YAkrEq/1z9G5ZrM/r oHpV7ILF+XOYBU2HekNEP28d3d8b9QRPVWezC7+l7NKxuitCpS 5d/jAXXODM1solxXVaO/P1xl0d+7BfEz99HZeGrudF059CfbYV zCCBuap2WQ6B2PT+FYJ5w== Cc: kitten@ietf.org Subject: Re: [kitten] SCRAM for GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 14:18:34 -0000 Am Montag, den 07.02.2011, 18:20 -0500 schrieb Jeffrey Hutzelman: > --On Sunday, February 06, 2011 04:49:05 PM +0100 Gerd Stolpmann > wrote: > > > Hello, > > > > I'm implementing SCRAM (RFC 5802) for GSS-API. In my opinion, the text > > has a few imprecise statements, and I'd like to clarify on them. > > > > In particular, the question is how to interpret section 8, which reads > > > > "The messages are the > > same, but a) the GS2 header on the client's first message and channel > > binding data is excluded when SCRAM is used as a GSS-API mechanism, > > and b) the RFC2743 section 3.1 initial context token header is > > prefixed to the client's first authentication message (context > > token)." > > It may help to work backwards. > > SCRAM-as-SASL is exactly GS2 with SCRAM-as-GSSAPI as the GSS mech. > So, all the bits of SCRAM-as-SASL that come from GS2 are not present in > SCRAM-as-GSSAPI. The idea is that if I take your GSSAPI mechanism > implementation and plug it into a generic GS2 implementation, what I get > out is interoperable with a straight SCRAM-as-SASL. Thanks for explaining this - it's not immediately obvious (although I must admit one _can_ have this idea when reading the text). > > The exclusion (removal?) of the GS2 header probably means that the > > production for gs2-header should read > > > > gs2-header = epsilon > > > > which is also compatible with RFC 5801 (GS2). > > There are two places where the ABNF for SCRAM-as-SASL refers to the > gs2-header production. Ths production provides bits that actually come > from GS2, rather than from the SCRAM mechanism itself. When you are > implementing as a GSSAPI mechansim, the entire gs2-header production is > omitted. Ok, so this is the part I got right. > > However, the wording is > > not really precise. Another problem is the removal of the channel > > binding data (the sentence is quite strange English in this respect). > > This occurs in client-final-message-without-proof, which is defined as > > > > client-final-message-without-proof = > > channel-binding "," nonce ["," extensions] > > > > So, how to remove channel binding data here? It needs to be removed, > > because it is essentially a copy of the channel binding that might be in > > gs2-header. > > No, you don't remove the channel binding data. You remove gs2-header from > the CB data. Of course, if you got channel bindings from the application > (cbind-data), you still include that. What still confuses me is the definition of cbind-input (and channel-binding is just a base64 encoding of cbind-input): cbind-input = gs2-header [ cbind-data ] So, given the above symmetry that SCRAM-as-SASL=GS2(SCRAM-as-GSSAPI), I wonder how the GS2 implementation can ensure that the right gs2-header is included at this place. It cannot just add it here, because this would change the signatures (and it is also not described as such in RFC 5801). The conclusion is that even SCRAM-as-GSSAPI has to include the gs2-header at this point of the protocol - which feels a bit strange, and is probably the source of my confusion. Also, gs2-header may include gs2-authzid which also looks weird (at this point of the protocol). I see now that section 5.1 of RFC 5801 restricts the possible values for the chan_bindings parameter of GSS-API. So the format of cbind-input could be read as a consequence of this constraint on chan_bindings. In my project, I do not plan to support channel bindings, so I guess the client should just send "n" as gs2-header, and the server also tolerate "y". Do I come closer to the intended meaning? Gerd -- ------------------------------------------------------------ Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------ From jhutz@cmu.edu Tue Feb 8 09:01:10 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23A9B3A67FD for ; Tue, 8 Feb 2011 09:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbqamhSrOMW9 for ; Tue, 8 Feb 2011 09:01:09 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id EC5C23A680C for ; Tue, 8 Feb 2011 09:01:08 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p18H18ok020732 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 12:01:08 -0500 (EST) Date: Tue, 08 Feb 2011 12:01:08 -0500 From: Jeffrey Hutzelman To: Gerd Stolpmann Message-ID: <02D2A34AAD5EF22092B8FA07@minbar.fac.cs.cmu.edu> In-Reply-To: <1297174712.24058.284.camel@thinkpad> References: <20443_1297081892_p17CVV4b014766_1297007345.24058.228.camel@thinkpad> <15DB15AD8A1365B107FD88B5@minbar.fac.cs.cmu.edu> <1297174712.24058.284.camel@thinkpad> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] SCRAM for GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:01:10 -0000 --On Tuesday, February 08, 2011 03:18:32 PM +0100 Gerd Stolpmann wrote: >> > However, the wording is >> > not really precise. Another problem is the removal of the channel >> > binding data (the sentence is quite strange English in this respect). >> > This occurs in client-final-message-without-proof, which is defined as >> > >> > client-final-message-without-proof = >> > channel-binding "," nonce ["," extensions] >> > >> > So, how to remove channel binding data here? It needs to be removed, >> > because it is essentially a copy of the channel binding that might be >> > in gs2-header. >> >> No, you don't remove the channel binding data. You remove gs2-header >> from the CB data. Of course, if you got channel bindings from the >> application (cbind-data), you still include that. > > What still confuses me is the definition of cbind-input (and > channel-binding is just a base64 encoding of cbind-input): > > cbind-input = gs2-header [ cbind-data ] > > So, given the above symmetry that SCRAM-as-SASL=GS2(SCRAM-as-GSSAPI), I > wonder how the GS2 implementation can ensure that the right gs2-header > is included at this place. It cannot just add it here, because this > would change the signatures (and it is also not described as such in RFC > 5801). The conclusion is that even SCRAM-as-GSSAPI has to include the > gs2-header at this point of the protocol - which feels a bit strange, > and is probably the source of my confusion. Also, gs2-header may include > gs2-authzid which also looks weird (at this point of the protocol). GS2 takes the channel binding data passed to it by the application, prepends the GS2 header, and passes the result as channel binding data to the GSS-API mechanism. > I see now that section 5.1 of RFC 5801 restricts the possible values for > the chan_bindings parameter of GSS-API. No; it restricts the format of the c= attribute in the SCRAM mechanism. The GSS-API channel bindings (and, for that matter, the channel bindings provided by a SASL application) can be ~anything. gs2-header is part of the way GS2 wraps a GSS-API mechanism to form a SASL mechanism. So the format >of cbind-input > could be read as a consequence of this constraint on chan_bindings. In > my project, I do not plan to support channel bindings, so I guess the > client should just send "n" as gs2-header, and the server also tolerate > "y". If you're a GSS-API mechanism, you don't send gs2-header at all. The whole n/p/y thing is an artifact of how SASL does negotiation of channel bindings and is part of GS2. In the GSS-API mechanism, there is no negotiation; the channel bindings data sent by the client (which may be empty) must agree with that sent by the server, or authentication fails. Note that an implementation of SCRAM MUST support channel bindings, though an application doesn't have to use them. If yours is a single-application mechanism, you can decide that cbind-input is always empty and not pass it around as a parameter in your API, but you'd still have to compute the messages properly. -- Jeffrey T. Hutzelman (N3NHS) Carnegie Mellon University - Pittsburgh, PA From hartmans@mit.edu Tue Feb 8 09:05:33 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C34A3A67F3 for ; Tue, 8 Feb 2011 09:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ8JbUjDLSi0 for ; Tue, 8 Feb 2011 09:05:32 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 559543A67E9 for ; Tue, 8 Feb 2011 09:05:30 -0800 (PST) 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 9C82E20239; Tue, 8 Feb 2011 12:03:23 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3A6804307; Tue, 8 Feb 2011 12:05:28 -0500 (EST) From: Sam Hartman To: Gerd Stolpmann References: <20443_1297081892_p17CVV4b014766_1297007345.24058.228.camel@thinkpad> <15DB15AD8A1365B107FD88B5@minbar.fac.cs.cmu.edu> <1297174712.24058.284.camel@thinkpad> Date: Tue, 08 Feb 2011 12:05:28 -0500 In-Reply-To: <1297174712.24058.284.camel@thinkpad> (Gerd Stolpmann's message of "Tue, 08 Feb 2011 15:18:32 +0100") 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, Jeffrey Hutzelman Subject: Re: [kitten] SCRAM for GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:05:33 -0000 I don't think so. I think the fact the the gs2 header is part of the scram channel binding is simply because conceptually that is the channel binding data gs2 passes into the gss-api mechanism. So in a non-sasl use case I would not expect either n or y to appear in the channel binding for the GSS-API mechanism. From info@gerd-stolpmann.de Tue Feb 8 09:31:40 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CC43A67C0 for ; Tue, 8 Feb 2011 09:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1SYdGin8+K98 for ; Tue, 8 Feb 2011 09:31:39 -0800 (PST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id BD4423A672E for ; Tue, 8 Feb 2011 09:31:38 -0800 (PST) Received: from office1.lan.sumadev.de (dslb-094-219-214-016.pools.arcor-ip.net [94.219.214.16]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0LwGC6-1QCiD81m5G-01847G; Tue, 08 Feb 2011 18:31:44 +0100 Received: from [192.168.1.111] (546BE640.cm-12-4d.dynamic.ziggo.nl [84.107.230.64]) by office1.lan.sumadev.de (Postfix) with ESMTPA id 1A6BA5F702; Tue, 8 Feb 2011 18:31:44 +0100 (CET) From: Gerd Stolpmann To: Jeffrey Hutzelman In-Reply-To: <02D2A34AAD5EF22092B8FA07@minbar.fac.cs.cmu.edu> References: <20443_1297081892_p17CVV4b014766_1297007345.24058.228.camel@thinkpad> <15DB15AD8A1365B107FD88B5@minbar.fac.cs.cmu.edu> <1297174712.24058.284.camel@thinkpad> <02D2A34AAD5EF22092B8FA07@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" Date: Tue, 08 Feb 2011 18:31:42 +0100 Message-ID: <1297186302.24058.339.camel@thinkpad> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:aw+a9yKPLINvP+vd/zyZVhtxB3uTUhEXCcyOPziHokz tsnBav5dcVhFF9WTiisBcbreLZiMvZsNuy+pS+5eYGBPvtyhvM aDF1Xk1GbHOdeqmb7k/GnbQCUlsLynGz8vXYk2234sSb6ROtVW t0DRb8OAit0vy0rOYSxUWxXfCepzQPGIQUh2cIQ3T5R/y0dPek V9DF8qOkUv/ZzDhnft81g== Cc: kitten@ietf.org Subject: Re: [kitten] SCRAM for GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:31:40 -0000 Am Dienstag, den 08.02.2011, 12:01 -0500 schrieb Jeffrey Hutzelman: > --On Tuesday, February 08, 2011 03:18:32 PM +0100 Gerd Stolpmann > wrote: > > So, given the above symmetry that SCRAM-as-SASL=GS2(SCRAM-as-GSSAPI), I > > wonder how the GS2 implementation can ensure that the right gs2-header > > is included at this place. It cannot just add it here, because this > > would change the signatures (and it is also not described as such in RFC > > 5801). The conclusion is that even SCRAM-as-GSSAPI has to include the > > gs2-header at this point of the protocol - which feels a bit strange, > > and is probably the source of my confusion. Also, gs2-header may include > > gs2-authzid which also looks weird (at this point of the protocol). > > GS2 takes the channel binding data passed to it by the application, > prepends the GS2 header, and passes the result as channel binding data to > the GSS-API mechanism. > > > I see now that section 5.1 of RFC 5801 restricts the possible values for > > the chan_bindings parameter of GSS-API. > > No; it restricts the format of the c= attribute in the SCRAM mechanism. > The GSS-API channel bindings (and, for that matter, the channel bindings > provided by a SASL application) can be ~anything. gs2-header is part of > the way GS2 wraps a GSS-API mechanism to form a SASL mechanism. Right, this makes sense. I forgot that GS2 is also the caller of GSS_Init_sec_context, so it can easily smuggle the gs2-header in at this point. > If you're a GSS-API mechanism, you don't send gs2-header at all. The whole > n/p/y thing is an artifact of how SASL does negotiation of channel bindings > and is part of GS2. In the GSS-API mechanism, there is no negotiation; the > channel bindings data sent by the client (which may be empty) must agree > with that sent by the server, or authentication fails. Ok . > Note that an implementation of SCRAM MUST support channel bindings, though > an application doesn't have to use them. If yours is a single-application > mechanism, you can decide that cbind-input is always empty and not pass it > around as a parameter in your API, but you'd still have to compute the > messages properly. Right. What does "MUST" mean in this case? As far as channel binding data are just opaque tokens, there is no problem, and SCRAM can just transport them. However, at a certain point channel bindings need to be enforced. I guess you'd say this is the task of the application? Anyway, thanks for your patience. My confusion is gone. Gerd > > -- Jeffrey T. Hutzelman (N3NHS) > Carnegie Mellon University - Pittsburgh, PA > -- ------------------------------------------------------------ Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ------------------------------------------------------------ From jhutz@cmu.edu Tue Feb 8 09:43:31 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726BB3A67F1 for ; Tue, 8 Feb 2011 09:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMoIj482CDSG for ; Tue, 8 Feb 2011 09:43:30 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 9702D3A67E7 for ; Tue, 8 Feb 2011 09:43:30 -0800 (PST) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id p18HhYKM005583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Feb 2011 12:43:34 -0500 (EST) Date: Tue, 08 Feb 2011 12:43:33 -0500 From: Jeffrey Hutzelman To: Gerd Stolpmann Message-ID: <9AA9F771A85ED61D80769F00@minbar.fac.cs.cmu.edu> In-Reply-To: <1297186302.24058.339.camel@thinkpad> References: <20443_1297081892_p17CVV4b014766_1297007345.24058.228.camel@thinkpad> <15DB15AD8A1365B107FD88B5@minbar.fac.cs.cmu.edu> <1297174712.24058.284.camel@thinkpad> <02D2A34AAD5EF22092B8FA07@minbar.fac.cs.cmu.edu> <1297186302.24058.339.camel@thinkpad> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] SCRAM for GSS-API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 17:43:31 -0000 --On Tuesday, February 08, 2011 06:31:42 PM +0100 Gerd Stolpmann wrote: > What does "MUST" mean in this case? As far as channel binding data are > just opaque tokens, there is no problem, and SCRAM can just transport > them. However, at a certain point channel bindings need to be enforced. > I guess you'd say this is the task of the application? Yes. The job of SASL or GSS-API is to insure that the channel bindings data provided by the client agrees with that provided by the server. It is up to each of those, at the application level, to insure that the data they provide actually matches the channel in use. Neither SASL nor GSS-API can do this, because all they do is generate and process tokens which are transported by the application in whatever way it wants. -- Jeff From leifj@mnt.se Wed Feb 9 04:03:52 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94FC73A6977; Wed, 9 Feb 2011 04:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3nc4mjHZd8T; Wed, 9 Feb 2011 04:03:51 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 3A9353A696A; Wed, 9 Feb 2011 04:03:50 -0800 (PST) Received: from [192.36.125.230] (dhcp.pilsnet.sunet.se [192.36.125.230]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p19C3tog003919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Feb 2011 13:03:58 +0100 (CET) Message-ID: <4D5282AB.9010109@mnt.se> Date: Wed, 09 Feb 2011 13:03:55 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: "abfab@ietf.org" , "kitten@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [kitten] Fwd: New Version Notification for draft-ietf-kitten-gssapi-naming-exts-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 12:03:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -------- Original Message -------- Subject: New Version Notification for draft-ietf-kitten-gssapi-naming-exts-09 Date: Wed, 9 Feb 2011 04:02:34 -0800 (PST) From: IETF I-D Submission Tool To: leifj@sunet.se CC: Nicolas.Williams@sun.com A new version of I-D, draft-ietf-kitten-gssapi-naming-exts-09.txt has been successfully submitted by Leif Johansson and posted to the IETF repository. Filename: draft-ietf-kitten-gssapi-naming-exts Revision: 09 Title: GSS-API Naming Extensions Creation_date: 2011-02-06 WG ID: kitten Number_of_pages: 16 Abstract: The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. The IETF Secretariat. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1SgqsACgkQ8Jx8FtbMZncEWwCeOHWJ+064i64sqchql3M26G0Y DsQAoLQyx5efNICp/Ui9WoY5tsFIZi8Y =7zwv -----END PGP SIGNATURE----- From Internet-Drafts@ietf.org Wed Feb 9 04:15:02 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27F0C3A69B3; Wed, 9 Feb 2011 04:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gv9enm2O-T+b; Wed, 9 Feb 2011 04:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF5E3A696A; Wed, 9 Feb 2011 04:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110209121501.2887.62472.idtracker@localhost> Date: Wed, 09 Feb 2011 04:15:01 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 12:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : GSS-API Naming Extensions Author(s) : N. Williams, L. Johansson Filename : draft-ietf-kitten-gssapi-naming-exts-09.txt Pages : 16 Date : 2011-02-09 The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-gssapi-naming-exts-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-09040234.I-D@ietf.org> --NextPart-- From cantor.2@osu.edu Wed Feb 9 08:42:04 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 015D73A65A5 for ; Wed, 9 Feb 2011 08:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PW7sQl-3nBcj for ; Wed, 9 Feb 2011 08:42:03 -0800 (PST) Received: from defang4.it.ohio-state.edu (defang4.it.ohio-state.edu [128.146.216.84]) by core3.amsl.com (Postfix) with ESMTP id 19B203A63CA for ; Wed, 9 Feb 2011 08:42:00 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu ([164.107.81.41]) by defang4.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id p19Gg8E9007876 for ; Wed, 9 Feb 2011 11:42:09 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([2002:a46b:5129::a46b:5129]) with mapi; Wed, 9 Feb 2011 11:39:19 -0500 From: "Cantor, Scott E." To: "kitten@ietf.org" Thread-Topic: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt Thread-Index: AQHLyFKerOrNuFG8TkWYAVa2KXaeHJP5Xa/w Date: Wed, 9 Feb 2011 16:42:08 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071007A1A0@CIO-KRC-D1MBX01.osuad.osu.edu> References: <20110209121501.2887.62472.idtracker@localhost> In-Reply-To: <20110209121501.2887.62472.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.41; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.84 Subject: Re: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 16:42:04 -0000 A couple of comments on this draft: In section 6, I was a little concerned by the paragraph about potential spo= ofing of attribute names, and wondered why, if that's ultimately going to b= e a problem, we wouldn't just dictate a "primary" name component at the fro= nt of each name string that identifies the "context" (to use the term in th= e draft). It already says that names are effectively multi-part, and space-delimited.= Why not just make it formally: "prefix namepart( namepart)*" Either with a registry, or with an OID/URI to signify the "context". Also a nit, at the end of section 9: s/the SAML permanentIdentifier/SAML's "persistent" name identifier format/ -- Scott From hartmans@mit.edu Wed Feb 9 10:32:00 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 704AD3A67BD for ; Wed, 9 Feb 2011 10:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eREJhOX7IAwH for ; Wed, 9 Feb 2011 10:31:59 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id A43A23A67AB for ; Wed, 9 Feb 2011 10:31:59 -0800 (PST) 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 9AFB42022C; Wed, 9 Feb 2011 13:30:00 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0F46F4307; Wed, 9 Feb 2011 13:32:04 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott E." References: <20110209121501.2887.62472.idtracker@localhost> <7EE86E89365CA94F8E7B8251F926071007A1A0@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Wed, 09 Feb 2011 13:32:04 -0500 In-Reply-To: <7EE86E89365CA94F8E7B8251F926071007A1A0@CIO-KRC-D1MBX01.osuad.osu.edu> (Scott E. Cantor's message of "Wed, 9 Feb 2011 16:42:08 +0000") 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] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 18:32:01 -0000 >>>>> "Cantor," == Cantor, Scott E writes: Cantor,> A couple of comments on this draft: In section 6, I was a Cantor,> little concerned by the paragraph about potential spoofing Cantor,> of attribute names, and wondered why, if that's ultimately Cantor,> going to be a problem, we wouldn't just dictate a "primary" Cantor,> name component at the front of each name string that Cantor,> identifies the "context" (to use the term in the draft). I think there are a number of cases where you want one component names: * local attributes typically should be singletons * I'd expect things like the name of the SAML assertion from AAA for ABFAB to be a singleton. There's no reason to make it multi-component as its entire value is dictated by the spec. * I'd expect that names designed for GSS-API that are URNs might well not need multiple components. That was my reasoning at least. From cantor.2@osu.edu Wed Feb 9 11:14:47 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62CC3A69D3 for ; Wed, 9 Feb 2011 11:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qAT6tBTqkFq for ; Wed, 9 Feb 2011 11:14:47 -0800 (PST) Received: from defang3.it.ohio-state.edu (defang3.it.ohio-state.edu [128.146.216.83]) by core3.amsl.com (Postfix) with ESMTP id 207653A6810 for ; Wed, 9 Feb 2011 11:14:44 -0800 (PST) Received: from CIO-KRC-HT01.osuad.osu.edu ([164.107.81.38]) by defang3.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p19JEqhw025849; Wed, 9 Feb 2011 14:14:53 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([2002:a46b:5126::a46b:5126]) with mapi; Wed, 9 Feb 2011 14:12:03 -0500 From: "Cantor, Scott E." To: Sam Hartman Thread-Topic: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt Thread-Index: AQHLyFKerOrNuFG8TkWYAVa2KXaeHJP5Xa/wgAB0yQD//7eGIA== Date: Wed, 9 Feb 2011 19:14:52 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071007AEB7@CIO-KRC-D1MBX01.osuad.osu.edu> References: <20110209121501.2887.62472.idtracker@localhost> <7EE86E89365CA94F8E7B8251F926071007A1A0@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.38; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.83 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:14:48 -0000 > I think there are a number of cases where you want one component names: Sure. I should have clarified, I can imagine allowing for that (though stri= ctly speaking its just an optimization), but I thought it seemed odd to not= just propose a comprehensive solution that addressed all the cases. I real= ly wasn't sure, for example, what SAML attributes would be expected to call= themselves. Maybe that just has to be discussed yet. I think its ok to leave the specifics for SAML, PKIX, etc to other places, = but I think there needs to be a clear framework to plugin to. -- Scott From hartmans@mit.edu Wed Feb 9 11:33:48 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31C2F3A6866 for ; Wed, 9 Feb 2011 11:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STcMUJsQgLHR for ; Wed, 9 Feb 2011 11:33:47 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 775E63A69E2 for ; Wed, 9 Feb 2011 11:33:47 -0800 (PST) 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 E0F6B20222; Wed, 9 Feb 2011 14:31:46 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 319C94307; Wed, 9 Feb 2011 14:33:50 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott E." References: <20110209121501.2887.62472.idtracker@localhost> <7EE86E89365CA94F8E7B8251F926071007A1A0@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AEB7@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Wed, 09 Feb 2011 14:33:50 -0500 In-Reply-To: <7EE86E89365CA94F8E7B8251F926071007AEB7@CIO-KRC-D1MBX01.osuad.osu.edu> (Scott E. Cantor's message of "Wed, 9 Feb 2011 19:14:52 +0000") 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" , Sam Hartman Subject: Re: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:33:48 -0000 >>>>> "Cantor," == Cantor, Scott E writes: >> I think there are a number of cases where you want one component >> names: Cantor,> Sure. I should have clarified, I can imagine allowing for Cantor,> that (though strictly speaking its just an optimization), Cantor,> but I thought it seemed odd to not just propose a Cantor,> comprehensive solution that addressed all the cases. I think saying that a document creating name attributes needs to make sure the prefix is unique is sufficient. I thought tthat's what I did. I Cantor,> really wasn't sure, for example, what SAML attributes would Cantor,> be expected to call themselves. Maybe that just has to be Cantor,> discussed yet. Right. That's not defined by this draft any more, but will be in an update to draft-ietf-abfab-gss-eap-naming. If you think there's enough there that we want something between that document and the core naming exts document, let's discuss what would go there. Cantor,> I think its ok to leave the specifics for SAML, PKIX, etc Cantor,> to other places, but I think there needs to be a clear Cantor,> framework to plugin to. Agreed. Perhaps I'm missing some layer that's still needed. From cantor.2@osu.edu Wed Feb 9 11:50:48 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B99C3A69E2 for ; Wed, 9 Feb 2011 11:50:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2Og1EMJAvLB for ; Wed, 9 Feb 2011 11:50:47 -0800 (PST) Received: from defang12.it.ohio-state.edu (defang12.it.ohio-state.edu [128.146.216.21]) by core3.amsl.com (Postfix) with ESMTP id B05453A69BC for ; Wed, 9 Feb 2011 11:50:47 -0800 (PST) Received: from CIO-KRC-HT01.osuad.osu.edu ([164.107.81.38]) by defang12.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p19JouWU012703; Wed, 9 Feb 2011 14:50:56 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([2002:a46b:5126::a46b:5126]) with mapi; Wed, 9 Feb 2011 14:48:06 -0500 From: "Cantor, Scott E." To: Sam Hartman Thread-Topic: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt Thread-Index: AQHLyFKerOrNuFG8TkWYAVa2KXaeHJP5Xa/wgAB0yQD//7eGIIAAWbwA//+v9oA= Date: Wed, 9 Feb 2011 19:50:56 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071007AF19@CIO-KRC-D1MBX01.osuad.osu.edu> References: <20110209121501.2887.62472.idtracker@localhost> <7EE86E89365CA94F8E7B8251F926071007A1A0@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AEB7@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.38; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.21 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 19:50:48 -0000 > I think saying that a document creating name attributes needs to make > sure the prefix is unique is sufficient. I thought tthat's what I did. I didn't exactly read it as being that explicit, so maybe I'm just arguing = over the wording. I'll look at it again. =20 > Right. That's not defined by this draft any more, but will be in an > update to draft-ietf-abfab-gss-eap-naming. If you think there's enough > there that we want something between that document and the core naming > exts document, let's discuss what would go there. I guess as long as we think its ok for other use cases involving SAML and G= SS to reference an EAP-related RFC , that's fine. For example, my SAML mech= anism (and Klaas') would want to support this kind of thing, and we certain= ly want one convention for exposing SAML attributes here. Or we can factor that bit out, obviously. -- Scott From hartmans@mit.edu Wed Feb 9 12:27:32 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBDDC3A67C3 for ; Wed, 9 Feb 2011 12:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgDOHRSBt2jj for ; Wed, 9 Feb 2011 12:27:32 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 3DE3E3A67AA for ; Wed, 9 Feb 2011 12:27:32 -0800 (PST) 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 A41AE2022C; Wed, 9 Feb 2011 15:25:33 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1E74F4307; Wed, 9 Feb 2011 15:27:37 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott E." References: <20110209121501.2887.62472.idtracker@localhost> <7EE86E89365CA94F8E7B8251F926071007A1A0@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AEB7@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AF19@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Wed, 09 Feb 2011 15:27:37 -0500 In-Reply-To: <7EE86E89365CA94F8E7B8251F926071007AF19@CIO-KRC-D1MBX01.osuad.osu.edu> (Scott E. Cantor's message of "Wed, 9 Feb 2011 19:50:56 +0000") 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" , Sam Hartman Subject: Re: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 20:27:33 -0000 >>>>> "Cantor," == Cantor, Scott E writes: >> I think saying that a document creating name attributes needs to >> make sure the prefix is unique is sufficient. I thought tthat's >> what I did. Cantor,> I didn't exactly read it as being that explicit, so maybe Cantor,> I'm just arguing over the wording. I'll look at it again. I'm happy to improve the wording. >> Right. That's not defined by this draft any more, but will be in >> an update to draft-ietf-abfab-gss-eap-naming. If you think >> there's enough there that we want something between that document >> and the core naming exts document, let's discuss what would go >> there. Cantor,> I guess as long as we think its ok for other use cases Cantor,> involving SAML and GSS to reference an EAP-related RFC , Cantor,> that's fine. For example, my SAML mechanism (and Klaas') Cantor,> would want to support this kind of thing, and we certainly Cantor,> want one convention for exposing SAML attributes here. Do you think your mechanism would actually want the same prefix as GSS-EAP? Are the semantics actually that similar? I'd assumed you'd want the same basic structure: "prefix saml_name_type saml_name" but a different prefix. From cantor.2@osu.edu Wed Feb 9 12:33:22 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8B03A6811 for ; Wed, 9 Feb 2011 12:33:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1+ojzCGSHUyC for ; Wed, 9 Feb 2011 12:33:21 -0800 (PST) Received: from defang17.it.ohio-state.edu (defang17.it.ohio-state.edu [128.146.216.131]) by core3.amsl.com (Postfix) with ESMTP id 9B9A83A67B7 for ; Wed, 9 Feb 2011 12:33:19 -0800 (PST) Received: from CIO-KRC-HT01.osuad.osu.edu ([164.107.81.38]) by defang17.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p19KXF0U028138; Wed, 9 Feb 2011 15:33:22 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([2002:a46b:5126::a46b:5126]) with mapi; Wed, 9 Feb 2011 15:30:18 -0500 From: "Cantor, Scott E." To: Sam Hartman Thread-Topic: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt Thread-Index: AQHLyFKerOrNuFG8TkWYAVa2KXaeHJP5Xa/wgAB0yQD//7eGIIAAWbwA//+v9oCAAF8RgP//rNFw Date: Wed, 9 Feb 2011 20:33:07 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F926071007AFA6@CIO-KRC-D1MBX01.osuad.osu.edu> References: <20110209121501.2887.62472.idtracker@localhost> <7EE86E89365CA94F8E7B8251F926071007A1A0@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AEB7@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AF19@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.38; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.131 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 20:33:22 -0000 > Cantor,> I didn't exactly read it as being that explicit, so maybe > Cantor,> I'm just arguing over the wording. I'll look at it again. >=20 > I'm happy to improve the wording. It may be that an example will be sufficient (or in lieu of that just havin= g an existence proof elsewhere). > Do you think your mechanism would actually want the same prefix as > GSS-EAP? Are the semantics actually that similar? I'd assumed you'd > want the same basic structure: "prefix saml_name_type saml_name" but a > different prefix. I don't think there's any significant difference, it's a SAML attribute in = an assertion that's obtained in a verifiably secure way from a trusted sour= ce as part of an act of authentication (speaking at least of the basic use = case in abfab). The fact that the delivery is quite different and the verification process = is different doesn't change the semantic. -- Scott From hartmans@mit.edu Wed Feb 9 12:57:55 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CD8F3A6811 for ; Wed, 9 Feb 2011 12:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSgxfntpKfBX for ; Wed, 9 Feb 2011 12:57:54 -0800 (PST) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id C5FB23A67AE for ; Wed, 9 Feb 2011 12:57:54 -0800 (PST) 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 37F562022C; Wed, 9 Feb 2011 15:55:56 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3C3564307; Wed, 9 Feb 2011 15:58:00 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott E." References: <20110209121501.2887.62472.idtracker@localhost> <7EE86E89365CA94F8E7B8251F926071007A1A0@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AEB7@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AF19@CIO-KRC-D1MBX01.osuad.osu.edu> <7EE86E89365CA94F8E7B8251F926071007AFA6@CIO-KRC-D1MBX01.osuad.osu.edu> Date: Wed, 09 Feb 2011 15:58:00 -0500 In-Reply-To: <7EE86E89365CA94F8E7B8251F926071007AFA6@CIO-KRC-D1MBX01.osuad.osu.edu> (Scott E. Cantor's message of "Wed, 9 Feb 2011 20:33:07 +0000") 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" , Sam Hartman Subject: Re: [kitten] I-D Action:draft-ietf-kitten-gssapi-naming-exts-09.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Feb 2011 20:57:55 -0000 >>>>> "Cantor," == Cantor, Scott E writes: >> Do you think your mechanism would actually want the same prefix >> as GSS-EAP? Are the semantics actually that similar? I'd >> assumed you'd want the same basic structure: "prefix >> saml_name_type saml_name" but a different prefix. Cantor,> I don't think there's any significant difference, it's a Cantor,> SAML attribute in an assertion that's obtained in a Cantor,> verifiably secure way from a trusted source as part of an Cantor,> act of authentication (speaking at least of the basic use Cantor,> case in abfab). OK, that's different than how I was thinking about this. I'll ponder while updating gss-eap-naming and may end up recommending renaming that document if I agree with you. From Josh.Howlett@ja.net Fri Feb 25 02:37:27 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE303A685B; Fri, 25 Feb 2011 02:37:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRuTjQr-0XvK; Fri, 25 Feb 2011 02:37:26 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by core3.amsl.com (Postfix) with ESMTP id CF2863A67D4; Fri, 25 Feb 2011 02:37:25 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 99F1E4A6B63_D678698B; Fri, 25 Feb 2011 10:38:16 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 816524A6B5A_D678698F; Fri, 25 Feb 2011 10:38:16 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Fri, 25 Feb 2011 10:38:35 +0000 From: Josh Howlett To: "moonshot-community@jiscmail.ac.uk" Thread-Topic: Moonshot GSS EAP mechanism released and Cyrus GS2 mechanism relicensed Thread-Index: AcvU2BCufwOoXtwUTM2cQcOVzwk4mA== Date: Fri, 25 Feb 2011 10:38:34 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30BAC0A@EXC001> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {37B736D1-4D0F-4F2D-8BEB-A281203F2665} x-cr-hashedpuzzle: v4w= A7nf B4Ir CGKG DZt3 FHWA IraP NGUL OEMW PqP/ SGxo Wjvp ujkl 1PEr 5vEM /DIF; 6; YQBiAGYAYQBiAEAAaQBlAHQAZgAuAG8AcgBnADsAZQBtAHUAQABpAGUAdABmAC4AbwByAGcAOwBrAGkAdAB0AGUAbgBAAGkAZQB0AGYALgBvAHIAZwA7AG0AbwBiAGkAbABpAHQAeQBAAHQAZQByAGUAbgBhAC4AbwByAGcAOwBtAG8AbwBuAHMAaABvAHQALQBjAG8AbQBtAHUAbgBpAHQAeQBAAGoAaQBzAGMAbQBhAGkAbAAuAGEAYwAuAHUAawA7AHQAZgAtAGUAbQBjADIAQAB0AGUAcgBlAG4AYQAuAG8AcgBnAA==; Sosha1_v1; 7; {37B736D1-4D0F-4F2D-8BEB-A281203F2665}; agBvAHMAaAAuAGgAbwB3AGwAZQB0AHQAQABqAGEALgBuAGUAdAA=; Fri, 25 Feb 2011 10:37:56 GMT; TQBvAG8AbgBzAGgAbwB0ACAARwBTAFMAIABFAEEAUAAgAG0AZQBjAGgAYQBuAGkAcwBtACAAcgBlAGwAZQBhAHMAZQBkACAAYQBuAGQAIABDAHkAcgB1AHMAIABHAFMAMgAgAG0AZQBjAGgAYQBuAGkAcwBtACAAcgBlAGwAaQBjAGUAbgBzAGUAZAA= x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett , TF-EMC2 , "abfab@ietf.org" , TF-Mobility + Network Middleware , "emu@ietf.org" , "kitten@ietf.org" Subject: [kitten] Moonshot GSS EAP mechanism released and Cyrus GS2 mechanism relicensed X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 10:37:27 -0000 (Apologies for cross-posting) I am pleased to announce the release of the Moonshot GSS EAP mechanism impl= ementation under the BSD licence, and the relicensing of PADL Software's Cy= rus SASL GS2 implementation to the BSD licence. These implement draft-ietf-= abfab-gss-eap-00 and RFC5801 respectively. These mechanisms enable the use of EAP authentication methods for applicati= ons. SAML and RADIUS attributes may be exposed to applications for authoris= ation purposes through GSS-API Naming Extensions. The mechanism is also abl= e to use EAP keying material exported by the EAP method for message integri= ty and confidentiality between client and server. The source-code can be obtained from the Project Moonshot repository: http://www.project-moonshot.org/gitweb Many thanks to Luke Howard of PADL Software Pty for this excellent work. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From klaas@cisco.com Fri Feb 25 07:25:05 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABACB3A69EA for ; Fri, 25 Feb 2011 07:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.599 X-Spam-Level: X-Spam-Status: No, score=-12.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVdJS2MIptEd for ; Fri, 25 Feb 2011 07:25:04 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id F29153A69DD for ; Fri, 25 Feb 2011 07:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1954; q=dns/txt; s=iport; t=1298647556; x=1299857156; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=HbIJWbseD/MkOkscHtZCdr7DYrqk56HZPexvHI13dRE=; b=Ny+nY/vLvaXucl1picakrxj8it3GLzVmNpg9eb4IuoH0pEP2oC5gc8xa SOj23g6aKve7PNlAinfYnTYCx1msmimGjnFlGPBbykrcF7cBbG5c+Y+cT 5nd9nU3ok17N2AwfqEhLlzbi3wXhpbPwP90uB22kTCYLZ0o3nMyoUVUtW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwFABJZZ02rRN+K/2dsb2JhbACEJZQEjhJ0oUaLBJBmgSeBWIFrdgSMHQ X-IronPort-AV: E=Sophos;i="4.62,225,1297036800"; d="scan'208";a="410820997" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 25 Feb 2011 15:25:56 +0000 Received: from macmini.wierenga.net (sjc-vpnasa-327.cisco.com [10.21.105.73]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1PFPtkt014331 for ; Fri, 25 Feb 2011 15:25:56 GMT Message-ID: <4D67CA03.3080803@cisco.com> Date: Fri, 25 Feb 2011 16:25:55 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: kitten@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:25:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have submitted a new version of the sasl-saml draft. Apart from a few typo corrections the main change is that instead of having the SASL-client specify the URL of the IdP it now specifies a domain. The SASL-server is supposed to have a mapping from domain to IdP (either static or via a lookup mechanism). I made this change because Joe Hildebrand rightfully remarked that you can not expect a user to know the full url of his IdP. I welcome any comments and am happy to discuss at IETF 80. Klaas - -------- Original Message -------- Subject: New Version Notification for draft-ietf-kitten-sasl-saml-02 Date: Fri, 25 Feb 2011 07:20:38 -0800 (PST) From: IETF I-D Submission Tool To: klaas@cisco.com CC: lear@cisco.com, simon@josefsson.org A new version of I-D, draft-ietf-kitten-sasl-saml-02.txt has been successfully submitted by Klaas Wierenga and posted to the IETF repository. Filename: draft-ietf-kitten-sasl-saml Revision: 02 Title: A SASL and GSS-API Mechanism for SAML Creation_date: 2011-02-25 WG ID: kitten Number_of_pages: 26 Abstract: Security Assertion Markup Language (SAML) 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 mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. The IETF Secretariat. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1nygMACgkQH2Wy/p4XeFKkdACfbrnjqe17Kflwj8NTbdRggLav GFsAmwb851/psmxNmcmiF0yN44B7G2k+ =3Fvl -----END PGP SIGNATURE----- From Internet-Drafts@ietf.org Fri Feb 25 07:30:03 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C16CF3A68F1; Fri, 25 Feb 2011 07:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RURgtGRZryVe; Fri, 25 Feb 2011 07:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1EC63A69DD; Fri, 25 Feb 2011 07:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110225153001.20717.77815.idtracker@localhost> Date: Fri, 25 Feb 2011 07:30:01 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action:draft-ietf-kitten-sasl-saml-02.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A SASL and GSS-API Mechanism for SAML Author(s) : K. Wierenga, et al. Filename : draft-ietf-kitten-sasl-saml-02.txt Pages : 26 Date : 2011-02-25 Security Assertion Markup Language (SAML) 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 mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML 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-saml-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-kitten-sasl-saml-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-25072038.I-D@ietf.org> --NextPart-- From dave@cridland.net Fri Feb 25 07:32:17 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31C63A69D5 for ; Fri, 25 Feb 2011 07:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4V6VnQx7MTE for ; Fri, 25 Feb 2011 07:32:14 -0800 (PST) Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by core3.amsl.com (Postfix) with ESMTP id 1A17D3A69F2 for ; Fri, 25 Feb 2011 07:32:14 -0800 (PST) Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 32A2C116808D; Fri, 25 Feb 2011 15:33:04 +0000 (GMT) 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 VY1vG4ae3v-c; Fri, 25 Feb 2011 15:33:02 +0000 (GMT) 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 74D101168067; Fri, 25 Feb 2011 15:33:02 +0000 (GMT) References: <4D67CA03.3080803@cisco.com> In-Reply-To: <4D67CA03.3080803@cisco.com> MIME-Version: 1.0 Message-Id: <2745.1298647982.476882@puncture> Date: Fri, 25 Feb 2011 15:33:02 +0000 From: Dave Cridland To: Klaas Wierenga , Common Authentication Technologies - Next Generation Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:32:17 -0000 On Fri Feb 25 15:25:55 2011, Klaas Wierenga wrote: > I have submitted a new version of the sasl-saml draft. Apart from a > few > typo corrections the main change is that instead of having the > SASL-client specify the URL of the IdP it now specifies a domain. > The > SASL-server is supposed to have a mapping from domain to IdP (either > static or via a lookup mechanism). > I made this change because Joe Hildebrand rightfully remarked that > you > can not expect a user to know the full url of his IdP. At the risk of exposing my ignorance in SAML, is there no established method for discovering a IdP URI given a domain? 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 Josh.Howlett@ja.net Fri Feb 25 07:37:15 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A99C03A69D5 for ; Fri, 25 Feb 2011 07:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9n01I6Zl89Ux for ; Fri, 25 Feb 2011 07:37:14 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by core3.amsl.com (Postfix) with ESMTP id BEBA73A69E6 for ; Fri, 25 Feb 2011 07:37:14 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 699961A9C0AF_D67CCDEB; Fri, 25 Feb 2011 15:38:06 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 5E6F51A9BEA5_D67CCDEF; Fri, 25 Feb 2011 15:38:06 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0218.012; Fri, 25 Feb 2011 15:38:29 +0000 From: Josh Howlett To: Dave Cridland , Klaas Wierenga , Common Authentication Technologies - Next Generation Thread-Topic: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-saml-02 Thread-Index: AQHL1QFkC7GQmYq1p0CJffvqOcamVpQSWQOw Date: Fri, 25 Feb 2011 15:38:27 +0000 Message-ID: <55DC663C2F4F9F439F23543E0078E8B30BC79F@EXC001> References: <4D67CA03.3080803@cisco.com> <2745.1298647982.476882@puncture> In-Reply-To: <2745.1298647982.476882@puncture> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Josh Howlett Subject: Re: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 15:37:16 -0000 > At the risk of exposing my ignorance in SAML, is there no established > method for discovering a IdP URI given a domain? Yes, through indirection by reference to a metadata document describing the= IdP. See for example sec 4.2.2.2 of SAML2Meta. I think that might introduc= e more problems than it solves though. Josh. JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From cantor.2@osu.edu Mon Feb 28 10:50:12 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF7FE3A6A1D for ; Mon, 28 Feb 2011 10:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ph3NRJDOvHYw for ; Mon, 28 Feb 2011 10:50:08 -0800 (PST) Received: from defang14.it.ohio-state.edu (defang14.it.ohio-state.edu [128.146.216.128]) by core3.amsl.com (Postfix) with ESMTP id A58C93A6A19 for ; Mon, 28 Feb 2011 10:50:07 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu ([164.107.81.41]) by defang14.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p1SIp3dj013276; Mon, 28 Feb 2011 13:51:04 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([2002:a46b:5129::a46b:5129]) with mapi; Mon, 28 Feb 2011 13:47:36 -0500 From: "Cantor, Scott E." To: Klaas Wierenga , "kitten@ietf.org" Thread-Topic: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-saml-02 Thread-Index: AQHL1P/bjeJM1OYjTkSLCw+qJgfXgJQXRaZg Date: Mon, 28 Feb 2011 18:51:10 +0000 Message-ID: <7EE86E89365CA94F8E7B8251F92607100BE4ED@CIO-KRC-D1MBX01.osuad.osu.edu> References: <4D67CA03.3080803@cisco.com> In-Reply-To: <4D67CA03.3080803@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.41; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.128 Subject: Re: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 18:50:12 -0000 > I have submitted a new version of the sasl-saml draft. Apart from a few > typo corrections the main change is that instead of having the > SASL-client specify the URL of the IdP it now specifies a domain. The > SASL-server is supposed to have a mapping from domain to IdP (either > static or via a lookup mechanism). I don't think that's going to be generally feasible, even if the majority o= f domains happen to have one IdP. Many have >1, and that's just not suffici= ent. If you want to punt on discovery, that's ok I guess, but your mechanis= m should have the *option* to supply the IdP's entityID directly. If you were supplying the URL before (meaning the location), then I strongl= y agree that that's bad. The entityID should always be used in favor of a l= ocation, since neither is generally going to be easy for users to know, and= the entityID is stable, unlike the location. -- Scott From klaas@cisco.com Mon Feb 28 14:01:49 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7F83A6C89 for ; Mon, 28 Feb 2011 14:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyV9EcdXKno5 for ; Mon, 28 Feb 2011 14:01:48 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 3F1E03A6BEC for ; Mon, 28 Feb 2011 14:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1629; q=dns/txt; s=iport; t=1298930569; x=1300140169; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=7i2Bjx2+I3VYXbPKH2oEm4YdIz0e6PR7HSpLHsWeRxI=; b=UgCbuuqskRpMmtN5SvZczx8RpKo/wrzkHdvTvhPHZnjxo44BaYNsRPNh e4MQRYtgpHVnoVuSx3Au485m1Z8igPhXCxntN0GwdQArE+9VnWpZhnUED TSXpCDSNRpl1so4nJsYn61mQ8Fx2UKFhj9g+xx2AojAAHhyoseCrxMydt k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOqpa02rR7H+/2dsb2JhbACmRXSgAZtjhWEEjByMEQ X-IronPort-AV: E=Sophos;i="4.62,242,1297036800"; d="scan'208";a="271970294" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2011 22:02:48 +0000 Received: from macmini.wierenga.net (sjc-vpnasa-413.cisco.com [10.21.105.159]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1SM2mx2015217; Mon, 28 Feb 2011 22:02:48 GMT Message-ID: <4D6C1B87.3080407@cisco.com> Date: Mon, 28 Feb 2011 23:02:47 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Cantor, Scott E." References: <4D67CA03.3080803@cisco.com> <7EE86E89365CA94F8E7B8251F92607100BE4ED@CIO-KRC-D1MBX01.osuad.osu.edu> In-Reply-To: <7EE86E89365CA94F8E7B8251F92607100BE4ED@CIO-KRC-D1MBX01.osuad.osu.edu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 22:01:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/28/11 7:51 PM, Cantor, Scott E. wrote: >> I have submitted a new version of the sasl-saml draft. Apart from a >> few typo corrections the main change is that instead of having the >> SASL-client specify the URL of the IdP it now specifies a domain. >> The SASL-server is supposed to have a mapping from domain to IdP >> (either static or via a lookup mechanism). > > I don't think that's going to be generally feasible, even if the > majority of domains happen to have one IdP. Many have >1, and that's > just not sufficient. If you want to punt on discovery, that's ok I > guess, but your mechanism should have the *option* to supply the > IdP's entityID directly. well, you could go as specific as you want, all the way to fqdn if you wanted to, or alternatively do discovery on the limited set of IdPs for a particular domain... I am not very keen of having an end user specify an entityID... and if I make it optional than I need a way of indicating the two cases... > > If you were supplying the URL before (meaning the location), then I > strongly agree that that's bad. The entityID should always be used in > favor of a location, since neither is generally going to be easy for > users to know, and the entityID is stable, unlike the location. right Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1sG4cACgkQH2Wy/p4XeFIszgCgjziGWsu8B6OXdeVsOQr0Lypx vwcAoLri3/KTIjYSP2b1YlkdLjUkAAY9 =3yXs -----END PGP SIGNATURE----- From cantor.2@osu.edu Mon Feb 28 14:30:25 2011 Return-Path: X-Original-To: kitten@core3.amsl.com Delivered-To: kitten@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CF423A6CBC for ; Mon, 28 Feb 2011 14:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.537 X-Spam-Level: X-Spam-Status: No, score=-3.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vqofpuMow6w for ; Mon, 28 Feb 2011 14:30:24 -0800 (PST) Received: from defang18.it.ohio-state.edu (defang18.it.ohio-state.edu [128.146.216.132]) by core3.amsl.com (Postfix) with ESMTP id 8483B3A6CB9 for ; Mon, 28 Feb 2011 14:30:23 -0800 (PST) Received: from CIO-KRC-HT02.osuad.osu.edu ([164.107.81.41]) by defang18.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p1SMVMRG023266; Mon, 28 Feb 2011 17:31:22 -0500 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([2002:a46b:5129::a46b:5129]) with mapi; Mon, 28 Feb 2011 17:27:54 -0500 From: "Cantor, Scott E." To: Klaas Wierenga Thread-Topic: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-saml-02 Thread-Index: AQHL15a8J9FGW+dZSUS9anzkWRkG9g== Date: Mon, 28 Feb 2011 22:31:20 +0000 Message-ID: In-Reply-To: <4D6C1B87.3080407@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <314a7089-96be-4f71-969b-f6772b633574> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.41; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.132 Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-saml-02 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 22:30:25 -0000 On 2/28/11 5:02 PM, "Klaas Wierenga" wrote: >well, you could go as specific as you want, all the way to fqdn if you >wanted to, or alternatively do discovery on the limited set of IdPs for >a particular domain... I am not very keen of having an end user specify >an entityID... and if I make it optional than I need a way of indicating >the two cases... I think it's a setup issue for the client, not something the user enters (sort of like we do with 802.1x setup in many cases). But let me rephrase this: what is it you expect the client to ask for the user for to get the domain? Because users don't understand domains, and if you ask them for email address, what you'll get is gmail.com. -- Scott