From alexey.melnikov@isode.com Thu Dec 1 07:19: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 95B6511E81FC; Thu, 1 Dec 2011 07:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ZMDaUK5A0IPO; Thu, 1 Dec 2011 07:19:31 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5160011E8199; Thu, 1 Dec 2011 07:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1322752770; d=isode.com; s=selector; i=@isode.com; bh=JmAAG7Wml69jSEJCxG+8s2abkdMZdWoXpH6L3IqAgUo=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZGeXmxVvrEfdjQ4mrBTvhl6xQbMl5yruWQ7GWmAZiUeLZq1nixk3E1Ed1VfIpQjbUp8gDp CyhzHEER2GuwnFmMGPLnUM3xMSBSJ//ESnnLybjG7HrxGU8JZHp/27KAJwjd8RaTKYLFKo a2i5ncFKL9TidM03eLlX8GLCVgWqPlg=; Received: from [192.168.1.144] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 1 Dec 2011 15:19:30 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4ED79B00.1020703@isode.com> Date: Thu, 01 Dec 2011 15:19:28 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: William Mills References: <1322547891.26139.YahooMailNeo@web31812.mail.mud.yahoo.com> In-Reply-To: <1322547891.26139.YahooMailNeo@web31812.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , "draft-ietf-kitten-sasl-openid.all@tools.ietf.org" , "iesg@ietf.org" , "apps-discuss@ietf.org" Subject: Re: [kitten] [APPS-REVIEW] review of draft-ietf-kitten-sasl-openid-07 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 15:19:32 -0000 Hi William, Thank you for the review. I will reply to a couple of your points and I hope document editors will reply to the rest. On 29/11/2011 06:24, William Mills wrote: > I have been selected as the Applications Area Review Team reviewer for this draft (for background on apps-review, please seehttp://www.apps.ietf.org/content/applications-area-review-team). > > Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft. > > Document: draft-ietf-kitten-sasl-openid-07 > Reviewer: William J. Mills > Review Date: November 28, 2011 > IETF Last Call Date: October 25, 2011 > > Review Summary: > > This draft is almost ready for publication as a Proposed Standard, but should address the three major issues below before proceeding. Some minor issues and nits are also noted. > > Document Summary: > > This document defines a pure SASL mechanism for OpenID, but it conforms to the new bridge between SASL and the GSS-API called GS2 [RFC5801], so it defines both a SASL and a GSS-API mechanism. > . > > Major Issues: > > Section 1.2. Applicability: This section requires TLS but channel binding is not supported by the mechanism. OpenID itself does not require TLS for client to relying party interactions, as integrity can be assured with a MAC signature and replayability is dealt with in the OpenID nonce. Requiring TLS does not appear to be based on the underlying security profile of OpenID. If TLS is ot be required channel binding should be supported. If TLS is not required then there is the possibility of a DOS against the return_to entrypoint returned to the user, sending a false failure message. > > > Section 3.2 Authentication Request: In the second full paragraph defining transaction id, the language here probably isn't strong enough. What it says now is > > The form of this transaction is left to the RP to decide, but > SHOULD be large enough to be resistant to being guessed or attacked. > > (Nit: At the very least "transaction" needs to be "transaction id") I think it would be better if the current text is replaced with > > The form of this transaction id is left to the implementer, but it > MUST be resistant to being guessed or attacked. I agree with this, but the MUST by itself doesn't provide enough information about how to implement a conformant implementation, so ... > I think MUST is justified here because the RP is possibly open to a DOS if the value is guessable. A paragraph in the security considerations section might be warranted to talk about how to pick good unguessable values, although this has been done many times in many different specs. ... There is an RFC on generating good randomness: [RFC4086]. It should be cited here. > Side comment: maybe we need an RFC just for this and then everyone can cite it. > > 3.3. Server Response > > The problem I see here is that the result sent to the server that is "used to set state in the server accordingly" is not guaranteed to provide a username that will be useful to the SASL endpoint. The RP might get a full email address, or might get a bare username. In the case of an IMAP server supporting multiple domains this may be significant. The spec really should define how the SASL identities are determined from the response from the OP. The authentication identity is specified in Section 3.1 (it is passed from the client to the server). However, two things are missing in the document: 1). A more precise definition of the authentication identity format. Section 3.1 says that it is a URI, but doesn't specify any specific URI scheme as mandatory to implement or even as recommended. Lack of specificity can lead to types of problem you point out above. 2). Section 3.3 should probably talk about whether any verification of the returned data can and should be performed to make sure that it corresponds to the identity requested. Unless editors can make a good argument why this doesn't belong in Section 3.3. > It's possible that this could be solved by moving 6.1 and making it 3.3.1. Identity mapping seems to fit better here than in security considerations. > > > Minor issues: > > User confusion on names: The problem I see is one of confusion for the user of an OpenID enabled SASL client for Mail. Some endpoint will need to be given usrename, some will be given an dOpenID endpoint. Clarifying language might be useful to guide the client implementer. Is there a disocvery method that the client can use ot go from a username/domain to the OpenID endpoint ot send to the RP? > > More examples: I'd prefer to see an example of a failure flow included. I tend to like examples though, and find them helpful in parsing the normative text. > > 3.3. Server Response& 3.4. Error Handling& 5. Example > > There's an inconsistency here I think could be better. In the Exmaple we have a success case where the client returns and empty client message in order to prompt the server to finalize the SASL negotiation. In the error handling case we have an explicit continuation from the client sending "=". Is the "=" sign after the error return actually required or can this simply be an empty client message. This means if the client knows the negotiation is complete and has not gotten a result it just always sends the empty message. Personally I would appreciate an error case example. > Nits: > > Section 1, 4th para, first sentence: I would change "As currently envisioned, this mechanism is to allow" to "This mechanism allows". > > Section 1, 5th para, 2nd sentence: "will continued to be" change continued to continue. Yeah, these make sense. Best Regards, Alexey, as the document shepherd. From wmills@yahoo-inc.com Thu Dec 1 08:36:37 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 4696821F9134 for ; Thu, 1 Dec 2011 08:36:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.498 X-Spam-Level: X-Spam-Status: No, score=-17.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 rzeH1HQFURq5 for ; Thu, 1 Dec 2011 08:36:36 -0800 (PST) Received: from nm16-vm0.bullet.mail.ac4.yahoo.com (nm16-vm0.bullet.mail.ac4.yahoo.com [98.139.52.238]) by ietfa.amsl.com (Postfix) with SMTP id ABE8711E827E for ; Thu, 1 Dec 2011 08:36:20 -0800 (PST) Received: from [98.139.52.197] by nm16.bullet.mail.ac4.yahoo.com with NNFMP; 01 Dec 2011 16:36:14 -0000 Received: from [98.139.52.138] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 01 Dec 2011 16:36:14 -0000 Received: from [127.0.0.1] by omp1021.mail.ac4.yahoo.com with NNFMP; 01 Dec 2011 16:36:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 308429.22732.bm@omp1021.mail.ac4.yahoo.com Received: (qmail 98946 invoked by uid 60001); 1 Dec 2011 16:36:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1322757373; bh=CuKY1Y0Wtx36D8p0b8+SEvXb6DHTvWFgOji9AUGGUwI=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aaxyGwttkRVcT3gGj1eVH5SYadMdB1xl8y3xAdB9ZikDf0bW9mX9yEuFxClFRB/jNw464desDQMI5F33xzF8nkQWqE3GNSMsk5d49jsjXuakGHH/Jn/W565Lj3fmFauQp7hAF10gL6ZNGUqB+hLEi9MkDMxvNfnNMnkT18mYmrs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MyMqvxvjlqqbHkdIk47iVj2qTAJKKsDIj5Uct8xYtYUhW7OfQ10zy38Nz7fAvDd0+KZPoFqr1bwEzCjs6sxIfzrIfiAYgs5XT4nnCpgdZetlECixUfWwuX9Q3cUqRz0wwGd6kQjOspJMIe/UHowTreVy9tIPg4/AsD4FfHHPgNw=; X-YMail-OSG: 7yU1PX0VM1nQMlLYTeUFCikj_dNT3ofW2KyOsQ9W86G6K0Z BceIrsfkHZsivHiShmnwIpUQXiWkOVPjv6lLziHT3l4Sp7gJcV1OHW0KRSNQ WGoAFPajw6UPeghza3vOQc7EEkE62Ghs.uxWlidNIFRil156wNWXwUCqg2mk oJthMPv7woezrQ84D5ljQ3XHCjH1ZPy050hpXZv3MrcDmGUst0RLpnkAIOtj 4dXLnS_ExMW2JrfC0iFn9wrr97gGX_c4_uEUOAE34O11HSaevKrMpxciiJ_c .yqr_4VIqIml0qJkWnR_izbDtj9C7XCfLy1IGe5xw3D8HIqssTvmwmPV3SQ1 ApiUx6ZOkX_ZRpHu0NZv3K_gv8bBtO0cqD3IVVSOjgHTrKGqbduGFz16BLg_ _FqYeIqWVc4HfUQ-- Received: from [99.31.212.42] by web31802.mail.mud.yahoo.com via HTTP; Thu, 01 Dec 2011 08:36:13 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <1322547891.26139.YahooMailNeo@web31812.mail.mud.yahoo.com> Message-ID: <1322757373.30894.YahooMailNeo@web31802.mail.mud.yahoo.com> Date: Thu, 1 Dec 2011 08:36:13 -0800 (PST) From: William Mills To: William Mills , "apps-discuss@ietf.org" , "draft-ietf-kitten-sasl-openid.all@tools.ietf.org" In-Reply-To: <1322547891.26139.YahooMailNeo@web31812.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1036955950-1173862516-1322757373=:30894" Cc: "kitten@ietf.org" , "iesg@ietf.org" Subject: Re: [kitten] [APPS-REVIEW] review of draft-ietf-kitten-sasl-openid-07 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 16:36:37 -0000 ---1036955950-1173862516-1322757373=:30894 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I should have put a disclaimer in the review.=A0 My weakest subject in this= review is the GSS-API bridge, it looked right to me but I'm in no way auth= oritative there. I know Hannes and Eliot are strong there though.=0A=0A-bil= l=0A=0A=0A=0A________________________________=0A From: William Mills =0ATo: "apps-discuss@ietf.org" ; "dr= aft-ietf-kitten-sasl-openid.all@tools.ietf.org" =0ACc: "kitten@ietf.org" ; "iesg@i= etf.org" =0ASent: Monday, November 28, 2011 10:24 PM=0ASubj= ect: [kitten] [APPS-REVIEW] review of draft-ietf-kitten-sasl-openid-07=0A = =0AI have been selected as the Applications Area Review Team reviewer for t= his draft (for background on apps-review, please see http://www.apps.ietf.o= rg/content/applications-area-review-team). =0A=0APlease resolve these comme= nts along with any other Last Call comments you may receive. Please wait fo= r direction from your document shepherd or AD before posting a new version = of the draft.=0A=0ADocument: draft-ietf-kitten-sasl-openid-07=0AReviewer: W= illiam J. Mills=0AReview Date: November 28, 2011=0AIETF Last Call Date:=A0 = October 25, 2011=0A=0AReview Summary:=0A=0AThis draft is almost ready for p= ublication as a Proposed Standard, but should address the three major issue= s below before proceeding.=A0 Some minor issues and nits are also noted.=0A= =0ADocument Summary:=0A=0AThis document defines a pure SASL mechanism for O= penID, but it conforms to the new bridge between SASL and the GSS-API calle= d GS2 [RFC5801], so it defines both a SASL and a GSS-API mechanism.=0A.=0A= =0AMajor Issues:=0A=0ASection=A0 1.2.=A0=A0Applicability:=A0 This section r= equires TLS but channel binding is not supported by the mechanism.=A0 OpenI= D itself does not require TLS for client to relying party interactions, as = integrity can be assured with a MAC signature and replayability is dealt wi= th in the OpenID nonce.=A0 Requiring TLS does not appear to be based on the= underlying security profile of OpenID.=A0 If TLS is ot be required channel= binding should be supported.=A0 If TLS is not required then there is the p= ossibility of a DOS against the return_to entrypoint returned to the user, = sending a false failure message.=0A=0A=0ASection 3.2 Authentication Request= :=A0 In the second full paragraph defining transaction id, the language her= e probably isn't strong enough.=A0=A0=A0 What it says now is =0A=0A=A0=A0 T= he form of this transaction is left to the RP to decide, but =0A=A0=A0 SHOU= LD be large enough to be resistant to being guessed or attacked.=0A=0A(Nit:= At the very least "transaction" needs to be "transaction id") I think it w= ould be better if the current text is replaced with=0A=0A=A0=A0 The form of= this transaction id is left to the implementer, but it=0A=A0=A0 MUST be re= sistant to being guessed or attacked.=0A=0AI think MUST is justified here b= ecause the RP is possibly open to a DOS if the value is guessable.=A0 A par= agraph in the security considerations section might be warranted to talk ab= out how to pick good unguessable values, although this has been done many t= imes in many different specs.=A0 Side comment: maybe we need an RFC just fo= r this and then everyone can cite it.=0A=0A3.3.=A0=A0Server Response=0A=0AT= he problem I see here is that the result sent to the server that is "used t= o set state in the server accordingly" is not guaranteed to provide a usern= ame=A0 that will be useful to the SASL endpoint.=A0 The RP might get a full= email address, or might get a bare username.=A0 In the case of an IMAP ser= ver supporting multiple domains this may be significant.=A0 The spec really= should define how the SASL identities are determined from the response fro= m the OP.=0A=0AIt's possible that this could be solved by moving 6.1 and ma= king it 3.3.1.=A0 Identity mapping seems to fit better here than in securit= y considerations.=0A=0A=0AMinor issues:=0A=0AUser confusion on names: The p= roblem I see is one of confusion for the user of an OpenID enabled SASL cli= ent for Mail.=A0 Some endpoint will need to be given usrename, some will be= given an dOpenID endpoint.=A0 Clarifying language might be useful to guide= the client implementer.=A0 Is there a disocvery method that the client can= use ot go from a username/domain to the OpenID endpoint ot send to the RP?= =0A=0AMore examples:=A0 I'd prefer to see an example of a failure flow incl= uded.=A0 I tend to like examples though, and find them helpful in parsing t= he normative text.=0A=0A3.3.=A0=A0Server Response & 3.4.=A0=A0Error Handlin= g & 5. Example=0A=0AThere's an inconsistency here I think could be better.= =A0=A0In the Exmaple we have a success case where the client returns and em= pty client message in order to prompt the server to finalize the SASL negot= iation.=A0 In the error handling case we have an explicit continuation from= the client sending "=3D".=A0=A0 Is the "=3D" sign after the error return a= ctually required or can this simply be an empty client message.=A0 This mea= ns if the client knows the negotiation is complete and has not gotten a res= ult it just always sends the empty message.=0A=0A=0ANits:=0A=0ASection 1, 4= th para, first sentence:=A0 I would change "As currently envisioned, this m= echanism is to allow" to "This mechanism allows".=0A=0ASection 1, 5th para,= 2nd sentence: "will continued to be" change continued to continue.=0A_____= __________________________________________=0AKitten mailing list=0AKitten@i= etf.org=0Ahttps://www.ietf.org/mailman/listinfo/kitten ---1036955950-1173862516-1322757373=:30894 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
I should have put a disclaimer in the review.  My weakest subject in= this review is the GSS-API bridge, it looked right to me but I'm in no way= authoritative there. I know Hannes and Eliot are strong there though.

