From iesg-secretary@ietf.org Tue Oct 11 09:58:38 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D8621F8E8B; Tue, 11 Oct 2011 09:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHRU7-DddxkB; Tue, 11 Oct 2011 09:58:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32D721F8DBE; Tue, 11 Oct 2011 09:58:37 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20111011165837.28805.94902.idtracker@ietfa.amsl.com> Date: Tue, 11 Oct 2011 09:58:37 -0700 Cc: kitten@ietf.org Subject: [kitten] Last Call: (A SASL & GSS-API Mechanism for OpenID) to Proposed Standard X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2011 16:58:38 -0000 The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'A SASL & GSS-API Mechanism for OpenID' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-10-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract OpenID has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL and GSS-API mechanism for OpenID that allows the integration of existing OpenID Identity Providers with applications using SASL and GSS-API. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-openid/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-openid/ No IPR declarations have been submitted directly on this I-D. From tmarkmann@googlemail.com Thu Oct 13 04:53:30 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A3921F8B2B for ; Thu, 13 Oct 2011 04:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xeh3r6k9EF4O for ; Thu, 13 Oct 2011 04:53:30 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 16EB121F87C9 for ; Thu, 13 Oct 2011 04:53:30 -0700 (PDT) Received: by vws5 with SMTP id 5so1760542vws.31 for ; Thu, 13 Oct 2011 04:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=EIbkfIUy64DbA6ZYfvp+8R/vvmKw1AFB3LrsE/iaMis=; b=ntebKn0YEzbi1aRc4QDV4ooJDnkovrh/FB3y9VMrtll8seGfs0d82FJKCVk33yqFdQ xSjjcNFE9+iAaYlGAHZ/4sSKj7W1KiTSxwQpAmQf8Y4C3Murl+dofaAiQDCUMQ0KHPoS Wt16Fx44SIn39q4ZowckmG8ITk2Eb7WoSTWKw= Received: by 10.68.36.166 with SMTP id r6mr8454562pbj.77.1318506809070; Thu, 13 Oct 2011 04:53:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.56.72 with HTTP; Thu, 13 Oct 2011 04:53:09 -0700 (PDT) From: Tobias Markmann Date: Thu, 13 Oct 2011 13:53:09 +0200 Message-ID: To: Common Authentication Technologies - Next Generation Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Channel Binding to TLS in a Java only environment X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 11:53:30 -0000 Hi, is it possible to access the TLS Finished message sent of the latest/inner-most TLS connection with standard JDK Java APIs? Has somebody done that already? If so, how? Wondering since it was need to have SCRAM-*-PLUS. Cheers, Tobi From mrex@sap.com Thu Oct 13 07:11:48 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B7721F8AA8 for ; Thu, 13 Oct 2011 07:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.032 X-Spam-Level: X-Spam-Status: No, score=-10.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vRLOKwHoFXDN for ; Thu, 13 Oct 2011 07:11:43 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0012D21F8AEA for ; Thu, 13 Oct 2011 07:11:42 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p9DEBbWK004586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 13 Oct 2011 16:11:37 +0200 (MEST) From: Martin Rex Message-Id: <201110131411.p9DEBa9v025756@fs4113.wdf.sap.corp> To: tmarkmann@googlemail.com (Tobias Markmann) Date: Thu, 13 Oct 2011 16:11:36 +0200 (MEST) In-Reply-To: from "Tobias Markmann" at Oct 13, 11 01:53:09 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] Channel Binding to TLS in a Java only environment X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 14:11:48 -0000 Tobias Markmann wrote: > > is it possible to access the TLS Finished message sent of the > latest/inner-most TLS connection with standard JDK Java APIs? Has > somebody done that already? If so, how? Wondering since it was need to > have SCRAM-*-PLUS. Are you actually asking for an official API in JDK to access the tls-unique channel bindings (which consists of the **decrypted** *first* finished message (of the two finished messages at the end of a TLS handshake, one in each direction. (for a full TLS handshake the client sends the first finished message, for an abbreviated TLS handshake, aka TLS session resume, the server sends the first finished message). But with the addition of TLS extension renegotiation_info (rfc5746) that information needs to be persisted anyway, so this would have been the perfect time to add the necessary APIs for it as well (that's how I did it four our implementation). Since it is a new API, it can not adversely affect any of the existing callers, so it was safe to ship as a feature enhancement. But I can't speak about Java/JDK, it is nothing that I use. -Martin From tmarkmann@googlemail.com Thu Oct 13 11:21:51 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E662D21F8A95 for ; Thu, 13 Oct 2011 11:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li3u6-O9cGmo for ; Thu, 13 Oct 2011 11:21:51 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 4933721F8678 for ; Thu, 13 Oct 2011 11:21:51 -0700 (PDT) Received: by pzk37 with SMTP id 37so3454243pzk.9 for ; Thu, 13 Oct 2011 11:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=zX/hGTy2QZCYpkRost190WE+3CwCDeiO7o1813n4iqE=; b=Ri7IS69ISLTaCyRdBnRlLUefCXZr1WzwcRrYnO04cZDSYBe3EsK1x9E+sUPI2MlkkD pP2O2vyOttIAQvsV2fEBZmHaxGkaHaM5+Y+zRGL1MbBIwWlaOndfQFYQR0NjeZh07QPg Jbaq8y9Kwz1WSTwsY5vzMKDasM2s2DnDXN5RY= Received: by 10.68.36.6 with SMTP id m6mr10455668pbj.111.1318530111044; Thu, 13 Oct 2011 11:21:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.56.72 with HTTP; Thu, 13 Oct 2011 11:21:31 -0700 (PDT) In-Reply-To: <201110131411.p9DEBa9v025756@fs4113.wdf.sap.corp> References: <201110131411.p9DEBa9v025756@fs4113.wdf.sap.corp> From: Tobias Markmann Date: Thu, 13 Oct 2011 20:21:31 +0200 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] Channel Binding to TLS in a Java only environment X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 18:21:52 -0000 On Thu, Oct 13, 2011 at 16:11, Martin Rex wrote: > Are you actually asking for an official API in JDK to access > the tls-unique channel bindings (which consists of the **decrypted** > *first* finished message (of the two finished messages at the end > of a TLS handshake, one in each direction. =C2=A0(for a full TLS handshak= e > the client sends the first finished message, for an abbreviated > TLS handshake, aka TLS session resume, the server sends the first > finished message). Yes. Initially I was intending to write a XMPP client for Android and on the first look I did not find an API which provides that data for me. I wondered whether standard JDK, SE or EE, just any JDK had an API which provides the data OpenSSL's SSL_get_finished() function provides. > > But with the addition of TLS extension renegotiation_info (rfc5746) > that information needs to be persisted anyway, so this would have > been the perfect time to add the necessary APIs for it as well > (that's how I did it four our implementation). =C2=A0Since it is a > new API, it can not adversely affect any of the existing callers, > so it was safe to ship as a feature enhancement. > > But I can't speak about Java/JDK, it is nothing that I use. > Right. The Java SE documentation [1] does not seem to list any method related to that. If it had an API that would provide the data of the finished message one could probably find it in SSLSession [2]. So if one wants to have channel binding in a Java application one probably has to run his own TLS stack (either implemented in Java or as a JNI binding to a C lib) which then gives you access to the finished message. [1] http://download.oracle.com/javase/7/docs/api/javax/net/ssl/package-summ= ary.html [2] http://download.oracle.com/javase/7/docs/api/javax/net/ssl/SSLSession.h= tml Tobi From cantor.2@osu.edu Thu Oct 13 11:48:56 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC43B21F8AC3 for ; Thu, 13 Oct 2011 11:48:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaMfNCKVYonA for ; Thu, 13 Oct 2011 11:48:56 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by ietfa.amsl.com (Postfix) with ESMTP id 352FC21F8AC9 for ; Thu, 13 Oct 2011 11:48:56 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9DImYvk004197; Thu, 13 Oct 2011 14:48:54 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%13]) with mapi; Thu, 13 Oct 2011 14:48:42 -0400 From: "Cantor, Scott" To: Tobias Markmann Thread-Topic: [kitten] Channel Binding to TLS in a Java only environment Thread-Index: AQHMiZ6/OR+95vgK9UuJsl6FVZ6XE5V6k9kAgABF1ID//8SJgA== Date: Thu, 13 Oct 2011 18:48:41 +0000 Message-ID: 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-ID: <5ca27aa7-3096-4c8a-b440-408a64bc4634> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.133 Cc: "kitten@ietf.org" Subject: Re: [kitten] Channel Binding to TLS in a Java only environment X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Oct 2011 18:48:56 -0000 On 10/13/11 2:21 PM, "Tobias Markmann" wrote: > >Right. The Java SE documentation [1] does not seem to list any method >related to that. If it had an API that would provide the data of the >finished message one could probably find it in SSLSession [2]. >So if one wants to have channel binding in a Java application one >probably has to run his own TLS stack (either implemented in Java or >as a JNI binding to a C lib) which then gives you access to the >finished message. Or use tls-server-end-point -- Scott From hartmans@mit.edu Tue Oct 18 14:57:30 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96A21F8BAD; Tue, 18 Oct 2011 14:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B74LbyEUKK5C; Tue, 18 Oct 2011 14:57:29 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D011A21F8B9F; Tue, 18 Oct 2011 14:57:29 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7D41C20383; Tue, 18 Oct 2011 17:58:43 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CA8724235; Tue, 18 Oct 2011 17:57:17 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org,kitten@ietf.org Date: Tue, 18 Oct 2011 17:57:17 -0400 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] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 21:57:30 -0000 Hi. As a recollection while working on draft-hartman-gss-eap-naming which became draft-ietf-abfab-gss-eap-naming I introduced the concept of a naming extensions context. The idea is that two attributes are different depending on some broad context of their interpretation. The idea is for example that Kerberos attributes in an enterprise context probably want to be interpreted differently than SAML attributes in a federated context. Since then this concept has been worked into the core naming extensions document. (Perhaps some day we'll publish that) However, now it's time to align things between GSS-EAP and SAML ECP and other things. I think we're talking about basically the same context in both mechanisms for the SAML assertion and attributes. We're talking about what I'll call the basic federated context. Attributes are asserted by a party associated with the authentication of the subject. The attributes are integrity protected and their origin authenticated. That is in EAP, if the RADIUS integrity protection fails we won't get this far. In SAML ECP, if we don't trust metadata for the IDP or if the SAML assertion is not signed, we won't make it this far. It's probably OK in this context to include attributes asserted by a third party that are re-asserted or otherwise vouched for by the IDP. It's probably a different context if you have third-party assertions including attribute query results or somehow multiple authentication statements. The key distinguisher of the context is that the IDP and acceptor are in different trust domains but thet IDP and attributes are in the same trust domains. First, have I got the context right? Second, what URN do we want to use. The current URNurn:ietf:params:gss-eap:saml-aaa-assertion has gss-eap and aaa in it both of which are wrong. Comments welcome. From cantor.2@osu.edu Tue Oct 18 17:01:41 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01DCB21F86AA; Tue, 18 Oct 2011 17:01:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65eCbbVIR4HC; Tue, 18 Oct 2011 17:01:39 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by ietfa.amsl.com (Postfix) with ESMTP id 3300D21F86A5; Tue, 18 Oct 2011 17:01:39 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9J01b1u029444; Tue, 18 Oct 2011 20:01:38 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi; Tue, 18 Oct 2011 20:03:23 -0400 From: "Cantor, Scott" To: Sam Hartman , "abfab@ietf.org" , "kitten@ietf.org" Thread-Topic: [kitten] SAML attributes and assertions for naming extensions Thread-Index: AQHMjeD54+roFKd/qkuapWbszhjT8JWCyMqA Date: Wed, 19 Oct 2011 00:01:39 +0000 Message-ID: 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-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.133 Subject: Re: [kitten] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 00:01:41 -0000 On 10/18/11 5:57 PM, "Sam Hartman" wrote: > >As a recollection while working on draft-hartman-gss-eap-naming which >became draft-ietf-abfab-gss-eap-naming I introduced the concept of a >naming extensions context. The idea is that two attributes are different >depending on some broad context of their interpretation. The idea is for >example that Kerberos attributes in an enterprise context probably want >to be interpreted differently than SAML attributes in a federated >context. And I think the proposal is that the context appear inside the naming extension attribute name as a modifier? >It's probably a different context if you have third-party assertions >including attribute query results or somehow multiple authentication >statements. My current implementation of that doesn't distinguish that case (the attributes end up in the same bucket), but it's an easy fix. https://issues.shibboleth.net/jira/browse/SSPCPP-399 >First, have I got the context right? Much of the time the use of third party sources tends to be for "local" sources associated with the domain of the application, but I agree in principle with the need to distinguish that. I suppose in that sense the cases I've seen would match what you were referring to for Kerberos, the enterprise scenario. >Second, what URN do we want to use. The current >URNurn:ietf:params:gss-eap:saml-aaa-assertion has gss-eap and aaa in it >both of which are wrong. Is it necessary that the value be fixed? If the application-specific names of the attributes themselves aren't fixed, do the contexts have to be? -- Scott From hartmans@painless-security.com Tue Oct 18 17:18:09 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A101021F8AEE; Tue, 18 Oct 2011 17:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Eyt82EOuBuX; Tue, 18 Oct 2011 17:18:09 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 07FC421F8AEC; Tue, 18 Oct 2011 17:18:08 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A87B2202C9; Tue, 18 Oct 2011 20:19:16 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D1F794235; Tue, 18 Oct 2011 20:17:50 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: Date: Tue, 18 Oct 2011 20:17:50 -0400 In-Reply-To: (Scott Cantor's message of "Wed, 19 Oct 2011 00:01:39 +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" , "abfab@ietf.org" , Sam Hartman Subject: Re: [kitten] [abfab] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 00:18:09 -0000 >>>>> "Cantor," == Cantor, Scott writes: Cantor,> On 10/18/11 5:57 PM, "Sam Hartman" wrote: >> >As a recollection while working on draft-hartman-gss-eap-naming which >> became draft-ietf-abfab-gss-eap-naming I introduced the concept >> of a naming extensions context. The idea is that two attributes >> are different depending on some broad context of their >> interpretation. The idea is for example that Kerberos attributes >> in an enterprise context probably want to be interpreted >> differently than SAML attributes in a federated context. Cantor,> And I think the proposal is that the context appear inside Cantor,> the naming extension attribute name as a modifier? Right. >> It's probably a different context if you have third-party >> assertions including attribute query results or somehow multiple >> authentication statements. Cantor,> My current implementation of that doesn't distinguish that Cantor,> case (the attributes end up in the same bucket), but it's Cantor,> an easy fix. Well, note that anything coming out of attribute mapping in your SP is completely separate and is unprefixed; the administrator is assumed to know their own policy. I'm not sure the most intuitive ECP implementation on top of Shibboleth SP would expose this at all. I'd encourage people to do so; see below. >> First, have I got the context right? Cantor,> Much of the time the use of third party sources tends to be Cantor,> for "local" sources associated with the domain of the Cantor,> application, but I agree in principle with the need to Cantor,> distinguish that. I suppose in that sense the cases I've Cantor,> seen would match what you were referring to for Kerberos, Cantor,> the enterprise scenario. right. >> Second, what URN do we want to use. The current >> URNurn:ietf:params:gss-eap:saml-aaa-assertion has gss-eap and aaa >> in it both of which are wrong. Cantor,> Is it necessary that the value be fixed? If the Cantor,> application-specific names of the attributes themselves Cantor,> aren't fixed, do the contexts have to be? So, I think there are two cases here. The first and probably more common is that an administrator uses some mechanism like your attribute mapping mechanism to map attributes. We don't care much about that case in the IETF. The second case is that someone is specifying a protocol--either in the IETF, or some community, where you do want the attributes to be standardized. To refer to an attribute in a protocol you need to know its context and name. I do think there are some realistic cases for this, although not many involve SAML attributes: 1) I want those RADIUS attributes. For example there is a draft for SNMP over ssh and another draft for RADIUS SNMP authorization. It seems entirely reasonable to me to want to implement that draft for gss-eap and in that case to want to access the specific RADIUS attributes that the RADIUS mapping draft says to use. 2) It seems entirely reasonable to want to ask for the raw assertion from your GSS EAP or ECP mechanism to go do something with it with your own SAML library. So, I'd prefer the context be fixed. I think we need it to be fixed for GSS-EAP. If the use cases for ECP are going to be different then we should consider that. However it would be valuable if you could plug one in case of the other. --Sam From cantor.2@osu.edu Tue Oct 18 18:10:48 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EEE21F84CF; Tue, 18 Oct 2011 18:10:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysbCduVjgLcv; Tue, 18 Oct 2011 18:10:47 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id 7613E21F84CE; Tue, 18 Oct 2011 18:10:45 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9J1AeA4009415; Tue, 18 Oct 2011 21:10:43 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi; Tue, 18 Oct 2011 21:10:33 -0400 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [abfab] [kitten] SAML attributes and assertions for naming extensions Thread-Index: AQHMjfSomHCcEQIe+EKdkBGpDpzay5WC296A Date: Wed, 19 Oct 2011 01:10:29 +0000 Message-ID: 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-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Cc: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [kitten] [abfab] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 01:10:48 -0000 On 10/18/11 8:17 PM, "Sam Hartman" wrote: > >Well, note that anything coming out of attribute mapping in your SP is >completely separate and is unprefixed; the administrator is assumed >to know their own policy. That's generally true, but it's still desirable for applications sitting on top to be able to distinguish between a piece of data from one source vs. another. >So, I'd prefer the context be fixed. I think we need it to be fixed for >GSS-EAP. If the use cases for ECP are going to be different then we >should consider that. However it would be valuable if you could plug one >in case of the other. I guess the way I look at it is that as a consumer of the GSS naming extensions, I'd be physically ill shipping code that hardcoded any names, so I see it all as a config time question. But then I'm also accused of designing systems that are too complex. -- Scott From nico@cryptonector.com Tue Oct 18 19:17:32 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DAA91F0C46; Tue, 18 Oct 2011 19:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.885 X-Spam-Level: X-Spam-Status: No, score=-1.885 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-uNACwLDLYo; Tue, 18 Oct 2011 19:17:32 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 14D911F0C42; Tue, 18 Oct 2011 19:17:32 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id B9B8136006A; Tue, 18 Oct 2011 19:17:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=XMqX3N76G3fQgoxaxVP3j hLHtBi965QjI/E2bFPkzhGJy+swaLsdT8E8VmiD2wVWdEo5tYP0NZ3h8cbTsRpDX 1BfkpjGegEdzUyWzAhST7QDWJNIlhv2gLIv3EGms+9ZlEn9tzHWIgO2TT35Yi1R2 FxDo2OuIypgrPLM/KO8ePk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=hyBAdcPr2Hdwx+Bj5vE9 yNzix9I=; b=QDTQx2T+iW+5IZS9pY6fQ977XbdbMGeU20+wml6q3NdGMg0Is/Yd Le7gijfSVAnHo5bAAOHpyoCEgV1KPfHpBQn3R3clgP3TIzR4Cla9dFlb8fWgC5CM l3yv/s/Gy5c5weh/L2TObitiBLGu4RiBHmPeJuquqD1s35WDMhCCWks= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 9865D360065; Tue, 18 Oct 2011 19:17:31 -0700 (PDT) Received: by pzk34 with SMTP id 34so3232627pzk.9 for ; Tue, 18 Oct 2011 19:17:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.129 with SMTP id h1mr4100374pbj.92.1318990651218; Tue, 18 Oct 2011 19:17:31 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Tue, 18 Oct 2011 19:17:31 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Oct 2011 21:17:31 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman , "abfab@ietf.org" , Sam Hartman Subject: Re: [kitten] [abfab] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 02:17:32 -0000 On Tue, Oct 18, 2011 at 8:10 PM, Cantor, Scott wrote: > On 10/18/11 8:17 PM, "Sam Hartman" wrote: >>So, I'd prefer the context be fixed. I think we need it to be fixed for >>GSS-EAP. If the use cases for ECP are going to be different then we >>should consider that. However it would be valuable if you could plug one >>in case of the other. > > I guess the way I look at it is that as a consumer of the GSS naming > extensions, I'd be physically ill shipping code that hardcoded any names, > so I see it all as a config time question. > > But then I'm also accused of designing systems that are too complex. We should want to not hard-code mechanism OIDs, for example, but we have little choice but to hard-code things whose semantics must be embedded in the application. For example: name types. We've added mechanism attributes as a way to avoid hard-coding mechanism OIDs: hard-code the semantics you want rather than the mechanisms you know at that time support those semantics. We could do that with mechanisms, but name-types seem to basic a unit for further decomposition. Ditto, I think, naming attributes, though perhaps not because they are so basic as because there's too much left to run-time interpretation. Fortunately, I think we'll be able to make some types of authorization operations configurable so that naming attributes need not be hard-coded but configurable (e.g., group-membership-like attributes). That said, I don't yet understand what Sam means by "context" here. Nico -- From gabilm@um.es Wed Oct 19 00:39:35 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D101C21F8AEA; Wed, 19 Oct 2011 00:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl7kVyhDhGkM; Wed, 19 Oct 2011 00:39:35 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 239EF21F8AE6; Wed, 19 Oct 2011 00:39:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id A0AB15D480; Wed, 19 Oct 2011 09:39:33 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id k0GqJLNQ2arr; Wed, 19 Oct 2011 09:39:33 +0200 (CEST) Received: from eduroam_um-230-15.inf.um.es (eduroam_um-230-15.inf.um.es [155.54.230.15]) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPA id C6F215D4BC; Wed, 19 Oct 2011 09:39:25 +0200 (CEST) Message-ID: <4E9E7F04.1050103@um.es> Date: Wed, 19 Oct 2011 09:40:52 +0200 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 19 Oct 2011 00:57:40 -0700 Cc: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [kitten] [abfab] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 07:39:36 -0000 Hi El 19/10/11 02:17, Sam Hartman escribió: > > > So, I think there are two cases here. The first and probably more > common is that an administrator uses some mechanism like your attribute > mapping mechanism to map attributes. We don't care much about that case > in the IETF. > > The second case is that someone is specifying a protocol--either in the > IETF, or some community, where you do want the attributes to be > standardized. Both alternatives can be implemented and can work together. The use of standardized attributes is the most desirable scenario but you can find also something like eduroam, where institutions manage attributes like "urn:....:entitlement:student", "urn:...:rol:estudiante", "urn:...:diritto:studente", etc. regards, Gabi > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de Ingenier’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From hartmans@painless-security.com Wed Oct 19 05:34:23 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E421A21F8BDB; Wed, 19 Oct 2011 05:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z0U7tka45DSN; Wed, 19 Oct 2011 05:34:23 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 80C9E21F8BAE; Wed, 19 Oct 2011 05:34:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 510A6203C7; Wed, 19 Oct 2011 08:35:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 094224235; Wed, 19 Oct 2011 08:34:08 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: Date: Wed, 19 Oct 2011 08:34:08 -0400 In-Reply-To: (Scott Cantor's message of "Wed, 19 Oct 2011 01:10:29 +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" , "abfab@ietf.org" , Sam Hartman Subject: Re: [kitten] [abfab] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 12:34:24 -0000 >>>>> "Cantor," == Cantor, Scott writes: Cantor,> On 10/18/11 8:17 PM, "Sam Hartman" wrote: >> >Well, note that anything coming out of attribute mapping in your SP is >> completely separate and is unprefixed; the administrator is >> assumed to know their own policy. Cantor,> That's generally true, but it's still desirable for Cantor,> applications sitting on top to be able to distinguish Cantor,> between a piece of data from one source vs. another. >> So, I'd prefer the context be fixed. I think we need it to be >> fixed for GSS-EAP. If the use cases for ECP are going to be >> different then we should consider that. However it would be >> valuable if you could plug one in case of the other. Cantor,> I guess the way I look at it is that as a consumer of the Cantor,> GSS naming extensions, I'd be physically ill shipping code Cantor,> that hardcoded any names, so I see it all as a config time Cantor,> question. Right and with my IETF hat on I'd be physicall ill shipping a spec that didn't nail that down. If you leave it to configuration you don't get interop. We need to support both models. So, any hints on a URN you'd like? From cantor.2@osu.edu Wed Oct 19 07:44:57 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77AFC21F8C0A; Wed, 19 Oct 2011 07:44:57 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qloMQb9s6Ox7; Wed, 19 Oct 2011 07:44:57 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id D814521F8AB8; Wed, 19 Oct 2011 07:44:56 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9JEhSQk005978; Wed, 19 Oct 2011 10:43:35 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi; Wed, 19 Oct 2011 10:45:13 -0400 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [abfab] [kitten] SAML attributes and assertions for naming extensions Thread-Index: AQHMjfSomHCcEQIe+EKdkBGpDpzay5WC296AgAECEQD//+ENAA== Date: Wed, 19 Oct 2011 14:43:22 +0000 Message-ID: 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-ID: <4675a461-dc98-48af-86e6-f5826769174a> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Cc: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [kitten] [abfab] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 14:44:57 -0000 On 10/19/11 8:34 AM, "Sam Hartman" wrote: > >So, any hints on a URN you'd like? I actually prefer urn:oid: because arguments over names are endless and non-terminating. As a second choice, maybe urn:ietf:kitten:something? -- Scott From nico@cryptonector.com Wed Oct 19 08:07:16 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F20821F8C1D; Wed, 19 Oct 2011 08:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id swNr7lcsr1nQ; Wed, 19 Oct 2011 08:07:16 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0932A21F8C19; Wed, 19 Oct 2011 08:07:16 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id C59B436006E; Wed, 19 Oct 2011 08:07:15 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=gqlwR6Ag86jA2PpO7ljV7 wabHQ8yow8kCl5OeHqGFHKp42Bwv3ZCO/h9RoZH8riOYeiYSZJANiNAtNwALqgAE LbhmsSFSNW9w6JVnWotvwhWj2S8bWuaBS4h3C9pKvPv9mWiWsbkKGsmpNliTJ06K cw7DmR/DqCyq03qm7trhZc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=8hBDqkBQsu7G0Fpn+8rD QD19mY0=; b=Y7Xzc3fiKKMPEpFUX3Jb18Wwl+kJRsfdmB7gVYDDsj/z4agx7oH8 pUKRnPcccmvKKJ4qSr5Cvf0kqnbkHXx8UtFkd+l+LzdmqI60yyGXfgk+GIw+Ethm LCBgjmRpNm5pWNtXJzOdDrOCttKmlv/u6x+8cEZ6cf5K7zuRADSjskM= Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 88DB236006D; Wed, 19 Oct 2011 08:07:15 -0700 (PDT) Received: by qyk34 with SMTP id 34so3059010qyk.10 for ; Wed, 19 Oct 2011 08:07:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.68 with SMTP id e4mr12871558pbk.126.1319036834573; Wed, 19 Oct 2011 08:07:14 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 08:07:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Oct 2011 10:07:14 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman , "abfab@ietf.org" , Sam Hartman Subject: Re: [kitten] [abfab] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:07:16 -0000 On Wed, Oct 19, 2011 at 9:43 AM, Cantor, Scott wrote: > On 10/19/11 8:34 AM, "Sam Hartman" wrote: >> >>So, any hints on a URN you'd like? > > I actually prefer urn:oid: because arguments over names are endless and > non-terminating. We have names because OIDs were too inconvenient... :) > As a second choice, maybe urn:ietf:kitten:something? I don't think we want WG names in there. Something like urn:ietf:security:nattr:...? Nico -- From cantor.2@osu.edu Wed Oct 19 08:50:30 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DDD21F8C12; Wed, 19 Oct 2011 08:50:30 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+o3jcSaw2r9; Wed, 19 Oct 2011 08:50:30 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id 045C521F8C0E; Wed, 19 Oct 2011 08:50:29 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9JFo3On018128; Wed, 19 Oct 2011 11:50:28 -0400 Received: from CIO-TNC-D1MBX09.osuad.osu.edu ([fe80::1c1e:740:88e5:3701]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi; Wed, 19 Oct 2011 11:52:16 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] [abfab] SAML attributes and assertions for naming extensions Thread-Index: AQHMjnEdTjhGgIlevE6ErJzeN9UpAZWD0L2A Date: Wed, 19 Oct 2011 15:50:23 +0000 Message-ID: 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-ID: <060d7c61-15cb-46ba-b5dd-404d113c9c53> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Cc: "kitten@ietf.org" , Sam Hartman , "abfab@ietf.org" , Sam Hartman Subject: Re: [kitten] [abfab] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:50:30 -0000 On 10/19/11 11:07 AM, "Nico Williams" wrote: >On Wed, Oct 19, 2011 at 9:43 AM, Cantor, Scott wrote: >> >> I actually prefer urn:oid: because arguments over names are endless and >> non-terminating. > >We have names because OIDs were too inconvenient... :) I know, and there's a high degree of overlap between the people who complain about them and the people who bitch endlessly at whatever name you pick. I care little for either set. >> As a second choice, maybe urn:ietf:kitten:something? > >I don't think we want WG names in there. Something like >urn:ietf:security:nattr:...? Given that it's explicitly meant as a GSS-API naming extension, maybe just use gssapi in the name. -- Scott From nico@cryptonector.com Wed Oct 19 08:59:38 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E24A21F8C87; Wed, 19 Oct 2011 08:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rQ2nPd5WHYKy; Wed, 19 Oct 2011 08:59:37 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0F421F8C96; Wed, 19 Oct 2011 08:59:37 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 5CCA3100C2; Wed, 19 Oct 2011 08:59:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=twL7YHUfvypVCWNG+tF3Cu3syrzQevmSXzjg7Xn7BoQm J85mASJcsgNs/6n1azWkxqH6uSaK4rDL6zbSTwFOfgxRv0VR3/CvNURE/MAST7aQ L3iGrwAvKJQgpUGPXOpi5KANjhBIwpdFC9AyNC5KqDjmU5ohniuSXYkRKtphLAo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=wKKf7qdHuW6iBiDIo5pfJjDnAaU=; b=seGlcnzmw6C quSwPieEfqiv27utXmnBJKhy8606odCmrFAta2cd2HvH8DS3g6zQr5dASQL1UyLd yJrtm2cO44/DChGlLNNYkjdIuABXeem7u0dgHXp03DEAQcRjiiivGylrsiMk47aW 9mrOBAiTmKc/f5xwwYkmHR6hi+klS+Vs= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 9D2EC100BA; Wed, 19 Oct 2011 08:56:14 -0700 (PDT) Received: by ywa8 with SMTP id 8so2205034ywa.31 for ; Wed, 19 Oct 2011 08:56:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.38.68 with SMTP id e4mr13115690pbk.126.1319039770802; Wed, 19 Oct 2011 08:56:10 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 19 Oct 2011 08:56:10 -0700 (PDT) In-Reply-To: References: Date: Wed, 19 Oct 2011 10:56:10 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Sam Hartman , "abfab@ietf.org" , Sam Hartman Subject: Re: [kitten] [abfab] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 15:59:38 -0000 On Wed, Oct 19, 2011 at 10:50 AM, Cantor, Scott wrote: > On 10/19/11 11:07 AM, "Nico Williams" wrote: >>On Wed, Oct 19, 2011 at 9:43 AM, Cantor, Scott wrote: >>> >>> I actually prefer urn:oid: because arguments over names are endless and >>> non-terminating. >> >>We have names because OIDs were too inconvenient... =C2=A0:) > > I know, and there's a high degree of overlap between the people who > complain about them and the people who bitch endlessly at whatever name > you pick. I care little for either set. I am neutral on this. I'd be just as happy to throw out all the OIDs and replace them with strings in a new version of the API. But you're right about one thing: OIDs represent a psychological barrier to addition of new constants, which might then encourage people to use the entities that exist rather than invent new ones with semantics equal or similar to existing ones. >>> As a second choice, maybe urn:ietf:kitten:something? >> >>I don't think we want WG names in there. =C2=A0Something like >>urn:ietf:security:nattr:...? > > Given that it's explicitly meant as a GSS-API naming extension, maybe jus= t > use gssapi in the name. Can such attributes be useful outside the GSS context? But, sure, urn:ietf:security:gss:nattr:... From hartmans@painless-security.com Wed Oct 19 09:05:32 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A1A521F8C8D; Wed, 19 Oct 2011 09:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOsbux6hi0Yl; Wed, 19 Oct 2011 09:05:32 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2057621F8C89; Wed, 19 Oct 2011 09:05:32 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2E6B320274; Wed, 19 Oct 2011 12:06:45 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 659FE4239; Wed, 19 Oct 2011 12:05:17 -0400 (EDT) From: Sam Hartman To: Nico Williams References: Date: Wed, 19 Oct 2011 12:05:17 -0400 In-Reply-To: (Nico Williams's message of "Wed, 19 Oct 2011 10:56:10 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , "abfab@ietf.org" , Sam Hartman Subject: Re: [kitten] [abfab] SAML attributes and assertions for naming extensions X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:05:32 -0000 OK. I'll attempt to propose something. 1) We're not going to use an OID for a lot of reasons including we don't have an OID arc to use for this and we already had that discussion as Nico points out. 2) the URNs proposed so far are not consistent with the IETF's namespace. From hartmans@mit.edu Thu Oct 20 07:13:36 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E01621F8B5B for ; Thu, 20 Oct 2011 07:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=-0.684, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2fALhpi76Qf for ; Thu, 20 Oct 2011 07:13:35 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id C94B821F8B7E for ; Thu, 20 Oct 2011 07:13:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id CD1462021E; Thu, 20 Oct 2011 10:14:47 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 196FC4239; Thu, 20 Oct 2011 10:13:20 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4DDDF593.5080100@oracle.com> <4E31DC54.8060208@mnt.se> Date: Thu, 20 Oct 2011 10:13:20 -0400 In-Reply-To: <4E31DC54.8060208@mnt.se> (Leif Johansson's message of "Fri, 29 Jul 2011 00:01:56 +0200") 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] WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:13:36 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> OK lets see if I can summarize the proposals that have been Leif> floating around in this thread: Leif> 1 change the signature for set_attribute 2 add a new method Leif> set_attribute_critical 3 clarify the semantics of Leif> set_attribute to always require that the attribute be "known" Leif> My personal preference is 3,2,1 in that order. My gut feeling Leif> is that an implementation should not allow setting of Leif> attributes it doesn't have some "knowledge of" but maybe I Leif> just haven't thought about the ramifications enough. Leif> Cheers Leif Leif> _______________________________________________ Kitten mailing Leif> list Kitten@ietf.org Leif> https://www.ietf.org/mailman/listinfo/kitten Ok, so what happened with this? It would be really good to get naming exts on its way. From shawn.emery@oracle.com Thu Oct 20 23:52:40 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D02D21F84C3 for ; Thu, 20 Oct 2011 23:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k5QoUIZLQoMb for ; Thu, 20 Oct 2011 23:52:39 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF7A21F84C1 for ; Thu, 20 Oct 2011 23:52:38 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9L6qamY015052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 21 Oct 2011 06:52:37 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9L6qZwq012372 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 21 Oct 2011 06:52:35 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9L6qTOM005271 for ; Fri, 21 Oct 2011 01:52:29 -0500 Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 20 Oct 2011 23:52:29 -0700 Message-ID: <4EA11691.5000007@oracle.com> Date: Fri, 21 Oct 2011 00:52:01 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:6.0.2) Gecko/20111003 Thunderbird/6.0.2 MIME-Version: 1.0 To: kitten@ietf.org References: <4DDDF593.5080100@oracle.com> <4E31DC54.8060208@mnt.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] X-CT-RefId: str=0001.0A090201.4EA116B5.00CE,ss=1,re=0.000,fgs=0 Subject: Re: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 06:52:40 -0000 On 10/20/11 08:13 AM, Sam Hartman wrote: >>>>>> "Leif" == Leif Johansson writes: > Leif> OK lets see if I can summarize the proposals that have been > Leif> floating around in this thread: > > Leif> 1 change the signature for set_attribute 2 add a new method > Leif> set_attribute_critical 3 clarify the semantics of > Leif> set_attribute to always require that the attribute be "known" > > Leif> My personal preference is 3,2,1 in that order. My gut feeling > Leif> is that an implementation should not allow setting of > Leif> attributes it doesn't have some "knowledge of" but maybe I > Leif> just haven't thought about the ramifications enough. > > Leif> Cheers Leif > Leif> _______________________________________________ Kitten mailing > Leif> list Kitten@ietf.org > Leif> https://www.ietf.org/mailman/listinfo/kitten > > Ok, so what happened with this? > It would be really good to get naming exts on its way. That was the chairs' to do item; determine if a consensus call needed to be made. After looking through the thread this does seem to be case. I will hopefully have something drafted this weekend. Sorry for the delay. Shawn. -- From leifj@mnt.se Sat Oct 22 16:42:25 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA72321F8AAA for ; Sat, 22 Oct 2011 16:42:25 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HXDJkFoctNT for ; Sat, 22 Oct 2011 16:42:25 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id A265C21F8801 for ; Sat, 22 Oct 2011 16:42:24 -0700 (PDT) Received: from [192.168.242.252] ([207.239.83.130]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9MNgDEN023283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 23 Oct 2011 01:42:21 +0200 (CEST) Message-ID: <4EA354D5.10208@mnt.se> Date: Sun, 23 Oct 2011 01:42:13 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: kitten@ietf.org References: <4DDDF593.5080100@oracle.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 23:42:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/27/2011 09:34 PM, Sam Hartman wrote: >>>>>> "Nico" == Nico Williams writes: > > Nico> I would prefer that we cover this now. > > Nico> Here's my proposal: add an 'int critical' argument to > Nico> GSS_Set_name_attribute() to indicate whether it is critical > Nico> that the mechanism understand the given attribute wherever the > Nico> name is used as an input, and allow the mechanism to ignore > Nico> non-critical attributes that it doesn't understand. > > I'm against changing the function signature of anything specified by C > bindings in this document. I'd support adding a new API in a future > document (set_critical_attribute) if we need it. I propose the chairs do a consensus call for introducing the following change to resolve this issue after which I can issue -12 and we can do another WGLC. The proposed change is: Add the following paragraph as the first paragraph of text (after the specification text) in 7.6: "An implementation SHOULD return GSS_S_UNAVAILABLE as indicated above if the attribute and its semantic is not understood by implementation. Allowing arbitrary attribute names to be set may alter the security properties of the established context." Also I propose changing all occurences of the term "attribute OID" to "attribute name" This is a residue from an earlier version of this draft when names were still OIDs. Arguably a minor nit. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6jVNQACgkQ8Jx8FtbMZnddQwCgr/rYS52Bp7BmOPQEEUcbLcU5 9YwAoK3JLo1ITXnGAELTu8O4UOWVA2qd =CTDi -----END PGP SIGNATURE----- From shawn.emery@oracle.com Wed Oct 26 11:07:12 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9AE21F8672 for ; Wed, 26 Oct 2011 11:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiDj9JWNaR-a for ; Wed, 26 Oct 2011 11:07:11 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by ietfa.amsl.com (Postfix) with ESMTP id 78BED21F85F7 for ; Wed, 26 Oct 2011 11:07:11 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9QI7AEo014350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 26 Oct 2011 18:07:10 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9QI792J028390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 26 Oct 2011 18:07:09 GMT Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9QI74Pi031845 for ; Wed, 26 Oct 2011 13:07:04 -0500 Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 26 Oct 2011 11:07:03 -0700 Message-ID: <4EA84C21.1090300@oracle.com> Date: Wed, 26 Oct 2011 12:06:25 -0600 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:6.0.2) Gecko/20111003 Thunderbird/6.0.2 MIME-Version: 1.0 To: "kitten@ietf.org" References: <4EA7B9FC.3000500@oracle.com> In-Reply-To: <4EA7B9FC.3000500@oracle.com> X-Forwarded-Message-Id: <4EA7B9FC.3000500@oracle.com> Content-Type: multipart/alternative; boundary="------------050700080000030106000705" X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4EA84C4F.0002:SCFMA922111,ss=1,re=-4.000,fgs=0 Subject: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 18:07:12 -0000 This is a multi-part message in MIME format. --------------050700080000030106000705 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit This starts a consensus call for changes to draft-ietf-kitten-gssapi-naming-exts-11. The call expires in two weeks (by 11/9/11). 1.1 Change the draft to clarify attributes that are not understood: The proposed change is: Add the following paragraph as the first paragraph of text (after the specification text) in 7.6: "An implementation SHOULD return GSS_S_UNAVAILABLE as indicated above if the attribute and its semantic is not understood by implementation. Allowing arbitrary attribute names to be set may alter the security properties of the established context." 1.2 Change the draft to support a critical argument. Text to be proposed. 1.3 Leave the draft as is. 1.4 Need more information. 2.1 Change the draft to remove attribute OID references: Changing all occurrences of the term "attribute OID" to "attribute name" This is a residue from an earlier version of this draft when names were still OIDs. Arguably a minor nit. 2.2 Leave the draft as is. 2.3 Need more information. Shawn. -- --------------050700080000030106000705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

This starts a consensus call for changes to draft-ietf-kitten-gssapi-naming-exts-11.  The call expires in two weeks (by 11/9/11).

1.1 Change the draft to clarify attributes that are not understood:

The proposed change is:

Add the following paragraph as the first paragraph of text (after the
specification text) in 7.6:

"An implementation SHOULD return GSS_S_UNAVAILABLE as indicated above
if the attribute and its semantic is not understood by implementation.
Allowing arbitrary attribute names to be set may alter the security
properties of the established context."

1.2 Change the draft to support a critical argument.  Text to be proposed.

1.3 Leave the draft as is.

1.4 Need more information.

2.1 Change the draft to remove attribute OID references:

Changing all occurrences of the term "attribute OID" to
"attribute name" This is a residue from an earlier version of this
draft when names were still OIDs. Arguably a minor nit.

2.2 Leave the draft as is.

2.3 Need more information.

Shawn.
--
--------------050700080000030106000705-- From cantor.2@osu.edu Wed Oct 26 11:29:19 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC8121F8B66 for ; Wed, 26 Oct 2011 11:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWO4AG5T3raU for ; Wed, 26 Oct 2011 11:29:18 -0700 (PDT) Received: from defang21.it.ohio-state.edu (defang21.it.ohio-state.edu [128.146.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id BC3FC21F8B49 for ; Wed, 26 Oct 2011 11:29:18 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang21.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id p9QISrWd005343 for ; Wed, 26 Oct 2011 14:29:17 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi; Wed, 26 Oct 2011 14:29:04 -0400 From: "Cantor, Scott" To: "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt Thread-Index: AQHMGk9ePlGRzA45C0OMSYHcBxvktpWP5aMA Date: Wed, 26 Oct 2011 18:29:00 +0000 Message-ID: In-Reply-To: <20110524201625.6926.92760.idtracker@ietfa.amsl.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: <94b65e1a-93e5-4e07-94d6-a44f4a0e2f66> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: No geolocation information available for 164.107.81.168 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.181 Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 18:29:19 -0000 Kept meaning to ask about this. There's a sentence at the very end, in section 9: "This is analogous to the SAML permanentIdentifier attribute and has comparable security and privacy properties and implications." The discussion is around using a naming extension as a unique identifier in cases where the mechanism is otherwise not exposing a unique peer identity. There's no such thing as a "permanentIdentifier" in SAML, and while this might be referring to the NameID format of "persistent", I think it's not specifically confining itself to directed/pairwise identifiers. I'd strike the sentence. If an example is really needed, then the allusion to SAML here will be more involved than just that. -- Scott From nico@cryptonector.com Wed Oct 26 14:04:43 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9CF11E80B3 for ; Wed, 26 Oct 2011 14:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZp5DtTh8IFL for ; Wed, 26 Oct 2011 14:04:42 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id E834111E808A for ; Wed, 26 Oct 2011 14:04:42 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 817212F4084 for ; Wed, 26 Oct 2011 14:04:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=mFR6i/6T/xnVQ5vvIJEV00bDhFQ2kFnpQHd8TnIlaowO eOcJjQtyDKnW7WbuWAPWiSMpf8REcTED0VG10Jks0DgQkQIRSY7VFYzZ5B4H1/yj 4IxFgcNSHr+RfI5tENn0VB8HfGJOCpC0swkcXEPpcmTPaS0/BTgmpViFWEXeM5Q= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=usXfR2T/2Yfa2NufTctTfqGp14U=; b=y5e8ZsDqQiB ReLCKQen/wFR2rqWXhbbjklKTU18Tmzr5OWW9+GPulbS9w3zH9w7c/gvEr517tj0 7Oto5wFq1WINgI83M6AI+ZdOjyCSqVvt1kiHTG3x/g7qgdaIymUgZqyY9Ykji1EX dqKno4mZ9NYmj/2eTOVynPWa0Whyc4Ac= Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id BF2E62F407E for ; Wed, 26 Oct 2011 14:04:15 -0700 (PDT) Received: by qadc10 with SMTP id c10so2407464qad.31 for ; Wed, 26 Oct 2011 14:04:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.35.129 with SMTP id h1mr64518992pbj.92.1319663054853; Wed, 26 Oct 2011 14:04:14 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 26 Oct 2011 14:04:14 -0700 (PDT) In-Reply-To: <4EA84C21.1090300@oracle.com> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> Date: Wed, 26 Oct 2011 16:04:14 -0500 Message-ID: From: Nico Williams To: Shawn Emery Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 21:04:43 -0000 On Wed, Oct 26, 2011 at 1:06 PM, Shawn Emery wrote= : > 1.1 Change the draft to clarify attributes that are not understood: > > The proposed change is: > > Add the following paragraph as the first paragraph of text (after the > specification text) in 7.6: > > "An implementation SHOULD return GSS_S_UNAVAILABLE as indicated above > if the attribute and its semantic is not understood by implementation. > Allowing arbitrary attribute names to be set may alter the security > properties of the established context." Can we have some guidance for when this function might be useful? Possible use cases: - To request that the given attribute be present (how about absent?) in the name to be authenticated by a credential to be acquired later with the given NAME object as desired_name (the one on which the attribute is being set). Note that for this use case the caller may want to know with certainty that credentials acquired with this NAME will bear the given attribute (see below). - To modify a NAME object that will be passed to another part of the syste= m. We probably need to state that modifying a NAME does not modify any credentials previously acquired with the same desired_name NAME object I don't understand the sentence that starts with "The peer being an authoritative...". > 1.2 Change the draft to support a critical argument.=C2=A0 Text to be pro= posed. I propose not adding a critical argument. Instead I propose stating that GSS_Acquire_cred() and friends can fail with either a new major status code or with an appropriate minor status code by which to indicate that a name attribute set with GSS_Set_name_attribute() could not be honored. OR, alternatively, I propose that attributes that cannot be asserted for whatever reason be silently ignored: the application can inquire the resulting credential to see that the desired attributes will be asserted. > 2.1 Change the draft to remove attribute OID references: > > Changing all occurrences of the term "attribute OID" to > "attribute name" This is a residue from an earlier version of this > draft when names were still OIDs. Arguably a minor nit. I support this. Nico -- From lukeh@padl.com Wed Oct 26 16:40:31 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A13D1F0C36 for ; Wed, 26 Oct 2011 16:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.863 X-Spam-Level: X-Spam-Status: No, score=-1.863 tagged_above=-999 required=5 tests=[AWL=0.736, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRYPLPZNUYCl for ; Wed, 26 Oct 2011 16:40:30 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id A223A1F0C34 for ; Wed, 26 Oct 2011 16:40:30 -0700 (PDT) Received: by us.padl.com with ESMTP id p9QNeAJw001418; Wed, 26 Oct 2011 19:40:13 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Thu, 27 Oct 2011 10:40:10 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> To: Nico Williams X-Mailer: Apple Mail (2.1251.1) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 23:40:31 -0000 >> 1.2 Change the draft to support a critical argument. Text to be proposed. > > I propose not adding a critical argument. Instead I propose stating > that GSS_Acquire_cred() and friends can fail with either a new major > status code or with an appropriate minor status code by which to > indicate that a name attribute set with GSS_Set_name_attribute() could > not be honored. OR, alternatively, I propose that attributes that > cannot be asserted for whatever reason be silently ignored: the > application can inquire the resulting credential to see that the > desired attributes will be asserted. +1 for not changing API signatures -- Luke From nico@cryptonector.com Wed Oct 26 16:47:14 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772AD1F0C36 for ; Wed, 26 Oct 2011 16:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.913 X-Spam-Level: X-Spam-Status: No, score=-1.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4xpyuPTt7LM for ; Wed, 26 Oct 2011 16:47:14 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2510E1F0C34 for ; Wed, 26 Oct 2011 16:47:14 -0700 (PDT) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id BBC5867C06E for ; Wed, 26 Oct 2011 16:47:13 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id 84D8B67C069 for ; Wed, 26 Oct 2011 16:47:13 -0700 (PDT) Received: by ywt2 with SMTP id 2so2437201ywt.31 for ; Wed, 26 Oct 2011 16:47:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.57.102 with SMTP id h6mr69551506pbq.7.1319672832349; Wed, 26 Oct 2011 16:47:12 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Wed, 26 Oct 2011 16:47:12 -0700 (PDT) In-Reply-To: References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> Date: Wed, 26 Oct 2011 18:47:12 -0500 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Oct 2011 23:47:14 -0000 On Wed, Oct 26, 2011 at 6:40 PM, Luke Howard wrote: >>> 1.2 Change the draft to support a critical argument. =C2=A0Text to be p= roposed. >> >> I propose not adding a critical argument. =C2=A0Instead I propose statin= g >> that GSS_Acquire_cred() and friends can fail with either a new major >> status code or with an appropriate minor status code by which to >> indicate that a name attribute set with GSS_Set_name_attribute() could >> not be honored. =C2=A0OR, alternatively, I propose that attributes that >> cannot be asserted for whatever reason be silently ignored: the >> application can inquire the resulting credential to see that the >> desired attributes will be asserted. > > +1 for not changing API signatures Agreed. It's too late to change the function signatures. Which of the two behaviors I propose do you prefer? Both strike me as obnoxious, but I prefer the second of the two I proposed on the theory that most uses of GSS_Set_name_attribute() will be non-critical. If that theory is wrong then let's go with the first behavior. Nico -- From leifj@mnt.se Thu Oct 27 00:10:22 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA2121F869E for ; Thu, 27 Oct 2011 00:10:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+XPSUX3s0Tm for ; Thu, 27 Oct 2011 00:10:21 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id AD0DB21F8696 for ; Thu, 27 Oct 2011 00:10:20 -0700 (PDT) Received: from [212.25.132.67] ([212.25.132.67]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9R7AFtx004495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Oct 2011 09:10:18 +0200 (CEST) Message-ID: <4EA903D7.7050701@mnt.se> Date: Thu, 27 Oct 2011 09:10:15 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 07:10:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/26/2011 08:29 PM, Cantor, Scott wrote: > Kept meaning to ask about this. There's a sentence at the very end, in > section 9: > > "This is analogous to the SAML permanentIdentifier attribute and has > comparable security and privacy properties and implications." > > The discussion is around using a naming extension as a unique identifier > in cases where the mechanism is otherwise not exposing a unique peer > identity. There's no such thing as a "permanentIdentifier" in SAML, and > while this might be referring to the NameID format of "persistent", I > think it's not specifically confining itself to directed/pairwise > identifiers. > > I'd strike the sentence. If an example is really needed, then the allusion > to SAML here will be more involved than just that. > Why not simply say "This is analogous to the SAML urn:oasis:names:tc:SAML:2.0:nameid-format:persistent NameID format and has comparable security and privacy properties and implications." I give you that you could (and might want to) include much more detail to make this a really understandable example wo prior SAML knowledge but nevertheless I believe it would be good to have something on this important topic. cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6pA9cACgkQ8Jx8FtbMZnce4wCeOvGrC+ZJnsSja7RpM3napkwy 4hkAoI3bk7zYzBrU1EeHI3CMh61sDZvJ =0PCK -----END PGP SIGNATURE----- From leifj@mnt.se Thu Oct 27 00:27:40 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6630721F85F7 for ; Thu, 27 Oct 2011 00:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNKUF3llDVaW for ; Thu, 27 Oct 2011 00:27:39 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 7922C21F85DB for ; Thu, 27 Oct 2011 00:27:39 -0700 (PDT) Received: from [212.25.132.67] ([212.25.132.67]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9R7RZdW015609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 27 Oct 2011 09:27:38 +0200 (CEST) Message-ID: <4EA907E7.3080501@mnt.se> Date: Thu, 27 Oct 2011 09:27:35 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: kitten@ietf.org References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 07:27:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/2011 01:47 AM, Nico Williams wrote: > On Wed, Oct 26, 2011 at 6:40 PM, Luke Howard wrote: >>>> 1.2 Change the draft to support a critical argument. Text to be proposed. >>> >>> I propose not adding a critical argument. Instead I propose stating >>> that GSS_Acquire_cred() and friends can fail with either a new major >>> status code or with an appropriate minor status code by which to >>> indicate that a name attribute set with GSS_Set_name_attribute() could >>> not be honored. OR, alternatively, I propose that attributes that >>> cannot be asserted for whatever reason be silently ignored: the >>> application can inquire the resulting credential to see that the >>> desired attributes will be asserted. >> >> +1 for not changing API signatures > > Agreed. It's too late to change the function signatures. > > Which of the two behaviors I propose do you prefer? Both strike me as > obnoxious, but I prefer the second of the two I proposed on the theory > that most uses of GSS_Set_name_attribute() will be non-critical. If > that theory is wrong then let's go with the first behavior. Nico - I'm not sure which alternative you indicated or if you wanted to propose alternative text, can you clarify please? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6pB+cACgkQ8Jx8FtbMZnc/xgCffb1komei1lciEE2iMgRvMTT8 10cAoMTBLMsBGkFouTFCDC9dEPSIWVNd =rOkj -----END PGP SIGNATURE----- From nico@cryptonector.com Thu Oct 27 07:10:28 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35C921F85A4 for ; Thu, 27 Oct 2011 07:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.914 X-Spam-Level: X-Spam-Status: No, score=-1.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HlgtjlsCdZ9 for ; Thu, 27 Oct 2011 07:10:27 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id E61CE21F89BA for ; Thu, 27 Oct 2011 07:10:26 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 4A881778071 for ; Thu, 27 Oct 2011 07:09:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=G14cqtyo7zKQi6zmED4WkGkMLBJRBwbJHrW44F8SkWwN 23oiHO8vBE6LzPViZgPR21LZS5PNo9FIibWmSAtIYSdngTKkjeS6ZV4HgSBJ/unq 2eWcVUkfHhtGFq64b2sH7HXePNr9491YSPcmXurEH3K2ZdicGyubpsnqtE+hxcg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=vWtew382CWKhZfy1XJedEX0+y9g=; b=OaR1c538cF3 6TNbcU+hJX17dWJhhO0A7ticU/azK8uP/6LC2W2yvPmzuC7b6+Snwu5ozrm5QuG0 iWsqkgymQWAy06FtbEKH6S5yzmplszm/j7wnQ7xb0c+P5SKclImgD8pyUbw49SwP j+wkX43LAvFSU8UKhFTlonDX+cUSE2VU= Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id DF465778061 for ; Thu, 27 Oct 2011 07:08:39 -0700 (PDT) Received: by qadc10 with SMTP id c10so3287272qad.31 for ; Thu, 27 Oct 2011 07:08:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.39.34 with SMTP id m2mr16307872pbk.75.1319724509622; Thu, 27 Oct 2011 07:08:29 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Thu, 27 Oct 2011 07:08:29 -0700 (PDT) In-Reply-To: <4EA907E7.3080501@mnt.se> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> Date: Thu, 27 Oct 2011 09:08:29 -0500 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:10:28 -0000 On Thu, Oct 27, 2011 at 2:27 AM, Leif Johansson wrote: > On 10/27/2011 01:47 AM, Nico Williams wrote: >> On Wed, Oct 26, 2011 at 6:40 PM, Luke Howard wrote: >>>>> 1.2 Change the draft to support a critical argument. =C2=A0Text to be= proposed. >>>> >>>> I propose not adding a critical argument. =C2=A0Instead I propose stat= ing >>>> that GSS_Acquire_cred() and friends can fail with either a new major >>>> status code or with an appropriate minor status code by which to >>>> indicate that a name attribute set with GSS_Set_name_attribute() could >>>> not be honored. =C2=A0OR, alternatively, I propose that attributes tha= t >>>> cannot be asserted for whatever reason be silently ignored: the >>>> application can inquire the resulting credential to see that the >>>> desired attributes will be asserted. >>> >>> +1 for not changing API signatures >> >> Agreed. =C2=A0It's too late to change the function signatures. >> >> Which of the two behaviors I propose do you prefer? =C2=A0Both strike me= as >> obnoxious, but I prefer the second of the two I proposed on the theory >> that most uses of GSS_Set_name_attribute() will be non-critical. =C2=A0I= f >> that theory is wrong then let's go with the first behavior. > > Nico - I'm not sure which alternative you indicated or if you wanted > to propose alternative text, can you clarify please? In the text quoted by Luke above there's two proposed changes separated by "OR". I did not propose text because I didn't know which of the two changes we'd want. However, I've come to realize that only the second alternative is workable, therefore I propose the following addition to section 7.6 (say, at the end of it): GSS_Set_name_attribute() MAY succeed even though a credential acquired with the resulting NAME may not actually result in a peer seeing the giv= en attribute. If it is critical that the attribute be asserted in subsequent security context establishments, then the caller must inquire the NAME for any CREDENTIAL HANDLE acquired with this NAME and then check that the requested attribute has indeed been set in the CREDENTIAL HANDLE's NAME. Nico -- From leifj@mnt.se Thu Oct 27 07:36:51 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24FD21F8AE6 for ; Thu, 27 Oct 2011 07:36:51 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4qu+V8cPTZN for ; Thu, 27 Oct 2011 07:36:50 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 7032E21F8538 for ; Thu, 27 Oct 2011 07:36:50 -0700 (PDT) Received: from [212.25.132.67] ([212.25.132.67]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9REaea7011425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2011 16:36:45 +0200 (CEST) Message-ID: <4EA96C78.5010603@mnt.se> Date: Thu, 27 Oct 2011 16:36:40 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:36:51 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/2011 04:08 PM, Nico Williams wrote: > On Thu, Oct 27, 2011 at 2:27 AM, Leif Johansson wrote: >> On 10/27/2011 01:47 AM, Nico Williams wrote: >>> On Wed, Oct 26, 2011 at 6:40 PM, Luke Howard wrote: >>>>>> 1.2 Change the draft to support a critical argument. Text to be proposed. >>>>> >>>>> I propose not adding a critical argument. Instead I propose stating >>>>> that GSS_Acquire_cred() and friends can fail with either a new major >>>>> status code or with an appropriate minor status code by which to >>>>> indicate that a name attribute set with GSS_Set_name_attribute() could >>>>> not be honored. OR, alternatively, I propose that attributes that >>>>> cannot be asserted for whatever reason be silently ignored: the >>>>> application can inquire the resulting credential to see that the >>>>> desired attributes will be asserted. >>>> >>>> +1 for not changing API signatures >>> >>> Agreed. It's too late to change the function signatures. >>> >>> Which of the two behaviors I propose do you prefer? Both strike me as >>> obnoxious, but I prefer the second of the two I proposed on the theory >>> that most uses of GSS_Set_name_attribute() will be non-critical. If >>> that theory is wrong then let's go with the first behavior. >> >> Nico - I'm not sure which alternative you indicated or if you wanted >> to propose alternative text, can you clarify please? > > In the text quoted by Luke above there's two proposed changes > separated by "OR". I did not propose text because I didn't know which > of the two changes we'd want. However, I've come to realize that only > the second alternative is workable, therefore I propose the following > addition to section 7.6 (say, at the end of it): > > GSS_Set_name_attribute() MAY succeed even though a credential acquired > with the resulting NAME may not actually result in a peer seeing the given > attribute. If it is critical that the attribute be asserted in > subsequent security > context establishments, then the caller must inquire the NAME for any > CREDENTIAL HANDLE acquired with this NAME and then check that the > requested attribute has indeed been set in the CREDENTIAL HANDLE's > NAME. > > Nico > -- Silently ignoring attributes feels like a bad idea. The current text basically already sais that setting unknown attributes results in an error. My proposal (1.1) just clarifies that text and does not change any API signatures. You want to go from "return error" to "silently ignore". Help me understand why that is better. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6pbHcACgkQ8Jx8FtbMZnc3eACcDrxgQksMsAiOmfsJbOS3tnEm Wa0AnjIkbSSxB5r1wSaSDbbbXK6/yKP5 =nGww -----END PGP SIGNATURE----- From cantor.2@osu.edu Thu Oct 27 07:38:56 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA7621F8541 for ; Thu, 27 Oct 2011 07:38:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArW6fXGrWWZ9 for ; Thu, 27 Oct 2011 07:38:55 -0700 (PDT) Received: from defang1.it.ohio-state.edu (defang1.it.ohio-state.edu [128.146.216.81]) by ietfa.amsl.com (Postfix) with ESMTP id 78C1321F8AED for ; Thu, 27 Oct 2011 07:38:55 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang1.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9REciAP003141; Thu, 27 Oct 2011 10:38:54 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi; Thu, 27 Oct 2011 10:38:43 -0400 From: "Cantor, Scott" To: Leif Johansson , "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt Thread-Index: AQHMGk9ePlGRzA45C0OMSYHcBxvktpWP5aMAgAEXv4CAADo1gA== Date: Thu, 27 Oct 2011 14:38:35 +0000 Message-ID: In-Reply-To: <4EA903D7.7050701@mnt.se> 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: <230eccfa-8a8a-414d-b113-10212affb090> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.81 Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:38:56 -0000 On 10/27/11 3:10 AM, "Leif Johansson" wrote: > >Why not simply say > >"This is analogous to the SAML >urn:oasis:names:tc:SAML:2.0:nameid-format:persistent NameID format and >has comparable security and privacy properties and implications." Obviously that's the "fix", but I think that's confusing in context because that format is about much more than uniqueness, and I think all you're trying to say in that sentence is that the naming attributes might themselves provide a unique (possibly omnidirectional) identifier. In other words, any SAML attribute of NameID might end up in there and be used for that purpose, not just (or even predominantly) that one. >I give you that you could (and might want to) include much more detail >to make this a really understandable example wo prior SAML knowledge >but nevertheless I believe it would be good to have something on this >important topic. I think I'd avoid the SAML reference, then, and just state something more general. Or I'd use more than one SAML example, because you don't just mean a directed ID here. -- Scott From cantor.2@osu.edu Thu Oct 27 07:42:50 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ACDC21F8B38 for ; Thu, 27 Oct 2011 07:42:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dve8VqxFYtEN for ; Thu, 27 Oct 2011 07:42:49 -0700 (PDT) Received: from defang20.it.ohio-state.edu (defang20.it.ohio-state.edu [128.146.216.134]) by ietfa.amsl.com (Postfix) with ESMTP id A66AF21F8B32 for ; Thu, 27 Oct 2011 07:42:47 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang20.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9REg8GL029545; Thu, 27 Oct 2011 10:42:45 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi; Thu, 27 Oct 2011 10:42:11 -0400 From: "Cantor, Scott" To: Leif Johansson , Nico Williams Thread-Topic: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11 Thread-Index: AQHMlLacOBSd8W+Kp0CUAqp9gADuuw== Date: Thu, 27 Oct 2011 14:42:04 +0000 Message-ID: In-Reply-To: <4EA96C78.5010603@mnt.se> 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: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.134 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 14:42:50 -0000 On 10/27/11 10:36 AM, "Leif Johansson" wrote: > >Silently ignoring attributes feels like a bad idea. I think it makes sense in context. If you're setting attributes onto a name that is to be used as input to credential acquisition, you're making a request for something. The change is saying you can request anything, but enforcement is up to you afterwards. That is much more likely to work reliably. That's a different use case from setting an attribute on an established context. I don't know what "unknown" means in that context, since whatever's doing the setting is probably trusted by the application. -- Scott From nico@cryptonector.com Thu Oct 27 08:18:34 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392E621F8B3C for ; Thu, 27 Oct 2011 08:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9ieUH+0Lwzi for ; Thu, 27 Oct 2011 08:18:33 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0E721F8B38 for ; Thu, 27 Oct 2011 08:18:33 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 597471DE081 for ; Thu, 27 Oct 2011 08:18:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=I4NZMKYKaBKdDxzcVlwg4vVz5OszFTdD7F0h7387EOWN iakREii0iO7Vw+58dpbWfwJdf+fu3xKhnmuvS3Ot+8I1IbizDofrpgqjnyLxp2zm e5O9ilVFhbICQQFCHU66eUo5dEt4kafjO7NuZMGuXYqSDe3YdjSX6eVNksTwT9s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=wWzEJHO74ecRKLGHdJUSiHhDNoM=; b=nS73jYFD4+r HNWKbDtOf20huQ9SPiPrXrik7oiNLbfjkWaplav1klQ6Zi39r3T3sZ8LPnlywfyK RIzzDc2I/bnAhKMP+X7mg4tWhGEcb7p+wW9sYHI0UwqOiUIvEBivK93EBAscE5j8 tcvJMY+9RBzuLF5DspPLgjQVvYBMCjCk= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 47E3A1DE078 for ; Thu, 27 Oct 2011 08:18:33 -0700 (PDT) Received: by pzk34 with SMTP id 34so7433279pzk.9 for ; Thu, 27 Oct 2011 08:18:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.39.34 with SMTP id m2mr16683646pbk.75.1319728712934; Thu, 27 Oct 2011 08:18:32 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Thu, 27 Oct 2011 08:18:32 -0700 (PDT) In-Reply-To: <4EA96C78.5010603@mnt.se> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> Date: Thu, 27 Oct 2011 10:18:32 -0500 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 15:18:34 -0000 On Thu, Oct 27, 2011 at 9:36 AM, Leif Johansson wrote: >> =C2=A0 =C2=A0GSS_Set_name_attribute() MAY succeed even though a credenti= al acquired >> =C2=A0 =C2=A0with the resulting NAME may not actually result in a peer s= eeing the given >> =C2=A0 =C2=A0attribute. =C2=A0If it is critical that the attribute be as= serted in >> subsequent security >> =C2=A0 =C2=A0context establishments, then the caller must inquire the NA= ME for any >> =C2=A0 =C2=A0CREDENTIAL HANDLE acquired with this NAME and then check th= at the >> =C2=A0 =C2=A0requested attribute has indeed been set in the CREDENTIAL H= ANDLE's >> =C2=A0 =C2=A0NAME. > > Silently ignoring attributes feels like a bad idea. Yes, but how can the mechglue/mech know at this time that a credential to be acquired with this name *later* will be able to assert the requested attribute?? I don't think it can. That's why I made the above proposal. > The current text basically already sais that setting unknown attributes > results in an error. My proposal (1.1) just clarifies that text and does > not change any API signatures. That works for unknown attributes, though what exactly is "unknown" here? Unknown to the world or to the mechglue or to the mech? Also, presumably the input NAME has to be an MN, otherwise the only way a mech gets a crack at this is either *later* (in which case we must be able to silently ignore some attrs) or if the mechglue invokes every mech (but then any mech that fails fails the whole thing). It has to be as I proposed. Alternatively we'd need a different API that works on the name of a CREDENTIAL HANDLE. > You want to go from "return error" to "silently ignore". Help me > understand why that is better. See above. Nico -- From cantor.2@osu.edu Thu Oct 27 09:56:40 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3EA421F8B0E for ; Thu, 27 Oct 2011 09:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Olf6aMuVKOJ for ; Thu, 27 Oct 2011 09:56:39 -0700 (PDT) Received: from defang20.it.ohio-state.edu (defang20.it.ohio-state.edu [128.146.216.134]) by ietfa.amsl.com (Postfix) with ESMTP id 6209421F8ADE for ; Thu, 27 Oct 2011 09:56:39 -0700 (PDT) Received: from CIO-KRC-HT02.osuad.osu.edu (cio-krc-ht02.osuad.osu.edu [164.107.81.40]) by defang20.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9RGuNFL023786; Thu, 27 Oct 2011 12:56:37 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi; Thu, 27 Oct 2011 12:56:11 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt Thread-Index: AQHMGk9ePlGRzA45C0OMSYHcBxvktpWP5aMAgAEXv4CAADo1gIAAZ1gA//+/GIA= Date: Thu, 27 Oct 2011 16:56:09 +0000 Message-ID: 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-ID: <82c9b972-0e0d-4cec-84fc-ab17966a92ff> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.40; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.134 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 16:56:41 -0000 On 10/27/11 12:48 PM, "Nico Williams" wrote: > >On the other hand, it's hard to see how to get a name attribute that >is "permanent identifier" into a credential's anonymous name. How >does the permanent identifier get authenticated? That's up to the mechanism, isn't it? >I think this calls >for having a more complete discussion of attribute issuer, and until >we have that concept in the API I'd feel more comfortable striking the >whole paragraph (indeed, I'll have to review the whole I-D to make >sure that's not the only place where we implicitly depend on a notion >of attribute issuer). I don't think this paragraph depends on that notion any more than the whole spec does. Identifiers aren't the only attributes that matter in a security context. -- Scott From nico@cryptonector.com Thu Oct 27 10:09:54 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7067D21F8BC3 for ; Thu, 27 Oct 2011 10:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUbkLi5A+z4q for ; Thu, 27 Oct 2011 10:09:44 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 63F8521F8AAC for ; Thu, 27 Oct 2011 10:09:42 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id D1E2D6B007C for ; Thu, 27 Oct 2011 10:09:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=HcyGS1JFLyXkmsfm+/AYtZWgsQB35WJBZbBspmL8lDDs Ysm/LjtGwQd/j7Edg236U290/5vEe58RZ+5dXuHPyCe+fbKYC1NzljrgSGQqSgLb s9mU0C2WT66UpcGTF2HlgKHdzUNHnqLpt8xh68ygrsW0Cl//iuefcEWu0eC8fjI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=R2R3eZuZPK9DWC7IKYIIapQxuwE=; b=GaZ+TSrP2T6 wO04BdS8azb3EPAd3tLsnP+r79/gC4M5Wfg9PTx89DxlqTeS3AheUPN1yNEygYVh aR6umtTS29yFajDEi4hvBLixMK1Md7h5uFm5rJ5XPd2ZSPEPMdXR85ozjekjQqPY mKLnOXIPQAhxSqQdKev6SCLYQrMraR8o= Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 9DBB36B007B for ; Thu, 27 Oct 2011 10:09:41 -0700 (PDT) Received: by pzk34 with SMTP id 34so7731251pzk.9 for ; Thu, 27 Oct 2011 10:09:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.12.199 with SMTP id a7mr10474474pbc.58.1319735378977; Thu, 27 Oct 2011 10:09:38 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Thu, 27 Oct 2011 10:09:38 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Oct 2011 12:09:38 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:09:54 -0000 On Thu, Oct 27, 2011 at 11:56 AM, Cantor, Scott wrote: > On 10/27/11 12:48 PM, "Nico Williams" wrote: >> >>On the other hand, it's hard to see how to get a name attribute that >>is "permanent identifier" into a credential's anonymous name. =C2=A0How >>does the permanent identifier get authenticated? > > That's up to the mechanism, isn't it? Sure. I did not express myself well. I was thinking of some credential that's truly anonymous and you want to add this attribute, and the mechanism lets you. But adding it hardly implies that the attribute is authenticated, and an unauthenticated permanent identifier isn't useful, is it? Now, I can see something like the Kerberos mechanism using an authenticated credential to obtain an anonymous credential that contains authenticated permanent identifier name attributes. And that may be the point, but anytime we talk about an authenticated name attribute I come back to: who's the issuer? Without a notion of issuer the issuer has to be the same as the issuer of the credential (the realm, if there is one, of the name, keeping in mind that realm here is a mechanism-specific concept). And that means that you couldn't have an issuer-less anonymous credential that contains authenticated attributes, because while those attributes might well be like certificates, the fact that we don't expose attribute issuers means that an issuer-less anonymous credential cannot bear any authenticated name attributes. Maybe I'm making much ado about nothing here. But I'm rather bothered by the lack of an issuer concept. (Moreover, an issuer concept would make explicit and generic the Kerberos concept of "realm", a nice side benefit!) >>I think this calls >>for having a more complete discussion of attribute issuer, and until >>we have that concept in the API I'd feel more comfortable striking the >>whole paragraph (indeed, I'll have to review the whole I-D to make >>sure that's not the only place where we implicitly depend on a notion >>of attribute issuer). > > I don't think this paragraph depends on that notion any more than the > whole spec does. Identifiers aren't the only attributes that matter in a > security context. Arguably the lack of a concept of issuer is a defect in the GSS-API v2u1 (see above), and also a defect in name attributes. That we can fix it separately is certainly true, but I'd like to have a discussion as to why not fix it now. Nico -- From cantor.2@osu.edu Thu Oct 27 10:19:09 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8F521F8B87 for ; Thu, 27 Oct 2011 10:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6UJsr1uyzeh for ; Thu, 27 Oct 2011 10:19:07 -0700 (PDT) Received: from defang19.it.ohio-state.edu (defang19.it.ohio-state.edu [128.146.216.133]) by ietfa.amsl.com (Postfix) with ESMTP id 933E121F8B6F for ; Thu, 27 Oct 2011 10:19:07 -0700 (PDT) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang19.it.ohio-state.edu (8.13.7/8.13.1) with ESMTP id p9RHIqx8026355; Thu, 27 Oct 2011 13:19:05 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi; Thu, 27 Oct 2011 13:18:23 -0400 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt Thread-Index: AQHMGk9ePlGRzA45C0OMSYHcBxvktpWP5aMAgAEXv4CAADo1gIAAZ1gA//+/GICAAEbSAP//v2EA Date: Thu, 27 Oct 2011 17:18:20 +0000 Message-ID: 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-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.171; country=US; region=OH; city=Columbus; latitude=39.9968; longitude=-82.9882; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9968,-82.9882&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.133 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 17:19:09 -0000 On 10/27/11 1:09 PM, "Nico Williams" wrote: > >Sure. I did not express myself well. I was thinking of some >credential that's truly anonymous and you want to add this attribute, >and the mechanism lets you. But adding it hardly implies that the >attribute is authenticated, and an unauthenticated permanent >identifier isn't useful, is it? It depends on the relationship between the caller of the set operation and the eventual consumer of the attributes. >Now, I can see something like the Kerberos mechanism using an >authenticated credential to obtain an anonymous credential that >contains authenticated permanent identifier name attributes. And that >may be the point, That's definitely the point of the paragraph. > but anytime we talk about an authenticated name >attribute I come back to: who's the issuer? Without a notion of >issuer the issuer has to be the same as the issuer of the credential >(the realm, if there is one, of the name, keeping in mind that realm >here is a mechanism-specific concept). Yes, this has certainly come up. >Arguably the lack of a concept of issuer is a defect in the GSS-API >v2u1 (see above), and also a defect in name attributes. That we can >fix it separately is certainly true, but I'd like to have a discussion >as to why not fix it now. I'm not saying I think it isn't needed, I was just saying its lack is not in any way specific to that paragraph. Perhaps the paragraph just highlights the problem more strongly than other text in the document. -- Scott From nico@cryptonector.com Thu Oct 27 11:10:36 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E6E21F8B6C for ; Thu, 27 Oct 2011 11:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cJHu9vId1yQ for ; Thu, 27 Oct 2011 11:10:36 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 1B18A21F8B8F for ; Thu, 27 Oct 2011 11:10:36 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id B3314318083 for ; Thu, 27 Oct 2011 11:10:18 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id D95D23180A4 for ; Thu, 27 Oct 2011 09:49:04 -0700 (PDT) Received: by qyk34 with SMTP id 34so964462qyk.10 for ; Thu, 27 Oct 2011 09:48:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.25.101 with SMTP id b5mr31864163pbg.24.1319734108979; Thu, 27 Oct 2011 09:48:28 -0700 (PDT) Received: by 10.68.50.69 with HTTP; Thu, 27 Oct 2011 09:48:28 -0700 (PDT) In-Reply-To: References: <4EA903D7.7050701@mnt.se> Date: Thu, 27 Oct 2011 11:48:28 -0500 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Oct 2011 18:10:36 -0000 On Thu, Oct 27, 2011 at 9:38 AM, Cantor, Scott wrote: > I think I'd avoid the SAML reference, then, and just state something more > general. Or I'd use more than one SAML example, because you don't just > mean a directed ID here. The reference to SAML is not necessary to understand the preceding sentence, so I agree: remove the SAML reference. On the other hand, it's hard to see how to get a name attribute that is "permanent identifier" into a credential's anonymous name. How does the permanent identifier get authenticated? I think this calls for having a more complete discussion of attribute issuer, and until we have that concept in the API I'd feel more comfortable striking the whole paragraph (indeed, I'll have to review the whole I-D to make sure that's not the only place where we implicitly depend on a notion of attribute issuer). I'd actually feel more comfortable adding a function by which to obtain the NAME of the issuer of a given attribute. I believe Sam does not want to hold up the I-D for that, that he believes that we can address that later, but I don't see why we could not address it now. Nico -- From leifj@mnt.se Fri Oct 28 00:34:32 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42A521F85C7 for ; Fri, 28 Oct 2011 00:34:32 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ioh3CweDvibI for ; Fri, 28 Oct 2011 00:34:32 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id EA84E21F85BB for ; Fri, 28 Oct 2011 00:34:31 -0700 (PDT) Received: from [192.36.125.212] (dhcp.pilsnet.sunet.se [192.36.125.212]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p9S7YLPB027943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 28 Oct 2011 09:34:25 +0200 (CEST) Message-ID: <4EAA5AFD.9000305@mnt.se> Date: Fri, 28 Oct 2011 09:34:21 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] Consensus Calls for draft-ietf-kitten-gssapi-naming-exts-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2011 07:34:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/27/2011 05:18 PM, Nico Williams wrote: > On Thu, Oct 27, 2011 at 9:36 AM, Leif Johansson wrote: >>> GSS_Set_name_attribute() MAY succeed even though a credential acquired >>> with the resulting NAME may not actually result in a peer seeing the given >>> attribute. If it is critical that the attribute be asserted in >>> subsequent security >>> context establishments, then the caller must inquire the NAME for any >>> CREDENTIAL HANDLE acquired with this NAME and then check that the >>> requested attribute has indeed been set in the CREDENTIAL HANDLE's >>> NAME. >> >> Silently ignoring attributes feels like a bad idea. > > Yes, but how can the mechglue/mech know at this time that a credential > to be acquired with this name *later* will be able to assert the > requested attribute?? > > I don't think it can. That's why I made the above proposal. OK now I actually get it. I think your proposal makes sense... Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6qWv0ACgkQ8Jx8FtbMZncVlwCcDjwPW65y3kdFQq8dQoCNKCri VtgAnjBGc6s0+km4/FrbW4034QmpxGrT =snWu -----END PGP SIGNATURE----- From hannes.tschofenig@gmx.net Sun Oct 30 01:12:42 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C7B21F8586 for ; Sun, 30 Oct 2011 01:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.48 X-Spam-Level: X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioLXhsLwxjZp for ; Sun, 30 Oct 2011 01:12:41 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id EDC5121F8573 for ; Sun, 30 Oct 2011 01:12:40 -0700 (PDT) Received: (qmail invoked by alias); 30 Oct 2011 08:12:39 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [10.0.0.4]) [88.115.216.191] by mail.gmx.net (mp068) with SMTP; 30 Oct 2011 09:12:39 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18SS1UdgngSP4e4mGmSZvAaHIxQ1Oi7YM92NNeFLH rsIHwB+9BvLq5W From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 30 Oct 2011 10:12:34 +0200 Message-Id: <233ABB62-E5CC-40DD-A82E-E9EEBF251A0D@gmx.net> To: kitten@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [kitten] Nits in draft-ietf-kitten-sasl-openid-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Oct 2011 08:12:42 -0000 I just re-read = http://tools.ietf.org/html/draft-ietf-kitten-sasl-openid-06 and noticed = a few nits. Since the draft is currently in IESG evaluation it is not a = good time to update it and hence I will post the nits to the list so = that they do not get forgotten.=20 FROM: Simple Authentication and Security Layer (SASL) [RFC4422] (SASL) is used = by application protocols such IMAP [RFC3501], POP [RFC1939] and XMPP = [RFC3920], with the goal of modularizing authentication and security = layers, so that newer mechanisms can be added as needed. TO: The Simple Authentication and Security Layer (SASL) [RFC4422] is used by = application layer protocols, such as IMAP [RFC3501], POP [RFC1939] and = XMPP [RFC3920], with the goal of modularizing authentication and = security layers, so that newer mechanisms can be added as needed. Reason: IMHO this is better English (but what do I know).=20 FROM: Because this mechanism transports information that should not be controlled by an attacker, the OpenID mechanism MUST only be used over channels protected by TLS, and the client MUST successfully validate the server certificate, or similar integrity protected and authenticated channels. [RFC5280][RFC6125] TO: The OpenID mechanism MUST only be used over channels protected by TLS, and the client MUST successfully validate the server certificate, or similar integrity protected and authenticated channels.=20 Reason: The first part of the sentence does not make a lot of sense to = me.=20 The references also appear here a bit out of the blue.=20 FROM: When considering this flow in the context of SASL, we note that while the RP and the client both need to change their code to implement this SASL mechanism, it is a design constraint that the OP behavior remain untouched, in order for implementations to interoperate with existing IdPs.=20 TO: When considering this flow in the context of SASL, we note that while the RP and the client both need to change their code to implement this SASL mechanism, it is a design constraint that the OP behavior **remains** untouched, in order for implementations to interoperate = with existing IdPs.=20 FROM: However, it may be necessary for a SASL client to invoke to another application. TO: However, it may be necessary for a SASL client to invoke **WHAT** to another = application. [Hannes: There is something missing in my opinion.]=20 FROM: The SASL mechanism is client-first, and as explained in [RFC4422] the = server will send an empty challenge if needed. TO: The SASL mechanism is client-first and, as explained in [RFC4422], the = server will send an empty challenge, if needed. FROM: After normalizing the User-Supplied Identifier as discussed in [OpenID], = the Relying Party performs discovery on it and establishes the OP = Endpoint URL that the end user uses for authentication. TO: After normalizing the User-Supplied Identifier, as discussed in = [OpenID], the Relying Party performs discovery on it and establishes the = OP Endpoint URL that the end user utilizes for authentication. FROM: The Relying Party and the OP optionally establish an association -- a shared secret established using Diffie-Hellman Key Exchange. The OP uses an association to sign subsequent messages and the Relying Party to verify those messages; ; this removes the need for subsequent direct requests to verify the signature after each authentication request/response. TO: The Relying Party and the OP optionally establish an association, i.e., = a security association that contains a shared secret established using a = Diffie-Hellman key exchange. The OP and the Relying Party use this = association to cryptographically authenticate and integrity protect = subsequent message exchanges. This removes the need to perform = computationally expensive cryptographic operations using public key = cryptography for each request/response between the OP and the Relying = Party. FROM: The SASL client now sends an response consisting of "=3D", to indicate that authentication continues via the normal OpenID flow. TO: The SASL client now sends a response consisting of "=3D" to indicate that authentication continues via the normal OpenID flow. FROM: Next the client optionally authenticates to the OP and then approves or disapproves authentication to the Relying Party. TO: Next, the client optionally authenticates to the OP and then approves or disapproves authentication to the Relying Party. FROM: The manner in which the end user is authenticated to their respective OP and any policies surrounding such authentication is out of scope of OpenID and and hence also out of scope for this specification.=20 TO: The manner in which the end user is authenticated to their respective OP and any policies surrounding such authentication is out of scope of OpenID and hence also out of scope for this specification.=20 FROM: The client transmits over HTTP/TLS the redirect of the OP result to the RP. This step happens out of band from SASL. TO: The client transmits the redirect of the OP result to the RP over = HTTP/TLS .=20 This step happens outside SASL. FROM: The RP MAY send an OpenID check_authentication request directly to the OP, if no association has been established, and the OP should be expected to respond. Again this step happens out of band from SASL. TO: The RP MAY send an OpenID check_authentication request directly to the OP, if no association has been established, and the OP is expected to respond. Again, this step happens outside SASL. FROM: The SASL server sends an appropriate SASL response to the client, with optional Open Simple Registry (SREG) attributes. TO: The SASL server sends an appropriate SASL response to the client, which may optionally piggyback attributes defined by the = OpenID Simple Registry (SREG) extension = [openid-simple-registration-extension-1_0]. I noticed that the figure in Section 2 has no caption and it also not = referenced in the text either.=20 FROM: To ensure that a specific request is bound, and in particular to ease interprocess communication, it may be necessary for the relying party to encode some sort of nonce or transaction-id in the URIs it transmits through the client for success or failure. TO: To ensure that the OpenID exchange is bound to the SASL exchange it = may be necessary for the relying party to encode some sort of nonce or transaction-id in the URIs it transmits through the client for success or failure. Btw, I noticed that sometimes we write "relying party" and sometimes = "Relying Party".=20 We typically do not use capitalized "Identity Provider" terminology, = which looks a bit inconsistent.=20 FROM: Recall section 5 of [RFC4422] for what needs to be described here. TO: Recall Section 5 of [RFC4422] for what needs to be described here. FROM: The user would input his Openid into his mail user agent, when he configures the account. TO: The user would input his OpenID into his mail user agent when he = configures the account. In our example, no association is created between the Relying Party and = the OP.=20 FROM: This section and its sub-sections and appropriate references of it not referenced elsewhere in this document are not required for SASL implementors, but this section MUST be observed to implement the GSS- API mechanism discussed below. TO: This section describes the OpenID GSS-API mechanism and is relevant only = for GSS-API developers.=20 From internet-drafts@ietf.org Mon Oct 31 01:05:49 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AFB21F8D00; Mon, 31 Oct 2011 01:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW6jHR-p0lwT; Mon, 31 Oct 2011 01:05:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B78821F8B77; Mon, 31 Oct 2011 01:05:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.62 Message-ID: <20111031080548.26639.27575.idtracker@ietfa.amsl.com> Date: Mon, 31 Oct 2011 01:05:48 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2011 08:05:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next= Generation Working Group of the IETF. Title : A SASL and GSS-API Mechanism for SAML Author(s) : Klaas Wierenga Eliot Lear Simon Josefsson Filename : draft-ietf-kitten-sasl-saml-05.txt Pages : 25 Date : 2011-10-31 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-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-05.txt