-bill
<= br>
From:= William Mills <wmills@yahoo-inc.com>
To: "apps-discuss@ietf.org" <apps-discuss@ietf.org= >; "draft-ietf-kitten-sasl-openid.all@tools.ietf.org" <draft-ietf-kitten-sasl-openid.all@tools.ietf.org>
Cc: "kitten@ietf.org" <kitten@ietf.o= rg>; "iesg@ietf.org" <iesg@ietf.org>
Sent: Monday, November 28, 2011 10:24 PM
Subject: [kitten] [APPS-REVIEW]= review of draft-ietf-kitten-sasl-openid-07
=0AI have been = selected as the Applications Area Review Team reviewer for this draft (for = background on apps-review, please see http://www.apps.ietf.org/content/appl= ications-area-review-team).

Please resolve these comments along wit= h any other Last Call comments you may receive. Please wait for direction f= rom your document shepherd or AD before posting a new version of the draft.=

Document: draft-ietf-kitten-sasl-openid-07
Reviewer: William J. = Mills
Review Date: November 28, 2011
IETF Last Call Date:  Octob= er 25, 2011

Review Summary:

This draft is almost ready for pu= blication as a Proposed Standard, but should address the three major issues= below before proceeding.  Some minor issues and nits are also noted.<= br>
Document Summary:

This document defines a pure SASL mechanism= for OpenID, but it conforms to the new bridge between SASL and the GSS-API= called GS2 [RFC5801], so it defines both a SASL and a GSS-API mechanism.
.

Major Issues:

Section  1.2.&nbs= p; Applicability:  This section requires TLS but channel binding = is not supported by the mechanism.  OpenID itself does not require TLS= for client to relying party interactions, as integrity can be assured with= a MAC signature and replayability is dealt with in the OpenID nonce. = Requiring TLS does not appear to be based on the underlying security profi= le of OpenID.  If TLS is ot be required channel binding should be supp= orted.  If TLS is not required then there is the possibility of a DOS = against the return_to entrypoint returned to the user, sending a false fail= ure message.


Section 3.2 Authentication Request:  In the se= cond full paragraph defining transaction id, the language here probably isn= 't strong enough.    What it says now is

  = ; The form of this transaction is left to the RP to decide, but
   SHOULD be large enough to be resistant to being guessed o= r attacked.

(Nit: At the very least "transaction" needs to be "trans= action id") I think it would be better if the current text is replaced with=

   The form of this transaction id is left to the impleme= nter, but it
   MUST be resistant to being guessed or attacked= .

I think MUST is justified here because the RP is possibly open to = a DOS if the value is guessable.  A paragraph in the security consider= ations section might be warranted to talk about how to pick good unguessabl= e values, although this has been done many times in many different specs.&n= bsp; Side comment: maybe we need an RFC just for this and then everyone can= cite it.

3.3.  Server Response

The problem I see h= ere is that the result sent to the server that is "used to set state in the= server accordingly" is not guaranteed to provide a username  that will be useful to the SASL endpoint.  The RP might get a full em= ail address, or might get a bare username.  In the case of an IMAP ser= ver supporting multiple domains this may be significant.  The spec rea= lly should define how the SASL identities are determined from the response = from the OP.

It's possible that this could be solved by moving 6.1 a= nd making it 3.3.1.  Identity mapping seems to fit better here than in= security considerations.


Minor issues:

User confusion on= names: The problem I see is one of confusion for the user of an OpenID ena= bled SASL client for Mail.  Some endpoint will need to be given usrena= me, some will be given an dOpenID endpoint.  Clarifying language might= be useful to guide the client implementer.  Is there a disocvery meth= od that the client can use ot go from a username/domain to the OpenID endpo= int ot send to the RP?

More examples:  I'd prefer to see an example of a failure flow included.  I tend to like examples thoug= h, and find them helpful in parsing the normative text.

3.3. &n= bsp;Server Response & 3.4.  Error Handling & 5. Example
There's an inconsistency here I think could be better.  In = the Exmaple we have a success case where the client returns and empty clien= t message in order to prompt the server to finalize the SASL negotiation.&n= bsp; In the error handling case we have an explicit continuation from the c= lient sending "=3D".   Is the "=3D" sign after the error return a= ctually required or can this simply be an empty client message.  This = means if the client knows the negotiation is complete and has not gotten a = result it just always sends the empty message.


Nits:

Sect= ion 1, 4th para, first sentence:  I would change "As currently envisio= ned, this mechanism is to allow" to "This mechanism allows".

Section 1, 5th para, 2nd sentence: "will continued to be" = change continued to continue.
__________________________________________= _____
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mai= lman/listinfo/kitten


---1036955950-1173862516-1322757373=:30894-- From nico@cryptonector.com Thu Dec 1 10:01: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 2A85A11E8266 for ; Thu, 1 Dec 2011 10:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=0.260, 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 6VmYRWg+kswR for ; Thu, 1 Dec 2011 10:01:22 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 95F221F0C7B for ; Thu, 1 Dec 2011 10:01:19 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id F139D26C075 for ; Thu, 1 Dec 2011 10:01:18 -0800 (PST) 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=oR6Vdpidl44xyNmm/cofl bpKamKJN73KE7hwLBDyJUlfrqhgu5Mh66HpuaRxgPuHL4ZMbywYYh4f9L7DUGQzf HcX/s048uCWcfvS0iEz+c8rCLFnUKT5z6OL/PqqzUQIEDI9di7X8bn0DBxvXB5Y5 zAf2Ef1jirgjggtyXAPJpE= 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=m/cBvxq0br4h1LiZNyFd tusD800=; b=sN5kaM3IJEE7oTehmOuHwi8CjjGroqkmc8jGJDIvi+42LYWP0u2S SBo9a8Quj4cHPuHNpDKcsQcADc+g5DEGBBuaA0o2yL7qzn66O4C9hpeSTeNZdmxv Dt1cHxXTvD2S95iGTwpA1sa0FGGMVgUQMQLfaJ0G63DN/BPnB7Qry3E= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id D8A0326C06F for ; Thu, 1 Dec 2011 10:01:18 -0800 (PST) Received: by dadv40 with SMTP id v40so821397dad.31 for ; Thu, 01 Dec 2011 10:01:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.36.8 with SMTP id m8mr6632611pbj.128.1322762478380; Thu, 01 Dec 2011 10:01:18 -0800 (PST) Received: by 10.68.73.4 with HTTP; Thu, 1 Dec 2011 10:01:18 -0800 (PST) In-Reply-To: <4EC32551.20906@mnt.se> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> Date: Thu, 1 Dec 2011 12:01:18 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 18:01:23 -0000 Sam, Shawn, and i met today for about 50 minutes and we've reached a conclusion. Below are my notes; actual I-D text to follow at some point when I have time to write it up. 1) All name attributes -or, rather, name attribute namespaces- are in fact locally critical for the mechanisms that must carry them. 2) We may want to (IMO should want to) define a namespace of attributes that are entirely application-specific. For example: local process privileges. 3) When GSS_Set_name_attribute() is called on an MN the function MUST fail if the MN's mechanism failes to understand the given name attribute's semantics. 4) When GSS_Set_name_attribute() is called on a non-MN the function MUST NOT fail on account of the name attribute not being known by some mechanisms but MAY fail if the name attribute is not known by any mechanisms. A subsequent call to GSS_Acquire_cred() with a NAME that has name attributes will result in a CREDENTIAL HANDLE for the subset of desired_mechs which understand *all* of the name attributes that were set. Note that (4) implies that it's not easy to determine which mechanisms don't support a given name attribute, but it makes the common case where an application wants to negotiate mechanisms easy: Import_name(), Set_name_attribute(), Acquire_cred(), Inquire_cred(), negotiate mechanisms, then Init_sec_context(). (This applies to SSHv2, for example, but also to SPNEGO.) 5) We will probably want a new function by which to ask which mechanisms understand a given name attribute, and another function by which to ask what name attribute prefixes a given mechanism supports. We should define these two functions in a new I-D that also takes care of inquiry of authenticated name attribute issuer name. Nico -- From wmills@yahoo-inc.com Thu Dec 1 21:21:06 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 0C1F421F8B45 for ; Thu, 1 Dec 2011 21:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.538 X-Spam-Level: X-Spam-Status: No, score=-17.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] 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 BcZZtAg2NAJK for ; Thu, 1 Dec 2011 21:21:04 -0800 (PST) Received: from nm8.bullet.mail.ac4.yahoo.com (nm8.bullet.mail.ac4.yahoo.com [98.139.52.205]) by ietfa.amsl.com (Postfix) with SMTP id AB36311E80AF for ; Thu, 1 Dec 2011 21:20:02 -0800 (PST) Received: from [98.139.52.192] by nm8.bullet.mail.ac4.yahoo.com with NNFMP; 02 Dec 2011 05:19:59 -0000 Received: from [98.139.52.153] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 02 Dec 2011 05:19:59 -0000 Received: from [127.0.0.1] by omp1036.mail.ac4.yahoo.com with NNFMP; 02 Dec 2011 05:19:59 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 99592.36327.bm@omp1036.mail.ac4.yahoo.com Received: (qmail 90137 invoked by uid 60001); 2 Dec 2011 05:19:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1322803198; bh=WcDZl/+nQp/gJi9vL37FQRIPHBQS9k5JnHu0siXzB6s=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=XaTWdxN2paoaUnML/F37X750bnlYefH/ucrJ+tHud8qsF9lmvV1KQ4IXtY1+yLvFI2YYF92B2stTUdyyvVWK2fwO7Xdrv0R9Dxl2oAznakY7sNex+HQSBQf1OBapgbbjDP/6Qgs4gdeHhlJotOpAA37e38MufFdrU8br9XPYS+s= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oZBgGwC/u7qwuo40crZ/RYr8CuwQu2OPD/siOS4sUy6Ic9/JSYJF/jXs/aUhWjm7vNHE/ZlrYzaPCBhBs6q2DshVKSb2Tw6cRZFuAWFdzdDurLwn9uZsAe0RSiv+365BySTMTXz7niYBLzBf3D+f18ORwBVKKu2/L+AjaUljMXM=; X-YMail-OSG: _gTSY0AVM1kGkDtSj.Ne1JDBWxrNBYDihXJQoiv6rw6JUT5 1g0h_a0ddyImb55L.jOAh9rlAOQSIZakxa5PSaTF3M9NNAJaP0z8ka28gEsP mkbEMGsux_KVCt_FhuniQxxmH_0AtoK94XLjGicm4YO4s58FNsfTH2FSGqnY BADmQS9Y6I59Y6GWGULi2ApAXquZHyGI._g52mTsZ3NXEjmOPduLnZ_JjotK btE_f69pAnKlsbz_TChzvEClspGHtzjEIcLYUUPhbdKoPDanb4wxR505Zd9f nWwH7MLeDaE76H62vUq_9xGxU_jUFrkngYOtx.u3ZqYOb_yYubfSotJRr8uO wwqN2U1ZtsE7YUoXl.O2CHPXrLDNl61olLu5Vi.Vba_rXzDyBWFVBBKcdGas 18IiEXtKOs22FDwJa3G2ibJIkfVqoS1tpHhoQwCRMXWs.EO0l6qETYorugdJ 9LmfNKIpj.Nud4k5wE8UrczksuPzPcZx2qCo- Received: from [99.31.212.42] by web31809.mail.mud.yahoo.com via HTTP; Thu, 01 Dec 2011 21:19:58 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <4ED7F0D8.6010703@cs.tcd.ie> <17870960-E739-40BC-B2C1-EB93507F34EA@oracle.com> <4ED8288E.90101@cs.tcd.ie> <1322790633.20785.YahooMailNeo@web31816.mail.mud.yahoo.com> <4ED82F99.9030400@cs.tcd.ie> <1322791836.55576.YahooMailNeo@web31806.mail.mud.yahoo.com> Message-ID: <1322803198.38192.YahooMailNeo@web31809.mail.mud.yahoo.com> Date: Thu, 1 Dec 2011 21:19:58 -0800 (PST) From: William Mills To: Stephen Farrell , "kitten@ietf.org" In-Reply-To: <1322791836.55576.YahooMailNeo@web31806.mail.mud.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [kitten] [OAUTH-WG] Mandatory-to-implement token type X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2011 05:21:06 -0000 =0A=0A(Adding kitten@ in, hit "r" instead of "a".... and to extend my previ= ous thought)=0A=0AIf we make a weak token mandatory, then it has to actuall= y work right?=A0=A0 =0A=0AI think it's a mistake to put something in the sp= ec that we *know* some use cases will be forced to ignore or be non-complia= nt on.=0A=0AI'm leaning toward a paragraph in the spec that talks about the= interop problems, leaves it intentionally unsolved, and foreshadows a "bis= " version.=0A=0AI'd actually also be happy with a MTI token set if we can l= imit the MUST to implementations meant for general purpose use on the inter= net or by general purpose clients, and I'd go so far as to say we should ha= ve both Bearer and MAC for general use.=A0 This gives us profiles that work= well in both in cleartext and secure channels.=A0=A0 This would leave cust= om clients and special purpose applications free to do what they will do an= yway.=0A=0A-bill=0A=0A=0A=0A=0A________________________________=0AFrom: Ste= phen Farrell =0ATo: William Mills =0ACc: Phil Hunt ; Barry Leiba ; oauth WG =0ASent: Thursday, December 1, 2011= 5:53 PM=0ASubject: Re: [OAUTH-WG] Mandatory-to-implement token type=0A=0A= =0A=0AOn 12/02/2011 01:50 AM, William Mills wrote:=0A> If we MTI a "weaker"= token type (arguably Bearer falls here) that means=0A> the spec will be in= appropriate in higher security requirement situations, those folks walk awa= y.=0A=0ADisagree. People who need more can specify more.=0A=0AThe base spec= not having an MTI doesn't help them at all since=0Aabsent any MTI it'd cle= arly not be appropriate for higher=0Asecurity environments to use your term= .=0A=0A> If we MTI something like SAML it makes the folks that want a light= weight Bearer token solution walk away.=0A=0AI would agree that SAML might= be too heavy. If the WG do=0Apick an MTI then it does need to be relativel= y simple.=0A=0AS.=0A=0A>=0A>=0A> ________________________________=0A>=A0=A0= =A0From: Stephen Farrell=0A> To: Phil Hunt=0A> Cc: Barry Leiba; oauth WG=0A> Sent: Thursday, December 1, 2011 5:23 PM=0A> Subject: Re: = [OAUTH-WG] Mandatory-to-implement token type=0A>=0A>=0A> On 12/02/2011 12:2= 3 AM, Phil Hunt wrote:=0A>> Because different token types have distinct adv= antages in different scenarios, choosing a single MTI would be difficult.= =0A>=0A> I just don't get that. Why is it somehow difficult to pick one=0A>= but at the same time easy to implement any?=0A>=0A> =0A>=0A> __= ______________________________=0A>=A0=A0=A0From: Stephen Farrell=0A> To: Phil Hunt=0A> Cc: Barry Leib= a; oauth WG=0A> Sent: Thursday, De= cember 1, 2011 5:23 PM=0A> Subject: Re: [OAUTH-WG] Mandatory-to-implement t= oken type=0A>=0A>=0A>=0A> On 12/02/2011 12:23 AM, Phil Hunt wrote:=0A>> Bec= ause different token types have distinct advantages in different scenarios,= choosing a single MTI would be difficult.=0A>=0A> I just don't get that. W= hy is it somehow difficult to pick one=0A> but at the same time easy to imp= lement any?=0A>=0A>> E.g. MAC tokens work well for non-TLS protected=0Areso= urces.=A0 Bearer tokens in contrast are easier to use, but require TLS prot= ected service to avoid theft-of-credential.=0A>=0A> So picking is a nuisanc= e sure. But it helps interop.=0A>=0A>> Even at this level, site security po= licies will simply override=0A> whatever is stated in the specification and= choose one type only.=0A>=0A> Yes, but those policies will be affected by = what's available in=0A> the running code. I'd like if what's available was = known when=0A> the coder says "we implement RFC"=0A>=0A>> Having multi= ple MTIs, suggests choice and that causes other problems. What happens when= a client wants to use a bearer token over an unprotected connection? How d= oes the client discover what can be used and when?=0A>=0A> Having no MTI ca= uses identical problems.=0A>=0A>> The approach we have now where the Token = specification defines interop requirements and a profile for=0Ause with OAu= th2 seems to be a good way to go.=0A>=0A> We disagree about that I guess. T= o me it seems a peculiar way to go=0A> unless one assumes that coders write= code that's specific to a specific=0A> service provider.=0A>=0A> S.=0A>=0A= >> Phil=0A>>=0A>> @independentid=0A>> www.independentid.com=0A>> phil.hunt@= oracle.com=0A>>=0A>>=0A>>=0A>>=0A>>=0A>> On 2011-12-01, at 1:25 PM, Stephen= Farrell wrote:=0A>>=0A>>>=0A>>> Barry, all,=0A>>>=0A>>> First, apologies f= or being so slow responding, various=0A>>> travels got in the way. I hope w= e can quickly resolve this now.=0A>>>=0A>>> Bit of process first: at the me= eting we discussed this and at=0Athe=0A>>> end of that discussion, there we= re quite a few more folks for the=0A>>> "pick one" position. People who fav= our that outcome and really=0A>>> care about that need to speak up on the l= ist, since the list=0A>>> consensus trumps the sense of the room in the cha= irs' evaluation=0A>>> of the WG consensus.=0A>>>=0A>>> Second, at the meeti= ng I said that I'd like to see either MAC or=0A>>> bearer picked as MTI, an= d if not, that I want the draft to say=0A>>> why its ok to have no MTI toke= n type. So the WG either need to=0A>>> pick one, or else explicitly and con= vincingly justify not=0A>>> picking one. That's the "firm" AD position to w= hich Barry=0A>>> referred. (I didn't properly call out the "if not" part of= =0A>>> that in my AD review, sorry.)=0A>>>=0A>>> My own argument for pickin= g one is simple: if every=0Arelevant=0A>>> piece of code has to know how to= handle one then it becomes=0A>>> easier to get interop. If everyone decide= s for themselves=0A>>> then interop is less likely since there are currentl= y two=0A>>> choices and may be more in future.=0A>>>=0A>>> I do realise tha= t the background here and current practice=0A>>> is that code tends to be w= ritten that is specific to a=0A>>> resource server (or however that's best = phrased) but that's=0A>>> maybe where the IETF differs from the community t= hat produced=0A>>> OAuth - here we want two independent implementers who've= =0A>>> never talked to produce code that interops even so.=0A>>>=0A>>> I al= so realise that that's not the full story for getting=0A>>> interop with OA= uth and that more is needed. However, this=0A>>> aspect is otherwise fully = specified and so I=0Adon't buy the=0A>>> argument that this isn't worth doi= ng just because we don't=0A>>> have the full registration story etc. figure= d out. If we don't=0A>>> sort this out now, then later specs will have to u= pdate=0A>>> this one in this respect. possibly making existing code=0A>>> "= non-compliant" in some sense, so just going ahead and doing=0A>>> it right = now is better.=0A>>>=0A>>> So, pick one (my strong personal preference) or = establish and=0A>>> document why you're not picking one seem to me to be th= e choices=0A>>> available.=0A>>>=0A>>> Regards,=0A>>> Stephen.=0A>>>=0A>>>= =0A>>> On 11/17/2011 08:28 AM, Barry Leiba wrote:=0A>>>> Stephen, as AD, br= ought up the question of mandatory-to-implement=0A>>>> token types, in the = IETF 82 meeting.=A0 There was some=0Aextended=0A>>>> discussion on the poin= t:=0A>>>>=0A>>>> - Stephen is firm in his belief that it's necessary for=0A= >>>> interoperability.=A0 He notes that mandatory to *implement* is not the= =0A>>>> same as mandatory to *use*.=0A>>>> - Several participants believe t= hat without a mechanism for requesting=0A>>>> or negotiating a token type, = there is no value in having any type be=0A>>>> mandatory to implement.=0A>>= >>=0A>>>> Stephen is happy to continue the discussion on the list, and make= his=0A>>>> point clear.=A0 In any case, there was clear consensus in the r= oom that=0A>>>> we *should* specify a mandatory-to-implement type, and that= that type=0A>>>> be bearer tokens.=A0 This would be specified in the base = document, and=0A>>>> would make a normative reference from the=0Abase doc t= o the bearer token=0A>>>> doc.=0A>>>>=0A>>>> We need to confirm that consen= sus on the mailing list, so this starts=0A>>>> the discussion.=A0 Let's wor= k on resolving this over the next week or=0A>>>> so, and moving forward:=0A= >>>>=0A>>>> 1. Should we specify some token type as mandatory to implement?= =A0 Why=0A>>>> or why not (*briefly*)?=0A>>>>=0A>>>> 2. If we do specify on= e, which token type should it be?=0A>>>>=0A>>>> Barry, as chair=0A>>>> ____= ___________________________________________=0A>>>> OAuth mailing list=0A>>>= > OAuth@ietf.org=0A>>>> https://www.ietf.org/mailman/listinfo/oauth=0A>>>>= =0A>>> _______________________________________________=0A>>> OAuth mailing = list=0A>>> OAuth@ietf.org=0A>>> https://www.ietf.org/mailman/listinfo/oauth= =0A>>=0A>>=0A> _______________________________________________=0A> OAuth ma= iling list=0A> OAuth@ietf.org=0A> https://www.ietf.org/mailman/listinfo/oau= th From leifj@mnt.se Fri Dec 2 13:44:33 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 4B1FF1F0C78 for ; Fri, 2 Dec 2011 13:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOwHjs6aXLpf for ; Fri, 2 Dec 2011 13:44:32 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 4A2E01F0C74 for ; Fri, 2 Dec 2011 13:44:32 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB2LiKri023144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Dec 2011 22:44:25 +0100 (CET) Message-ID: <4ED946B4.1070205@mnt.se> Date: Fri, 02 Dec 2011 22:44:20 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 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, 02 Dec 2011 21:44:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/01/2011 07:01 PM, Nico Williams wrote: > Sam, Shawn, and i met today for about 50 minutes and we've reached > a conclusion. Below are my notes; actual I-D text to follow at > some point when I have time to write it up. OK I guess we'll have a consensus discussion when you send that then. Cheers Leif > > 1) All name attributes -or, rather, name attribute namespaces- are > in fact locally critical for the mechanisms that must carry them. > > 2) We may want to (IMO should want to) define a namespace of > attributes that are entirely application-specific. For example: > local process privileges. > > 3) When GSS_Set_name_attribute() is called on an MN the function > MUST fail if the MN's mechanism failes to understand the given > name attribute's semantics. > > 4) When GSS_Set_name_attribute() is called on a non-MN the > function MUST NOT fail on account of the name attribute not being > known by some mechanisms but MAY fail if the name attribute is not > known by any mechanisms. A subsequent call to GSS_Acquire_cred() > with a NAME that has name attributes will result in a CREDENTIAL > HANDLE for the subset of desired_mechs which understand *all* of > the name attributes that were set. > > Note that (4) implies that it's not easy to determine which > mechanisms don't support a given name attribute, but it makes the > common case where an application wants to negotiate mechanisms > easy: Import_name(), Set_name_attribute(), Acquire_cred(), > Inquire_cred(), negotiate mechanisms, then Init_sec_context(). > (This applies to SSHv2, for example, but also to SPNEGO.) > > 5) We will probably want a new function by which to ask which > mechanisms understand a given name attribute, and another function > by which to ask what name attribute prefixes a given mechanism > supports. We should define these two functions in a new I-D that > also takes care of inquiry of authenticated name attribute issuer > name. > > Nico -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7ZRrQACgkQ8Jx8FtbMZndUPgCghJ9fBssgKWAXGVyVtkksk8cx gGoAn3+LCLxVnshpYUzeIzbG6MM/iK/A =Mu3w -----END PGP SIGNATURE----- From nico@cryptonector.com Fri Dec 2 14:08:33 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 6775F21F8BD5 for ; Fri, 2 Dec 2011 14:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.76 X-Spam-Level: X-Spam-Status: No, score=-1.76 tagged_above=-999 required=5 tests=[AWL=0.217, 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 6yz1ES5lp2nq for ; Fri, 2 Dec 2011 14:08:32 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id E8B1F21F8BCB for ; Fri, 2 Dec 2011 14:08:32 -0800 (PST) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id A365726C069 for ; Fri, 2 Dec 2011 14:08:32 -0800 (PST) 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=JvYIgCM8rgz00hFEhcTokUyOf+Ea0nxWeoiUrUtJtm1h zEg3vESGGEZTKE0gnhmfJadA1gkpdaaLXq437wBnE0Bx9Ppg0FyoRyug8qCCPMBE WdHNb9vE5SMJd85CwpRj/HB7W+s6VK2lFlAT8tVTWuycjgeM3EmnNIDRO9JCRTc= 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=zKo/3n4zLUX4UhELxMWsdcSqdHQ=; b=TEjT7EKmImf LCpeI2k50GK5ETQ4ptKjUy/K/c40nJwVkzzZ0LxVMRxIjnbDP92Bf1vcKR8TBQGP 75m9w/LhJOB5UIQdjg1SHMXtDthPW5OAcm4/nfaZlBr/ZVoAnlMat6CoiPOzxIca ajX/iodIfOZ332yytWWM/NGhs3aVGWwA= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 89D7F26C064 for ; Fri, 2 Dec 2011 14:08:32 -0800 (PST) Received: by dadv40 with SMTP id v40so2567854dad.31 for ; Fri, 02 Dec 2011 14:08:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.12.7 with SMTP id u7mr234976pbb.77.1322863712016; Fri, 02 Dec 2011 14:08:32 -0800 (PST) Received: by 10.68.73.4 with HTTP; Fri, 2 Dec 2011 14:08:31 -0800 (PST) In-Reply-To: <4ED946B4.1070205@mnt.se> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4ED946B4.1070205@mnt.se> Date: Fri, 2 Dec 2011 16:08:31 -0600 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] new text for section 7.6 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, 02 Dec 2011 22:08:33 -0000 On Fri, Dec 2, 2011 at 3:44 PM, Leif Johansson wrote: > On 12/01/2011 07:01 PM, Nico Williams wrote: >> Sam, Shawn, and i met today for about 50 minutes and we've reached >> a conclusion. =C2=A0Below are my notes; actual I-D text to follow at >> some point when I have time to write it up. > > OK I guess we'll have a consensus discussion when you send that then. But you can give me a hint as to whether you disagree, no? If not, why not= ? From nico@cryptonector.com Fri Dec 2 19:48:29 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 A73BA21F8B1E for ; Fri, 2 Dec 2011 19:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 r2+g28J7xqYr for ; Fri, 2 Dec 2011 19:48:28 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id E235921F8B1D for ; Fri, 2 Dec 2011 19:48:28 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 92626286062 for ; Fri, 2 Dec 2011 19:48:28 -0800 (PST) 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=QdmmesNi6+tz0so14UCcK 0eaBC6LM16OhP2iFlbfC3V+lTbC2fi6snBIy2PaF7UPwsSpLfacfIV1TCbVxLR8r ibg4hV+uLjVGqgYRXfr65Wk3vbTtQhD7GpsEsEbQqJtMiVL3Ynoe0ZaI7bC2NyBO Rbjd2Rdo19GD5Ev6AUugjM= 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=ZeBYNhBymypKXE+D1uN8 WvIDbdw=; b=jEexzeyhgLEFQdD2YTQSadudcqn08wim6UrOTJ1Mpnqd0qZtqYSs TKt5lYSBZul9JyDuvD7lSB0o7nnWyRAguX6MC4kQ03vPJqk/o1wL5K3R+EFv7nQF 71nzs+KoQO3Zw9SSWnYUWy32u66+iNExnCHOoUcPY21LHSsIk7mYVpA= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 79AC6286060 for ; Fri, 2 Dec 2011 19:48:28 -0800 (PST) Received: by dadv40 with SMTP id v40so2857455dad.31 for ; Fri, 02 Dec 2011 19:48:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.199.6 with SMTP id jg6mr2291925pbc.26.1322884108016; Fri, 02 Dec 2011 19:48:28 -0800 (PST) Received: by 10.68.73.4 with HTTP; Fri, 2 Dec 2011 19:48:27 -0800 (PST) Received: by 10.68.73.4 with HTTP; Fri, 2 Dec 2011 19:48:27 -0800 (PST) In-Reply-To: References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> Date: Fri, 2 Dec 2011 21:48:27 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: multipart/alternative; boundary=e89a8f642d16565b6504b327f596 Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 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, 03 Dec 2011 03:48:29 -0000 --e89a8f642d16565b6504b327f596 Content-Type: text/plain; charset=UTF-8 Proposed text for section 7.6: When the given name object is an MN this function MUST fail if the mechanism for which the name is an MN does recognize the attribute name or the namespace it belomgs to. This is because name attributes generally have some semantics that mechanisms must understand. On the other hand, when the given name is not an MN this function MUSTNOT fail -- instead credential acquisition with the resulting name MUST fail for mechanisms that don't understand any one or more name attributes set with this function. Applications may wish to use a non-MN, then acquire and use credentials with that name as the desired name. The acquired credentials will have elements only for the mechanisms that can carry the name attributes set on the name. In the future we may add an attribute namespace for attributes that only have application-specific semantics. But note that mechanisms will still need to know how to transport such attributes. We may also wish to add functions by which to inquire whether a mechanism(s) understands a given attribute name or namespace, and to list which attributes or attribute namespaces a mechanism understands. Note there's a reference to name attr as OID left in section 7.6. Nico -- --e89a8f642d16565b6504b327f596 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Proposed text for section 7.6:

=C2=A0=C2=A0 When the given name object is an MN this function MUST fail= if the
=C2=A0=C2=A0 mechanism for which the name is an MN does recognize the
=C2=A0=C2=A0 attribute name or the namespace it belomgs to.=C2=A0 This is b= ecause
=C2=A0=C2=A0 name attributes generally have some semantics that
=C2=A0=C2=A0 mechanisms must understand.

=C2=A0=C2=A0 On the other hand, when the given name is not an MN this =C2=A0=C2=A0 function MUSTNOT fail -- instead credential acquisition with t= he
=C2=A0=C2=A0 resulting name MUST fail for mechanisms that don't
=C2=A0 understand any one or more name attributes set with this
function.=C2=A0 Applications may wish to use a non-MN, then acquire
=C2=A0=C2=A0 and use credentials with that name as the desired name.
=C2=A0=C2=A0 The acquired credentials will have elements only for the
=C2=A0=C2=A0 mechanisms that can carry the name attributes set on the name.=

=C2=A0=C2=A0 In the future we may add an attribute namespace for
=C2=A0=C2=A0 attributes that only have application-specific semantics.
=C2=A0=C2=A0 But note that mechanisms will still need to know how to
=C2=A0=C2=A0 transport such attributes.=C2=A0 We may also wish to add funct= ions
=C2=A0=C2=A0 by which to inquire whether a mechanism(s) understands a
=C2=A0=C2=A0 given attribute name or namespace, and to list which
=C2=A0=C2=A0 attributes or attribute namespaces a mechanism
=C2=A0=C2=A0 understands.

Note there's a reference to name attr as OID left in section 7.6.

Nico
--

--e89a8f642d16565b6504b327f596-- From leifj@mnt.se Sat Dec 3 03:27:15 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 904CF21F9395 for ; Sat, 3 Dec 2011 03:27:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKWch8h3JAl1 for ; Sat, 3 Dec 2011 03:27:14 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBEA21F9392 for ; Sat, 3 Dec 2011 03:27:13 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB3BQLsX021125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 3 Dec 2011 12:26:33 +0100 (CET) Message-ID: <4EDA075D.4090903@mnt.se> Date: Sat, 03 Dec 2011 12:26:21 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 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, 03 Dec 2011 11:27:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/03/2011 04:48 AM, Nico Williams wrote: > Proposed text for section 7.6: > > When the given name object is an MN this function MUST fail if the Say something specific about error return codes instead. > mechanism for which the name is an MN does recognize the attribute > name or the namespace it belomgs to. This is because name > attributes generally have some semantics that mechanisms must > understand. We don't use the term namespace anywhere else in the spec. Lets not introduce new terminology here. Same goes for 'element' further down. > > On the other hand, when the given name is not an MN this function > MUSTNOT fail -- instead credential acquisition with the resulting > name MUST fail for mechanisms that don't understand any one or more > name attributes set with this function. Applications may wish to > use a non-MN, then acquire and use credentials with that name as > the desired name. The acquired credentials will have elements only > for the mechanisms that can carry the name attributes set on the > name. I find that text extremely difficult to understand and I'd like to get some feedback from implementors saying they grok this (Luke that means you :-)) > > In the future we may add an attribute namespace for attributes that > only have application-specific semantics. But note that mechanisms > will still need to know how to transport such attributes. We may > also wish to add functions by which to inquire whether a > mechanism(s) understands a given attribute name or namespace, and > to list which attributes or attribute namespaces a mechanism > understands. That sounds like something for the list and not for the spec - at the very least is should be separated from the rest of the text. > > Note there's a reference to name attr as OID left in section 7.6. > Yeah I fixed that already. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7aB10ACgkQ8Jx8FtbMZnd8IgCeJfU0bdjnLXpMzOU291gphcnb QXMAnioVSgBk11d6BrxHb9ABveOJBiEA =HMsc -----END PGP SIGNATURE----- From ietf@augustcellars.com Sat Dec 3 14:56:58 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB2F21F93AF for ; Sat, 3 Dec 2011 14:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BEFORE=1.272, HTML_MESSAGE=0.001, 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 149IuA5on2jd for ; Sat, 3 Dec 2011 14:56:57 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id BB52E21F842D for ; Sat, 3 Dec 2011 14:56:57 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id EE6D42C9F4; Sat, 3 Dec 2011 14:56:56 -0800 (PST) From: "Jim Schaad" To: "'Nico Williams'" , "'Leif Johansson'" References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> In-Reply-To: Date: Sat, 3 Dec 2011 14:56:22 -0800 Message-ID: <007301ccb20e$ca795fa0$5f6c1ee0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0074_01CCB1CB.BC5890A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHaIP3Js/zIi2coJEq1or+wYSsaUQIwDc7wApVwEocBluANlAIcTMxvAb4AZQwBqkzVBwDVQLXkAVzkFssBb9yX7AE5Afr4Acm8pFMBBAK3PwJ/2//9lP+OW0A= Content-Language: en-us Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 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, 03 Dec 2011 22:56:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0074_01CCB1CB.BC5890A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf = Of Nico Williams Sent: Friday, December 02, 2011 7:48 PM To: Leif Johansson Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 =20 Proposed text for section 7.6: When the given name object is an MN this function MUST fail if the mechanism for which the name is an MN does recognize the attribute name or the namespace it belomgs to. This is because name attributes generally have some semantics that mechanisms must understand. On the other hand, when the given name is not an MN this function MUSTNOT fail -- instead credential acquisition with the resulting name MUST fail for mechanisms that don't understand any one or more name attributes set with this function. Applications may wish to use a non-MN, then acquire and use credentials with that name as the desired name. The acquired credentials will have elements only for the mechanisms that can carry the name attributes set on the name. I find the last sentence confusing. Specifically It appears to = contradict the MUST fail from the first sentence. This is quite likely = a shortage in my understanding. However the following might be better: The acquired credentials will only be fore mechanisms that can support = the name attributes set. In the future we may add an attribute namespace for attributes that only have application-specific semantics. But note that mechanisms will still need to know how to transport such attributes. We may also wish to add functions by which to inquire whether a mechanism(s) understands a given attribute name or namespace, and to list which attributes or attribute namespaces a mechanism understands. Note there's a reference to name attr as OID left in section 7.6. Nico --=20 ------=_NextPart_000_0074_01CCB1CB.BC5890A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

 

 

From:= = kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of = Nico Williams
Sent: Friday, December 02, 2011 7:48 = PM
To: Leif Johansson
Cc: = kitten@ietf.org
Subject: Re: [kitten] new text for section = 7.6

 

Proposed text for section = 7.6:

   When the given name object is an MN = this function MUST fail if the
   mechanism for which the = name is an MN does recognize the
   attribute name or the = namespace it belomgs to.  This is because
   name = attributes generally have some semantics that
   mechanisms = must understand.

   On the other hand, when = the given name is not an MN this
   function MUSTNOT fail = -- instead credential acquisition with the
   resulting = name MUST fail for mechanisms that don't
  understand any one or = more name attributes set with this
function.  Applications may = wish to use a non-MN, then acquire
   and use credentials = with that name as the desired name.
   The acquired = credentials will have elements only for the
   mechanisms = that can carry the name attributes set on the = name.

I find the last sentence confusing.=C2=A0 Specifically It appears to = contradict the MUST fail from the first sentence.=C2=A0 This is quite = likely a shortage in my understanding.=C2=A0 However the following might = be better:

The acquired credentials will only be fore mechanisms that can = support the name attributes set.

   In = the future we may add an attribute namespace for
   = attributes that only have application-specific = semantics.
   But note that mechanisms will still need to = know how to
   transport such attributes.  We may also = wish to add functions
   by which to inquire whether a = mechanism(s) understands a
   given attribute name or = namespace, and to list which
   attributes or attribute = namespaces a mechanism
   = understands.

Note there's a reference to name attr as = OID left in section 7.6.

Nico
-- =

------=_NextPart_000_0074_01CCB1CB.BC5890A0-- From nico@cryptonector.com Sat Dec 3 23:25: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 F402221F8797 for ; Sat, 3 Dec 2011 23:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.426 X-Spam-Level: X-Spam-Status: No, score=-0.426 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] 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 aVh-blJ+sr-o for ; Sat, 3 Dec 2011 23:25:11 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 3991721F85BB for ; Sat, 3 Dec 2011 23:25:11 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id C013A2AC06A for ; Sat, 3 Dec 2011 23:25:10 -0800 (PST) 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=DuPVP6sd5Huy14QcEAarblvZRhvC8MAsXxSwMu7HDkNp AUCYS8AeEArSdFD+Bqss2UuSUu1M+f0kMTavdj5WRjI4phvLLqpA7/G2ouqB5woq iAhhW0I8PQ+epyoyqFIjgH6f4nlihHscwAsGmP9AP0SDpzDJ3tk9+n6lIMSKfwU= 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=1PtdjbRrUCvjBgt6+Ai/FkzSwh0=; b=NDf/mpbeuPm J4nRoXk9H0sG0b1WoBhe+IbhPByYzjtzwu7KKk4+jHtCL7xwI2TLXsf0hyeupxfc YXiNVjg3jN9yMxMg0PccfpjHy8ov4T2UtQQwkLgb1NsBQz0wIeXW/k/5mHaQoGQa 8HpJdmAa+rxTFFkTynwf5ybOyLbwtGE0= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id A715C2AC069 for ; Sat, 3 Dec 2011 23:25:10 -0800 (PST) Received: by dadv40 with SMTP id v40so4108899dad.31 for ; Sat, 03 Dec 2011 23:25:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.12.7 with SMTP id u7mr11533774pbb.77.1322983510222; Sat, 03 Dec 2011 23:25:10 -0800 (PST) Received: by 10.68.73.4 with HTTP; Sat, 3 Dec 2011 23:25:10 -0800 (PST) In-Reply-To: <4EDA075D.4090903@mnt.se> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> Date: Sun, 4 Dec 2011 01:25:10 -0600 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] new text for section 7.6 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, 04 Dec 2011 07:25:12 -0000 On Sat, Dec 3, 2011 at 5:26 AM, Leif Johansson wrote: > On 12/03/2011 04:48 AM, Nico Williams wrote: >> Proposed text for section 7.6: >> >> When the given name object is an MN this function MUST fail if the > > Say something specific about error return codes instead. GSS_S_BAD_NAME_ATTR. >> mechanism for which the name is an MN does recognize the attribute >> name or the namespace it belomgs to. =C2=A0This is because name >> attributes generally have some semantics that mechanisms must >> understand. > > We don't use the term namespace anywhere else in the spec. Lets > not introduce new terminology here. Same goes for 'element' further > down. Indeed, but since we have attribute names it follows that we have attribute namespaces. The point is that if we expect mechanisms to understand any semantics for one name attribute, surely we can expect them to understand semantics of a set of name attributes related by a common name attribute name prefix. We don't strictly need to support "namespaces" as such. Consider a name attribute with application-specific semantics such that the only thing the mechanism needs to know is how to transport the attribute. But surely we'd want more than one such attribute. But surely, too, we don't want to have to modify mechanisms every time we add such an application-specific attribute. We could simply say that applications get one such attribute and that the value encoding must encode everything the application needs, but I suspect that having a namespace of name attributes just for application-specific attributes would be more convenient. I'll write some text for the intro about this. >> On the other hand, when the given name is not an MN this function >> MUSTNOT fail -- instead credential acquisition with the resulting >> name MUST fail for mechanisms that don't understand any one or more >> name attributes set with this function. =C2=A0Applications may wish to >> use a non-MN, then acquire and use credentials with that name as >> the desired name. The acquired credentials will have elements only >> for the mechanisms that can carry the name attributes set on the >> name. > > I find that text extremely difficult to understand and I'd > like to get some feedback from implementors saying they grok > this (Luke that means you :-)) If you call GSS_Import_name() with some name-type other than GSS_C_NT_EXPORTED_NAME you get a non-MN. If you then call GSS_Set_name_attribute() then the mechglue doesn't yet know which mechanism(s) you care about -- the mechglue could try all mechanisms, but that could be a lot of work, and also complicates the application, whereas deferring the validity check to credential acquisition time works much better. >> >> In the future we may add an attribute namespace for attributes that >> only have application-specific semantics. But note that mechanisms >> will still need to know how to transport such attributes. =C2=A0We may >> also wish to add functions by which to inquire whether a >> mechanism(s) understands a given attribute name or namespace, and >> to list which attributes or attribute namespaces a mechanism >> understands. > > That sounds like something for the list and not for the > spec - at the very least is should be separated from the > rest of the text. We've had forward-looking statements in GSS RFCs before... (channel binding comes to mind, in RFC2743). Nico -- From hartmans@mit.edu Mon Dec 5 06:49:29 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 5273221F8BD3 for ; Mon, 5 Dec 2011 06:49:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4EpuxQo0I5T for ; Mon, 5 Dec 2011 06:49:28 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D01D621F8BC4 for ; Mon, 5 Dec 2011 06:49:28 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 915882043E; Mon, 5 Dec 2011 09:49:40 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E22314367; Mon, 5 Dec 2011 09:49:19 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> Date: Mon, 05 Dec 2011 09:49:19 -0500 In-Reply-To: <4EDA075D.4090903@mnt.se> (Leif Johansson's message of "Sat, 03 Dec 2011 12:26:21 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 14:49:29 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> On 12/03/2011 04:48 AM, Nico Williams wrote: >> Proposed text for section 7.6: >> >> When the given name object is an MN this function MUST fail if >> the Leif> Say something specific about error return codes instead. Also, what does it mean for it to recognize the namespace? As I said, coming up with text here is going to be tricky. I agree with the intent and will not block anything, but the first cut text you proposed is not something I'd understand unless I was on the call with you. I do agree it captures the direction we wanted to go in. From hartmans@mit.edu Mon Dec 5 06:51: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 5EC0C21F8BB6 for ; Mon, 5 Dec 2011 06:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSnUrT41-uBh for ; Mon, 5 Dec 2011 06:51:34 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E99A721F8531 for ; Mon, 5 Dec 2011 06:51:33 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 18ADF2043E; Mon, 5 Dec 2011 09:51:50 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 29DDB4367; Mon, 5 Dec 2011 09:51:29 -0500 (EST) From: Sam Hartman To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> Date: Mon, 05 Dec 2011 09:51:29 -0500 In-Reply-To: (Nico Williams's message of "Fri, 2 Dec 2011 21:48:27 -0600") 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] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 14:51:34 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On the other hand, when the given name is not an MN this Nico> function MUSTNOT fail -- instead credential acquisition with MUSt NOT fail seems too strong. If a mechglue wants to walk all its mechanisms and see if any of them support the attribute that seems reasonable. I'd say MAY SUCCEED and could have my arm twisted into SHOULD ssucceed. From leifj@mnt.se Mon Dec 5 06:54:17 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 E56B721F8B6D for ; Mon, 5 Dec 2011 06:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.177 X-Spam-Level: X-Spam-Status: No, score=0.177 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] 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 8K6LVlmic2tq for ; Mon, 5 Dec 2011 06:54:17 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 9B69321F8B77 for ; Mon, 5 Dec 2011 06:54:16 -0800 (PST) Received: from [109.105.104.193] (dhcp59.se-tug.nordu.net [109.105.104.193] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB5Es2HP003144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 15:54:05 +0100 (CET) Message-ID: <4EDCDB0A.6030004@mnt.se> Date: Mon, 05 Dec 2011 15:54:02 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 14:54:18 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/04/2011 08:25 AM, Nico Williams wrote: > On Sat, Dec 3, 2011 at 5:26 AM, Leif Johansson > wrote: >> On 12/03/2011 04:48 AM, Nico Williams wrote: >>> Proposed text for section 7.6: >>> >>> When the given name object is an MN this function MUST fail if >>> the >> >> Say something specific about error return codes instead. > > GSS_S_BAD_NAME_ATTR. I seem to recall strong consensus not to change the API in a non- backwards compatible way since there are deployed implementations already. > >>> mechanism for which the name is an MN does recognize the >>> attribute name or the namespace it belomgs to. This is because >>> name attributes generally have some semantics that mechanisms >>> must understand. >> >> We don't use the term namespace anywhere else in the spec. Lets >> not introduce new terminology here. Same goes for 'element' >> further down. > > Indeed, but since we have attribute names it follows that we have > attribute namespaces. The point is that if we expect mechanisms > to not really but I take your point. I'm just saying that if we want to introduce namespaces then lets do a proper job or figure out a way to formulate the spec wo references to NS. > understand any semantics for one name attribute, surely we can > expect them to understand semantics of a set of name attributes > related by a common name attribute name prefix. > > We don't strictly need to support "namespaces" as such. Consider > a name attribute with application-specific semantics such that the > only thing the mechanism needs to know is how to transport the > attribute. But surely we'd want more than one such attribute. But > surely, too, we don't want to have to modify mechanisms every time > we add such an application-specific attribute. We could simply say > that applications get one such attribute and that the value > encoding must encode everything the application needs, but I > suspect that having a namespace of name attributes just for > application-specific attributes would be more convenient. > > I'll write some text for the intro about this. > ... or write the spec wo references to NS >>> On the other hand, when the given name is not an MN this >>> function MUSTNOT fail -- instead credential acquisition with >>> the resulting name MUST fail for mechanisms that don't >>> understand any one or more name attributes set with this >>> function. Applications may wish to use a non-MN, then acquire >>> and use credentials with that name as the desired name. The >>> acquired credentials will have elements only for the mechanisms >>> that can carry the name attributes set on the name. >> >> I find that text extremely difficult to understand and I'd like >> to get some feedback from implementors saying they grok this >> (Luke that means you :-)) > > If you call GSS_Import_name() with some name-type other than > GSS_C_NT_EXPORTED_NAME you get a non-MN. If you then call > GSS_Set_name_attribute() then the mechglue doesn't yet know which > mechanism(s) you care about -- the mechglue could try all > mechanisms, but that could be a lot of work, and also complicates > the application, whereas deferring the validity check to credential > acquisition time works much better. OK so what does that look like as normative language? > >>> >>> In the future we may add an attribute namespace for attributes >>> that only have application-specific semantics. But note that >>> mechanisms will still need to know how to transport such >>> attributes. We may also wish to add functions by which to >>> inquire whether a mechanism(s) understands a given attribute >>> name or namespace, and to list which attributes or attribute >>> namespaces a mechanism understands. >> >> That sounds like something for the list and not for the spec - at >> the very least is should be separated from the rest of the text. > > We've had forward-looking statements in GSS RFCs before... > (channel binding comes to mind, in RFC2743). absolutely - I'd just as soon not have it along with normative language. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7c2woACgkQ8Jx8FtbMZncGegCggahdueXkyg3VyWoTwHw59moa 2v0AoJN17743KvUopOD8O7cZVhxMgdbl =7nao -----END PGP SIGNATURE----- From leifj@mnt.se Mon Dec 5 06:56:07 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5D0521F8B87 for ; Mon, 5 Dec 2011 06:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[AWL=1.388, 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 Rc6dP58K4Fre for ; Mon, 5 Dec 2011 06:56:07 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 7681B21F8B6D for ; Mon, 5 Dec 2011 06:56:06 -0800 (PST) Received: from [109.105.104.193] (dhcp59.se-tug.nordu.net [109.105.104.193] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB5EtI0v018818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 15:55:22 +0100 (CET) Message-ID: <4EDCDB56.4060108@mnt.se> Date: Mon, 05 Dec 2011 15:55:18 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Sam Hartman References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 14:56:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2011 03:49 PM, Sam Hartman wrote: >>>>>> "Leif" == Leif Johansson writes: > > Leif> On 12/03/2011 04:48 AM, Nico Williams wrote: >>> Proposed text for section 7.6: >>> >>> When the given name object is an MN this function MUST fail if >>> the > > Leif> Say something specific about error return codes instead. > > Also, what does it mean for it to recognize the namespace? As I > said, coming up with text here is going to be tricky. I agree with > the intent and will not block anything, but the first cut text you > proposed is not something I'd understand unless I was on the call > with you. I do agree it captures the direction we wanted to go > in. Thats exactly how I'd put it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7c21YACgkQ8Jx8FtbMZnfXpQCgx/M/kWcTfTJhWBO61PgwUfXC QsoAnAtzjegrrQ++i5hgsFIS8qLuVlmM =RUCF -----END PGP SIGNATURE----- From nico@cryptonector.com Mon Dec 5 08:32:21 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 5924221F8C56 for ; Mon, 5 Dec 2011 08:32:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=-1.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] 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 2L+B4RDHk-z6 for ; Mon, 5 Dec 2011 08:32:20 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id CE96A21F8C4B for ; Mon, 5 Dec 2011 08:32:20 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 74E3A428072 for ; Mon, 5 Dec 2011 08:32:20 -0800 (PST) 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=RPhQIFk2j9+ppIOoE6yaeliTZ83nwbJHMEzyWX5vizcv opa3uYoktXHdAOEKWfJ5aOQO8QD7jZq6AlWuAtF2bC4QL//vYaoiTBLY+4Fyc8BB mxgAsAkbk5LxcT01wmH3mU4sOg56vUzLhRUkdGmv7u5WK7lbJeBD+LUxsgHidJI= 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=YyiYwCWEwf9IIYMEjzNTuA9XMf4=; b=wROOjv2ONLo pTSGMIfSQ3UFTaXqQTMfpVilgBD2041fThAy/h6t7TLo6mPzJ++kgyf/DOP/RlWT Y1gOq4iuaJT4qFpDK3sKdAYuKq5WrEPWFQuUR4kgaQmcnZJWLGCg15tCLaocClfe rNF0sE32voSFyCJYLA9a45XcGkFbns5E= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 5EE3F42806E for ; Mon, 5 Dec 2011 08:32:20 -0800 (PST) Received: by dadv40 with SMTP id v40so5904408dad.31 for ; Mon, 05 Dec 2011 08:32:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.36.8 with SMTP id m8mr24732650pbj.128.1323102738766; Mon, 05 Dec 2011 08:32:18 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 08:32:18 -0800 (PST) In-Reply-To: <4EDCDB0A.6030004@mnt.se> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> <4EDCDB0A.6030004@mnt.se> Date: Mon, 5 Dec 2011 10:32:18 -0600 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] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 16:32:21 -0000 On Mon, Dec 5, 2011 at 8:54 AM, Leif Johansson wrote: > On 12/04/2011 08:25 AM, Nico Williams wrote: >> On Sat, Dec 3, 2011 at 5:26 AM, Leif Johansson >> wrote: >>> On 12/03/2011 04:48 AM, Nico Williams wrote: >>>> Proposed text for section 7.6: >>>> >>>> When the given name object is an MN this function MUST fail if >>>> the >>> >>> Say something specific about error return codes instead. >> >> GSS_S_BAD_NAME_ATTR. > > I seem to recall strong consensus not to change the API in a non- > backwards compatible way since there are deployed implementations > already. Then there's nothing to say about specific major status codes. Only GSS_S_FAILURE will do. >>> We don't use the term namespace anywhere else in the spec. Lets >>> not introduce new terminology here. Same goes for 'element' >>> further down. >> >> Indeed, but since we have attribute names it follows that we have >> attribute namespaces. =C2=A0The point is that if we expect mechanisms >> to > > not really but I take your point. I'm just saying that if we want to > introduce namespaces then lets do a proper job or figure out a way > to formulate the spec wo references to NS. Fair enough. Since attribute names imply a namespace of attribute names, we needn't really say anything about that which is implied. It seems prudent to anticipate the need for namespaces, but it isn't strictly necessary, so I'll give on this. >>> I find that text extremely difficult to understand and I'd like >>> to get some feedback from implementors saying they grok this >>> (Luke that means you :-)) >> >> If you call GSS_Import_name() with some name-type other than >> GSS_C_NT_EXPORTED_NAME you get a non-MN. =C2=A0If you then call >> GSS_Set_name_attribute() then the mechglue doesn't yet know which >> mechanism(s) you care about -- the mechglue could try all >> mechanisms, but that could be a lot of work, and also complicates >> the application, whereas deferring the validity check to credential >> acquisition time works much better. > > OK so what does that look like as normative language? It means writing a paragraph or three elaborating on the text that you found confusing. One paragraph would cover the GSS_Import_name-then-Acquire_credential() case and the other would cover the GSS_Import_name-thenAdd_cred() case. >> We've had forward-looking statements in GSS RFCs before... >> (channel binding comes to mind, in RFC2743). > > absolutely - I'd just as soon not have it along with normative language. Meaning you'd be happy to see it in some other section of the same I-D? Nico -- From nico@cryptonector.com Mon Dec 5 08:43:33 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 161E821F8AAC for ; Mon, 5 Dec 2011 08:43:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[AWL=0.408, 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 LwPwbS0BQ5U4 for ; Mon, 5 Dec 2011 08:43:32 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 471A621F8A80 for ; Mon, 5 Dec 2011 08:43:32 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id AF79B10079 for ; Mon, 5 Dec 2011 08:43:19 -0800 (PST) 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=bPoHl69AWHaAit8RwKhlALJ6ppMTBALKXNhEyKjwPdM/ intfY7ddmH9MZ3n36WaKI9+Wejk1iX0L6Z53L4Hj1rW8nkBOKlKNhS1eqEFd246T DxzAR+Z+SbhLN3zQQONT9/pZ7oRXJbsFYSzfAwMe44YPVDdknDrFfubQz8sVVDU= 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=i1MyZeExHE6mV5QGRfAx00lQR2M=; b=LxR1aklQ0Xf hiVyowsByOdp24gN6F2ev2496DoArrtLEc5AfADXRic7KYqOKZnFVJu2mWoMI8HP 7ngb/DUceWFxJnfYAaFInTrdmtdJtVmXMvx1i5Ixb69+uhmA2Dw5YcMGApnQecZU G4ixzOCFIkR3zeSXMEjywyp4mNM/bzuI= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.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 65E6B10060 for ; Mon, 5 Dec 2011 08:43:04 -0800 (PST) Received: by dadv40 with SMTP id v40so5916347dad.31 for ; Mon, 05 Dec 2011 08:43:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.12.7 with SMTP id u7mr24353517pbb.77.1323103383773; Mon, 05 Dec 2011 08:43:03 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 08:43:03 -0800 (PST) In-Reply-To: References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> Date: Mon, 5 Dec 2011 10:43:03 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 16:43:33 -0000 On Mon, Dec 5, 2011 at 8:51 AM, Sam Hartman wrote: >>>>>> "Nico" =3D=3D Nico Williams writes: > =C2=A0 =C2=A0Nico> =C2=A0 =C2=A0On the other hand, when the given name is= not an MN this > =C2=A0 =C2=A0Nico> function MUSTNOT fail -- instead credential acquisitio= n with > > MUSt NOT fail seems too strong. =C2=A0If a mechglue wants to walk all its > mechanisms and see if any of them support the attribute that seems > reasonable. =C2=A0I'd say MAY SUCCEED and could have my arm twisted into > SHOULD ssucceed. It seems easier to defer checking mechanism support in the non-MN case given that the end result is the same (no credential handle) when none of the available mechanisms understand the given attribute. The distinction between success and failure in this one case lies in whether the application gets to know which specific attributes are not understood across the board. This raises the following question: is it important for applications to be able to use the non-MN case and determine which attributes are not understood? If applications will generally all of a set of attributes set on a name then they don't need to know which attributes are not understood across the board. On the other hand, if applications can have fallback strategies then they do need to know. Ah, that convinces me: I want to not preclude that case. So let's change that to MAY succeed. Nico -- From nico@cryptonector.com Mon Dec 5 09:30:04 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 BE00D21F8C52 for ; Mon, 5 Dec 2011 09:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.218 X-Spam-Level: X-Spam-Status: No, score=-0.218 tagged_above=-999 required=5 tests=[AWL=-1.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] 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 8zpLOkj+yUOW for ; Mon, 5 Dec 2011 09:30:04 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 42B3521F8C4B for ; Mon, 5 Dec 2011 09:30:04 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id EAD662AC073 for ; Mon, 5 Dec 2011 09:30:03 -0800 (PST) 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=UyeZ4v2ntrvLnqwsKzW5L eswesDiPqKKnpL4PJ20s9W4nAHcEiNYZrfPSoPFWHojqGsy4aMxQlUM4ea928pGz JrpqY5ZrzIPfwHNbddvu79ke6LnB7QHYjce0iPsCN+NwZ7NlD/TJK/PYzK8N+0pz 0kEQHbJy3TAzkpkz6gzhVE= 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=DDtVt5dLWa7xZRXIpAmN /Z6dHhc=; b=OralEDlfhg6m9DtG+NLYh7JPsRIX1CCTVpkBstmtUDpCjQ+d0dzy ZwmW/IpABrfLMgHKDY+yK3QokZ2dOFMsQS+ogGDKQHH7f5/2yO3tJtVdRLAYL8fI sAFGTmVvozXQnctaUFrsiWVGVszAlqjVfnYhG+dYOfE6/kZALcOd74w= Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id C25BE2AC072 for ; Mon, 5 Dec 2011 09:30:03 -0800 (PST) Received: by ghrr18 with SMTP id r18so5470026ghr.31 for ; Mon, 05 Dec 2011 09:30:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.37.1 with SMTP id u1mr24559496pbj.111.1323105791266; Mon, 05 Dec 2011 09:23:11 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 09:23:11 -0800 (PST) In-Reply-To: References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> Date: Mon, 5 Dec 2011 11:23:11 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 17:30:04 -0000 New proposal for section 7.6: When the given name object is an MN this function MUST fail (with GSS_S_FAILURE) if the mechanism for which the name is an MN does recognize the attribute name or the namespace it belomgs to. This is because name attributes generally have some semantics that mechanisms must understand. On the other hand, when the given name is not an MN this function MAY succeed even if none of the available mechanisms understand the given attribute, in which subsequent credential acquisition attempts (via GSS_Acquire_cred() or GSS_Add_cred()) with the resulting name MUST fail for mechanisms that don't understand any one or more name attributes set with this function. Applications may wish to use a non-MN, then acquire a credential with that name as the desired name. The acquired credentials will have elements only for the mechanisms that can carry the name attributes set on the name. I think that paragraph should be clear now. Is it? I'll propose new text with forward-looking statements for an informative section separately. Nico -- From hartmans@mit.edu Mon Dec 5 10:29: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 D092021F8C7A for ; Mon, 5 Dec 2011 10:29:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.965 X-Spam-Level: X-Spam-Status: No, score=-101.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, 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 APMQdVtuL78Y for ; Mon, 5 Dec 2011 10:29:57 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 65C4321F8C73 for ; Mon, 5 Dec 2011 10:29:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E1284204D5; Mon, 5 Dec 2011 13:30:12 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EA8664367; Mon, 5 Dec 2011 13:29:51 -0500 (EST) From: Sam Hartman To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> Date: Mon, 05 Dec 2011 13:29:51 -0500 In-Reply-To: (Nico Williams's message of "Mon, 5 Dec 2011 11:23:11 -0600") 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] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:29:57 -0000 Nico, I'm happy with your text if you make one substitution: s:does recognize:does not recognize. As currently written, mechanisms must reject attributes they understand. I believe that to be a typo. From nico@cryptonector.com Mon Dec 5 10:33: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 D63F921F8C80 for ; Mon, 5 Dec 2011 10:33:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=0.455, 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 QNSVXpnzATTr for ; Mon, 5 Dec 2011 10:33:35 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id E081A21F8C22 for ; Mon, 5 Dec 2011 10:33:34 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 8378F594069 for ; Mon, 5 Dec 2011 10:33:34 -0800 (PST) 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=eOJXKmgIPjmP3VIFsHxwd 6zHO3sUKN7uSsIzfBkdtV0UuTbwxXNLGkCVXP4aWYefgk5CsFHLMFiKoaytiHoRo MNE5DGM1IuoEwPZ2XjLkrPEO1y4oyYoNirVnvdhLUYW4YpbDz2DBscpcEH6jt3UO oEKzzu9tQv7Zz/rM4gPOqI= 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=Y5o2Teyxyj/AcPRwpolO nwYEr60=; b=q2HCkzO3nHK3rXG5UL7QHsW6dTAQe1raV8eNef46wkqZjLgMkCNp gdKw5om0FTbumH4PW4LzxBlI9oi7lgi9qgAPIqs/gr+EPIeK/MjvO+WgyQM5E66U MSCE2ld4nkvwcRd4VAlgd5Vp1Y529+trqQP+/rhx/ad5v0/jKsw2lEg= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 695F8594061 for ; Mon, 5 Dec 2011 10:33:34 -0800 (PST) Received: by dadv40 with SMTP id v40so6047787dad.31 for ; Mon, 05 Dec 2011 10:33:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.199.6 with SMTP id jg6mr25590614pbc.26.1323110014064; Mon, 05 Dec 2011 10:33:34 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 10:33:34 -0800 (PST) In-Reply-To: References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> Date: Mon, 5 Dec 2011 12:33:34 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 18:33:35 -0000 Yes, that's a typo. From nico@cryptonector.com Mon Dec 5 11:20:45 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 720EA11E80DF for ; Mon, 5 Dec 2011 11:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=0.420, 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 GnE1XUhk1g1P for ; Mon, 5 Dec 2011 11:20:45 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id D6F1811E80DD for ; Mon, 5 Dec 2011 11:20:44 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 826F5678075 for ; Mon, 5 Dec 2011 11:20:44 -0800 (PST) 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=w7Tq9Ex6TWsBM7F9FrB1J Covym0N5LAsB87av2CPhAzl/5VjtNYPFOncoE4ltDqoAzUr5krpEsP4IKPD5wv0z NECg2PQ6BWpVFmpGCmcBginYE2Jpnw7n280UhRgmjExALysKy/SDE/eHBAFO7RKI DcaPeQtbJokY9kg3bzIq3k= 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=nifZ4FTuTipbSwRSAUXG 09U75zs=; b=qw13UpBqA5Rh4wkUJqN6sKMBqIK4tst7iMkGImrGq7pbqrIxwRFT jwHE6q3+5QHJKA/fEQOe95B1N1fbcortftTFARwSAPV6ejDCO1bLfzVyUBeGcjhQ QG/XGjvjgRFfGAm3cKtOObAtl2fxSukJ9Me2STvQwLIiFmS2JUgcW30= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 68C2D678069 for ; Mon, 5 Dec 2011 11:20:44 -0800 (PST) Received: by dadv40 with SMTP id v40so6101757dad.31 for ; Mon, 05 Dec 2011 11:20:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.36.8 with SMTP id m8mr25838198pbj.128.1323112844106; Mon, 05 Dec 2011 11:20:44 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 11:20:44 -0800 (PST) In-Reply-To: References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> Date: Mon, 5 Dec 2011 13:20:44 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:20:45 -0000 I'd like to add a paragraph about criticality: Note that this means that all name attributes are locally critical: the mechanism(s) must understand them. The reason for this is that name attributes must necessarily have some meaning that the mechanism must understand, even in the case of application-specific attributes (in which case the mechanism must know to transport the attribute to any peer). However, there is no provision to ensure that peers understand any given name attribute. Individual name attributes may be critical with respect to peers, and the specification of the attribute will have to indicate which of the mechanism's protocol or the application is expected to enforce criticality. Nico -- From leifj@mnt.se Mon Dec 5 11:34: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 A1C1621F8CA5 for ; Mon, 5 Dec 2011 11:34:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[AWL=-1.388, BAYES_00=-2.599, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] 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 ofvGd-+CyQp6 for ; Mon, 5 Dec 2011 11:34:13 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 94FAF21F8BDE for ; Mon, 5 Dec 2011 11:34:11 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB5JY0G6026008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 20:34:05 +0100 (CET) Message-ID: <4EDD1CA7.9010901@mnt.se> Date: Mon, 05 Dec 2011 20:33:59 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> <4EDCDB0A.6030004@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:34:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2011 05:32 PM, Nico Williams wrote: > On Mon, Dec 5, 2011 at 8:54 AM, Leif Johansson > wrote: >> On 12/04/2011 08:25 AM, Nico Williams wrote: >>> On Sat, Dec 3, 2011 at 5:26 AM, Leif Johansson >>> wrote: >>>> On 12/03/2011 04:48 AM, Nico Williams wrote: >>>>> Proposed text for section 7.6: >>>>> >>>>> When the given name object is an MN this function MUST fail >>>>> if the >>>> >>>> Say something specific about error return codes instead. >>> >>> GSS_S_BAD_NAME_ATTR. >> >> I seem to recall strong consensus not to change the API in a >> non- backwards compatible way since there are deployed >> implementations already. > > Then there's nothing to say about specific major status codes. > Only GSS_S_FAILURE will do. ok but then I'm not an implementor... so I'm not sure how much weight to give to what I say about this point. > >>>> We don't use the term namespace anywhere else in the spec. >>>> Lets not introduce new terminology here. Same goes for >>>> 'element' further down. >>> >>> Indeed, but since we have attribute names it follows that we >>> have attribute namespaces. The point is that if we expect >>> mechanisms to >> >> not really but I take your point. I'm just saying that if we want >> to introduce namespaces then lets do a proper job or figure out a >> way to formulate the spec wo references to NS. > > Fair enough. Since attribute names imply a namespace of attribute > names, we needn't really say anything about that which is implied. > It seems prudent to anticipate the need for namespaces, but it > isn't strictly necessary, so I'll give on this. > >>>> I find that text extremely difficult to understand and I'd >>>> like to get some feedback from implementors saying they grok >>>> this (Luke that means you :-)) >>> >>> If you call GSS_Import_name() with some name-type other than >>> GSS_C_NT_EXPORTED_NAME you get a non-MN. If you then call >>> GSS_Set_name_attribute() then the mechglue doesn't yet know >>> which mechanism(s) you care about -- the mechglue could try >>> all mechanisms, but that could be a lot of work, and also >>> complicates the application, whereas deferring the validity >>> check to credential acquisition time works much better. >> >> OK so what does that look like as normative language? > > It means writing a paragraph or three elaborating on the text that > you found confusing. One paragraph would cover the > GSS_Import_name-then-Acquire_credential() case and the other would > cover the GSS_Import_name-thenAdd_cred() case. > sounds good >>> We've had forward-looking statements in GSS RFCs before... >>> (channel binding comes to mind, in RFC2743). >> >> absolutely - I'd just as soon not have it along with normative >> language. > > Meaning you'd be happy to see it in some other section of the same > I-D? Yep. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7dHKMACgkQ8Jx8FtbMZnd1qACaA8rwcdBPXMke3lu8yhrixEgG xYUAn3O06nIbTsbux2EaXVzUpHLDB2Fm =zp8B -----END PGP SIGNATURE----- From leifj@mnt.se Mon Dec 5 11:35:26 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 0436721F8CA9 for ; Mon, 5 Dec 2011 11:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, SARE_FWDLOOK=1.666, SARE_LWFORWARD=1.11] 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 shl2tmGfrAY3 for ; Mon, 5 Dec 2011 11:35:25 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id C466221F8CA3 for ; Mon, 5 Dec 2011 11:35:23 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB5JZHFo006122 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 20:35:20 +0100 (CET) Message-ID: <4EDD1CF4.2010909@mnt.se> Date: Mon, 05 Dec 2011 20:35:16 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:35:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2011 06:23 PM, Nico Williams wrote: > New proposal for section 7.6: > > When the given name object is an MN this function MUST fail (with > GSS_S_FAILURE) if the mechanism for which the name is an MN does > recognize the attribute name or the namespace it belomgs to. This > is because name attributes generally have some semantics that > mechanisms must understand. > > On the other hand, when the given name is not an MN this function > MAY succeed even if none of the available mechanisms understand > the given attribute, in which subsequent credential acquisition > attempts (via GSS_Acquire_cred() or GSS_Add_cred()) with the > resulting name MUST fail for mechanisms that don't understand any > one or more name attributes set with this function. Applications > may wish to use a non-MN, then acquire a credential with that name > as the desired name. The acquired credentials will have elements > only for the mechanisms that can carry the name attributes set on > the name. > > I think that paragraph should be clear now. Is it? > much better. > I'll propose new text with forward-looking statements for an > informative section separately. > > Nico -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7dHPQACgkQ8Jx8FtbMZnfqrQCfVOpeVlqusTTFyYUBpOd6Ar+8 bZYAn2Gvb9olv06led2vNzzERNzedEvX =YhjW -----END PGP SIGNATURE----- From leifj@mnt.se Mon Dec 5 11:36:26 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 4761B21F8CA3 for ; Mon, 5 Dec 2011 11:36:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.694, 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 c7+xlcSIVNj4 for ; Mon, 5 Dec 2011 11:36:25 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 7F66421F8CA5 for ; Mon, 5 Dec 2011 11:36:25 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB5JaHmx018665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 20:36:21 +0100 (CET) Message-ID: <4EDD1D31.6030106@mnt.se> Date: Mon, 05 Dec 2011 20:36:17 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:36:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2011 08:20 PM, Nico Williams wrote: > I'd like to add a paragraph about criticality: > > Note that this means that all name attributes are locally > critical: the mechanism(s) must understand them. The reason for > this is that name attributes must necessarily have some meaning > that the mechanism must understand, even in the case of > application-specific attributes (in which case the mechanism must > know to transport the attribute to any peer). However, there is no > provision to ensure that peers understand any given name attribute. > Individual name attributes may be critical with respect to peers, > and the specification of the attribute will have to indicate which > of the mechanism's protocol or the application is expected to > enforce criticality. > > Nico -- I think that make sens to include immediately after the new text you just proposed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7dHTEACgkQ8Jx8FtbMZndjQACfe1hYrtFNDBxIhwT+Bqh4hc40 locAn2gmmFXU7hUblJqZJQRm1let9dVa =G1K1 -----END PGP SIGNATURE----- From nico@cryptonector.com Mon Dec 5 11:40:13 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 724411F0C36 for ; Mon, 5 Dec 2011 11:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.587 X-Spam-Level: X-Spam-Status: No, score=-1.587 tagged_above=-999 required=5 tests=[AWL=0.390, 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 sz0q6jJxl2cW for ; Mon, 5 Dec 2011 11:40:13 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5E51F0C34 for ; Mon, 5 Dec 2011 11:40:13 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id C0BAD26406C for ; Mon, 5 Dec 2011 11:40:12 -0800 (PST) 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=C8bj2mK8wI95+G4NxLxPH hZ3gk0xApAUMkKWQFhBWQvAEywpJj5ebE36N+svHy5IWvPFFYILHpHlr2zamC+7I 0KSUA/M3LsSRjZdb/PavkMCh65VNnvw4vWz1FTdWI7vBG4shHyZudHQPkv0ZVjCh +isVy/Iw1OlYatG8Y4vL98= 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=c1hEWDl7eCNpU40axXO5 DSCTdlY=; b=oyhVAoVaBRhFr3ukcYRoNAoIjCGhrKOw43Lo9N6tknYuw0NCiK3r c191R9CPjh3GdDaJsQv0URATPypnM/jg9aXc/cNYkmwtrJVsVK7IuRZVMEKqraEz j1cdJV+Ra1XhmGp8Wpsi+xlpuVJ2DsT6kCNyB8wcBcizeS+E46LWq/E= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id A7810264063 for ; Mon, 5 Dec 2011 11:40:12 -0800 (PST) Received: by dadv40 with SMTP id v40so6123558dad.31 for ; Mon, 05 Dec 2011 11:40:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.72.234 with SMTP id g10mr25636324pbv.94.1323114012358; Mon, 05 Dec 2011 11:40:12 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 11:40:12 -0800 (PST) In-Reply-To: <4EDD1CA7.9010901@mnt.se> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> <4EDCDB0A.6030004@mnt.se> <4EDD1CA7.9010901@mnt.se> Date: Mon, 5 Dec 2011 13:40:12 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:40:13 -0000 On Mon, Dec 5, 2011 at 1:33 PM, Leif Johansson wrote: >>>>> Say something specific about error return codes instead. >>>> >>>> GSS_S_BAD_NAME_ATTR. >>> >>> I seem to recall strong consensus not to change the API in a >>> non- backwards compatible way since there are deployed >>> implementations already. >> >> Then there's nothing to say about specific major status codes. >> Only GSS_S_FAILURE will do. > > ok but then I'm not an implementor... so I'm not sure how much > weight to give to what I say about this point. I don't think it's a problem to add new major status codes specializing GSS_S_FAILURE since GSS_S_FAILURE is so generic and we can't really define any minor status codes here by which to specialize it. Without enough information the application can only assume that something went wrong, and it might as well do that when receiving any unknown major status codes. This is a rule we probably want for the API as a whole: whenever there are two or more error conditions for which only GSS_S_FAILURE is specified we can later add a new major status code to distinguish some of those error conditions. Nico -- From leifj@mnt.se Mon Dec 5 11:41: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 B302221F8C74 for ; Mon, 5 Dec 2011 11:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.211 X-Spam-Level: X-Spam-Status: No, score=-1.211 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, SARE_FWDLOOK=1.666] 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 fatnEN77kJEp for ; Mon, 5 Dec 2011 11:41:41 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id BED8C21F8C6B for ; Mon, 5 Dec 2011 11:41:40 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB5JfXi5024148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 20:41:37 +0100 (CET) Message-ID: <4EDD1E6D.3070000@mnt.se> Date: Mon, 05 Dec 2011 20:41:33 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:41:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2011 06:23 PM, Nico Williams wrote: > New proposal for section 7.6: > Are we ok now? Just waiting for Nicos forward-looking text and then I'll push out -12 unless anyone screams bloody murder in the next few hrs.. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7dHm0ACgkQ8Jx8FtbMZnexNgCgyZf4iGv8kIOUUizYUhfMY0qM UDMAnjQ3eGzfhtxObH+bhn6rfDj+mjWJ =SmCo -----END PGP SIGNATURE----- From nico@cryptonector.com Mon Dec 5 11:41: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 247011F0C4D for ; Mon, 5 Dec 2011 11:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.613 X-Spam-Level: X-Spam-Status: No, score=-1.613 tagged_above=-999 required=5 tests=[AWL=0.364, 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 9iLvy0p89ILe for ; Mon, 5 Dec 2011 11:41:47 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id A332F1F0C47 for ; Mon, 5 Dec 2011 11:41:47 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 53AE494064 for ; Mon, 5 Dec 2011 11:41:47 -0800 (PST) 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=StTXmh6cAxTT7bWB7NxOJ atVNZ6wLXPOQa0X20pqPpyqsg+F7Z+Mk4KF2UXQwcClgvZXZKsntFmDdw0jJQJnq JUS7BmMRuBag9vjTX/sKOjZTPxPFvgOLzQnzX9cQWqjl8A8lWuxH1GSdpGkntlRs 9W/IHD3M5WNHwqtziVEgE0= 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=+WStAB0Bavh7BhjRPzrf zUIWcCw=; b=Pm7fqTd4qS9KiSPk0zjsG9/aQHaxKA3jIv6TcOoQboQJQQFjh7A1 B9cRbCzspB+s/ZIGi5mf5VfIkmqkJg17C5fiaPbVAlkSME35Fc6fakaFJ2eH2ynX /D7auBZX6kjluo2tSPzkaAFvUpUVXukIt70cAKkQlqjfxL9dFhncZ00= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 280EA9405E for ; Mon, 5 Dec 2011 11:41:47 -0800 (PST) Received: by dadv40 with SMTP id v40so6125673dad.31 for ; Mon, 05 Dec 2011 11:41:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.37.1 with SMTP id u1mr25443328pbj.111.1323114106719; Mon, 05 Dec 2011 11:41:46 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 11:41:46 -0800 (PST) In-Reply-To: <4EDD1D31.6030106@mnt.se> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDD1D31.6030106@mnt.se> Date: Mon, 5 Dec 2011 13:41:46 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:41:48 -0000 On Mon, Dec 5, 2011 at 1:36 PM, Leif Johansson wrote: > On 12/05/2011 08:20 PM, Nico Williams wrote: >> I'd like to add a paragraph about criticality: > > I think that make sens to include immediately after the new text you > just proposed. Yes. From nico@cryptonector.com Mon Dec 5 11:47: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 60C7721F8C07 for ; Mon, 5 Dec 2011 11:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.802 X-Spam-Level: X-Spam-Status: No, score=-0.802 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_FWDLOOK=1.666] 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 P3lwinLv2FST for ; Mon, 5 Dec 2011 11:47:50 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id A2EB721F8BBC for ; Mon, 5 Dec 2011 11:47:50 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 752CA584057 for ; Mon, 5 Dec 2011 11:47:41 -0800 (PST) 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=pjDxmRhnmlbtRGcMNuT1X PvIsYkuwVXBYkPZv/aPrLcdKaY3NIo46vGlF0jt7Sv2ZtFokaoy++vzrXciqVpY9 6uMYiHzt0vQ072G/RibOZYuyHf1Ws1Q2yb1tEo2YQfhcJ0UtYOaWnKHwqbo4u2um lKJr8ZBmiALowclj735f3c= 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=R/4NYxsPIaxlWRLXEyaS lGHu4dI=; b=pIcUxrHh6GKKWljvtLbenqdBv9lrDZhS7fQ0VLAVJNF+x3g9Q496 movBQML7KuoyeqV9MttE4rGzKvxAGZOQVw+UnkXxh7mJRyO38Dkzlw5YDEwVE5b5 40QfuMmGKAY7Qpni640pex6BzxxImXaDR+/9FD6udRiSbk2BpMhuv8k= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPSA id B2CCE584064 for ; Mon, 5 Dec 2011 11:47:35 -0800 (PST) Received: by dadv40 with SMTP id v40so6132279dad.31 for ; Mon, 05 Dec 2011 11:47:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.72.234 with SMTP id g10mr25682130pbv.94.1323114454547; Mon, 05 Dec 2011 11:47:34 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 11:47:34 -0800 (PST) In-Reply-To: <4EDD1E6D.3070000@mnt.se> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDD1E6D.3070000@mnt.se> Date: Mon, 5 Dec 2011 13:47:34 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 19:47:51 -0000 On Mon, Dec 5, 2011 at 1:41 PM, Leif Johansson wrote: > On 12/05/2011 06:23 PM, Nico Williams wrote: >> New proposal for section 7.6: >> > > Are we ok now? Just waiting for Nicos forward-looking text and then > I'll push out -12 unless anyone screams bloody murder in the next > few hrs.. Sam indicated support, with a typo correction. As for the forward-looking text, just take that one paragraph and add it to the end of the introduction: In the future we may add an attribute namespace for attributes that only have application-specific semantics. But note that mechanisms will still need to know how to transport such attributes. We may also wish to add functions by which to inquire whether a mechanism(s) understands a given attribute name or namespace, and to list which attributes or attribute namespaces a mechanism understands. Finally, we're likely to add a function by which to determine the name of the issuer of a name attribute. Also, w.r.t. local attribute naming... since URIs never separate the scheme from the rest by two colons, why not reserve two colons for future extensions or for local name attributes? Nico -- From leifj@mnt.se Mon Dec 5 12:06: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 6AEAE11E80B5 for ; Mon, 5 Dec 2011 12:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.165 X-Spam-Level: X-Spam-Status: No, score=-1.165 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, SARE_FWDLOOK=1.666] 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 jjpBfmpbXiVA for ; Mon, 5 Dec 2011 12:06:48 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 58CA821F8B31 for ; Mon, 5 Dec 2011 12:06:48 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB5K6dmM022608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 21:06:42 +0100 (CET) Message-ID: <4EDD244F.9010608@mnt.se> Date: Mon, 05 Dec 2011 21:06:39 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDD1E6D.3070000@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 20:06:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2011 08:47 PM, Nico Williams wrote: > On Mon, Dec 5, 2011 at 1:41 PM, Leif Johansson > wrote: >> On 12/05/2011 06:23 PM, Nico Williams wrote: >>> New proposal for section 7.6: >>> >> >> Are we ok now? Just waiting for Nicos forward-looking text and >> then I'll push out -12 unless anyone screams bloody murder in the >> next few hrs.. > > Sam indicated support, with a typo correction. As for the > forward-looking text, just take that one paragraph and add it to > the end of the introduction: > > In the future we may add an attribute namespace for attributes > that only have application-specific semantics. But note that > mechanisms will still need to know how to transport such > attributes. We may also wish to add functions by which to inquire > whether a mechanism(s) understands a given attribute name or > namespace, and to list which attributes or attribute namespaces a > mechanism understands. Finally, we're likely to add a function by > which to determine the name of the issuer of a name attribute. Call me picky but I'm not big on the 'we' thing in a specification. It sounds like some cabal that owns the spec that that is only partly true. > > Also, w.r.t. local attribute naming... since URIs never separate > the scheme from the rest by two colons, why not reserve two colons > for future extensions or for local name attributes? Attribute names can be URIs so perhaps http://localhost/bla is enough? Not sure if two colons is legal... Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7dJE8ACgkQ8Jx8FtbMZnepGgCghePAITRXbNyh8Jpei8D3lXyt ZewAoKkfPZjbMIGQwb3qHG/AE/gt9Qdm =rW44 -----END PGP SIGNATURE----- From ietf@augustcellars.com Mon Dec 5 12:10:46 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F225121F8B61 for ; Mon, 5 Dec 2011 12:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.963 X-Spam-Level: X-Spam-Status: No, score=-2.963 tagged_above=-999 required=5 tests=[AWL=0.637, 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 uc9rFUf1ziA9 for ; Mon, 5 Dec 2011 12:10:45 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCF521F8B0B for ; Mon, 5 Dec 2011 12:10:45 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 0EFE22CA07; Mon, 5 Dec 2011 12:10:43 -0800 (PST) From: "Jim Schaad" To: "'Nico Williams'" , "'Leif Johansson'" References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> <4EDCDB0A.6030004@mnt.se> <4EDD1CA7.9010901@mnt.se> In-Reply-To: Date: Mon, 5 Dec 2011 12:10:15 -0800 Message-ID: <00ff01ccb389$e74e6db0$b5eb4910$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHaIP3Js/zIi2coJEq1or+wYSsaUQIwDc7wApVwEocBluANlAIcTMxvAb4AZQwBqkzVBwDVQLXkAVzkFssBb9yX7AE5Afr4Acm8pFMBBAK3PwJ/2//9AW1mpwIB6d7/TgKjo6UlAOH3bTIClJDC7gEO/WqDlK6BfuA= Content-Language: en-us Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 20:10:46 -0000 +1 Code should be written to allow for unexpected error codes to appear at a later date and tread as GSS_S_FAILURE. Jim > -----Original Message----- > From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf > Of Nico Williams > Sent: Monday, December 05, 2011 11:40 AM > To: Leif Johansson > Cc: kitten@ietf.org > Subject: Re: [kitten] new text for section 7.6 > > On Mon, Dec 5, 2011 at 1:33 PM, Leif Johansson wrote: > >>>>> Say something specific about error return codes instead. > >>>> > >>>> GSS_S_BAD_NAME_ATTR. > >>> > >>> I seem to recall strong consensus not to change the API in a > >>> non- backwards compatible way since there are deployed > >>> implementations already. > >> > >> Then there's nothing to say about specific major status codes. > >> Only GSS_S_FAILURE will do. > > > > ok but then I'm not an implementor... so I'm not sure how much weight > > to give to what I say about this point. > > I don't think it's a problem to add new major status codes specializing > GSS_S_FAILURE since GSS_S_FAILURE is so generic and we can't really define > any minor status codes here by which to specialize it. Without enough > information the application can only assume that something went wrong, > and it might as well do that when receiving any unknown major status codes. > This is a rule we probably want for the API as a whole: whenever there are > two or more error conditions for which only GSS_S_FAILURE is specified we > can later add a new major status code to distinguish some of those error > conditions. > > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nico@cryptonector.com Mon Dec 5 12:13:24 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA8C11E80E4 for ; Mon, 5 Dec 2011 12:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=0.370, 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 HavbcpFnu4NP for ; Mon, 5 Dec 2011 12:13:24 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 3009211E80CD for ; Mon, 5 Dec 2011 12:13:24 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id AE29C2AC072 for ; Mon, 5 Dec 2011 12:13:23 -0800 (PST) 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=jA6g58ue4HHUvUFoncdXG zb7/Z/yTKXrDQ75CsgnIBnaBHpbmxzk8oy/o+xbPmA2NQWKUyOU67EwbT4xbY5ub VGomkKU9p4DFsP9b1yzY9daUgOOcPprZzuvgX5YupwyDGLZiwKJEZbuICdKJnD0X /GD2B823IKyOzYItthiiWw= 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=gyKzxU7JO3R12FL/EweG WLH6EVM=; b=KqTB5px4LRPvebim877qk7Rrdtn/+xxIw1qsbxXvZb0v2Hwrf9kj 1YRJe9NPy6IQRkpq8SR0P6cs3WmYAX9jXRqXaa46BfAFGg1zci0qDLlVB4SnYgop 2UqylmWgMi3rQd3TegOdA21awFdIc3VKXv+qVHxg8xZkQRwdnqjPJYo= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTPSA id 9478B2AC071 for ; Mon, 5 Dec 2011 12:13:23 -0800 (PST) Received: by dadv40 with SMTP id v40so6159837dad.31 for ; Mon, 05 Dec 2011 12:13:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.37.1 with SMTP id u1mr25643480pbj.111.1323116003182; Mon, 05 Dec 2011 12:13:23 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 12:13:23 -0800 (PST) In-Reply-To: <4EDD244F.9010608@mnt.se> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDD1E6D.3070000@mnt.se> <4EDD244F.9010608@mnt.se> Date: Mon, 5 Dec 2011 14:13:23 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 20:13:25 -0000 On Mon, Dec 5, 2011 at 2:06 PM, Leif Johansson wrote: > Call me picky but I'm not big on the 'we' thing in a specification. It > sounds like some cabal that owns the spec that that is only partly true. We here is "the IETF". I don't see anything wrong with that, but if you want to feel free to change that text to the passive voice ("In the future ... may be added"). Nico -- From nico@cryptonector.com Mon Dec 5 12:37: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 771551F0C60 for ; Mon, 5 Dec 2011 12:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.42 X-Spam-Level: X-Spam-Status: No, score=-0.42 tagged_above=-999 required=5 tests=[AWL=-0.857, BAYES_40=-0.185, 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 d7yaLzbj9c1l for ; Mon, 5 Dec 2011 12:37:54 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id DCAE11F0C6C for ; Mon, 5 Dec 2011 12:37:54 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id B05AAB406F for ; Mon, 5 Dec 2011 12:37:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=BFkhIQzzGk6d5z5bIZolddSZT/wUmXC/w324dBkFD9NZ r4YXJ4/K/wi8wl8/1+PfqtaG0vflVgZd+UKQUXtHEDpLQ24WwD1JkzMqbUYn4sEL nVZkfG+6tSmdAfXJXlmi+ZrivGmCfqYrbkL+3ig7XXtjwjRdoGJTFujmuqcf2ac= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=M/hERLzxKi9FGetABsSTKGdJPfc=; b=gS58+7xsk/c ouKqOmaYiiFFOrtNgYgLfyypePRyjw1GMKiGUEiQdIM+TkwA+aVrDwm6tPVmliGz LfoRO44A8MqXfVpX5wB2ssG9IMvP9Sm9YqoF3iEGlNnDLSr7TA6uvsUfNaG/M8q7 TM6BvwWIEJxF4jUbSe8NdpgD4F1N2YYk= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 96C6DB406B for ; Mon, 5 Dec 2011 12:37:54 -0800 (PST) Received: by dadv40 with SMTP id v40so6187295dad.31 for ; Mon, 05 Dec 2011 12:37:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.12.7 with SMTP id u7mr25872072pbb.77.1323117474021; Mon, 05 Dec 2011 12:37:54 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 12:37:53 -0800 (PST) Date: Mon, 5 Dec 2011 14:37:53 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Another small update to naming exts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 20:37:57 -0000 The security considerations section says: The security of the application may be critically dependent on the security of the attributes. This document classifies attributes as asserted or authenticated. Asserted (non-authenticated) attributes MUST NOT be used if the attribute has security implications for the application (eg authorization decisions) since asserted attributes may easily be controlled by the peer directly. I want to relax this somewhat from "MUST NOT be used" to "MUST NOT be used in any way except to reduce granted privilege ...". Consider an assertion regarding process privileges (Solaris) / capabilities (Linux). The peer should use such an assertion only to reduce privilege that would otherwise have been granted to the other. Nico -- From nico@cryptonector.com Mon Dec 5 12:48:04 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 CBF5C21F8B00 for ; Mon, 5 Dec 2011 12:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=0.395, 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 h2WPjxlrstTC for ; Mon, 5 Dec 2011 12:48:04 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 533EF21F85B9 for ; Mon, 5 Dec 2011 12:48:04 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 65D656B007F for ; Mon, 5 Dec 2011 12:48:03 -0800 (PST) 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=JhFyDbqKB/rVv33aFBhLk qsMHA4aKlDaEYT9zDSwU6xToNxYQDqpdqKxgdzPtxHr0cUbfXj9jq7UC9ODxF9uY OcHL9C4FaDeY1DhRMKI8J6KJ4kxUW6G6mSovolEhvne7IpPkZL0wG71HR835J4Gt 9SgRxJkCc0mPgipvgQBYH8= 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=c7th3oMqPgCPBy5OHoAK ehRsIA4=; b=N9Rv4bdGi/hN0EEUnEWrK/LPZh/sDIICmiKD40743eBGu0LQcckV 9gFp5spX5T3FhLZEfwDZucpO0S8/Jbx5Qmj+KsbSm6IQJVRvjdAtEfpsd1P/zcC7 3gvbxAnGDsre0QUXn+M3KnEiT/8hGgvXVt/FtpWIUWOXkDMSi4gZVKk= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (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 4A99F6B007E for ; Mon, 5 Dec 2011 12:48:03 -0800 (PST) Received: by dadv40 with SMTP id v40so6200399dad.31 for ; Mon, 05 Dec 2011 12:48:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.56.73 with SMTP id y9mr26840442pbp.9.1323118082979; Mon, 05 Dec 2011 12:48:02 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 12:48:02 -0800 (PST) In-Reply-To: <00ff01ccb389$e74e6db0$b5eb4910$@augustcellars.com> References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> <4EDCDB0A.6030004@mnt.se> <4EDD1CA7.9010901@mnt.se> <00ff01ccb389$e74e6db0$b5eb4910$@augustcellars.com> Date: Mon, 5 Dec 2011 14:48:02 -0600 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 20:48:04 -0000 On Mon, Dec 5, 2011 at 2:10 PM, Jim Schaad wrote: > +1 > > Code should be written to allow for unexpected error codes to appear at a > later date and tread as GSS_S_FAILURE. Do we have more support for this? If so I'd propose GSS_S_BAD_NAME_ATTR. And we might also need GSS_S_BAD_NAME_ATTR_VAL (for when the semantics of the attribute require that the mechanism understand the value and the value is invalid). Nico -- From hartmans@mit.edu Mon Dec 5 13:19: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 1C9DE1F0C9F for ; Mon, 5 Dec 2011 13:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.165 X-Spam-Level: X-Spam-Status: No, score=-102.165 tagged_above=-999 required=5 tests=[AWL=0.100, 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 MlbeMCb9uloZ for ; Mon, 5 Dec 2011 13:19:37 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A77481F0C9E for ; Mon, 5 Dec 2011 13:19:37 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6565320126; Mon, 5 Dec 2011 16:19:53 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7C6E84367; Mon, 5 Dec 2011 16:19:32 -0500 (EST) From: Sam Hartman To: Nico Williams References: Date: Mon, 05 Dec 2011 16:19:32 -0500 In-Reply-To: (Nico Williams's message of "Mon, 5 Dec 2011 14:37:53 -0600") 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] Another small update to naming exts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:19:38 -0000 I support relaxing the security considerations text for asserted attributes to permit reduction in privilege. From hartmans@mit.edu Mon Dec 5 13:22: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 31D4811E80CC for ; Mon, 5 Dec 2011 13:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.19 X-Spam-Level: X-Spam-Status: No, score=-102.19 tagged_above=-999 required=5 tests=[AWL=0.075, 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 umVBW7z-W8jr for ; Mon, 5 Dec 2011 13:22:15 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id BE10211E80C4 for ; Mon, 5 Dec 2011 13:22:15 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 839F820126; Mon, 5 Dec 2011 16:22:31 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4D2584367; Mon, 5 Dec 2011 16:22:10 -0500 (EST) From: Sam Hartman To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDD1E6D.3070000@mnt.se> Date: Mon, 05 Dec 2011 16:22:10 -0500 In-Reply-To: (Nico Williams's message of "Mon, 5 Dec 2011 13:47:34 -0600") 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] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:22:16 -0000 >>>>> "Nico" == Nico Williams writes: Nico> Also, w.r.t. local attribute naming... since URIs never Nico> separate the scheme from the rest by two colons, why not Nico> reserve two colons for future extensions or for local name Nico> attributes? I don't support this change. There are so many better ways to do this when we do it. From hartmans@mit.edu Mon Dec 5 13:26:59 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62271F0CA5 for ; Mon, 5 Dec 2011 13:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.205 X-Spam-Level: X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=0.060, 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 rcdCtb-+WXu3 for ; Mon, 5 Dec 2011 13:26:59 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 715DE1F0C9E for ; Mon, 5 Dec 2011 13:26:59 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5DCCF20244; Mon, 5 Dec 2011 16:27:15 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 45F764367; Mon, 5 Dec 2011 16:26:54 -0500 (EST) From: Sam Hartman To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> <4EDCDB0A.6030004@mnt.se> <4EDD1CA7.9010901@mnt.se> <00ff01ccb389$e74e6db0$b5eb4910$@augustcellars.com> Date: Mon, 05 Dec 2011 16:26:54 -0500 In-Reply-To: (Nico Williams's message of "Mon, 5 Dec 2011 14:48:02 -0600") 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] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:26:59 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Mon, Dec 5, 2011 at 2:10 PM, Jim Schaad wrote: >> +1 >> >> Code should be written to allow for unexpected error codes to >> appear at a later date and tread as GSS_S_FAILURE. Nico> Do we have more support for this? I'd kind of prefer not to add a new error code at this point in the spec's evolution. However if it were two years ago I'd definitely support adding the error codes. Realistically no matter what we say we'll get GSS_S_FAILURE for a while in the wild. It's not a big deal to me if we do add the error codes. From leifj@mnt.se Mon Dec 5 13:46: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 1D5DE11E80B3 for ; Mon, 5 Dec 2011 13:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.964 X-Spam-Level: X-Spam-Status: No, score=-1.964 tagged_above=-999 required=5 tests=[AWL=0.635, 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 HGlQDMUSVoXw for ; Mon, 5 Dec 2011 13:46:13 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 2688911E8081 for ; Mon, 5 Dec 2011 13:46:12 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB5Lk3mQ002027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2011 22:46:07 +0100 (CET) Message-ID: <4EDD3B9B.4090603@mnt.se> Date: Mon, 05 Dec 2011 22:46:03 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDD1E6D.3070000@mnt.se> <4EDD244F.9010608@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:46:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2011 09:13 PM, Nico Williams wrote: > On Mon, Dec 5, 2011 at 2:06 PM, Leif Johansson > wrote: >> Call me picky but I'm not big on the 'we' thing in a >> specification. It sounds like some cabal that owns the spec that >> that is only partly true. > > We here is "the IETF". I don't see anything wrong with that, but > if you want to feel free to change that text to the passive voice > ("In the future ... may be added"). > > Nico -- I was trying for "Future specifications may..." but I take your point and will try for something reasonable... Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7dO5sACgkQ8Jx8FtbMZnd5QgCgwVCzbox3kTQGPph42yvXHia5 GaEAoKhS4ZgvMb4crQr4VJR1Zo4g20Ci =s/xM -----END PGP SIGNATURE----- From leifj@mnt.se Mon Dec 5 13:48: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 3F19B11E80B6 for ; Mon, 5 Dec 2011 13:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.044 X-Spam-Level: X-Spam-Status: No, score=-2.044 tagged_above=-999 required=5 tests=[AWL=0.555, 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 ZAJKb7nL7lVq for ; Mon, 5 Dec 2011 13:48:11 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA9F11E8081 for ; Mon, 5 Dec 2011 13:48:11 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB5Lm7KG020827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Dec 2011 22:48:10 +0100 (CET) Message-ID: <4EDD3C17.70507@mnt.se> Date: Mon, 05 Dec 2011 22:48:07 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] Another small update to naming exts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:48:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2011 10:19 PM, Sam Hartman wrote: > I support relaxing the security considerations text for asserted > attributes to permit reduction in privilege. +1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7dPBcACgkQ8Jx8FtbMZncNugCgmpWoGlsqLcSZ1RL9LEHUAybq EGMAnRsD2F9tBJugxB4wQqD+sNq2c+P5 =rEtF -----END PGP SIGNATURE----- From nico@cryptonector.com Mon Dec 5 13:49:46 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAD211E80B0 for ; Mon, 5 Dec 2011 13:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[AWL=0.375, 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 LX1Ak9GR7myY for ; Mon, 5 Dec 2011 13:49:42 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 7D44711E8081 for ; Mon, 5 Dec 2011 13:49:42 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 328C094079 for ; Mon, 5 Dec 2011 13:49:42 -0800 (PST) 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=aqPmypkNxWgbEJUG9KaxSTJzD3dq4sGgF9ujhKmw967w SoTjB44zQRC1D2b1ZZjwu+vWg+A3LBEEKJg1P0IU/fmKTXGq8fzIozyOAMYnu70x 21SF5R43fcBgsMop5y1iFtwDaYhO+EblndNquFQRw9jMYLICcclWfuThnup0Svk= 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=2/xf9Wf1dUvYYn7BNAJ7DGLTQJA=; b=fOyWJ/Z5qJ0 VEHtyW17D2/+zPeyhq88CEbCL0jCwlTVyc/4ci20n78Nc02jJFOF43zTMnxGBoPS KRlkR2WGTdp1Hz6BFZhnmJPcMJXp+U+mgdoiPs51JhpGrTlBNhzb5lFkakZ5yLSr HwsTgIEfhKFiWm40uIbcCPYIoQnvD9GE= Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id C59BF94070 for ; Mon, 5 Dec 2011 13:49:41 -0800 (PST) Received: by ggnk5 with SMTP id k5so2128992ggn.31 for ; Mon, 05 Dec 2011 13:49:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.72.234 with SMTP id g10mr26436604pbv.94.1323121780823; Mon, 05 Dec 2011 13:49:40 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 13:49:40 -0800 (PST) In-Reply-To: References: <4EA7B9FC.3000500@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> <4EDCDB0A.6030004@mnt.se> <4EDD1CA7.9010901@mnt.se> <00ff01ccb389$e74e6db0$b5eb4910$@augustcellars.com> Date: Mon, 5 Dec 2011 15:49:40 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 21:49:46 -0000 On Mon, Dec 5, 2011 at 3:26 PM, Sam Hartman wrote: >>>>>> "Nico" =3D=3D Nico Williams writes: > > =C2=A0 =C2=A0Nico> On Mon, Dec 5, 2011 at 2:10 PM, Jim Schaad wrote: > =C2=A0 =C2=A0>> +1 > =C2=A0 =C2=A0>> > =C2=A0 =C2=A0>> Code should be written to allow for unexpected error code= s to > =C2=A0 =C2=A0>> appear at a later date and tread as GSS_S_FAILURE. > > =C2=A0 =C2=A0Nico> Do we have more support for this? > > I'd kind of prefer not to add a new error code at this point in the > spec's evolution. =C2=A0However if it were two years ago I'd definitely > support adding the error codes. =C2=A0Realistically no matter what we say > we'll get GSS_S_FAILURE for a while in the wild. I don't mind if applications get GSS_S_FAILURE for a while. I would rather we specify a new status code now, but it's not a big deal if we don't. > It's not a big deal to me if we do add the error codes. So is that a yes or a no? :) Nico -- From lukeh@padl.com Mon Dec 5 14:16:46 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EF311E80D0 for ; Mon, 5 Dec 2011 14:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKrqenjCihDs for ; Mon, 5 Dec 2011 14:16:43 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 50FBD11E80A2 for ; Mon, 5 Dec 2011 14:16:43 -0800 (PST) Received: by us.padl.com with ESMTP id pB5MGCTB021715; Mon, 5 Dec 2011 17:16:15 -0500 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Tue, 6 Dec 2011 09:16:12 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> <4EDCDB0A.6030004@mnt.se> <4EDD1CA7.9010901@mnt.se> <00ff01ccb389$e74e6db0$b5eb4910$@augustc! ellars.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] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:16:46 -0000 Existing implementations return GSS_S_UNAVAILABLE if the attribute is = absent, from memory this is consistent with the draft. Apologies if you = were talking about something else (e.g. bad attribute syntax). -- Luke On 06/12/2011, at 7:48 AM, Nico Williams wrote: > On Mon, Dec 5, 2011 at 2:10 PM, Jim Schaad = wrote: >> +1 >>=20 >> Code should be written to allow for unexpected error codes to appear = at a >> later date and tread as GSS_S_FAILURE. >=20 > Do we have more support for this? >=20 > If so I'd propose GSS_S_BAD_NAME_ATTR. And we might also need > GSS_S_BAD_NAME_ATTR_VAL (for when the semantics of the attribute > require that the mechanism understand the value and the value is > invalid). >=20 > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com From nico@cryptonector.com Mon Dec 5 14:21:47 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 78C5B11E80D6 for ; Mon, 5 Dec 2011 14:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.62 X-Spam-Level: X-Spam-Status: No, score=-1.62 tagged_above=-999 required=5 tests=[AWL=0.357, 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 B6-aq7enFTy4 for ; Mon, 5 Dec 2011 14:21:45 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 75BC311E80D0 for ; Mon, 5 Dec 2011 14:21:44 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id 3DD8C286064 for ; Mon, 5 Dec 2011 14:21:44 -0800 (PST) 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=f6zBe+MD+iwOaETXnWqzf qKKJXdSLU3f024qgu/H7i04v+ALsAR3K0uFuH3aF+nQsJD7cyxnTKqwbI03S5/SA lIhZfWp8NH1W33XPj3dFCHpm8s1c3Ecmose72WeNewhjfBraOEXTgq+4UikUDDql SrYFLm5PoTB/gvAv/AtEWQ= 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=3Un5OsM/f2KSzenED4yZ rlWgtuk=; b=EDbXdLi7Q8Q+g+uxsVhttmt7sHLw/p0IdoDJYAUPKgBMwQR8xxZm cOyi3L3MWekac35Ou+94KZJlk76HOZQvGu5FU3edk8nbStIOTH1CdN5xwS4HNBJg 2qhrLBOnQ8KFivtof1ZwbD7cznYrmXgPQzAUXxvrYSu+oXfd3iHaAn8= Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPSA id 16619286060 for ; Mon, 5 Dec 2011 14:21:44 -0800 (PST) Received: by ggnk5 with SMTP id k5so2158454ggn.31 for ; Mon, 05 Dec 2011 14:21:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.25.69 with SMTP id a5mr26614604pbg.43.1323123703212; Mon, 05 Dec 2011 14:21:43 -0800 (PST) Received: by 10.68.73.4 with HTTP; Mon, 5 Dec 2011 14:21:43 -0800 (PST) In-Reply-To: References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> <4EDCDB0A.6030004@mnt.se> <4EDD1CA7.9010901@mnt.se> Date: Mon, 5 Dec 2011 16:21:43 -0600 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2011 22:21:47 -0000 On Mon, Dec 5, 2011 at 4:16 PM, Luke Howard wrote: > Existing implementations return GSS_S_UNAVAILABLE if the attribute is absent, from memory this is consistent with the draft. Apologies if you were talking about something else (e.g. bad attribute syntax). Oh, I completely missed that. Emily Litella moment for me.. (i.e., "never mind"). From mrex@sap.com Mon Dec 5 18:13: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 7C94321F85EF for ; Mon, 5 Dec 2011 18:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.075 X-Spam-Level: X-Spam-Status: No, score=-10.075 tagged_above=-999 required=5 tests=[AWL=0.174, 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 xhWU+UBhLEOK for ; Mon, 5 Dec 2011 18:13:41 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C660C21F85DB for ; Mon, 5 Dec 2011 18:13:40 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pB62DaXr026264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2011 03:13:37 +0100 (MET) From: Martin Rex Message-Id: <201112060213.pB62Dab9012262@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Tue, 6 Dec 2011 03:13:36 +0100 (MET) In-Reply-To: from "Nico Williams" at Dec 5, 11 02:37:53 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] Another small update to naming exts 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: Tue, 06 Dec 2011 02:13:41 -0000 Nico Williams wrote: > > The security considerations section says: > > The security of the application may be critically dependent on the > security of the attributes. This document classifies attributes as > asserted or authenticated. Asserted (non-authenticated) attributes > MUST NOT be used if the attribute has security implications for the > application (eg authorization decisions) since asserted attributes > may easily be controlled by the peer directly. > > I want to relax this somewhat from "MUST NOT be used" to "MUST NOT be > used in any way except to reduce granted privilege ...". > > Consider an assertion regarding process privileges (Solaris) / > capabilities (Linux). The peer should use such an assertion only to > reduce privilege that would otherwise have been granted to the other. That sounds like a bad idea and *will* confuse apps developers, create a false sense of security and cause security problems. Like many of those "client-side" security features that Microsoft had in SMB/CIFS, such as not seeing shares with a $ char at the end in the "net view" output and not being able to cd upwards in a share when using a Windows client rather than a samba client. -Martin From cantor.2@osu.edu Mon Dec 5 18:45:33 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 EC0861F0C64 for ; Mon, 5 Dec 2011 18:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 IiouBJibTzVf for ; Mon, 5 Dec 2011 18:45:33 -0800 (PST) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 45ACF1F0C63 for ; Mon, 5 Dec 2011 18:45:33 -0800 (PST) Received: from CIO-TNC-HT06.osuad.osu.edu (cio-tnc-ht06.osuad.osu.edu [164.107.81.171]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id pB62jApj008438; Mon, 5 Dec 2011 21:45:11 -0500 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; Mon, 5 Dec 2011 21:45:10 -0500 From: "Cantor, Scott" To: "mrex@sap.com" Thread-Topic: [kitten] Another small update to naming exts Thread-Index: AQHMs43Wpm9uZxiEYkaFYFxeAtv5JpXOZggA//+0/gA= Date: Tue, 6 Dec 2011 02:45:08 +0000 Message-ID: In-Reply-To: <201112060213.pB62Dab9012262@fs4113.wdf.sap.corp> 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: <8fcbfe4a-277b-4b98-9b61-2bac2b36cd12> 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.226 Cc: "kitten@ietf.org" Subject: Re: [kitten] Another small update to naming exts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 02:45:34 -0000 On 12/5/11 9:13 PM, "Martin Rex" wrote: > >That sounds like a bad idea and *will* confuse apps developers, >create a false sense of security and cause security problems. Is the general provision on differentiating treatment of "unauthenticated" attributes any less likely to confuse the same developers? -- Scott From leifj@mnt.se Tue Dec 6 00:23:55 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 2B8C721F8B34 for ; Tue, 6 Dec 2011 00:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jUV-GydDU3U for ; Tue, 6 Dec 2011 00:23:54 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id F05A421F8AAF for ; Tue, 6 Dec 2011 00:23:53 -0800 (PST) Received: from [192.36.125.231] (dhcp.pilsnet.sunet.se [192.36.125.231] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB68NlSi005953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Dec 2011 09:23:51 +0100 (CET) Message-ID: <4EDDD113.8090305@mnt.se> Date: Tue, 06 Dec 2011 09:23:47 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: kitten@ietf.org References: <4EA7B9FC.3000500@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> <4EDCDB0A.6030004@mnt.se> <4EDD1CA7.9010901@mnt.se> <00ff01ccb389$e74e6db0$b5eb4910$@augustc! ellars.com> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 08:23:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2011 11:16 PM, Luke Howard wrote: > Existing implementations return GSS_S_UNAVAILABLE if the attribute > is absent, from memory this is consistent with the draft. Apologies > if you were talking about something else (e.g. bad attribute > syntax). > Yes that is what we're talking about and I think Nico wants to change that to something else. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7d0RMACgkQ8Jx8FtbMZndADwCdFdJ+ui4fosh22cuoJObRF0Ov bnwAoMD5sYYi2RS//hq9aTDtqyJJeztJ =mGZR -----END PGP SIGNATURE----- From leifj@mnt.se Tue Dec 6 06:07: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 F2D2221F8B50 for ; Tue, 6 Dec 2011 06:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.905 X-Spam-Level: X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[AWL=0.694, 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 1eUG5HFtqXmW for ; Tue, 6 Dec 2011 06:07:37 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 752CB21F8B3F for ; Tue, 6 Dec 2011 06:07:37 -0800 (PST) Received: from [109.105.104.193] (dhcp59.se-tug.nordu.net [109.105.104.193] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pB6E7VDS024182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Dec 2011 15:07:35 +0100 (CET) Message-ID: <4EDE21A3.20802@mnt.se> Date: Tue, 06 Dec 2011 15:07:31 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: kitten@ietf.org References: <4EA7B9FC.3000500@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDA075D.4090903@mnt.se> <4EDCDB0A.6030004@mnt.se> <4EDD1CA7.9010901@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] new text for section 7.6 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 14:07:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2011 11:21 PM, Nico Williams wrote: > On Mon, Dec 5, 2011 at 4:16 PM, Luke Howard > wrote: >> Existing implementations return GSS_S_UNAVAILABLE if the >> attribute is absent, from memory this is consistent with the >> draft. Apologies if you were talking about something else (e.g. >> bad attribute syntax). > > Oh, I completely missed that. Emily Litella moment for me.. > (i.e., "never mind"). Yeah but this is how the discussion got started. The text you now said "never mind" about is the very text you wanted to change! Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7eIaMACgkQ8Jx8FtbMZnd5XACdHaLjJeCRCKUwrgvTao3qk05v Me8AnRyVUT4SJQTBxGevbqtIQp8A2C1K =BB4e -----END PGP SIGNATURE----- From hartmans@mit.edu Tue Dec 6 07:23:24 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3E721F85A1 for ; Tue, 6 Dec 2011 07:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.215 X-Spam-Level: X-Spam-Status: No, score=-102.215 tagged_above=-999 required=5 tests=[AWL=0.050, 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 dCA-uKRzhMFm for ; Tue, 6 Dec 2011 07:23:24 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7C85421F8558 for ; Tue, 6 Dec 2011 07:23:24 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0D8392019A; Tue, 6 Dec 2011 10:23:38 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2BFA04367; Tue, 6 Dec 2011 10:23:17 -0500 (EST) From: Sam Hartman To: mrex@sap.com References: <201112060213.pB62Dab9012262@fs4113.wdf.sap.corp> Date: Tue, 06 Dec 2011 10:23:17 -0500 In-Reply-To: <201112060213.pB62Dab9012262@fs4113.wdf.sap.corp> (Martin Rex's message of "Tue, 6 Dec 2011 03:13:36 +0100 (MET)") 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] Another small update to naming exts X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2011 15:23:25 -0000 >>>>> "Martin" == Martin Rex writes: Martin> That sounds like a bad idea and *will* confuse apps Martin> developers, create a false sense of security and cause Martin> security problems. Martin, I think it is valuable to be able to represent mechanism features such as ap-req authorization data in Kerberos. From mrex@sap.com Tue Dec 6 09:10:33 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 D622321F8BF7 for ; Tue, 6 Dec 2011 09:10:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.11 X-Spam-Level: X-Spam-Status: No, score=-10.11 tagged_above=-999 required=5 tests=[AWL=0.139, 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 lkMIXWdhZMqs for ; Tue, 6 Dec 2011 09:10:33 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C2EAD21F8B81 for ; Tue, 6 Dec 2011 09:10:32 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pB6HAHrw008484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Dec 2011 18:10:17 +0100 (MET) From: Martin Rex Message-Id: <201112061710.pB6HAHIc002515@fs4113.wdf.sap.corp> To: nico@cryptonector.com (Nico Williams) Date: Tue, 6 Dec 2011 18:10:17 +0100 (MET) In-Reply-To: from "Nico Williams" at Dec 5, 11 01:40:12 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] new text for section 7.6 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: Tue, 06 Dec 2011 17:10:34 -0000 Nico Williams wrote: > > I don't think it's a problem to add new major status codes > specializing GSS_S_FAILURE since GSS_S_FAILURE is so generic and we > can't really define any minor status codes here by which to specialize > it. Huh? A GSS-API mechanism that returns GSS_S_FAILURE *without* and accompanying minor_status that translates into something that the end user can understand would be thoroughly broken. http://tools.ietf.org/html/rfc2744#page-14 The GSS major status code GSS_S_FAILURE is used to indicate that the underlying mechanism detected an error for which no specific GSS *> status code is defined. The mechanism-specific status code will *> provide more details about the error. ^^^^^^ > > Without enough information the application can only assume that > something went wrong, and it might as well do that when receiving any > unknown major status codes. In theory, portable applications can distinguish major status codes in order to use a programmatic remedy. i.e. an expired GSS-API security context could be worked around by establishing a new security context. But in general, programmatic recovery from any GSS-API errors is quite difficult. With GSS_S_FAILURE and mechanism-specific (and most of the time implementation-specific) error codes, programmatic recovery is limited to non-portable apps when used with specific implementations. > > This is a rule we probably want for the > API as a whole: whenever there are two or more error conditions for > which only GSS_S_FAILURE is specified we can later add a new major > status code to distinguish some of those error conditions. That sounds like a very bad idea. Because if there are error codes where distinguishing them at the mechanism level helps the user, some apps might code to recognize GSS_S_FAILURE in combination with the minor_status value. If you later define new major status codes and change the gssapi mechanism, you're going to break those apps in the installed base that work on recognizing the minor_status value. -Martin From stephen.farrell@cs.tcd.ie Thu Dec 15 04:52:21 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 E53E221F8ABB for ; Thu, 15 Dec 2011 04:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=1.150, 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 t4mw+zK3jsS5 for ; Thu, 15 Dec 2011 04:52:18 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id CE3EC21F8AB8 for ; Thu, 15 Dec 2011 04:52:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 109A4171C24 for ; Thu, 15 Dec 2011 12:52:15 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1323953530; bh=7ON2xVkzzm0h5B c7Nez7nUfSD9CJQCZtVw8Iw7Uu0YM=; b=oGxEbw9WancpwHXiMhBPVN0bnrL5Nu YBn8j9uo370oIV97CUrsey88e86kXBEc6YYjZkTGIcEGZT3YIs/iWf2+6pYS7MoS ka1Kcza1dmOYeasj6KFTs9l183xLIwxDhqW6WT2CITCPxZFVZjKy1QZrSeNfSg3+ 1hD/lY5Uw0qh22nuHYZCyzKx5WCgl6DgArYdBPgAGOyZGGuykR7rjEJp9lz7PNmP BP8c0U1/hJr3zVv1HJnLz92D9oXvT9NvoXFLoZfng1BEUisgGHNs+Tl6d8Zahzc1 5QV3Aus29hmmk8i17wlIFk6OYws6UZMQd6dWH2/UwZUNH7ckVUVb156A== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id M02MIJPQkTZa for ; Thu, 15 Dec 2011 12:52:10 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 9465E171BFE for ; Thu, 15 Dec 2011 12:52:10 +0000 (GMT) Message-ID: <4EE9ED7A.3040302@cs.tcd.ie> Date: Thu, 15 Dec 2011 12:52:10 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: kitten@ietf.org References: <4ECC405A.1000605@cs.tcd.ie> In-Reply-To: <4ECC405A.1000605@cs.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml 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, 15 Dec 2011 12:52:22 -0000 Folks, Any response to those questions of mine? This has been sitting a while... Or, have I missed the response and dropped the ball? Cheers, S. On 11/23/2011 12:37 AM, Stephen Farrell wrote: > > Hi, > > I've reviewed this and its ready or nearly ready for > IETF LC - I've a few questions though so I'm not sure. > (That's the first, numbered group in the attached.) > > Let's see if there's changes needed or not and then > proceed. (IESG comments on the openid spec might also > be worth a look with respect to this when we get them > next week.) > > Cheers, > S. > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From klaas@cisco.com Thu Dec 15 07:23:29 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 DD53221F8484 for ; Thu, 15 Dec 2011 07:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 iKmioMCtFzeK for ; Thu, 15 Dec 2011 07:23:26 -0800 (PST) Received: from out23-ams.mf.surf.net (out23-ams.mf.surf.net [145.0.1.23]) by ietfa.amsl.com (Postfix) with ESMTP id AA53B21F8483 for ; Thu, 15 Dec 2011 07:23:25 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pBFFNHEE025089; Thu, 15 Dec 2011 16:23:19 +0100 Received: from [84.35.81.2] (helo=[192.168.49.128]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1RbD7h-000Awj-D7; Thu, 15 Dec 2011 16:21:29 +0100 References: <4ECC405A.1000605@cs.tcd.ie> <4EE9ED7A.3040302@cs.tcd.ie> In-Reply-To: <4EE9ED7A.3040302@cs.tcd.ie> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Message-Id: <4881BF09-3949-4989-8B42-C89646A04282@cisco.com> Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (9A405) From: Klaas Wierenga Date: Thu, 15 Dec 2011 16:23:22 +0100 To: Stephen Farrell X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uG9rnhjP - 78a00f1aecac - 20111215 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.23 Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml 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, 15 Dec 2011 15:23:29 -0000 Stephen, No, nothing dropped on your side. The action is on me, I was on holidays and= will respond before Xmas. Klaas Sent from my iPad On 15 dec. 2011, at 13:53, "Stephen Farrell" wro= te: >=20 > Folks, >=20 > Any response to those questions of mine? This has > been sitting a while... >=20 > Or, have I missed the response and dropped the ball? >=20 > Cheers, > S. >=20 > On 11/23/2011 12:37 AM, Stephen Farrell wrote: >>=20 >> Hi, >>=20 >> I've reviewed this and its ready or nearly ready for >> IETF LC - I've a few questions though so I'm not sure. >> (That's the first, numbered group in the attached.) >>=20 >> Let's see if there's changes needed or not and then >> proceed. (IESG comments on the openid spec might also >> be worth a look with respect to this when we get them >> next week.) >>=20 >> Cheers, >> S. >>=20 >>=20 >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From leifj@mnt.se Fri Dec 16 14:59:05 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 1852921F8B02 for ; Fri, 16 Dec 2011 14:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.135 X-Spam-Level: X-Spam-Status: No, score=-2.135 tagged_above=-999 required=5 tests=[AWL=0.464, 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 mofkJou31rqB for ; Fri, 16 Dec 2011 14:59:04 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id E3AD121F8B01 for ; Fri, 16 Dec 2011 14:59:03 -0800 (PST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pBGMwqDS005360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2011 23:58:57 +0100 (CET) Message-ID: <4EEBCD2C.6020004@mnt.se> Date: Fri, 16 Dec 2011 23:58:52 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Nico Williams References: <4EA7B9FC.3000500@oracle.com> <4EA84C21.1090300@oracle.com> <4EA907E7.3080501@mnt.se> <4EA96C78.5010603@mnt.se> <4EBF28AF.5020200@mnt.se> <4EC07933.70003@oracle.com> <4EC32551.20906@mnt.se> <4EDD1E6D.3070000@mnt.se> <4EDD244F.9010608@mnt.se> In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] new text for section 7.6 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, 16 Dec 2011 22:59:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/05/2011 09:13 PM, Nico Williams wrote: > On Mon, Dec 5, 2011 at 2:06 PM, Leif Johansson > wrote: >> Call me picky but I'm not big on the 'we' thing in a >> specification. It sounds like some cabal that owns the spec that >> that is only partly true. > > We here is "the IETF". I don't see anything wrong with that, but > if you want to feel free to change that text to the passive voice > ("In the future ... may be added"). > > Nico -- Yeah If I can think of a way to give it some polish I will and if not I'll just use your text. In either case I'll drop a new version shortly. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7rzSwACgkQ8Jx8FtbMZnf1pACeKfSkhnmYqpWTWC0plRvENxaD vykAn13izYAU2qF3/y1DlVtzxhY+nxb6 =/AFR -----END PGP SIGNATURE----- From internet-drafts@ietf.org Fri Dec 16 15:04:46 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74F51F0C79; Fri, 16 Dec 2011 15:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 lbd1E9Lc-nCC; Fri, 16 Dec 2011 15:04:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654FC1F0C3F; Fri, 16 Dec 2011 15:04:46 -0800 (PST) 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.64p1 Message-ID: <20111216230446.3059.15446.idtracker@ietfa.amsl.com> Date: Fri, 16 Dec 2011 15:04:46 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-gssapi-naming-exts-12.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: Fri, 16 Dec 2011 23:04:47 -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 : GSS-API Naming Extensions Author(s) : Nicolas Williams Leif Johansson Sam Hartman Simon Josefsson Filename : draft-ietf-kitten-gssapi-naming-exts-12.txt Pages : 19 Date : 2011-12-16 The Generic Security Services API (GSS-API) provides a simple naming architecture that supports name-based authorization. This document introduces new APIs that extend the GSS-API naming model to support name attribute transfer between GSS-API peers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kitten-gssapi-naming-exts-12= .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-gssapi-naming-exts-12.= txt From klaas@cisco.com Mon Dec 19 02:14:15 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 7517621F8B46 for ; Mon, 19 Dec 2011 02:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MANGLED_SEX=2.3, 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 Ers7r3N6Pxag for ; Mon, 19 Dec 2011 02:14:14 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6610921F84CE for ; Mon, 19 Dec 2011 02:14:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=6491; q=dns/txt; s=iport; t=1324289654; x=1325499254; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=ds8hqRCnNwXEWFeUzeZjBD6g3a8PjJXym1QIC8g9gAw=; b=IFFojx4p0CZTHcdHcPN5ww0U0wLHG1aHh1OD1/mjktBZKABEv5m0Rkft 2i1qHxDG3u4+woPzeOJ40uH4JQIICD+eib1UPkyWjVrTy/qTqyBKJKCDX bgZrLp5pq6pBIjfl3+Bph3dLzhY89qa4UXkbXZ3eTeHhIeSVQhwwLcG43 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJkN706tJV2a/2dsb2JhbABDq1+BBYFyAQEBAwESAWYFCwtGVwY1h1iZZQGeEYshYwSUfpIv X-IronPort-AV: E=Sophos;i="4.71,375,1320624000"; d="scan'208";a="45103495" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 19 Dec 2011 10:14:14 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBJAECPG000665; Mon, 19 Dec 2011 10:14:13 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Klaas Wierenga In-Reply-To: <4ECC405A.1000605@cs.tcd.ie> Date: Mon, 19 Dec 2011 11:14:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ECC405A.1000605@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1251.1) Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 10:14:15 -0000 On Nov 23, 2011, at 1:37 AM, Stephen Farrell wrote: Hi Stephen, >=20 > I've reviewed this and its ready or nearly ready for > IETF LC - I've a few questions though so I'm not sure. > (That's the first, numbered group in the attached.) Thanks for your detailed review!=20 > Let's see if there's changes needed or not and then > proceed. (IESG comments on the openid spec might also > be worth a look with respect to this when we get them > next week.) questions: ---------- > #1, 1.2 - what does "or similar integrity protected and > authenticated channels" mean? If you mean IPsec, then saying that > seems right. The problem though is that people do say things like > this when they mean "use it in clear on the intranet" which is not > desirable here presumably. (I realise now I let this pass for the > openid spec but we could still fix that too;-) I'm sure we can come > up with a better wording that captures the WG's desired meaning but > doesn't leave open the option to just run this in clear. Hmm, IPsec is indeed the most obvious alternative, but I didn't want to = enumerate, acknowledging that is conceivable that other means to provide = integrity and authentication can be developed or used. I would argue = that an Intranet is NOT an "integrity protected and authenticated channel". How about just calling that out: "Because this mechanism transports information that should not be controlled by an attacker, the SAML 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, like through the use of IPsec. = [ RFC5280][RFC6125] note: An Intranet does not constitute such an integrity protected and = authenticated channel" > #2, s2, what does "sends a domain" mean near the end of p5? ehm, I assume you mean end of p4. It's a domain name, the assumption is = that one RP can serve multiple IdPs, the domain name is used by the RP = to construct the appropriate SAML request. In earlier versions we used = the SAML entity-id (a URL or URN) but given that it is likely that an = end-user may need to enter this into their client WG consensus was that = we needed something simpler, hence the domain name, assuming that it is = easy to either construct the request from that or do a simple lookup in = table that holds domain to entity-id mapping. See also 3.2 > #3, s3.2 says that the SASL server "transmits" stuff to the IdP, > but there's no line for that in figure 2 - what's up there? Is it > sent via the client really? Be less confusing to say so, if so. If > not, then I think something needs to change. ack, this line is multi interpretable, it is supposed to say that a = redirect uri (to the IdP) is sent to the client, not that something is = transmitted to the IdP. Proposed change: "The SASL Server transmits to the SASL client a redirect URI to the IdP = (corresponding to the domain the user provided), with a SAML authentication request as one of the parameters." > #4, s.3, says the client uses a "HTTP GET" - shouldn't that be > HTTPS? yes, or rather HTTP(S) > #5, s3.2, the client "MUST handle" auth with the IdP - that seems > ambiguous - how's I test for it? Maybe s/MUST handle/handles/ since > that's really SAML, right? yes, I agree, this is indeed outside the scope of this spec > #6, s3.2, what does it mean to say the client "relays the response > to the RP via HTTP(S)"? That makes the client sound like an HTTP > proxy which, I think, misleading. It is meant to indicate that the response is again transmitted by means = of a redirect of the browser, how about: "After all authentication has been completed by the IdP, the IdP will = send a redirect message to the client in the form of an HTTP(S) URI = corresponding to the Relying Party as specified in the authentication = request ("AssertionConsumerServiceURL") and with the SAML response as = one of the parameters." > #7 s4, the first para needs changes as were done with openid, e.g. > NORMATIVE isn't 2119 language etc. ack > minor, can be handled alongside IETF LC, or earlier, or not at all: > ------------------------------------------------------------------- >=20 > general: you sometimes talk about the "SASL server" and other times > use "Relying Party" or RP, I think it'd be good to say those are > basically the same (or whatever is the case). That's nearly all > there, at the end of 3.2, but I think it might be better to just > say that those are the same thing near the front and then just use > one of the terms all the time after that. Should be clearer for > coders I'd hope. yes, that makes sense =20 > s2, How is this about "non-HTTP Use Cases"? It seems much broader. > Suggest renaming the section, maybe to "Authentication Flow."=20 ack =20 > s2, "some sort of cookie" is a bit vague - can't you do better? yes we can ;-) > s2, Why "must" the RP "remain untouched"? That may be resonable but > it doesn't seem like its a must - you could have chosen to modify > the IdP if you'd liked. Maybe s/must remain/is better/? ehm, (assuming s/RP/IdP/) I suggest s/must remain/can remain/ (as this = is one of the distinguishing features from sasl-saml-ec) >=20 > s2, is 3986 really a useful reference for the URI sent at step 3 on > p5? Isn't there some saml reference that'd be better? hmm, yes that appears a bit generic, I'll dig up something better > s3.1, it might be useful to label the abnf as such (xml2rfc can > help with that a bit if you make it a figure with artwork of type > abnf). ack =20 > s3.x, it'd be good to tie the sections here back to figure 2, e.g. > put stuff like "(message 2 in Figure 2)" in as parenthethic notes. ack =20 > s6.1, is the encoding shown for steps 4, 5 and others obvious for > implementers? Maybe it is, but I was surprised. ehm, I'd like to think so ;-) What in particular surprises you?=20 >=20 > nits: > ----- >=20 > p3, s/We want to point out that the/The/ > p3, s/is optional/is OPTIONAL/ > p3, s/that uses/that use/ > p3, s/to a maximum extent/to the maximum extent/ > p3, s/The mechamsisms assumes/The mechanism assumes/ > p3, s/will continued to/will continue to/ > p4, s/Applicability Because/Because/ > p5, s/RP now has/The RP now has/ ack Thanks again, Klaas From stephen.farrell@cs.tcd.ie Mon Dec 19 05:20:10 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C6521F8B75 for ; Mon, 19 Dec 2011 05:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.299 X-Spam-Level: X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_SEX=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 594qQaxNjGfV for ; Mon, 19 Dec 2011 05:20:09 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id C76DF21F8B6D for ; Mon, 19 Dec 2011 05:20:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id DE255171C7B; Mon, 19 Dec 2011 13:20:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1324300805; bh=QCCUpIcGhxmI5D xb5i3AyslhnuNRFjrdtO3pPZxs0U4=; b=0ROeL2G1e2cGpp+uOL0MwHWUjH+NDN wl6q+NEh2000Iu639+MnSvxby1CnpNPeL67+nZbfkFNb6asdVW2CX1m/phiQ4B3T 9qxBVrCkDjVfuKL4BD9+k7X1q3pPmH0ewixwStquTI3obYedK5y72cYk6cokEosl jZFyvojO9aMSfgyYRHwGqj6sx4YQ399hjym+edrbHPNL1WjYe6JN+YovwcdUmFY4 pjjf9jpKlXxMX8x+yuMmtePvBzhnL+jVLP8b8zsBj4JVX7dBgHeOOvsTgE1HaBgS Bqe/E7+SrNOBEWuB36KA58NkdKFZXnD0BOt9w4i4s73uPZemvAEBfL1Q== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 96GB4nSBTW1j; Mon, 19 Dec 2011 13:20:05 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 75399171C69; Mon, 19 Dec 2011 13:20:01 +0000 (GMT) Message-ID: <4EEF39F7.2060108@cs.tcd.ie> Date: Mon, 19 Dec 2011 13:19:51 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Klaas Wierenga References: <4ECC405A.1000605@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 13:20:10 -0000 Hi Klaas, On 12/19/2011 10:14 AM, Klaas Wierenga wrote: > > On Nov 23, 2011, at 1:37 AM, Stephen Farrell wrote: > > Hi Stephen, > >> >> I've reviewed this and its ready or nearly ready for >> IETF LC - I've a few questions though so I'm not sure. >> (That's the first, numbered group in the attached.) > > Thanks for your detailed review! From the answers below I guess a revised I-D is going to help here so I've marked it thusly in the tracker. Let me know if that's wrong. > >> Let's see if there's changes needed or not and then >> proceed. (IESG comments on the openid spec might also >> be worth a look with respect to this when we get them >> next week.) > > questions: > ---------- > >> #1, 1.2 - what does "or similar integrity protected and >> authenticated channels" mean? If you mean IPsec, then saying that >> seems right. The problem though is that people do say things like >> this when they mean "use it in clear on the intranet" which is not >> desirable here presumably. (I realise now I let this pass for the >> openid spec but we could still fix that too;-) I'm sure we can come >> up with a better wording that captures the WG's desired meaning but >> doesn't leave open the option to just run this in clear. > > Hmm, IPsec is indeed the most obvious alternative, but I didn't want to enumerate, acknowledging that is conceivable that other means to provide integrity and authentication can be developed or used. I would argue that an Intranet is NOT an "integrity protected and > authenticated channel". How about just calling that out: > > "Because this mechanism transports information that > should not be controlled by an attacker, the SAML 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, like through the use of IPsec. [ > RFC5280][RFC6125] > > note: An Intranet does not constitute such an integrity protected and authenticated channel" I can live with that if the WG want to say it that way. > > >> #2, s2, what does "sends a domain" mean near the end of p5? > > ehm, I assume you mean end of p4. No, p5: " 2. The client initiates a SASL authentication with SAML20 and sends a domain" > It's a domain name, the assumption is that one RP can serve multiple IdPs, the domain name is used by the RP to construct the appropriate SAML request. In earlier versions we used the SAML entity-id (a URL or URN) but given that it is likely that an end-user may need to enter this into their client WG consensus was that we needed something simpler, hence the domain name, assuming that it is easy to either construct the request from that or do a simple lookup in table that holds domain to entity-id mapping. See also 3.2 So should it say "a domain name that allows the RP to contact the IdP" or something like that? > >> #3, s3.2 says that the SASL server "transmits" stuff to the IdP, >> but there's no line for that in figure 2 - what's up there? Is it >> sent via the client really? Be less confusing to say so, if so. If >> not, then I think something needs to change. > > ack, this line is multi interpretable, it is supposed to say that a redirect uri (to the IdP) is sent to the client, not that something is transmitted to the IdP. Proposed change: > > "The SASL Server transmits to the SASL client a redirect URI to the IdP (corresponding > to the domain the user provided), with a SAML authentication request > as one of the parameters." That helps. Maybe "redirect URI to the IdP" is a bit oddly phrased though. Perhaps "a URI that (re)directs the SASL client to the IdP" is better? A couple of follow on questions arising from that. Is the client expected to sanity check that URI in any way? What bad stuff might happen if the client doesn't do any checks? > >> #4, s.3, says the client uses a "HTTP GET" - shouldn't that be >> HTTPS? > > yes, or rather HTTP(S) Or maybe "an HTTP GET (sent over a server-authenticated TLS channel)" is what's really meant? > >> #5, s3.2, the client "MUST handle" auth with the IdP - that seems >> ambiguous - how's I test for it? Maybe s/MUST handle/handles/ since >> that's really SAML, right? > > yes, I agree, this is indeed outside the scope of this spec ok >> #6, s3.2, what does it mean to say the client "relays the response >> to the RP via HTTP(S)"? That makes the client sound like an HTTP >> proxy which, I think, misleading. > > It is meant to indicate that the response is again transmitted by means of a redirect of the browser, how about: > > "After all authentication has been completed by the IdP, the IdP will send a redirect message to the client in the form of an HTTP(S) URI corresponding to the Relying Party as specified in the authentication request ("AssertionConsumerServiceURL") and with the SAML response as one of the parameters." Better. But is "HTTP(S)" right here or "https" which the right scheme? >> #7 s4, the first para needs changes as were done with openid, e.g. >> NORMATIVE isn't 2119 language etc. > > ack Ok, as are the rest except the last one. > >> minor, can be handled alongside IETF LC, or earlier, or not at all: >> ------------------------------------------------------------------- >> >> general: you sometimes talk about the "SASL server" and other times >> use "Relying Party" or RP, I think it'd be good to say those are >> basically the same (or whatever is the case). That's nearly all >> there, at the end of 3.2, but I think it might be better to just >> say that those are the same thing near the front and then just use >> one of the terms all the time after that. Should be clearer for >> coders I'd hope. > > yes, that makes sense > >> s2, How is this about "non-HTTP Use Cases"? It seems much broader. >> Suggest renaming the section, maybe to "Authentication Flow." > > ack > >> s2, "some sort of cookie" is a bit vague - can't you do better? > > yes we can ;-) > >> s2, Why "must" the RP "remain untouched"? That may be resonable but >> it doesn't seem like its a must - you could have chosen to modify >> the IdP if you'd liked. Maybe s/must remain/is better/? > > ehm, (assuming s/RP/IdP/) I suggest s/must remain/can remain/ (as this is one of the distinguishing features from sasl-saml-ec) > >> >> s2, is 3986 really a useful reference for the URI sent at step 3 on >> p5? Isn't there some saml reference that'd be better? > > hmm, yes that appears a bit generic, I'll dig up something better > >> s3.1, it might be useful to label the abnf as such (xml2rfc can >> help with that a bit if you make it a figure with artwork of type >> abnf). > > ack > >> s3.x, it'd be good to tie the sections here back to figure 2, e.g. >> put stuff like "(message 2 in Figure 2)" in as parenthethic notes. > > ack > >> s6.1, is the encoding shown for steps 4, 5 and others obvious for >> implementers? Maybe it is, but I was surprised. > > ehm, I'd like to think so ;-) What in particular surprises you? I was surprised by the volume of base64 and the lack of detail as to how its generated. If you tell me its obvious to implementers then fine. (Has someone coded this up from the spec who's not an author?) Cheers, S > >> >> nits: >> ----- >> >> p3, s/We want to point out that the/The/ >> p3, s/is optional/is OPTIONAL/ >> p3, s/that uses/that use/ >> p3, s/to a maximum extent/to the maximum extent/ >> p3, s/The mechamsisms assumes/The mechanism assumes/ >> p3, s/will continued to/will continue to/ >> p4, s/Applicability Because/Because/ >> p5, s/RP now has/The RP now has/ > > ack > > Thanks again, > > Klaas > > From klaas@cisco.com Mon Dec 19 05:45: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 7FA1321F8A55 for ; Mon, 19 Dec 2011 05:45:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, MANGLED_SEX=2.3, 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 MlHqJRPLbe49 for ; Mon, 19 Dec 2011 05:45:53 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDC021F8505 for ; Mon, 19 Dec 2011 05:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=9177; q=dns/txt; s=iport; t=1324302353; x=1325511953; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5bH4RNEGW0TjlRb4hJT6dKLjUT3yJeOcelLZIfeLme0=; b=MLmNB7Y58xiPlN+B3mo1UF9lSJCryekMPKb488gF37/wOYGhBzijRY3y hd2iRGY456RhQulKqD3F33CCDLoNWQsmOYLdjbEDJqV1tcenZ1tOf/8VH nxdjHKJ/R7wuNOFVlMYG/449S7JE6H7qfAVcxLAtAUhBLflfwYghuWHDM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPI/706tJXG9/2dsb2JhbABDqROCTYEFgXIBAQEDARIBZgULCxguVwY1h1iZSgGeKYshYwSUfpIv X-IronPort-AV: E=Sophos;i="4.71,376,1320624000"; d="scan'208";a="45178126" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 19 Dec 2011 13:45:48 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id pBJDjljN024558; Mon, 19 Dec 2011 13:45:47 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Klaas Wierenga In-Reply-To: <4EEF39F7.2060108@cs.tcd.ie> Date: Mon, 19 Dec 2011 14:45:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <15C7DDA7-C249-4D72-8E77-F822CD4192E6@cisco.com> References: <4ECC405A.1000605@cs.tcd.ie> <4EEF39F7.2060108@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1251.1) Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 13:45:54 -0000 On Dec 19, 2011, at 2:19 PM, Stephen Farrell wrote: Hi, >=20 > Hi Klaas, >=20 > On 12/19/2011 10:14 AM, Klaas Wierenga wrote: >>=20 >> On Nov 23, 2011, at 1:37 AM, Stephen Farrell wrote: >>=20 >> Hi Stephen, >>=20 >>>=20 >>> I've reviewed this and its ready or nearly ready for >>> IETF LC - I've a few questions though so I'm not sure. >>> (That's the first, numbered group in the attached.) >>=20 >> Thanks for your detailed review! >=20 > =46rom the answers below I guess a revised I-D is going > to help here so I've marked it thusly in the tracker. > Let me know if that's wrong. No, I think that is right. >>=20 >>> Let's see if there's changes needed or not and then >>> proceed. (IESG comments on the openid spec might also >>> be worth a look with respect to this when we get them >>> next week.) >>=20 >> questions: >> ---------- >>=20 >>> #1, 1.2 - what does "or similar integrity protected and >>> authenticated channels" mean? If you mean IPsec, then saying that >>> seems right. The problem though is that people do say things like >>> this when they mean "use it in clear on the intranet" which is not >>> desirable here presumably. (I realise now I let this pass for the >>> openid spec but we could still fix that too;-) I'm sure we can come >>> up with a better wording that captures the WG's desired meaning but >>> doesn't leave open the option to just run this in clear. >>=20 >> Hmm, IPsec is indeed the most obvious alternative, but I didn't want = to enumerate, acknowledging that is conceivable that other means to = provide integrity and authentication can be developed or used. I would = argue that an Intranet is NOT an "integrity protected and >> authenticated channel". How about just calling that out: >>=20 >> "Because this mechanism transports information that >> should not be controlled by an attacker, the SAML 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, like through the use of = IPsec. [ >> RFC5280][RFC6125] >>=20 >> note: An Intranet does not constitute such an integrity protected and = authenticated channel" >=20 > I can live with that if the WG want to say it > that way. >=20 >>=20 >>=20 >>> #2, s2, what does "sends a domain" mean near the end of p5? >>=20 >> ehm, I assume you mean end of p4. >=20 > No, p5: >=20 > " 2. The client initiates a SASL authentication with SAML20 and = sends > a domain" >=20 > > It's a domain name, the assumption is that one RP can serve multiple = IdPs, the domain name is used by the RP to construct the appropriate = SAML request. In earlier versions we used the SAML entity-id (a URL or = URN) but given that it is likely that an end-user may need to enter this = into their client WG consensus was that we needed something simpler, = hence the domain name, assuming that it is easy to either construct the = request from that or do a simple lookup in table that holds domain to = entity-id mapping. See also 3.2 >=20 > So should it say "a domain name that allows the RP to contact the IdP" > or something like that? Ehm, I would prefer to say "a domain name that allows the RP to = determine the appropriate IdP" >=20 >>=20 >>> #3, s3.2 says that the SASL server "transmits" stuff to the IdP, >>> but there's no line for that in figure 2 - what's up there? Is it >>> sent via the client really? Be less confusing to say so, if so. If >>> not, then I think something needs to change. >>=20 >> ack, this line is multi interpretable, it is supposed to say that a = redirect uri (to the IdP) is sent to the client, not that something is = transmitted to the IdP. Proposed change: >>=20 >> "The SASL Server transmits to the SASL client a redirect URI to the = IdP (corresponding >> to the domain the user provided), with a SAML authentication = request >> as one of the parameters." >=20 > That helps. Maybe "redirect URI to the IdP" is a bit oddly > phrased though. Perhaps "a URI that (re)directs the SASL client to > the IdP" is better? a gladly accept your native speaker formulation > A couple of follow on questions arising from that. Is the client > expected to sanity check that URI in any way? What bad stuff > might happen if the client doesn't do any checks? >=20 >>=20 >>> #4, s.3, says the client uses a "HTTP GET" - shouldn't that be >>> HTTPS? >>=20 >> yes, or rather HTTP(S) >=20 > Or maybe "an HTTP GET (sent over a server-authenticated TLS > channel)" is what's really meant? Ehm, is there a difference, apart from the fact that you (rightfully) = call out that the server needs to be authenticated? Or is this to make = it more generic for all integrity protected channels with server = authentication? Maybe I just miss your point. >=20 >>=20 >>> #5, s3.2, the client "MUST handle" auth with the IdP - that seems >>> ambiguous - how's I test for it? Maybe s/MUST handle/handles/ since >>> that's really SAML, right? >>=20 >> yes, I agree, this is indeed outside the scope of this spec >=20 > ok >=20 >>> #6, s3.2, what does it mean to say the client "relays the response >>> to the RP via HTTP(S)"? That makes the client sound like an HTTP >>> proxy which, I think, misleading. >>=20 >> It is meant to indicate that the response is again transmitted by = means of a redirect of the browser, how about: >>=20 >> "After all authentication has been completed by the IdP, the IdP will = send a redirect message to the client in the form of an HTTP(S) URI = corresponding to the Relying Party as specified in the authentication = request ("AssertionConsumerServiceURL") and with the SAML response as = one of the parameters." >=20 > Better. But is "HTTP(S)" right here or "https" which the > right scheme? I guess this goes to the previous question >=20 >>> #7 s4, the first para needs changes as were done with openid, e.g. >>> NORMATIVE isn't 2119 language etc. >>=20 >> ack >=20 > Ok, as are the rest except the last one. >=20 >>=20 >>> minor, can be handled alongside IETF LC, or earlier, or not at all: >>> ------------------------------------------------------------------- >>>=20 >>> general: you sometimes talk about the "SASL server" and other times >>> use "Relying Party" or RP, I think it'd be good to say those are >>> basically the same (or whatever is the case). That's nearly all >>> there, at the end of 3.2, but I think it might be better to just >>> say that those are the same thing near the front and then just use >>> one of the terms all the time after that. Should be clearer for >>> coders I'd hope. >>=20 >> yes, that makes sense >>=20 >>> s2, How is this about "non-HTTP Use Cases"? It seems much broader. >>> Suggest renaming the section, maybe to "Authentication Flow." >>=20 >> ack >>=20 >>> s2, "some sort of cookie" is a bit vague - can't you do better? >>=20 >> yes we can ;-) >>=20 >>> s2, Why "must" the RP "remain untouched"? That may be resonable but >>> it doesn't seem like its a must - you could have chosen to modify >>> the IdP if you'd liked. Maybe s/must remain/is better/? >>=20 >> ehm, (assuming s/RP/IdP/) I suggest s/must remain/can remain/ (as = this is one of the distinguishing features from sasl-saml-ec) >>=20 >>>=20 >>> s2, is 3986 really a useful reference for the URI sent at step 3 on >>> p5? Isn't there some saml reference that'd be better? >>=20 >> hmm, yes that appears a bit generic, I'll dig up something better >>=20 >>> s3.1, it might be useful to label the abnf as such (xml2rfc can >>> help with that a bit if you make it a figure with artwork of type >>> abnf). >>=20 >> ack >>=20 >>> s3.x, it'd be good to tie the sections here back to figure 2, e.g. >>> put stuff like "(message 2 in Figure 2)" in as parenthethic notes. >>=20 >> ack >>=20 >>> s6.1, is the encoding shown for steps 4, 5 and others obvious for >>> implementers? Maybe it is, but I was surprised. >>=20 >> ehm, I'd like to think so ;-) What in particular surprises you? >=20 > I was surprised by the volume of base64 and the lack of detail > as to how its generated. ah ok, I am not particularly happy about the double base64 encoding = myself, but this is how I understand the SASL and SAML specs > If you tell me its obvious to implementers then fine. > (Has someone coded this up from the spec who's not an author?) Well, I had a student implement from the spec, but admittedly, I was = around to answer questions Klaas > Cheers, > S >=20 >>=20 >>>=20 >>> nits: >>> ----- >>>=20 >>> p3, s/We want to point out that the/The/ >>> p3, s/is optional/is OPTIONAL/ >>> p3, s/that uses/that use/ >>> p3, s/to a maximum extent/to the maximum extent/ >>> p3, s/The mechamsisms assumes/The mechanism assumes/ >>> p3, s/will continued to/will continue to/ >>> p4, s/Applicability Because/Because/ >>> p5, s/RP now has/The RP now has/ >>=20 >> ack >>=20 >> Thanks again, >>=20 >> Klaas >>=20 >>=20 From stephen.farrell@cs.tcd.ie Mon Dec 19 05:54:37 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 42C9E21F8AF3 for ; Mon, 19 Dec 2011 05:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.299 X-Spam-Level: X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_SEX=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5MEg+5ZD7he for ; Mon, 19 Dec 2011 05:54:36 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 3198121F8AD2 for ; Mon, 19 Dec 2011 05:54:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 7DA2F171C6B; Mon, 19 Dec 2011 13:54:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1324302875; bh=buBqtoPrm5HY02 EPEUIZc3wcfJDjl0kiaLz6yhtkpuI=; b=OS6EubSrJTdY+moN9ttZEAi1KieaSA Falb/kVdNZSpXP4ngNp54Qj3ckw7Ctie1aeYAWvJNvO+lS98KaJ6adlucQgQ9hOR U1HqYxFD/FwZIDCGZXkjp8t/OJffLLMqBQeHD6d0BRCiFNc75hma+eqg/z20afSo tKJTUBOpsu/xgXtpJT+x0yJN7RWFjGw94fuuEkw8+yYGi6UgMknFAYt7Q2eIc/m2 109NQL3sgZGR/rw7PbYxr3cV1bU2knBoUj+Daus3FZH5STxk5deostggrBGY1PIO wMZuMRtkTBrSicq6cmyHXntf8IoIi7csWgOUqE7EZ7B1mfxtJySZ/0MQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id X6wp4iQLxZhX; Mon, 19 Dec 2011 13:54:35 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 1BF0E171C69; Mon, 19 Dec 2011 13:54:34 +0000 (GMT) Message-ID: <4EEF4210.7020002@cs.tcd.ie> Date: Mon, 19 Dec 2011 13:54:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Klaas Wierenga References: <4ECC405A.1000605@cs.tcd.ie> <4EEF39F7.2060108@cs.tcd.ie> <15C7DDA7-C249-4D72-8E77-F822CD4192E6@cisco.com> In-Reply-To: <15C7DDA7-C249-4D72-8E77-F822CD4192E6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 13:54:37 -0000 Hiya, I guess the only point below is how to phrase "HTTP(S)" throughout. I guess I'm not that fond of "HTTP(S)" since to me it means "either HTTP or HTTP/TLS" and that's not really what you mean here. Or maybe I'm getting stuff wrong again;-) S On 12/19/2011 01:45 PM, Klaas Wierenga wrote: > > On Dec 19, 2011, at 2:19 PM, Stephen Farrell wrote: > > Hi, > >> >> Hi Klaas, >> >> On 12/19/2011 10:14 AM, Klaas Wierenga wrote: >>> >>> On Nov 23, 2011, at 1:37 AM, Stephen Farrell wrote: >>> >>> Hi Stephen, >>> >>>> >>>> I've reviewed this and its ready or nearly ready for >>>> IETF LC - I've a few questions though so I'm not sure. >>>> (That's the first, numbered group in the attached.) >>> >>> Thanks for your detailed review! >> >> From the answers below I guess a revised I-D is going >> to help here so I've marked it thusly in the tracker. >> Let me know if that's wrong. > > No, I think that is right. > >>> >>>> Let's see if there's changes needed or not and then >>>> proceed. (IESG comments on the openid spec might also >>>> be worth a look with respect to this when we get them >>>> next week.) >>> >>> questions: >>> ---------- >>> >>>> #1, 1.2 - what does "or similar integrity protected and >>>> authenticated channels" mean? If you mean IPsec, then saying that >>>> seems right. The problem though is that people do say things like >>>> this when they mean "use it in clear on the intranet" which is not >>>> desirable here presumably. (I realise now I let this pass for the >>>> openid spec but we could still fix that too;-) I'm sure we can come >>>> up with a better wording that captures the WG's desired meaning but >>>> doesn't leave open the option to just run this in clear. >>> >>> Hmm, IPsec is indeed the most obvious alternative, but I didn't want to enumerate, acknowledging that is conceivable that other means to provide integrity and authentication can be developed or used. I would argue that an Intranet is NOT an "integrity protected and >>> authenticated channel". How about just calling that out: >>> >>> "Because this mechanism transports information that >>> should not be controlled by an attacker, the SAML 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, like through the use of IPsec. [ >>> RFC5280][RFC6125] >>> >>> note: An Intranet does not constitute such an integrity protected and authenticated channel" >> >> I can live with that if the WG want to say it >> that way. >> >>> >>> >>>> #2, s2, what does "sends a domain" mean near the end of p5? >>> >>> ehm, I assume you mean end of p4. >> >> No, p5: >> >> " 2. The client initiates a SASL authentication with SAML20 and sends >> a domain" >> >>> It's a domain name, the assumption is that one RP can serve multiple IdPs, the domain name is used by the RP to construct the appropriate SAML request. In earlier versions we used the SAML entity-id (a URL or URN) but given that it is likely that an end-user may need to enter this into their client WG consensus was that we needed something simpler, hence the domain name, assuming that it is easy to either construct the request from that or do a simple lookup in table that holds domain to entity-id mapping. See also 3.2 >> >> So should it say "a domain name that allows the RP to contact the IdP" >> or something like that? > > Ehm, I would prefer to say "a domain name that allows the RP to determine the appropriate IdP" > >> >>> >>>> #3, s3.2 says that the SASL server "transmits" stuff to the IdP, >>>> but there's no line for that in figure 2 - what's up there? Is it >>>> sent via the client really? Be less confusing to say so, if so. If >>>> not, then I think something needs to change. >>> >>> ack, this line is multi interpretable, it is supposed to say that a redirect uri (to the IdP) is sent to the client, not that something is transmitted to the IdP. Proposed change: >>> >>> "The SASL Server transmits to the SASL client a redirect URI to the IdP (corresponding >>> to the domain the user provided), with a SAML authentication request >>> as one of the parameters." >> >> That helps. Maybe "redirect URI to the IdP" is a bit oddly >> phrased though. Perhaps "a URI that (re)directs the SASL client to >> the IdP" is better? > > a gladly accept your native speaker formulation > >> A couple of follow on questions arising from that. Is the client >> expected to sanity check that URI in any way? What bad stuff >> might happen if the client doesn't do any checks? >> >>> >>>> #4, s.3, says the client uses a "HTTP GET" - shouldn't that be >>>> HTTPS? >>> >>> yes, or rather HTTP(S) >> >> Or maybe "an HTTP GET (sent over a server-authenticated TLS >> channel)" is what's really meant? > > Ehm, is there a difference, apart from the fact that you (rightfully) call out that the server needs to be authenticated? Or is this to make it more generic for all integrity protected channels with server authentication? Maybe I just miss your point. > >> >>> >>>> #5, s3.2, the client "MUST handle" auth with the IdP - that seems >>>> ambiguous - how's I test for it? Maybe s/MUST handle/handles/ since >>>> that's really SAML, right? >>> >>> yes, I agree, this is indeed outside the scope of this spec >> >> ok >> >>>> #6, s3.2, what does it mean to say the client "relays the response >>>> to the RP via HTTP(S)"? That makes the client sound like an HTTP >>>> proxy which, I think, misleading. >>> >>> It is meant to indicate that the response is again transmitted by means of a redirect of the browser, how about: >>> >>> "After all authentication has been completed by the IdP, the IdP will send a redirect message to the client in the form of an HTTP(S) URI corresponding to the Relying Party as specified in the authentication request ("AssertionConsumerServiceURL") and with the SAML response as one of the parameters." >> >> Better. But is "HTTP(S)" right here or "https" which the >> right scheme? > > I guess this goes to the previous question > >> >>>> #7 s4, the first para needs changes as were done with openid, e.g. >>>> NORMATIVE isn't 2119 language etc. >>> >>> ack >> >> Ok, as are the rest except the last one. >> >>> >>>> minor, can be handled alongside IETF LC, or earlier, or not at all: >>>> ------------------------------------------------------------------- >>>> >>>> general: you sometimes talk about the "SASL server" and other times >>>> use "Relying Party" or RP, I think it'd be good to say those are >>>> basically the same (or whatever is the case). That's nearly all >>>> there, at the end of 3.2, but I think it might be better to just >>>> say that those are the same thing near the front and then just use >>>> one of the terms all the time after that. Should be clearer for >>>> coders I'd hope. >>> >>> yes, that makes sense >>> >>>> s2, How is this about "non-HTTP Use Cases"? It seems much broader. >>>> Suggest renaming the section, maybe to "Authentication Flow." >>> >>> ack >>> >>>> s2, "some sort of cookie" is a bit vague - can't you do better? >>> >>> yes we can ;-) >>> >>>> s2, Why "must" the RP "remain untouched"? That may be resonable but >>>> it doesn't seem like its a must - you could have chosen to modify >>>> the IdP if you'd liked. Maybe s/must remain/is better/? >>> >>> ehm, (assuming s/RP/IdP/) I suggest s/must remain/can remain/ (as this is one of the distinguishing features from sasl-saml-ec) >>> >>>> >>>> s2, is 3986 really a useful reference for the URI sent at step 3 on >>>> p5? Isn't there some saml reference that'd be better? >>> >>> hmm, yes that appears a bit generic, I'll dig up something better >>> >>>> s3.1, it might be useful to label the abnf as such (xml2rfc can >>>> help with that a bit if you make it a figure with artwork of type >>>> abnf). >>> >>> ack >>> >>>> s3.x, it'd be good to tie the sections here back to figure 2, e.g. >>>> put stuff like "(message 2 in Figure 2)" in as parenthethic notes. >>> >>> ack >>> >>>> s6.1, is the encoding shown for steps 4, 5 and others obvious for >>>> implementers? Maybe it is, but I was surprised. >>> >>> ehm, I'd like to think so ;-) What in particular surprises you? >> >> I was surprised by the volume of base64 and the lack of detail >> as to how its generated. > > ah ok, I am not particularly happy about the double base64 encoding myself, but this is how I understand the SASL and SAML specs > >> If you tell me its obvious to implementers then fine. >> (Has someone coded this up from the spec who's not an author?) > > Well, I had a student implement from the spec, but admittedly, I was around to answer questions > > Klaas > >> Cheers, >> S >> >>> >>>> >>>> nits: >>>> ----- >>>> >>>> p3, s/We want to point out that the/The/ >>>> p3, s/is optional/is OPTIONAL/ >>>> p3, s/that uses/that use/ >>>> p3, s/to a maximum extent/to the maximum extent/ >>>> p3, s/The mechamsisms assumes/The mechanism assumes/ >>>> p3, s/will continued to/will continue to/ >>>> p4, s/Applicability Because/Because/ >>>> p5, s/RP now has/The RP now has/ >>> >>> ack >>> >>> Thanks again, >>> >>> Klaas >>> >>> > > From klaas@cisco.com Mon Dec 19 06:18: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 069361F0C38 for ; Mon, 19 Dec 2011 06:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.927 X-Spam-Level: X-Spam-Status: No, score=-3.927 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, MANGLED_SEX=2.3, 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 vbrhJvc1Mqww for ; Mon, 19 Dec 2011 06:18:39 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E4F6021F8B57 for ; Mon, 19 Dec 2011 06:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=10180; q=dns/txt; s=iport; t=1324304319; x=1325513919; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=JRGFE6ON4pnWH1HzMZTh0pOEvwQfKsBhs3/RRqz3HHc=; b=Af+39U6LhLH3dztYJGz20pueRlmZOgqVrF5FwDLsBR4l8aQbrIIUF33r FhctNHhBUSoFOsS/MD4UW4nrZFGBG8GpNic29g8UcExFBl8hzUJgGYBTz 0PvgUOaZ6C3wesJ5fyexqBKyQiFzqk/qSuKFXJWga4C1j1WCtOIPuPFly k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAIhG706tJV2c/2dsb2JhbABDqROCTYEFgXIBAQEDARIBZgULCxguVwY1h1iZTgGeJYshYwSUfpIv X-IronPort-AV: E=Sophos;i="4.71,376,1320624000"; d="scan'208";a="45176509" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 19 Dec 2011 14:18:38 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id pBJEIafY024814; Mon, 19 Dec 2011 14:18:37 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Klaas Wierenga In-Reply-To: <4EEF4210.7020002@cs.tcd.ie> Date: Mon, 19 Dec 2011 15:18:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ECC405A.1000605@cs.tcd.ie> <4EEF39F7.2060108@cs.tcd.ie> <15C7DDA7-C249-4D72-8E77-F822CD4192E6@cisco.com> <4EEF4210.7020002@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1251.1) Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 14:18:40 -0000 On Dec 19, 2011, at 2:54 PM, Stephen Farrell wrote: Hi, > I guess the only point below is how to phrase > "HTTP(S)" throughout. I guess I'm not that > fond of "HTTP(S)" since to me it means "either > HTTP or HTTP/TLS" and that's not really what > you mean here. Or maybe I'm getting stuff wrong > again;-) ah ok, let me try to rephrase=20 Klaas >=20 > S >=20 > On 12/19/2011 01:45 PM, Klaas Wierenga wrote: >>=20 >> On Dec 19, 2011, at 2:19 PM, Stephen Farrell wrote: >>=20 >> Hi, >>=20 >>>=20 >>> Hi Klaas, >>>=20 >>> On 12/19/2011 10:14 AM, Klaas Wierenga wrote: >>>>=20 >>>> On Nov 23, 2011, at 1:37 AM, Stephen Farrell wrote: >>>>=20 >>>> Hi Stephen, >>>>=20 >>>>>=20 >>>>> I've reviewed this and its ready or nearly ready for >>>>> IETF LC - I've a few questions though so I'm not sure. >>>>> (That's the first, numbered group in the attached.) >>>>=20 >>>> Thanks for your detailed review! >>>=20 >>> =46rom the answers below I guess a revised I-D is going >>> to help here so I've marked it thusly in the tracker. >>> Let me know if that's wrong. >>=20 >> No, I think that is right. >>=20 >>>>=20 >>>>> Let's see if there's changes needed or not and then >>>>> proceed. (IESG comments on the openid spec might also >>>>> be worth a look with respect to this when we get them >>>>> next week.) >>>>=20 >>>> questions: >>>> ---------- >>>>=20 >>>>> #1, 1.2 - what does "or similar integrity protected and >>>>> authenticated channels" mean? If you mean IPsec, then saying that >>>>> seems right. The problem though is that people do say things like >>>>> this when they mean "use it in clear on the intranet" which is not >>>>> desirable here presumably. (I realise now I let this pass for the >>>>> openid spec but we could still fix that too;-) I'm sure we can = come >>>>> up with a better wording that captures the WG's desired meaning = but >>>>> doesn't leave open the option to just run this in clear. >>>>=20 >>>> Hmm, IPsec is indeed the most obvious alternative, but I didn't = want to enumerate, acknowledging that is conceivable that other means to = provide integrity and authentication can be developed or used. I would = argue that an Intranet is NOT an "integrity protected and >>>> authenticated channel". How about just calling that out: >>>>=20 >>>> "Because this mechanism transports information that >>>> should not be controlled by an attacker, the SAML 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, like through the use of = IPsec. [ >>>> RFC5280][RFC6125] >>>>=20 >>>> note: An Intranet does not constitute such an integrity protected = and authenticated channel" >>>=20 >>> I can live with that if the WG want to say it >>> that way. >>>=20 >>>>=20 >>>>=20 >>>>> #2, s2, what does "sends a domain" mean near the end of p5? >>>>=20 >>>> ehm, I assume you mean end of p4. >>>=20 >>> No, p5: >>>=20 >>> " 2. The client initiates a SASL authentication with SAML20 and = sends >>> a domain" >>>=20 >>>> It's a domain name, the assumption is that one RP can serve = multiple IdPs, the domain name is used by the RP to construct the = appropriate SAML request. In earlier versions we used the SAML entity-id = (a URL or URN) but given that it is likely that an end-user may need to = enter this into their client WG consensus was that we needed something = simpler, hence the domain name, assuming that it is easy to either = construct the request from that or do a simple lookup in table that = holds domain to entity-id mapping. See also 3.2 >>>=20 >>> So should it say "a domain name that allows the RP to contact the = IdP" >>> or something like that? >>=20 >> Ehm, I would prefer to say "a domain name that allows the RP to = determine the appropriate IdP" >>=20 >>>=20 >>>>=20 >>>>> #3, s3.2 says that the SASL server "transmits" stuff to the IdP, >>>>> but there's no line for that in figure 2 - what's up there? Is it >>>>> sent via the client really? Be less confusing to say so, if so. = If >>>>> not, then I think something needs to change. >>>>=20 >>>> ack, this line is multi interpretable, it is supposed to say that a = redirect uri (to the IdP) is sent to the client, not that something is = transmitted to the IdP. Proposed change: >>>>=20 >>>> "The SASL Server transmits to the SASL client a redirect URI to the = IdP (corresponding >>>> to the domain the user provided), with a SAML authentication = request >>>> as one of the parameters." >>>=20 >>> That helps. Maybe "redirect URI to the IdP" is a bit oddly >>> phrased though. Perhaps "a URI that (re)directs the SASL client to >>> the IdP" is better? >>=20 >> a gladly accept your native speaker formulation >>=20 >>> A couple of follow on questions arising from that. Is the client >>> expected to sanity check that URI in any way? What bad stuff >>> might happen if the client doesn't do any checks? >>>=20 >>>>=20 >>>>> #4, s.3, says the client uses a "HTTP GET" - shouldn't that be >>>>> HTTPS? >>>>=20 >>>> yes, or rather HTTP(S) >>>=20 >>> Or maybe "an HTTP GET (sent over a server-authenticated TLS >>> channel)" is what's really meant? >>=20 >> Ehm, is there a difference, apart from the fact that you (rightfully) = call out that the server needs to be authenticated? Or is this to make = it more generic for all integrity protected channels with server = authentication? Maybe I just miss your point. >>=20 >>>=20 >>>>=20 >>>>> #5, s3.2, the client "MUST handle" auth with the IdP - that seems >>>>> ambiguous - how's I test for it? Maybe s/MUST handle/handles/ = since >>>>> that's really SAML, right? >>>>=20 >>>> yes, I agree, this is indeed outside the scope of this spec >>>=20 >>> ok >>>=20 >>>>> #6, s3.2, what does it mean to say the client "relays the response >>>>> to the RP via HTTP(S)"? That makes the client sound like an HTTP >>>>> proxy which, I think, misleading. >>>>=20 >>>> It is meant to indicate that the response is again transmitted by = means of a redirect of the browser, how about: >>>>=20 >>>> "After all authentication has been completed by the IdP, the IdP = will send a redirect message to the client in the form of an HTTP(S) URI = corresponding to the Relying Party as specified in the authentication = request ("AssertionConsumerServiceURL") and with the SAML response as = one of the parameters." >>>=20 >>> Better. But is "HTTP(S)" right here or "https" which the >>> right scheme? >>=20 >> I guess this goes to the previous question >>=20 >>>=20 >>>>> #7 s4, the first para needs changes as were done with openid, e.g. >>>>> NORMATIVE isn't 2119 language etc. >>>>=20 >>>> ack >>>=20 >>> Ok, as are the rest except the last one. >>>=20 >>>>=20 >>>>> minor, can be handled alongside IETF LC, or earlier, or not at = all: >>>>> = ------------------------------------------------------------------- >>>>>=20 >>>>> general: you sometimes talk about the "SASL server" and other = times >>>>> use "Relying Party" or RP, I think it'd be good to say those are >>>>> basically the same (or whatever is the case). That's nearly all >>>>> there, at the end of 3.2, but I think it might be better to just >>>>> say that those are the same thing near the front and then just use >>>>> one of the terms all the time after that. Should be clearer for >>>>> coders I'd hope. >>>>=20 >>>> yes, that makes sense >>>>=20 >>>>> s2, How is this about "non-HTTP Use Cases"? It seems much broader. >>>>> Suggest renaming the section, maybe to "Authentication Flow." >>>>=20 >>>> ack >>>>=20 >>>>> s2, "some sort of cookie" is a bit vague - can't you do better? >>>>=20 >>>> yes we can ;-) >>>>=20 >>>>> s2, Why "must" the RP "remain untouched"? That may be resonable = but >>>>> it doesn't seem like its a must - you could have chosen to modify >>>>> the IdP if you'd liked. Maybe s/must remain/is better/? >>>>=20 >>>> ehm, (assuming s/RP/IdP/) I suggest s/must remain/can remain/ (as = this is one of the distinguishing features from sasl-saml-ec) >>>>=20 >>>>>=20 >>>>> s2, is 3986 really a useful reference for the URI sent at step 3 = on >>>>> p5? Isn't there some saml reference that'd be better? >>>>=20 >>>> hmm, yes that appears a bit generic, I'll dig up something better >>>>=20 >>>>> s3.1, it might be useful to label the abnf as such (xml2rfc can >>>>> help with that a bit if you make it a figure with artwork of type >>>>> abnf). >>>>=20 >>>> ack >>>>=20 >>>>> s3.x, it'd be good to tie the sections here back to figure 2, e.g. >>>>> put stuff like "(message 2 in Figure 2)" in as parenthethic notes. >>>>=20 >>>> ack >>>>=20 >>>>> s6.1, is the encoding shown for steps 4, 5 and others obvious for >>>>> implementers? Maybe it is, but I was surprised. >>>>=20 >>>> ehm, I'd like to think so ;-) What in particular surprises you? >>>=20 >>> I was surprised by the volume of base64 and the lack of detail >>> as to how its generated. >>=20 >> ah ok, I am not particularly happy about the double base64 encoding = myself, but this is how I understand the SASL and SAML specs >>=20 >>> If you tell me its obvious to implementers then fine. >>> (Has someone coded this up from the spec who's not an author?) >>=20 >> Well, I had a student implement from the spec, but admittedly, I was = around to answer questions >>=20 >> Klaas >>=20 >>> Cheers, >>> S >>>=20 >>>>=20 >>>>>=20 >>>>> nits: >>>>> ----- >>>>>=20 >>>>> p3, s/We want to point out that the/The/ >>>>> p3, s/is optional/is OPTIONAL/ >>>>> p3, s/that uses/that use/ >>>>> p3, s/to a maximum extent/to the maximum extent/ >>>>> p3, s/The mechamsisms assumes/The mechanism assumes/ >>>>> p3, s/will continued to/will continue to/ >>>>> p4, s/Applicability Because/Because/ >>>>> p5, s/RP now has/The RP now has/ >>>>=20 >>>> ack >>>>=20 >>>> Thanks again, >>>>=20 >>>> Klaas >>>>=20 >>>>=20 >>=20 >>=20 From nico@cryptonector.com Mon Dec 19 15:39:46 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B81F1F0C51 for ; Mon, 19 Dec 2011 15:39:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[AWL=1.300, 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 YagLbBNSTzc6 for ; Mon, 19 Dec 2011 15:39:41 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 9C98D1F0C40 for ; Mon, 19 Dec 2011 15:39:41 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 4ED5021DE7E for ; Mon, 19 Dec 2011 15:39:41 -0800 (PST) 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=SlmnzQbhDagRrXiu2ZZqZHX72yM4Wl9AcU1ZhO6PQJE9 +BcAj1Xc0x6t1YeoExJfJ6hH5EZexH+DEneKMFzHss61USziWw+T2Z4hJuQtC1Xz mrItjZ3wvGssNdY0BoLw70DJAObQHiniuJGUvSpyvnn2O+hFNYXAU9pDySMByoU= 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=raFN0pGh/cqwzlDut4+n7r4ASLs=; b=OEcNkpcLGVq IDmAkkBQoD+LPxiXQ5AjGnq99AY6iicMwXz398TA3sgS0m14wc5j+ITAFyCVTYyX jtHA8/wm2eb2vUXUVUJCjMgb54bqAcJWl0vFUmdKJTWfp8I/5MnixMH810cZJzc5 AFttLkNiixUCrNDfJhyrX3ePc1hjRa3k= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 5DC9121DE83 for ; Mon, 19 Dec 2011 15:39:27 -0800 (PST) Received: by pbdd12 with SMTP id d12so4578955pbd.31 for ; Mon, 19 Dec 2011 15:39:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.197.5 with SMTP id iq5mr30659576pbc.101.1324337967490; Mon, 19 Dec 2011 15:39:27 -0800 (PST) Received: by 10.68.32.227 with HTTP; Mon, 19 Dec 2011 15:39:27 -0800 (PST) In-Reply-To: References: <4ECC405A.1000605@cs.tcd.ie> Date: Mon, 19 Dec 2011 17:39:27 -0600 Message-ID: From: Nico Williams To: Klaas Wierenga Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 23:39:46 -0000 On Mon, Dec 19, 2011 at 4:14 AM, Klaas Wierenga wrote: > On Nov 23, 2011, at 1:37 AM, Stephen Farrell wrote: >> #1, 1.2 - what does "or similar integrity protected and >> authenticated channels" mean? If you mean IPsec, then saying that >> seems right. =C2=A0The problem though is that people do say things like >> this when they mean "use it in clear on the intranet" which is not >> desirable here presumably. (I realise now I let this pass for the >> openid spec but we could still fix that too;-) I'm sure we can come >> up with a better wording that captures the WG's desired meaning but >> doesn't leave open the option to just run this in clear. > > Hmm, IPsec is indeed the most obvious alternative, but I didn't want to e= numerate, acknowledging that is conceivable that other means to provide int= egrity and authentication can be developed or used. I would argue that an I= ntranet is NOT an "integrity protected and > authenticated channel". How about just calling that out: Note that use of IPsec as an alternative to TLS is fraught with dangers, and one must a) use IPsec channels (see RFC5660, which has not yet been implemented near as I can tell), b) use non-existent APIs by which to query the ID of the peer (the server, in this case). Alternatively one can skip TLS and expect that IPsec is properly configured, or one could use IPsec APIs (non-standard) by which to configure IPsec such that a channel effectively exists with a strongly authenticated peer. It really is not worthwhile to attempt to write text for running SASL applications over IPsec. It is OK to say something about similar channels, but don't bother with IPsec, IMO, Nico -- From hannes.tschofenig@nsn.com Tue Dec 20 01:36:29 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 1E3CD21F8B16 for ; Tue, 20 Dec 2011 01:36:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 hKGNyXiC3yK4 for ; Tue, 20 Dec 2011 01:36:28 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 4C52221F8AF8 for ; Tue, 20 Dec 2011 01:36:27 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id pBK9aOfe006620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 Dec 2011 10:36:26 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id pBK9aJ9O027700 for ; Tue, 20 Dec 2011 10:36:24 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Dec 2011 10:36:23 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {0F59FB4D-37BC-48F4-8FAF-E7644951B572} x-cr-hashedpuzzle: LyA= B6iR DPlF EDmR EIeb FGsq GXK8 HSSk HTas IRPl IhrF I4yY Jxvo J5OR LAnv LUNP; 1; awBpAHQAdABlAG4AQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {0F59FB4D-37BC-48F4-8FAF-E7644951B572}; aABhAG4AbgBlAHMALgB0AHMAYwBoAG8AZgBlAG4AaQBnAEAAbgBzAG4ALgBjAG8AbQA=; Tue, 20 Dec 2011 09:36:19 GMT; UwBBAFMATAAgAE8AQQB1AHQAaAA6ACAATgBlAHgAdAAgAFMAdABlAHAAcwA= Content-class: urn:content-classes:message Date: Tue, 20 Dec 2011 11:36:19 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SASL OAuth: Next Steps Thread-Index: Acy++tRCaIv87RfyRzu6nB9TBbGyCQ== From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 20 Dec 2011 09:36:23.0992 (UTC) FILETIME=[D6B0E380:01CCBEFA] Subject: [kitten] SASL OAuth: Next Steps 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, 20 Dec 2011 09:36:29 -0000 Hi all,=20 Around IETF#82 I have submitted the SASL OAuth draft as a WG item. Here is the draft version: http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt At the KITTEN IETF#82 meeting I gave a presentation illustrating the recent changes and I also listed the open issues. Here are the slides: http://www.ietf.org/proceedings/82/slides/kitten-1.pdf The slides illustrate the design choices of how OAuth messages are integrated into SASL.=20 Last week I attended an identity management workshop organized by ISOC and I met Leif there. I used the opportunity to chat with him about the feedback he gave during the IETF meeting.=20 I would need your feedback on the following important design decision. Currently, the OAuth messages are encoded as HTTP headers and Leif had suggested to instead use a JSON encoding.=20 The benefit is that we do not need to incorporate HTTP-specific aspects that are not relevant to the task at hand, the specification becomes clearer and easier to make an analysis of what parts a relevant to our task.=20 Here is an example from the current draft version: --------------- GET / HTTP/1.1 Host: imap.example.com Authorization: BEARER = "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D" --------------- A possible JSON based representation would be: --------------- {"token-type":" BEARER",=20 "token":" vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D"} --------------- In my made-up example I define two attributes: a token container and a token type attribute. The accessed resource is most likely in the protected token itself and is additionally carried in the underlying transport mechanism and therefore not needed again.=20 In any case, I believe Leif's suggestion is good. I wonder what others think about it. =20 Ciao Hannes From stpeter@stpeter.im Tue Dec 20 08:41: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 A781821F8B56 for ; Tue, 20 Dec 2011 08:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 a+y4Le3BBsrR for ; Tue, 20 Dec 2011 08:41:41 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0C87521F8B51 for ; Tue, 20 Dec 2011 08:41:40 -0800 (PST) Received: from dhcp-64-101-72-192.cisco.com (unknown [64.101.72.192]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7765542475; Tue, 20 Dec 2011 09:49:35 -0700 (MST) Message-ID: <4EF0BA3C.8020404@stpeter.im> Date: Tue, 20 Dec 2011 09:39:24 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: "Tschofenig, Hannes (NSN - FI/Espoo)" References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> X-Enigmail-Version: 1.3.4 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] SASL OAuth: Next Steps 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, 20 Dec 2011 16:41:41 -0000 On 12/20/11 2:36 AM, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > I would need your feedback on the following important design decision. > Currently, the OAuth messages are encoded as HTTP headers and Leif had > suggested to instead use a JSON encoding. > > The benefit is that we do not need to incorporate HTTP-specific aspects > that are not relevant to the task at hand, the specification becomes > clearer and easier to make an analysis of what parts a relevant to our > task. Ciao Hannes, I'm working to get people in the XMPP community interested in an OAuth2 mechanism for SASL, so I am in favor of providing a separation from the underlying data transfer protocol. Peter -- Peter Saint-Andre https://stpeter.im/ From wmills@yahoo-inc.com Tue Dec 20 08:56: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 8479C11E8099 for ; Tue, 20 Dec 2011 08:56:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.415 X-Spam-Level: X-Spam-Status: No, score=-15.415 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_20=-0.74, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 hMPkqT2SyArT for ; Tue, 20 Dec 2011 08:56:40 -0800 (PST) Received: from nm28-vm3.bullet.mail.ne1.yahoo.com (nm28-vm3.bullet.mail.ne1.yahoo.com [98.138.91.158]) by ietfa.amsl.com (Postfix) with SMTP id 7592621F8ACA for ; Tue, 20 Dec 2011 08:56:40 -0800 (PST) Received: from [98.138.90.48] by nm28.bullet.mail.ne1.yahoo.com with NNFMP; 20 Dec 2011 16:56:33 -0000 Received: from [98.138.87.3] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 20 Dec 2011 16:56:33 -0000 Received: from [127.0.0.1] by omp1003.mail.ne1.yahoo.com with NNFMP; 20 Dec 2011 16:56:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 408935.12734.bm@omp1003.mail.ne1.yahoo.com Received: (qmail 83957 invoked by uid 60001); 20 Dec 2011 16:56:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1324400192; bh=jr6vKaHPRIAZeYn4cgSf6aLD3FcoqFDn5MoMiRX6DYo=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=rRID1sPWHUM3HrvLwCuxatjjnGAZNwKa8jxy6WDRb2rsIqcg+/3JfvY4LPLTItM8UyUcEJkhw9cC7+jon+485urlbQCGdE19K3JSTwuGOs4ZxmdAbsniXXRHEkdN9QLWmIizRKVSQszkB+d/A8QAw5KmdhUsreUF+v/9o47ccgY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=fdeXp1dG+9bq1x2KodgyCzzKI4OhGtOCBynulJZ6DnyUtN87htKHAwZ+1L0opGTC/qORXqwwn30KyzfFO0Z5ovvnONfFq8C5oxX8slRgT/NKxfoBaaKSivAFrzN2HQ/GvbfhfhBoleMizT8V/JPeB+Z4kE20MNopGD1l00xXCO0=; X-YMail-OSG: w2HkkF4VM1kFSflBXWp7v9jwjvgyGidwExRqDMERfjhUfhx _X7mtQzTfn3xUvBrdNBnDkJhAY2FoJYQfr08HOTpfWTjkHHk46UyT0ixNWZc 8vaflduMAqXUiVuxRpEP7JKn58BSzz3QVrObaSXgux4Ojr23CpdetcMM7QTj E2qN8dFpYoNdKzLvRrzwG6uY64RXuvWpsyGL2jIGaKMQfAp1idXKfQg62r30 F24AOx2kQzNvnOesfJtrWVUcQSrIlpap1pa25XXv4FT2JONC5CV4Vs49A23z AhROiig6NG3jLQKxQJMN3dunuVXLqN3EJ2LbaaefK.8cZ_C9B5bZ9J8szkhq zSZe.DwTrHVowQSN18xojKm1GJb2VaZMlrxC6TrHusCPvqROgZp7UFhS1rQ9 DIvvZoGvJTPEYSlZCyFUOCWqV63uCu2pKavxKmX96vLk89FjtreyLhz.nxdb TSKhH3jsni6md8SleBoVn.Yvbw10TkjAuusS4 Received: from [209.131.62.115] by web31816.mail.mud.yahoo.com via HTTP; Tue, 20 Dec 2011 08:56:32 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> Message-ID: <1324400192.71699.YahooMailNeo@web31816.mail.mud.yahoo.com> Date: Tue, 20 Dec 2011 08:56:32 -0800 (PST) From: William Mills To: "Tschofenig, Hannes \(NSN - FI/Espoo\)" , "kitten@ietf.org" In-Reply-To: <999913AB42CC9341B05A99BBF358718DE38797@FIESEXC035.nsn-intra.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1238014912-1129528729-1324400192=:71699" Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 16:56:41 -0000 ---1238014912-1129528729-1324400192=:71699 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The choice to use HTTP format here means that any new OAuth 2 enabled auth = profile is supported without having to define a new mapping.=A0 We don't ha= ve to do anything in this spec to support a new profile.=A0 If we decide on= JSON encoding we then have to define how the mapping will work, and we hav= e to make sure it will be robust enough to survive anything new.=0A=0AIf th= is were independent of other specs HTTP would be a very poor format choice.= =A0 Since it would be possible for OAuth 2 authentication enabled HTTP auth= methods to use other headers for example, I think simply leaning directly = on those specifications is cleanest.=0A=0A-bill=0A=0A=0A=0A=0A_____________= ___________________=0A From: "Tschofenig, Hannes (NSN - FI/Espoo)" =0ATo: kitten@ietf.org =0ASent: Tuesday, December 20, 20= 11 1:36 AM=0ASubject: [kitten] SASL OAuth: Next Steps=0A =0AHi all, =0A=0AA= round IETF#82 I have submitted the SASL OAuth draft as a WG item. Here=0Ais= the draft version:=0Ahttp://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-0= 0.txt=0A=0AAt the KITTEN IETF#82 meeting I gave a presentation illustrating= the=0Arecent changes and I also listed the open issues. Here are the slide= s:=0Ahttp://www.ietf.org/proceedings/82/slides/kitten-1.pdf=0A=0AThe slides= illustrate the design choices of how OAuth messages are=0Aintegrated into = SASL. =0A=0ALast week I attended an identity management workshop organized = by ISOC=0Aand I met Leif there. I used the opportunity to chat with him abo= ut the=0Afeedback he gave during the IETF meeting. =0A=0AI would need your = feedback on the following important design decision.=0ACurrently, the OAuth= messages are encoded as HTTP headers and Leif had=0Asuggested to instead u= se a JSON encoding. =0A=0AThe benefit is that we do not need to incorporate= HTTP-specific aspects=0Athat are not relevant to the task at hand, the spe= cification becomes=0Aclearer and easier to make an analysis of what parts a= relevant to our=0Atask. =0A=0AHere is an example from the current draft ve= rsion:=0A=0A---------------=0A=A0 GET / HTTP/1.1=0A=A0 Host: imap.example= .com=0A=A0 Authorization: BEARER "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg= =3D=3D"=0A---------------=0A=0AA possible JSON based representation would b= e:=0A---------------=0A=A0 {"token-type":" BEARER", =0A=A0 =A0 "token":" v= F9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D"}=0A---------------=0AIn my m= ade-up example I define two attributes: a token container and a=0Atoken typ= e attribute. The accessed resource is most likely in the=0Aprotected token = itself and is additionally carried in the underlying=0Atransport mechanism = and therefore not needed again. =0A=0AIn any case, I believe Leif's suggest= ion is good. I wonder what others=0Athink about it.=A0 =0A=0ACiao=0AHannes= =0A=0A_______________________________________________=0AKitten mailing list= =0AKitten@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/kitten ---1238014912-1129528729-1324400192=:71699 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The = choice to use HTTP format here means that any new OAuth 2 enabled auth prof= ile is supported without having to define a new mapping.  We don't hav= e to do anything in this spec to support a new profile.  If we decide = on JSON encoding we then have to define how the mapping will work, and we h= ave to make sure it will be robust enough to survive anything new.

If this were independent of other specs HTTP would be a ve= ry poor format choice.  Since it would be possible for OAuth 2 authent= ication enabled HTTP auth methods to use other headers for example, I think= simply leaning directly on those specifications is cleanest.
-bill


From: "Tschofenig, Hannes (NSN - FI/Esp= oo)" <hannes.tschofenig@nsn.com>
To: kitten@ietf.org
Sent: Tuesday, December 20, 2011 1:36 AM
Subject: [kitten] SASL OAuth: Next Steps=

=0AHi all,

Around IETF#82 I have submitted the SAS= L OAuth draft as a WG item. Here
is the draft version:
http://www.iet= f.org/id/draft-ietf-kitten-sasl-oauth-00.txt

At the KITTEN IETF#82 m= eeting I gave a presentation illustrating the
recent changes and I also = listed the open issues. Here are the slides:
http://www.ietf.org/proceed= ings/82/slides/kitten-1.pdf

The slides illustrate the design choices= of how OAuth messages are
integrated into SASL.

Last week I att= ended an identity management workshop organized by ISOC
and I met Leif t= here. I used the opportunity to chat with him about the
feedback he gave= during the IETF meeting.

I would need your feedback on the followi= ng important design decision.
Currently, the OAuth messages are encoded = as HTTP headers and Leif had
suggested to instead use a JSON encoding. <= br>
The benefit is that we do not need to incorporate HTTP-specific aspe= cts
that are not relevant to the task at hand, the specification becomes
clearer= and easier to make an analysis of what parts a relevant to our
task.
Here is an example from the current draft version:

-----------= ----
  GET / HTTP/1.1
  Host: imap.example.com
  Authorization:= BEARER "vF9dft4qmTc2Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D"
---------------=

A possible JSON based representation would be:
---------------  {"token-type":" BEARER",
    "token":" vF9dft4qmTc2= Nvb3RlckBhbHRhdmlzdGEuY29tCg=3D=3D"}
---------------
In my made-up ex= ample I define two attributes: a token container and a
token type attrib= ute. The accessed resource is most likely in the
protected token itself = and is additionally carried in the underlying
transport mechanism and th= erefore not needed again.

In any case, I believe Leif's suggestion = is good. I wonder what others
think about it. 

Ciao
Hannes=

_______________________________________________
Kitten mailing l= ist
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

---1238014912-1129528729-1324400192=:71699-- From shawn.emery@oracle.com Tue Dec 20 11:38: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 7BE8521F84D4 for ; Tue, 20 Dec 2011 11:38:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej4bxqpaPaQm for ; Tue, 20 Dec 2011 11:38:23 -0800 (PST) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 032A121F84B0 for ; Tue, 20 Dec 2011 11:38:22 -0800 (PST) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id pBKJcLPR016673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 20 Dec 2011 19:38:22 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 pBKJcLRC022094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Dec 2011 19:38:21 GMT Received: from abhmt103.oracle.com (abhmt103.oracle.com [141.146.116.55]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id pBKJcKKc022875 for ; Tue, 20 Dec 2011 13:38:21 -0600 Received: from [10.159.208.113] (/10.159.208.113) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 20 Dec 2011 11:38:20 -0800 Message-ID: <4EF0E40F.8070505@oracle.com> Date: Tue, 20 Dec 2011 12:37:51 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:8.0) Gecko/20111202 Thunderbird/8.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <4DDDF593.5080100@oracle.com> In-Reply-To: <4DDDF593.5080100@oracle.com> X-Forwarded-Message-Id: <4DDDF593.5080100@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090201.4EF0E42E.00E4,ss=1,re=0.000,fgs=0 Subject: [kitten] WGLC on draft-ietf-kitten-gssapi-naming-exts-12 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, 20 Dec 2011 19:38:23 -0000 This message officially starts the 4th kitten Working Group Last Call for the following document: GSS-API Naming Extensions http://tools.ietf.org/html/draft-ietf-kitten-gssapi-naming-exts-12 The Working Group Last Call for this document starts today on Tuesday, December 20th and will end on Tuesday, January 3rd. Please send any comments to the kitten mailing list or directly to the chairs. Feed-back from reviews that found no issues are also welcome. Thank you, Shawn Emery, kitten WG co-chair -- From internet-drafts@ietf.org Wed Dec 21 05:43: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 5904121F8573; Wed, 21 Dec 2011 05:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 Dn5UPr9jYQtA; Wed, 21 Dec 2011 05:43:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE34621F8512; Wed, 21 Dec 2011 05:43:42 -0800 (PST) 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.64p1 Message-ID: <20111221134342.27027.14393.idtracker@ietfa.amsl.com> Date: Wed, 21 Dec 2011 05:43:42 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2011 13:43:43 -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-06.txt Pages : 28 Date : 2011-12-21 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-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-06.txt From klaas@cisco.com Wed Dec 21 05:47:20 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 8138821F85DB for ; Wed, 21 Dec 2011 05:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[AWL=1.398, 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 Enruzp6eFtgT for ; Wed, 21 Dec 2011 05:47:19 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id C9BC221F8508 for ; Wed, 21 Dec 2011 05:47:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2112; q=dns/txt; s=iport; t=1324475239; x=1325684839; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=n/gwgkysWz4/rKyPjbYLehIXQu6B5RUKRXz6IbjO1Co=; b=hYRtIFyxolOTlzMGcEeAO1tJ4OsVvtxAEzUakh9P6ksNvw3g1qewQ9UD DCLh+TMMP104Sen8x+p4TCqXDglr9JSUN7KdwGBYVBJVpxVqBwDvSTp6W dQhILF+6YhxSh2Cli9KFdPdfTwXQ0Ns/O+nFI2LU5zH3q7W1PEzGtYQGd 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABEppk6tJXHB/2dsb2JhbACeW3iIcItlkjSGGQSQEY52 X-IronPort-AV: E=Sophos;i="4.71,388,1320624000"; d="scan'208";a="43344233" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 21 Dec 2011 13:47:19 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id pBLDlIJg000591; Wed, 21 Dec 2011 13:47:18 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Klaas Wierenga In-Reply-To: Date: Wed, 21 Dec 2011 14:47:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4ECC405A.1000605@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1251.1) Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml 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, 21 Dec 2011 13:47:20 -0000 Hi, I have updated the draft to version 6 and resubmitted, I think I have = addressed all your comments, with the exception of calling out IPSec as = an alternative channel cf. Nico's arguments. I believe all the changes are cosmetic, but encourage the WG to verify. Klaas On Dec 20, 2011, at 12:39 AM, Nico Williams wrote: > On Mon, Dec 19, 2011 at 4:14 AM, Klaas Wierenga = wrote: >> On Nov 23, 2011, at 1:37 AM, Stephen Farrell wrote: >>> #1, 1.2 - what does "or similar integrity protected and >>> authenticated channels" mean? If you mean IPsec, then saying that >>> seems right. The problem though is that people do say things like >>> this when they mean "use it in clear on the intranet" which is not >>> desirable here presumably. (I realise now I let this pass for the >>> openid spec but we could still fix that too;-) I'm sure we can come >>> up with a better wording that captures the WG's desired meaning but >>> doesn't leave open the option to just run this in clear. >>=20 >> Hmm, IPsec is indeed the most obvious alternative, but I didn't want = to enumerate, acknowledging that is conceivable that other means to = provide integrity and authentication can be developed or used. I would = argue that an Intranet is NOT an "integrity protected and >> authenticated channel". How about just calling that out: >=20 > Note that use of IPsec as an alternative to TLS is fraught with > dangers, and one must a) use IPsec channels (see RFC5660, which has > not yet been implemented near as I can tell), b) use non-existent APIs > by which to query the ID of the peer (the server, in this case). > Alternatively one can skip TLS and expect that IPsec is properly > configured, or one could use IPsec APIs (non-standard) by which to > configure IPsec such that a channel effectively exists with a strongly > authenticated peer. >=20 > It really is not worthwhile to attempt to write text for running SASL > applications over IPsec. It is OK to say something about similar > channels, but don't bother with IPsec, IMO, >=20 > Nico > -- From nico@cryptonector.com Wed Dec 21 23:42:06 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 081B721F853E for ; Wed, 21 Dec 2011 23:42:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.866 X-Spam-Level: X-Spam-Status: No, score=-1.866 tagged_above=-999 required=5 tests=[AWL=0.111, 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 2hTrKTH-b1lX for ; Wed, 21 Dec 2011 23:42:05 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 394CC21F851F for ; Wed, 21 Dec 2011 23:42:05 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id DF75A54057 for ; Wed, 21 Dec 2011 23:42:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :date:message-id:subject:from:to:content-type; q=dns; s= cryptonector.com; b=CRj2f2BKToOu7nW7OHjrkdb5Q1fLDw7u2UVE4tbzngRR PY5z2vsmdAUg1yCre5oUiTnZFLrptB9lw0zvX/yYxRPNUZ0L74jBB3tH6DiJxTYR pAwdwjQRB48l8UxLTeN67m7B4WYnEuc7Y47igOa65MGT8x07RgJDQTxhTIDE6yI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:content-type; s= cryptonector.com; bh=61ikA7l5Nm6OKwYvIvJUX5/lnCE=; b=gZ8q2MUxzT4 T6Qo/5Fx6z4+VVFmj3F7z9eUweOekT32cSusVG8Y4jIW4Sam0N4EQeve1/A1lKVs UqEkV4Bogu0i66uutoMdGogNU0nloKe4cemXZvB9JdKoYRDY9JIVtlWw3EVt3b5x 0ViXoLMchCFFmeq2P5xsuIgVnRIJfmg4= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id C59F254055 for ; Wed, 21 Dec 2011 23:42:04 -0800 (PST) Received: by dajz8 with SMTP id z8so7657763daj.31 for ; Wed, 21 Dec 2011 23:42:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.73.234 with SMTP id o10mr20976702pbv.90.1324539724278; Wed, 21 Dec 2011 23:42:04 -0800 (PST) Received: by 10.68.32.227 with HTTP; Wed, 21 Dec 2011 23:42:04 -0800 (PST) Date: Thu, 22 Dec 2011 01:42:04 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Naming extensions, next round: issuer and other standard name attributes 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, 22 Dec 2011 07:42:06 -0000 We want to be able to inquire a NAME's and name attribute's issuer. Until today I thought this would mean that we should add a function like GSS_Get_name_attribute() but which also outputs the attribute's issuer name as a NAME. Then the lightbulb went off: For any given attribute name, all we need to do is transform it, such as by prefixing it with another attribute name, such that the resulting attribute's value will be the issuer of the original. For example, if given an attribute X we could obtain the issuer name by calling GSS_Get_name_attribute() to get the attribute named "urn:ietf:...:issuer-name X", which would then output an exported name token for the attribute X's issuer NAME, and the display name of the issuer as well. This idea might seem strange at first, but think that if we had a function by which to get an actual NAME object for an issuer, the application would likely turn around and call GSS_Display/Export_name() on it. This approach then simplifies the API! (I met with Sam today, and as soon as I said "for any given attribute name" he knew the rest before I said anything else and agreed with the idea.) This gets us everything except the issuer name's name-type, so we can add an additional attribute prefix by which to request the issuer name's name-type, which results in GSS_Get_name_attribute() outputting the name-type OID as a DER- encoded value and as a string in the display_value output parameter. Oh, and we might want a prefix by which to get a composite exported name token for the issuer. Also, these attribute name prefixes used alone should operate on the input_name itself rather than a given attribute of it. This gives us our first opportunity to specify a generic attribute name. Are there others? Yes! An obvious one is the trust transited path, which I believe we can generalize such that its value and display_value is specific to the mechanism that is the source of the given MN. So I think we have at least four generic name attributes to specify: - urn:ietf::issuer-name - urn:ietf::issuer-name-name-type - urn:ietf::issuer-name-composite - urn:ietf::transit-path (this last one would not be used as a prefix) The transit path would be nicer and more generic still if were available as discrete elements, one per-transit hop, so perhaps we want: - urn:ietf::transit-path-hop-name: - urn:ietf::transit-path-hop-name-name-type: - urn:ietf::transit-path-hop-name-composite: I would also like us to define a single name attribute by which to specify application- specific authorization-data to be carried by the mechanism. The example use case I gave earlier was of privileges ("capabilities" in Linux speak) by which to reduce privileges that would be granted by the peer. - urn:ietf::application-attribute We could say that attribute names of the form "urn:ietf::application-attribute " are all supported by any mechanism that supports this one attribute. That's quite a few generic attributes. Any others? I can think of some that I'm not so sure about, such as a name attribute whose value is an exported composite name token of the local name of the security context from which this name came: this would allow APIs that receive only a single NAME parameter to actually have access to the name of the other peer of a security context when the NAME passed in was obtained from GSS_Inquire_context() or GSS_Init/Accept_sec_context(). But I think that's a bit of a stretch. Also, given that section 6 (Representation of Attribute Names) gives the ability to prefix a name attribute with another, I don't think we need to define a further notion of name attribute namespace. Nico -- From stephen.farrell@cs.tcd.ie Thu Dec 22 06:56:37 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 9F26B21F8564 for ; Thu, 22 Dec 2011 06:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Aq0ZL+pLYZ2b for ; Thu, 22 Dec 2011 06:56:33 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id D601621F8560 for ; Thu, 22 Dec 2011 06:56:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id E6031171CC5; Thu, 22 Dec 2011 14:56:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1324565785; bh=KQ+x0XiZSZYdz7 jAILGqEQ8YA1NeDRZaWdFY5ri31Xc=; b=ThCeUwHbPI4JnThzvUaDqr3K2Y2LMD uxVQwTlcD8p6T7FNpNTV4TrZpqY3t1QtfJM1o6oLlBW5RWCYAlihd0+Z0yQJ0nai 99EOERCxEiz6HwYdnNAthJpNyvJKjcQm9uB1NQwUpR5fGdKAfZdNdyl4+TqPoEA5 wuG9Gi16k+orZTH2Dwovlpa2a+Q41nSMc86BzGfM7SoglArzUpp8G+hs24k+CKH/ 25Fzhfa3htucenZJ1KLgMQMffNkaOpcI3ngMBGiQ5LJSyeqSwIhSQeqcMT1BtHoF 7wWVu4K8UCUwZ3FCg/pkZyN9jfWDr7b/c9QDQ3vTsvklg6dJt+LNWcKQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id JzsROTWOtV6C; Thu, 22 Dec 2011 14:56:25 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 6F5FC171D83; Thu, 22 Dec 2011 14:56:22 +0000 (GMT) Message-ID: <4EF34518.7010400@cs.tcd.ie> Date: Thu, 22 Dec 2011 14:56:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Klaas Wierenga References: <4ECC405A.1000605@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml 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, 22 Dec 2011 14:56:37 -0000 Hi Klaas, Those changes look good to me and I hope the WG. I've asked for IETF LC to start, if there are any WG comments they can be handled as part of that I guess. S. On 12/21/2011 01:47 PM, Klaas Wierenga wrote: > Hi, > > I have updated the draft to version 6 and resubmitted, I think I have addressed all your comments, with the exception of calling out IPSec as an alternative channel cf. Nico's arguments. > I believe all the changes are cosmetic, but encourage the WG to verify. > > Klaas > > On Dec 20, 2011, at 12:39 AM, Nico Williams wrote: > >> On Mon, Dec 19, 2011 at 4:14 AM, Klaas Wierenga wrote: >>> On Nov 23, 2011, at 1:37 AM, Stephen Farrell wrote: >>>> #1, 1.2 - what does "or similar integrity protected and >>>> authenticated channels" mean? If you mean IPsec, then saying that >>>> seems right. The problem though is that people do say things like >>>> this when they mean "use it in clear on the intranet" which is not >>>> desirable here presumably. (I realise now I let this pass for the >>>> openid spec but we could still fix that too;-) I'm sure we can come >>>> up with a better wording that captures the WG's desired meaning but >>>> doesn't leave open the option to just run this in clear. >>> >>> Hmm, IPsec is indeed the most obvious alternative, but I didn't want to enumerate, acknowledging that is conceivable that other means to provide integrity and authentication can be developed or used. I would argue that an Intranet is NOT an "integrity protected and >>> authenticated channel". How about just calling that out: >> >> Note that use of IPsec as an alternative to TLS is fraught with >> dangers, and one must a) use IPsec channels (see RFC5660, which has >> not yet been implemented near as I can tell), b) use non-existent APIs >> by which to query the ID of the peer (the server, in this case). >> Alternatively one can skip TLS and expect that IPsec is properly >> configured, or one could use IPsec APIs (non-standard) by which to >> configure IPsec such that a channel effectively exists with a strongly >> authenticated peer. >> >> It really is not worthwhile to attempt to write text for running SASL >> applications over IPsec. It is OK to say something about similar >> channels, but don't bother with IPsec, IMO, >> >> Nico >> -- > > From iesg-secretary@ietf.org Thu Dec 22 06:58: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 3658821F8ABC; Thu, 22 Dec 2011 06:58:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, 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 h1du+ScrYdvP; Thu, 22 Dec 2011 06:58:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC3D521F85C7; Thu, 22 Dec 2011 06:58:27 -0800 (PST) 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.64p1 Message-ID: <20111222145827.13018.86722.idtracker@ietfa.amsl.com> Date: Thu, 22 Dec 2011 06:58:27 -0800 Cc: kitten@ietf.org Subject: [kitten] Last Call: (A SASL and GSS-API Mechanism for SAML) 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: Thu, 22 Dec 2011 14:58:32 -0000 The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'A SASL and GSS-API Mechanism for SAML' 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 2012-01-05. 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 Security Assertion Markup Language (SAML) has found its usage on the Internet for Web Single Sign-On. Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) are application frameworks to generalize authentication. This memo specifies a SASL mechanism and a GSS-API mechanism for SAML 2.0 that allows the integration of existing SAML Identity Providers with applications using SASL and GSS-API. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml/ No IPR declarations have been submitted directly on this I-D. From klaas@cisco.com Thu Dec 22 07:03: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 0CE4921F88AB for ; Thu, 22 Dec 2011 07:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.55 X-Spam-Level: X-Spam-Status: No, score=-5.55 tagged_above=-999 required=5 tests=[AWL=1.049, 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 296odBibJR85 for ; Thu, 22 Dec 2011 07:03:30 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B9F3221F8A66 for ; Thu, 22 Dec 2011 07:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=2592; q=dns/txt; s=iport; t=1324566210; x=1325775810; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=9IfFKslntOpXKdz6Ee+yDyzN2LHVvuS56z4pEv48RZo=; b=gfoIwKBv9cvc609Qd2kqKwEknw3+hMpWikYD4SaCNHC/KG/N/YrvuhSH jtMV1/sm55CwYSgbyr1gTgURcaqGOLea2BugscM2Kphx4/2LQ9i09sOiF 42ax82NKV96qimHgsxmIA4k6c+oLIgx5H/PENpATUagFiJ2o/RcM1TS0G 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAF1F806tJV2a/2dsb2JhbABErCuBBYFyAQEBAwESAWYFCwsYLlcGEyKHWJkLAZ46iyxjBJUBkjM X-IronPort-AV: E=Sophos;i="4.71,393,1320624000"; d="scan'208";a="46183157" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 22 Dec 2011 15:03:28 +0000 Received: from rtp-kwiereng-8711.cisco.com (rtp-kwiereng-8711.cisco.com [10.116.7.34]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pBMF3RTh016368; Thu, 22 Dec 2011 15:03:27 GMT Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Klaas Wierenga In-Reply-To: <4EF34518.7010400@cs.tcd.ie> Date: Thu, 22 Dec 2011 16:03:26 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73DB8DAF-CDC5-4C0E-A063-08C503657304@cisco.com> References: <4ECC405A.1000605@cs.tcd.ie> <4EF34518.7010400@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1251.1) Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml 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, 22 Dec 2011 15:03:35 -0000 On Dec 22, 2011, at 3:56 PM, Stephen Farrell wrote: Hi Stephen, > Those changes look good to me and I hope the WG. >=20 > I've asked for IETF LC to start, if there are any > WG comments they can be handled as part of that > I guess. Thanks, and happy holidays! Klaas >=20 > S. >=20 > On 12/21/2011 01:47 PM, Klaas Wierenga wrote: >> Hi, >>=20 >> I have updated the draft to version 6 and resubmitted, I think I have = addressed all your comments, with the exception of calling out IPSec as = an alternative channel cf. Nico's arguments. >> I believe all the changes are cosmetic, but encourage the WG to = verify. >>=20 >> Klaas >>=20 >> On Dec 20, 2011, at 12:39 AM, Nico Williams wrote: >>=20 >>> On Mon, Dec 19, 2011 at 4:14 AM, Klaas Wierenga = wrote: >>>> On Nov 23, 2011, at 1:37 AM, Stephen Farrell wrote: >>>>> #1, 1.2 - what does "or similar integrity protected and >>>>> authenticated channels" mean? If you mean IPsec, then saying that >>>>> seems right. The problem though is that people do say things like >>>>> this when they mean "use it in clear on the intranet" which is not >>>>> desirable here presumably. (I realise now I let this pass for the >>>>> openid spec but we could still fix that too;-) I'm sure we can = come >>>>> up with a better wording that captures the WG's desired meaning = but >>>>> doesn't leave open the option to just run this in clear. >>>>=20 >>>> Hmm, IPsec is indeed the most obvious alternative, but I didn't = want to enumerate, acknowledging that is conceivable that other means to = provide integrity and authentication can be developed or used. I would = argue that an Intranet is NOT an "integrity protected and >>>> authenticated channel". How about just calling that out: >>>=20 >>> Note that use of IPsec as an alternative to TLS is fraught with >>> dangers, and one must a) use IPsec channels (see RFC5660, which has >>> not yet been implemented near as I can tell), b) use non-existent = APIs >>> by which to query the ID of the peer (the server, in this case). >>> Alternatively one can skip TLS and expect that IPsec is properly >>> configured, or one could use IPsec APIs (non-standard) by which to >>> configure IPsec such that a channel effectively exists with a = strongly >>> authenticated peer. >>>=20 >>> It really is not worthwhile to attempt to write text for running = SASL >>> applications over IPsec. It is OK to say something about similar >>> channels, but don't bother with IPsec, IMO, >>>=20 >>> Nico >>> -- >>=20 >>=20 From nico@cryptonector.com Thu Dec 22 10:32: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 6C2BF21F854E for ; Thu, 22 Dec 2011 10:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[AWL=0.099, 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 VnYOt13lZIOP for ; Thu, 22 Dec 2011 10:32:27 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id A1E2B21F84ED for ; Thu, 22 Dec 2011 10:32:27 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 3AC2C67803E for ; Thu, 22 Dec 2011 10:32:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to: content-type; q=dns; s=cryptonector.com; b=wsE9WP1w8TUJ+U0FKCt8L Ot9DkVRyNGE3uyrnpz/FZ0OGy4IlbkVYnLD3u6jpg7BSEYKaESPrMH09oeT6X/v2 4fhMAK1smhG9ihZU5cexnm20oYoT9xqfvqRlZvtAcsRcZtSAMa/gJYiVdPR9j6pT X5GGt+FN0Vdtz7NcAdnWRI= 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:content-type; s=cryptonector.com; bh=Mf/X2160WLmBawH+3r4KeeV /1+s=; b=HwMQ7qyIOPzklvhLK9N5EmR4mNOz/5wPriRFUN5kDzh00Ys4AgUa165 kI15uyjQU5CNiH64tuZB8lB9ocXRgXm0BxKdMiUDZKzXm+RmWE0Obnmhpya+ZD/Z XES1CtbEjWL+TJZeSYcAqwd6p1gr+ARc3dwCIDXaeYuvIwe+/RT0= Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id 6FA33678069 for ; Thu, 22 Dec 2011 10:32:26 -0800 (PST) Received: by pbdd12 with SMTP id d12so6970553pbd.31 for ; Thu, 22 Dec 2011 10:32:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.197.134 with SMTP id iu6mr19147618pbc.67.1324578739851; Thu, 22 Dec 2011 10:32:19 -0800 (PST) Received: by 10.68.32.227 with HTTP; Thu, 22 Dec 2011 10:32:19 -0800 (PST) In-Reply-To: References: Date: Thu, 22 Dec 2011 12:32:19 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [kitten] Naming extensions, next round: issuer and other standard name attributes 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, 22 Dec 2011 18:32:28 -0000 Another set of useful generic attributes would be ones corresponding to the components of multi-component names such as GSS_C_NT_HOSTBASED_SERVICE: - urn:ietf::hostbased-service:service - urn:ietf::hostbased-service:hostname This would allow for generic applications to inquire a hostbased service MN and get at the components generically. Today applications can't do this without understanding mechanism-specific name type syntaxes. For example, today a hostbased service name MN for Kerberos will display as service/hostname@REALM, NOT as service@hostname, so an application that wants to see what hostname was used has to know how to parse this -- what a pain! This gets much worse with PKIX-based mechanisms too. The above problem comes up a *lot* for GSS acceptor applications that use GSS_C_NO_CREDENTIAL and which have actual credentials for multiple acceptor names. With naming extensions the application could simply call GSS_Get_name_attribute(acceptor_name, "urn:ietf::hostbased-service:hostname") to get the hostname, and GSS_Get_name_attribute(acceptor_name, "urn:ietf::hostbased-service:service") to get the service name. And this is completely generic! (Mechanisms that don't have true hostbased service naming and instead substitute host naming, like the old mech_dh mechanism.) Also add: - urn:ietf::applicable-name-type: (value is "true" if the MN can be considered to be of the given name type) - urn:ietf::best-fit-generic-name-type (value is OID of generic name type that best fits the given MN) and numbered component accessors: - urn:ietf::name-component: So, the list of generic name attributes so far would be: - issuer attributes: - urn:ietf::issuer-name - urn:ietf::issuer-name-name-type - urn:ietf::issuer-name-composite - transit path attributes - urn:ietf::transit-path - urn:ietf::transit-path-hop-name: - urn:ietf::transit-path-hop-name-name-type: - urn:ietf::transit-path-hop-name-composite: - name type and name component attributes - urn:ietf::best-fit-generic-name-type - urn:ietf::applicable-name-type: - urn:ietf::name-component: - urn:ietf::hostbased-service:service - urn:ietf::hostbased-service:hostname - urn:ietf::domainbased-service:service - urn:ietf::domainbased-service:domain - urn:ietf::domainbased-service:hostname - other attributes - urn:ietf::application-attribute Nico -- From alexey.melnikov@isode.com Sun Dec 25 06:08:05 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 A23DC21F8500 for ; Sun, 25 Dec 2011 06:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 tfL0buzQHgbQ for ; Sun, 25 Dec 2011 06:08:05 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 140C321F84FB for ; Sun, 25 Dec 2011 06:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1324822075; d=isode.com; s=selector; i=@isode.com; bh=cChKtQVAc6BkzcjwYw1htT9vcAaUkocYktLqVyV1zaw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=BI5c0srJZeEDCD4KFDQAADbChriQrEpC/k9p069QGR2yfcZSSgXvC/UPxhqaf0yx+qTDmj C0rl5juTkClOQktFL0Wmchzhy3ObVIX4deyLwE3zOmzlJc/d1vWO6C4D1NOCPJR7AkOij0 5r2f+HFxabY4ChxdGQFjbIzE87aPdvQ=; Received: from [192.168.0.109] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 25 Dec 2011 14:07:55 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4EF72A20.8000700@isode.com> Date: Sun, 25 Dec 2011 13:50:24 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: kitten@ietf.org References: <4ECC405A.1000605@cs.tcd.ie> <4EF34518.7010400@cs.tcd.ie> <73DB8DAF-CDC5-4C0E-A063-08C503657304@cisco.com> In-Reply-To: <73DB8DAF-CDC5-4C0E-A063-08C503657304@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 14:08:05 -0000 Additional comments (mostly nits) on the latest version: In Section 3.2: Note: While the SASL client MAY sanity check the URI it received, ultimately it is the SAML IdP that will be validated by the SAML client out-of-scope for this document.. 2 dots at the end. I also think "which is" is missing before "out-of-scope. In Section 3.3: The SAML SASL mechanism is actually also a GSS-API mechanism. The SAML user takes the role of the GSS-API Initiator and the SAML Relying Party takes the role of the GSS-API Acceptor. The SAML Idenity Provider does not have a role in GSS-API, and is considered typo: Identity an internal matter for the OpenID mechanism.The messages are the Typo: SAML20 same, but It doesn't look like the reference to [RFC4648] needs to be Normative. In fact the current text is confusing. base64 encoding is only needed because you have an XMPP example and not for any other reason. From alexey.melnikov@isode.com Sun Dec 25 06:08:11 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4936D21F853A for ; Sun, 25 Dec 2011 06:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.366 X-Spam-Level: X-Spam-Status: No, score=-102.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 wJCu-qkCnWnV for ; Sun, 25 Dec 2011 06:08:10 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id C381021F851F for ; Sun, 25 Dec 2011 06:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1324822082; d=isode.com; s=selector; i=@isode.com; bh=EJ+itj/Q+pNL+VSolf5tiXGFSySvI8mwP6F5DL7BYHs=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=oh9CnENlXXcAqc1U9xNk1xV3puuHCvFciC6+6tjewd3j14Jg+IHIdERHfga+iz2LauonmA KIqNSrY13bCHH5BGeGfRENImOII37cIRzpfwPt1bXHi/l1ipjbOIt9F3vTS/sejmulBPjP v/IMGISftRtu35vfcvr1REx9WFn6gEA=; Received: from [192.168.0.109] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 25 Dec 2011 14:08:02 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4EF72BFC.3050000@isode.com> Date: Sun, 25 Dec 2011 13:58:20 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: Peter Saint-Andre , Klaas Wierenga References: <4ECC405A.1000605@cs.tcd.ie> <4EF34518.7010400@cs.tcd.ie> <73DB8DAF-CDC5-4C0E-A063-08C503657304@cisco.com> <4EF72A20.8000700@isode.com> In-Reply-To: <4EF72A20.8000700@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 14:08:11 -0000 On 25/12/2011 13:50, Alexey Melnikov wrote: > Additional comments (mostly nits) on the latest version: One more thing: Step 6: Client sends a BASE64 encoded empty response to the challenge: = Is this actually correct, or is this how XMPP sends empty response? Either way, I think the text should read: Client sends the empty response to the challenge encoded as a single =. Because base64 certainly doesn't allow for that. From alexey.melnikov@isode.com Sun Dec 25 06:08:11 2011 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FD421F853A for ; Sun, 25 Dec 2011 06:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.175, 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 wKyhAlyUy8k3 for ; Sun, 25 Dec 2011 06:08:11 -0800 (PST) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2C26421F852E for ; Sun, 25 Dec 2011 06:08:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1324822089; d=isode.com; s=selector; i=@isode.com; bh=qkBhKncyLLir3DyZLl2FYFR1m3j3ZTZb44dazzdgswk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=HrNYF3GCVTa2vTkBoO0tdkiy/nEDZZMa3VQWXQ9pBpHgN6lG2NHB5Az+8WCW9S745vWWgG H42sd2UocI+9ue9rSzo59Nrm8z+yXqUbzOrsxeTToESSOiS38pnT7ziY7BZbxEZtqohRLj 2JA2SdT4jUEE3DspgFPw0R7ZQ6iDTRg=; Received: from [192.168.0.109] ((unknown) [109.73.6.25]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 25 Dec 2011 14:08:08 +0000 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4EF72CA5.2000002@isode.com> Date: Sun, 25 Dec 2011 14:01:09 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0) Gecko/20111105 Thunderbird/8.0 To: kitten@ietf.org References: <4ECC405A.1000605@cs.tcd.ie> <4EF34518.7010400@cs.tcd.ie> <73DB8DAF-CDC5-4C0E-A063-08C503657304@cisco.com> <4EF72A20.8000700@isode.com> In-Reply-To: <4EF72A20.8000700@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Dec 2011 14:08:11 -0000 On 25/12/2011 13:50, Alexey Melnikov wrote: > Additional comments (mostly nits) on the latest version: One more thing: [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. This is likely to be need to be a Normative Reference. It is Ok that it is Informational, it is already in the Downref registry. From simon@josefsson.org Tue Dec 27 01:39:21 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 92E9221F867F for ; Tue, 27 Dec 2011 01:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, 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 cUITzT6zGb2S for ; Tue, 27 Dec 2011 01:39:21 -0800 (PST) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0A521F85F2 for ; Tue, 27 Dec 2011 01:39:18 -0800 (PST) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id pBR9dBTq009548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 27 Dec 2011 10:39:13 +0100 From: Simon Josefsson To: "Tschofenig\, Hannes \(NSN - FI\/Espoo\)" References: <999913AB42CC9341B05A99BBF358718DE38797__19699.0697448657$1324373802$gmane$org@FIESEXC035.nsn-intra.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:111227:kitten@ietf.org::vOu+TPLEgNHIjUij:FuPW X-Hashcash: 1:22:111227:hannes.tschofenig@nsn.com::HYIiZX9Wm50+SaeX:7oRM Date: Tue, 27 Dec 2011 10:39:12 +0100 In-Reply-To: <999913AB42CC9341B05A99BBF358718DE38797__19699.0697448657$1324373802$gmane$org@FIESEXC035.nsn-intra.net> (Hannes Tschofenig's message of "Tue, 20 Dec 2011 11:36:19 +0200") Message-ID: <87zkeepd4v.fsf@latte.josefsson.org> User-Agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: kitten@ietf.org Subject: Re: [kitten] SASL OAuth: Next Steps 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, 27 Dec 2011 09:39:21 -0000 "Tschofenig, Hannes (NSN - FI/Espoo)" writes: > Hi all, > > Around IETF#82 I have submitted the SASL OAuth draft as a WG item. Here > is the draft version: > http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt Thanks for this work, Hannes. I have been in a few discussions where OAuth v1 vs v2 has been confusing -- the protocols are different and incompatible. I think your document could be a bit more explicit that it intends to work with OAuth version 2 only (I am assuming that this is your intention -- correct me if I'm wrong) -- how about something like this: OLD: (Title) A SASL and GSS-API Mechanism for OAuth NEW: A SASL and GSS-API Mechanism for OAuth version 2 OLD: (Abstract) This document defines how an application client uses OAuth over the Simple Authentication and Security Layer (SASL) or the Generic NEW: This document defines how an application client uses OAuth version 2 over the Simple Authentication and Security Layer (SASL) or the Generic OLD: application protocols. NEW: application protocols. OAuth version 1 is not supported. OLD: (Introduction) OAuth [I-D.ietf-oauth-v2] enables a third-party application to obtain NEW: OAuth version 2 [I-D.ietf-oauth-v2] enables a third-party application to obtain OLD: the focus is on an HTTP-based environment only. NEW: the focus is on an HTTP-based environment only. Note that OAuth version 1 is not supported. Or something like that. /Simon From Hannes.Tschofenig@gmx.net Tue Dec 27 02:32: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 2B3E521F8586 for ; Tue, 27 Dec 2011 02:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 OCUNECZAnubk for ; Tue, 27 Dec 2011 02:32:42 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id A5CB421F8564 for ; Tue, 27 Dec 2011 02:32:41 -0800 (PST) Received: (qmail 25355 invoked by uid 0); 27 Dec 2011 10:25:59 -0000 Received: from 192.100.112.202 by rms-de007.v300.gmx.net with HTTP Content-Type: multipart/alternative; boundary="========GMXBoundary97681324981558198762" Date: Tue, 27 Dec 2011 11:25:57 +0100 From: "Hannes Tschofenig" Message-ID: <20111227102558.97680@gmx.net> MIME-Version: 1.0 To: "Simon Josefsson" ,"Tschofenig, Hannes (NSN - FI/Espoo)" X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: GMX.net Web Mailer x-registered: 0 X-GMX-UID: YfiLbkxHeSEqSJIAqXUhdW9+IGRvbwCp Cc: kitten@ietf.org Subject: Re: [kitten] SASL OAuth: Next Steps 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, 27 Dec 2011 10:32:43 -0000 --========GMXBoundary97681324981558198762 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi Simon, you raise an interesting point about the interaction between OAuth v1 and OAuth v2. Let us have a look at the architecture figure from the draft: ----+ +--------+ +---------------+ | | |--(A)-- Authorization Request --->| Resource | | | | | Owner | |Plain | |<-(B)------ Access Grant ---------| | |OAuth | | +---------------+ |2.0 | | | | | Client Credentials & +---------------+ | | |--(C)------ Access Grant -------->| Authorization | | | Client | | Server | | | |<-(D)------ Access Token ---------| | | | | (w/ Optional Refresh Token) +---------------+ | | | ----+ | | | | ----+ | | (Optional discovery) +---------------+ | | |--(1)------- User Name --------->| | | | Client | | | | | |<-(2)------ Authentication -------| | | | | endpoint information | Resource | |OAuth | | | Server | |over | |--(E)------ Access Token -------->| | |SASL/ | | | | |GSS- | |<-(F)---- Protected Resource -----| | |API +--------+ +---------------+ | ----+ The draft really only covers the interaction between the client and the resource server. Steps (1) and (2) are still sort of ideas rather than anything concrete given the status of the work in the OAuth WG. So, the draft focuses on presenting the token to a resource server (by the client) and to receive a response (potentionally an error). This is exchange (E) and (F) in the figure. Now, one can argue that there is similarity between OAuth v1 and v2 with regard to this step (if we believe in the idea that conveying the HTTP headers inside SASL will allow you to inherit all the functionality from the OAuth specification (such as the bearer token, the MAC authentication, or even the public key based version from OAuth v1). On the other hand you are right that these versions are substantially different and also the stuff that happens outside the context of the specification (namely the steps A-D) matter implementation wise since the code has to be there as well. So, the question shows up about how to indicate/communicate these feature and version differences. Interestingly, this is yet another issue that surfaced recently in the OAuth discussions under the topic of "mandatory-to-implement". In a nutshell, I don't really have a good response to you. If we switch to a JSON based encoding, as Leif had suggested, then the idea of simply inheriting the functionality from OAuth v1 and OAuth v2 does not work easily anymore and so the question does not show up. Whether this is a good thing or not I don't know. Your suggestion with being more precise about the supported functionality / version goes into a similar direction. Ciao Hannes > ----- Ursprüngliche Nachricht ----- > > Von: Simon Josefsson > > Gesendet: 27.12.11 11:39 Uhr > > An: Tschofenig\, Hannes \(NSN - FI\/Espoo\) > > Betreff: Re: [kitten] SASL OAuth: Next Steps > "Tschofenig, Hannes (NSN - FI/Espoo)" > writes: > > > Hi all, > > > > Around IETF#82 I have submitted the SASL OAuth draft as a WG item. Here > > is the draft version: > > http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt > > Thanks for this work, Hannes. I have been in a few discussions where > OAuth v1 vs v2 has been confusing -- the protocols are different and > incompatible. I think your document could be a bit more explicit that > it intends to work with OAuth version 2 only (I am assuming that this is > your intention -- correct me if I'm wrong) -- how about something like > this: > > OLD: (Title) > A SASL and GSS-API Mechanism for OAuth > NEW: > A SASL and GSS-API Mechanism for OAuth version 2 > > OLD: (Abstract) > This document defines how an application client uses OAuth over the > Simple Authentication and Security Layer (SASL) or the Generic > NEW: > This document defines how an application client uses OAuth version 2 over the > Simple Authentication and Security Layer (SASL) or the Generic > > OLD: > application protocols. > > NEW: > application protocols. OAuth version 1 is not supported. > > OLD: (Introduction) > OAuth [I-D.ietf-oauth-v2] enables a third-party application to obtain > > NEW: > OAuth version 2 [I-D.ietf-oauth-v2] enables a third-party application to obtain > > OLD: > the focus is on an HTTP-based environment only. > > NEW: > the focus is on an HTTP-based environment only. Note that OAuth > version 1 is not supported. > > Or something like that. > > /Simon > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --========GMXBoundary97681324981558198762 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Simon,
=20
=20 you raise an interesting point about the interaction between OAuth v1 and O= Auth v2.
=20
=20 Let us have a look at the architecture figure from the draft:
=20
=20             &nb= sp;            =             &nb= sp;            =             ----+=20    +--------+        &nbs= p;            &= nbsp;            +--= -------------+  |
=20    |        |--(A)-- Authoriza= tion Request --->|   Resource    |  |
=20    |        |   = ;            &n= bsp;            = ;      |     Owner  =    |  |Plain
=20    |        |<-(B)------ Ac= cess Grant ---------|         =       |  |OAuth
=20    |        |   = ;            &n= bsp;            = ;      +---------------+  |2.0
=20    |        |   = ;            &n= bsp;            = ;            &n= bsp;            |=20    |        |   = ;      Client Credentials &   &= nbsp; +---------------+  |
=20    |        |--(C)------ Acces= s Grant -------->| Authorization |  |
=20    | Client |        &nbs= p;            &= nbsp;            |&n= bsp;    Server    |  |
=20    |        |<-(D)------ Ac= cess Token ---------|         =       |  |
=20    |        |   = ;   (w/ Optional Refresh Token) +---------------+  |
= =20    |        |   = ;            &n= bsp;            = ;            &n= bsp;        ----+
=20    |        |
=20    |        |   = ;            &n= bsp;            = ;            &n= bsp;        ----+
=20    |        |   = ;     (Optional discovery)     = ; +---------------+  |
=20    |        |--(1)------- User= Name  --------->|        &= nbsp;      |  |
=20    | Client |        &nbs= p;            &= nbsp;            |&n= bsp;            = ;  |  |
=20    |        |<-(2)------ Au= thentication -------|         =       |  |
=20    |        |   = ;       endpoint information   = ; |    Resource   |  |OAuth
=20    |        |   = ;            &n= bsp;            = ;      |     Server  = ;  |  |over
=20    |        |--(E)------ Acces= s Token -------->|         =       |  |SASL/
=20    |        |   = ;            &n= bsp;            = ;      |       =         |  |GSS-
=20    |        |<-(F)---- Prot= ected Resource -----|         =       |  |API
=20    +--------+        &nbs= p;            &= nbsp;            +--= -------------+  |
=20             &nb= sp;            =             &nb= sp;            =             ----+=20
=20
=20 The draft really only covers the interaction between the client and the res= ource server.
=20 Steps (1) and (2) are still sort of ideas rather than anything concrete giv= en the status of the work in the OAuth WG.
=20
=20 So, the draft focuses on presenting the token to a resource server (by the = client) and to receive a response (potentionally an error).
=20 This is exchange (E) and (F) in the figure.
=20
=20 Now, one can argue that there is similarity between OAuth v1 and v2 with re= gard to this step (if we believe in the idea that conveying the HTTP header= s inside SASL will allow you to inherit all the functionality from the OAut= h specification (such as the bearer token, the MAC authentication, or even = the public key based version from OAuth v1).
=20
=20 On the other hand you are right that these versions are substantially diffe= rent and also the stuff that happens outside the context of the specificati= on (namely the steps A-D) matter implementation wise since the code has to = be there as well. So, the question shows up about how to indicate/communica= te these feature and version differences. Interestingly, this is yet anothe= r issue that surfaced recently in the OAuth discussions under the topic of = "mandatory-to-implement".
=20
=20 In a nutshell, I don't really have a good response to you. If we switch to = a JSON based encoding, as Leif had suggested, then the idea of simply inher= iting the functionality from OAuth v1 and OAuth v2 does not work easily any= more and so the question does not show up. Whether this is a good thing or = not I don't know. Your suggestion with being more precise about the support= ed functionality / version goes into a similar direction.
=20
=20 Ciao
=20 Hannes
=20
=20
=20 > ----- Urspr=C3=BCngliche Nachricht -----
=20 >
=20 > Von: Simon Josefsson
=20 >
=20 > Gesendet: 27.12.11 11:39 Uhr
=20 >
=20 > An: Tschofenig\, Hannes \(NSN - FI\/Espoo\)
=20 >
=20 > Betreff: Re: [kitten] SASL OAuth: Next Steps
=20 > "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>= ;
=20 > writes:
=20 >
=20 > > Hi all,
=20 > >
=20 > > Around IETF#82 I have submitted the SASL OAuth draft as a WG item= . Here
=20 > > is the draft version:
=20 > > http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt
= =20 >
=20 > Thanks for this work, Hannes.  I have been in a few discussions w= here
=20 > OAuth v1 vs v2 has been confusing -- the protocols are different and=20 > incompatible.  I think your document could be a bit more explicit= that
=20 > it intends to work with OAuth version 2 only (I am assuming that this = is
=20 > your intention -- correct me if I'm wrong) -- how about something like=
=20 > this:
=20 >
=20 > OLD: (Title)
=20 >            = ;      A SASL and GSS-API Mechanism for OAuth
=20 > NEW:
=20 >            = ;      A SASL and GSS-API Mechanism for OAuth vers= ion 2
=20 >
=20 > OLD: (Abstract)
=20 >    This document defines how an application client uses= OAuth over the
=20 >    Simple Authentication and Security Layer (SASL) or t= he Generic
=20 > NEW:
=20 >    This document defines how an application client uses= OAuth version 2 over the
=20 >    Simple Authentication and Security Layer (SASL) or t= he Generic
=20 >
=20 > OLD:
=20 >     application protocols.
=20 >
=20 > NEW:
=20 >     application protocols.  OAuth version 1 i= s not supported.
=20 >
=20 > OLD: (Introduction)
=20 >     OAuth [I-D.ietf-oauth-v2] enables a third-part= y application to obtain
=20 >
=20 > NEW:
=20 >     OAuth version 2 [I-D.ietf-oauth-v2] enables a = third-party application to obtain
=20 >
=20 > OLD:
=20 >    the focus is on an HTTP-based environment only.
=20 >
=20 > NEW:
=20 >    the focus is on an HTTP-based environment only. = ; Note that OAuth
=20 >    version 1 is not supported.
=20 >
=20 > Or something like that.
=20 >
=20 > /Simon
=20 > _______________________________________________
=20 > Kitten mailing list
=20 > Kitten@ietf.org
=20 > https://www.ietf.org/mailman/listinfo/kitten
=20 --========GMXBoundary97681324981558198762-- From wmills@yahoo-inc.com Tue Dec 27 08:46:18 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 39A5721F84F8 for ; Tue, 27 Dec 2011 08:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.998 X-Spam-Level: X-Spam-Status: No, score=-14.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] 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 F-4KDGYUc1R2 for ; Tue, 27 Dec 2011 08:46:17 -0800 (PST) Received: from nm34-vm6.bullet.mail.ne1.yahoo.com (nm34-vm6.bullet.mail.ne1.yahoo.com [98.138.229.86]) by ietfa.amsl.com (Postfix) with SMTP id 18B2F21F84D6 for ; Tue, 27 Dec 2011 08:46:16 -0800 (PST) Received: from [98.138.90.52] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 27 Dec 2011 16:46:12 -0000 Received: from [98.138.87.1] by tm5.bullet.mail.ne1.yahoo.com with NNFMP; 27 Dec 2011 16:46:12 -0000 Received: from [127.0.0.1] by omp1001.mail.ne1.yahoo.com with NNFMP; 27 Dec 2011 16:46:12 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 476453.41561.bm@omp1001.mail.ne1.yahoo.com Received: (qmail 98878 invoked by uid 60001); 27 Dec 2011 16:46:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1325004372; bh=OhV9iUPO5mMHUhOwynl2YNUx7bnMqhiG9VAOlbSliTY=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=Ud+YcikMoz9FQkPcaxtRcexB1rXgbxb39HKmf6+qMqUipIrIfogBiKgmOipukHe092pi9fzku3GhYtBMTK6ea/FKcgM0B/vVidsSbjoL9kp1N0G7/7+MB+iDf4TXb8C2hVcsO9qyjaxsRV+68yDIDHLA8M09Skj3AwNizLc7Bh0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=UINDsjODDC9T3YDMa2aUZGddxS0mWiZEq9wqbyA1jS0jV6BePZ1RWZaulw4ECiChGjdLSpKE0WNihuF2XbmxzZ0oEog9ywdg9IjcjUZaHCX8cPTddSkAYWqwvc2W3al78zJkd/ypG+4/xurt/E08F9CrY/rG1NGeqEvSp0nlhZM=; X-YMail-OSG: fMnMrBgVM1mLeDcagUqqtVxsY9oZiM._LW0khiFwkir1Vou gQblj13qb9NQNYqJ6LSyNo5CFFGWFBJee2Xut83yYruk9WvsXCNr7zSaKewJ FoW7PawR13drTmeCOEe8vWah7dXddFOXWtR5PJPYqcupV5n1bUqjePbVjRm6 sp8yOsoIQ3fZAA1.KYtzKxBwaZ8bdVG5IoJxr9BCeQrVIL5yYhRTjE51C6H5 41GyAJ_OWfoRiR8my.lcpbPulR5j_7atWE2slAirYY3MABx.Lwxy3_4oo7GM _WKzP0kRY.t06QJTEWptpUrP_bhLtv4U3dPoY8kPYURkiFCCHW5.bzp8vchP bbxAZ_AKmAXpg1XeMX4xuDxxvKwsi.5KHqmz9lOJUAVvxuCuhwzWeEKJL40n u1L_7lYrqyLw- Received: from [99.31.212.42] by web31811.mail.mud.yahoo.com via HTTP; Tue, 27 Dec 2011 08:46:11 PST X-RocketYMMF: william_john_mills X-Mailer: YahooMailWebService/0.8.116.331537 References: <999913AB42CC9341B05A99BBF358718DE38797__19699.0697448657$1324373802$gmane$org@FIESEXC035.nsn-intra.net> <87zkeepd4v.fsf@latte.josefsson.org> Message-ID: <1325004371.20396.YahooMailNeo@web31811.mail.mud.yahoo.com> Date: Tue, 27 Dec 2011 08:46:11 -0800 (PST) From: William Mills To: Simon Josefsson , "Tschofenig, Hannes \(NSN - FI/Espoo\)" In-Reply-To: <87zkeepd4v.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="764183289-790407880-1325004371=:20396" Cc: "kitten@ietf.org" Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: William Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 16:46:18 -0000 --764183289-790407880-1325004371=:20396 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable In fact, as written, there's nothing that prevents supporting an OAuth 1.0a= authentication to the RP, but the discovery stuff is incompatible.=A0 I do= n't want to write out OAuth 1.0a because extant server-to-server solutions = could migrate to this SASL mechanism, although this could be a veyr small n= umber in fact and maybe it isn't worth it.=0A=0A=0A=0A_____________________= ___________=0A From: Simon Josefsson =0ATo: "Tschofeni= g, Hannes (NSN - FI/Espoo)" =0ACc: kitten@ietf.= org =0ASent: Tuesday, December 27, 2011 1:39 AM=0ASubject: Re: [kitten] SAS= L OAuth: Next Steps=0A =0A"Tschofenig, Hannes (NSN - FI/Espoo)" =0Awrites:=0A=0A> Hi all, =0A>=0A> Around IETF#82 I have su= bmitted the SASL OAuth draft as a WG item. Here=0A> is the draft version:= =0A> http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt=0A=0AThanks= for this work, Hannes.=A0 I have been in a few discussions where=0AOAuth v= 1 vs v2 has been confusing -- the protocols are different and=0Aincompatibl= e.=A0 I think your document could be a bit more explicit that=0Ait intends = to work with OAuth version 2 only (I am assuming that this is=0Ayour intent= ion -- correct me if I'm wrong) -- how about something like=0Athis:=0A=0AOL= D: (Title)=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A SASL and GSS-API Mechanism = for OAuth=0ANEW:=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 A SASL and GSS-API Mech= anism for OAuth version 2=0A=0AOLD: (Abstract)=0A=A0 This document defines= how an application client uses OAuth over the=0A=A0 Simple Authentication= and Security Layer (SASL) or the Generic=0ANEW:=0A=A0 This document defin= es how an application client uses OAuth version 2 over the=0A=A0 Simple Au= thentication and Security Layer (SASL) or the Generic=0A=0AOLD:=0A=A0 =A0 a= pplication protocols.=0A=0ANEW:=0A=A0 =A0 application protocols.=A0 OAuth v= ersion 1 is not supported.=0A=0AOLD: (Introduction)=0A=A0 =A0 OAuth [I-D.ie= tf-oauth-v2] enables a third-party application to obtain=0A=0ANEW:=0A=A0 = =A0 OAuth version 2 [I-D.ietf-oauth-v2] enables a third-party application t= o obtain=0A=0AOLD:=0A=A0 the focus is on an HTTP-based environment only.= =0A=0ANEW:=0A=A0 the focus is on an HTTP-based environment only.=A0 Note t= hat OAuth=0A=A0 version 1 is not supported.=0A=0AOr something like that.= =0A=0A/Simon=0A_______________________________________________=0AKitten mai= ling list=0AKitten@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/kitten --764183289-790407880-1325004371=:20396 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
In fact, as written, there's nothing that prevents supporting an OAuth 1.= 0a authentication to the RP, but the discovery stuff is incompatible. = I don't want to write out OAuth 1.0a because extant server-to-server solut= ions could migrate to this SASL mechanism, although this could be a veyr sm= all number in fact and maybe it isn't worth it.

=
From: Simo= n Josefsson <simon@josefsson.org>
To: "Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
Sent: Tuesday, December 27, 2011 1:39 AM
Subject: Re: [kitten] SASL OAuth: Next Steps=

=0A"Tschofenig, Hannes (NSN - FI/Espoo)" <hannes.tschofenig@nsn.com>
writes:

> Hi all,
>=
> Around IETF#82 I have submitted the SASL OAuth draft as a WG item.= Here
> is the draft version:
> http://www.ietf.org/id/draft-ie= tf-kitten-sasl-oauth-00.txt

Thanks for this work, Hannes.  I ha= ve been in a few discussions where
OAuth v1 vs v2 has been confusing -- = the protocols are different and
incompatible.  I think your documen= t could be a bit more explicit that
it intends to work with OAuth versio= n 2 only (I am assuming that this is
your intention -- correct me if I'm= wrong) -- how about something like
this:

OLD: (Title)
  =               A SASL and GSS-API Mechan= ism for OAuth
NEW:
              &= nbsp; A SASL and GSS-API Mechanism for OAuth version 2

OLD: (Abstract)
  Th= is document defines how an application client uses OAuth over the
 = Simple Authentication and Security Layer (SASL) or the Generic
NEW:  This document defines how an application client uses OAuth version= 2 over the
  Simple Authentication and Security Layer (SASL) or t= he Generic

OLD:
    application protocols.

NEW:<= br>    application protocols.  OAuth version 1 is not suppor= ted.

OLD: (Introduction)
    OAuth [I-D.ietf-oauth-v2] = enables a third-party application to obtain

NEW:
    OA= uth version 2 [I-D.ietf-oauth-v2] enables a third-party application to obta= in

OLD:
  the focus is on an HTTP-based environment only.
NEW:
  the focus is on an HTTP-based environment only. = Note that OAuth
  version 1 is not supported.

Or something like that.

/Simon
____________________________________= ___________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.or= g/mailman/listinfo/kitten


--764183289-790407880-1325004371=:20396-- From hannes.tschofenig@gmx.net Wed Dec 28 00:13:26 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 97C7321F8906 for ; Wed, 28 Dec 2011 00:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 XaYxYLefCH0X for ; Wed, 28 Dec 2011 00:13:25 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 20FFE21F854E for ; Wed, 28 Dec 2011 00:13:23 -0800 (PST) Received: (qmail invoked by alias); 28 Dec 2011 08:13:22 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.104]) [88.115.216.191] by mail.gmx.net (mp018) with SMTP; 28 Dec 2011 09:13:22 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/tmJhVae3tEDNDZac9Dob2A2lRpgmCsDCbRlMJVh zFKStjHN88dTww Message-ID: <4EFAD00C.1010101@gmx.net> Date: Wed, 28 Dec 2011 10:15:08 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111220 Thunderbird/9.0 MIME-Version: 1.0 To: William Mills References: <999913AB42CC9341B05A99BBF358718DE38797__19699.0697448657$1324373802$gmane$org@FIESEXC035.nsn-intra.net> <87zkeepd4v.fsf@latte.josefsson.org> <1325004371.20396.YahooMailNeo@web31811.mail.mud.yahoo.com> In-Reply-To: <1325004371.20396.YahooMailNeo@web31811.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "kitten@ietf.org" , Simon Josefsson Subject: Re: [kitten] SASL OAuth: Next Steps X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 08:13:26 -0000 There are two design approaches, as I tried to explain in my earlier cryptic writeup. 1) Assume that all you need to specify is the exchange of the OAuth token and the rest is outside the scope of the specification. This approach had, for example, been chosen by RFC 5878 where an extension to TLS had been defined to carry SAML assertions and other tokens. The document does not explain where the TLS client gets these assertions from. Also SASL OAuth follows this approach and so does XMPP OAuth, see http://xmpp.org/extensions/xep-0235.html 2) Assume that you also want to standardize how the client obtains the token in addition to the mechanism to present it to the server. This approach is used, for example, with SASL SAML, see http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml/, and SASL SAML-EC, http://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/. The main question is: What level of interoperability we you want to accomplish? With (1) a client A may use protocol Foo to obtain a token and client B may use a different protocol, called Bar, to also obtain a token. Both interoperate nicely nicely with a server that understands how to receive tokens. Obviously, a random client implementation will not manage to get a token in every environment. Imagine that a client uses a library that only works with OAuth v1 code and the authorization server speaks only OAuth v2 then the entire procedure will of course fail. (2) is a restricted version of (1) that defines more than just the client to protected resource server exchange. Which approach is better? Hard to say. A possible middleground is to standardize (1) in addition to "profiles" for (2). For example, when a plain exchange of the OAuth token is defined with (1) then one could also pick a common way for obtaining tokens with, let's say, OAuth 2.0, and describe all the details. That description could even go further by looking into a specific application protocol usage (such as SASL within IMAP). Ciao Hannes On 27.12.2011 18:46, William Mills wrote: > In fact, as written, there's nothing that prevents supporting an OAuth > 1.0a authentication to the RP, but the discovery stuff is incompatible. > I don't want to write out OAuth 1.0a because extant server-to-server > solutions could migrate to this SASL mechanism, although this could be a > veyr small number in fact and maybe it isn't worth it. > > ------------------------------------------------------------------------ > *From:* Simon Josefsson > *To:* "Tschofenig, Hannes (NSN - FI/Espoo)" > *Cc:* kitten@ietf.org > *Sent:* Tuesday, December 27, 2011 1:39 AM > *Subject:* Re: [kitten] SASL OAuth: Next Steps > > "Tschofenig, Hannes (NSN - FI/Espoo)" > > writes: > > > Hi all, > > > > Around IETF#82 I have submitted the SASL OAuth draft as a WG item. Here > > is the draft version: > > http://www.ietf.org/id/draft-ietf-kitten-sasl-oauth-00.txt > > Thanks for this work, Hannes. I have been in a few discussions where > OAuth v1 vs v2 has been confusing -- the protocols are different and > incompatible. I think your document could be a bit more explicit that > it intends to work with OAuth version 2 only (I am assuming that this is > your intention -- correct me if I'm wrong) -- how about something like > this: > > OLD: (Title) > A SASL and GSS-API Mechanism for OAuth > NEW: > A SASL and GSS-API Mechanism for OAuth version 2 > > OLD: (Abstract) > This document defines how an application client uses OAuth over the > Simple Authentication and Security Layer (SASL) or the Generic > NEW: > This document defines how an application client uses OAuth version 2 > over the > Simple Authentication and Security Layer (SASL) or the Generic > > OLD: > application protocols. > > NEW: > application protocols. OAuth version 1 is not supported. > > OLD: (Introduction) > OAuth [I-D.ietf-oauth-v2] enables a third-party application to obtain > > NEW: > OAuth version 2 [I-D.ietf-oauth-v2] enables a third-party application to > obtain > > OLD: > the focus is on an HTTP-based environment only. > > NEW: > the focus is on an HTTP-based environment only. Note that OAuth > version 1 is not supported. > > Or something like that. > > /Simon > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten