From hannes.tschofenig@gmx.net Sun Feb 10 02:17:57 2013 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 D081721F84D0 for ; Sun, 10 Feb 2013 02:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.459 X-Spam-Level: X-Spam-Status: No, score=-102.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SC6Rj2AJL5VP for ; Sun, 10 Feb 2013 02:17:56 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 7A99E21F8430 for ; Sun, 10 Feb 2013 02:17:56 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MARmu-1UEu7N2S3G-00BfUt for ; Sun, 10 Feb 2013 11:17:55 +0100 Received: (qmail invoked by alias); 10 Feb 2013 10:17:55 -0000 Received: from a88-115-219-140.elisa-laajakaista.fi (EHLO VerenaNetbook) [88.115.219.140] by mail.gmx.net (mp019) with SMTP; 10 Feb 2013 11:17:55 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+vt45HDgCvQ+RTO9/ZNsUufjQ5xpy6Svegg/ugoX RnelPUa82QGkrS Message-ID: <05634A5BBACD435589A2C769AE0C4BC0@VerenaNetbook> From: "Hannes Tschofenig" To: "Jeffrey Hutzelman" References: <26027_1355766716_qBHHptmU008972_23F98B0F-9BC1-4717-9CB0-889676C898BE@gmx.net> <1355781348.2312.94.camel@minbar.fac.cs.cmu.edu> In-Reply-To: <1355781348.2312.94.camel@minbar.fac.cs.cmu.edu> Date: Sun, 10 Feb 2013 12:17:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 X-Y-GMX-Trusted: 0 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] OAuth SASL Draft Update 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, 10 Feb 2013 10:17:58 -0000 Hi Jeff, thanks for your review comments. I guess you are right that we got the description of the GSS flags wrong. I can just speculate why we made that mistake but it could be rooted in the complex relationship between SASL and the GSS-API. Maybe that's just an excuse from my side. Unfortunately, it seems that this is also the case for some previously published specifications (such as the SASL SAML document). In any case, your comments came at the right time and I will provide a text proposal with the correct description in a separate mail. Regarding the security consideration section you are right that we could have provided more text. However, that text already exists with RFC 6819 and we didn't want to repeat everything here again. The difference between the the SASL / GSS usage of OAuth and the HTTP usage is fairly small (intentionally); we are actually only talking about a different layer of encapsulation for the communication between the client and the resource server (speaking in OAuth terms). So, I could instead just reference the respective documents that explain security characteristics of OAuth. I will also post a text proposal to the list and then we can see which approach you like better. Ciao Hannes -----Original Message----- From: Jeffrey Hutzelman Sent: Monday, December 17, 2012 9:55 PM To: Hannes Tschofenig Cc: jhutz@cmu.edu ; kitten@ietf.org Subject: Re: [kitten] OAuth SASL Draft Update On Mon, 2012-12-17 at 19:51 +0200, Hannes Tschofenig wrote: > Hi all, > > I thought I should submit the current draft snapshot. Here is the current > version: > http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-09 > OAuth mechanims security contexts always have the mutual_state flag > (GSS_C_MUTUAL_FLAG) set to TRUE. OAuth supports credential > delegation, therefore security contexts may have the deleg_state flag > (GSS_C_DELEG_FLAG) set to either TRUE or FALSE. > > The mutual authentication property of this mechanism relies on > successfully comparing the TLS server identity with the negotiated > target name. Since the TLS channel is managed by the application > outside of the GSS-API mechanism, the mechanism itself is unable to > confirm the name while the application is able to perform this > comparison for the mechanism. For this reason, applications MUST > match the TLS server identity with the target name using the > appropriate application profile, as discussed in [RFC6125]. For > example, when SASL OAuth is run over IMAP then the IMAP profile of > RFC 6125 is used. So in other words, this mechanism does _not_ provide mutual auth. The mutual_state flag indicates that the _mechanism_ has authenticated the server. Here, you are saying that the mechanism cannot do so, and so it is up to the application to do so. That's fine, but then you cannot set mutual_auth, because that amounts to lying to the GSS-API application. This is important, because GSS applications depend on this flag to know whether they can depend on GSS-API channel bindings to bind the enclosing channel to the server's identity. That is, they use it to know whether it is OK that they are _not_ checking the TLS server cert (or whatever other channel is in use). You're basically saying that when using this mechanism, the application has to ignore mutual_state and assume the server is not authenticated (and so, neither is the enclosing channel). But you don't get to do that; it violates the API abstraction. Separately, I find the security considerations section in this document to be wholly inadequate. It basically says "there might be issues", but with a couple of specific exceptions does not explore what they are, whether or how the mechanism addresses them, or what steps should be taken to mitigate them. Please see RFC3552 for more information on what should be in the Security Considerations section of an RFC. Please pay particular attention to the discussion in section 5, and especially to the comments on what must be covered in the specific case of authentication mechanisms. IMHO the current document falls short in this regard. -- Jeff From wmills@yahoo-inc.com Sun Feb 10 08:55:15 2013 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 61C5221F85E6 for ; Sun, 10 Feb 2013 08:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.598 X-Spam-Level: X-Spam-Status: No, score=-17.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9GKbbI5+I1Z for ; Sun, 10 Feb 2013 08:55:14 -0800 (PST) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by ietfa.amsl.com (Postfix) with ESMTP id 11F1D21F8782 for ; Sun, 10 Feb 2013 08:55:13 -0800 (PST) Received: from BF1-EX10-CAHT02.y.corp.yahoo.com (bf1-ex10-caht02.corp.bf1.yahoo.com [10.74.209.57]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r1AGt1oa080216 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 10 Feb 2013 08:55:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1360515302; bh=+aqgEVr0wgrb/uhoCl56ao3Be5wYD86ki3fsIbM4oU8=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type; b=LFZW6WsbOZx8CZUDluFbkYcfAro3Ao5yrGv6+h8KCEl7fPxzZ8TIUcIDxaRpclszF 1RksIeleSQyJ6BQ2uJ9Vtbn/X/pdEiGdJEAz988IdxZVZ5c56lxYBRRN/nHyGohFZz BrW0WBxP3d0dQTg3PETpFrJC/zjSOKdobv8yTdMs= Received: from omp1047.mail.ne1.yahoo.com (98.138.89.232) by BF1-EX10-CAHT02.y.corp.yahoo.com (10.74.209.170) with Microsoft SMTP Server id 14.2.328.9; Sun, 10 Feb 2013 11:55:00 -0500 Received: (qmail 26722 invoked by uid 1000); 10 Feb 2013 16:55:00 -0000 Received: (qmail 83096 invoked by uid 60001); 10 Feb 2013 16:55:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1360515300; bh=o/wadoX5RUe1f6qIWINTeyy6U6SUigClUdz5OVgznSc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=LzXbvBiHje9AzndRi0D60jSfwMMvVbB0mQg/ac/bvINL3P1QJii2jZDy0KYZ6w0PSLlhwdLW2qurQZuzJaeHK3XhK0DYc/UkPuzOvAfZYweEMV1gyeT5FZHbeZ2x2c5a1Q5YvEJOJE/IBwqT/q9eE4v8JCAFWrAq3ubdFe8pd/M= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=MoqE2tiUxt4MMMVJvME0RXH1Ji8PvEq1K5TMrbc3bOfkCOUcmnsxvUs6fPj095PQIUwXbEKhtR622b1pu3ETKDnkdysDIQD4ZJC4DN0uY0ay8bArEuES+DZr5nPA7oA2awl8UtILKF8TqSk1eej115iAR0mrY0G/XEmKoUH1zEA=; X-YMail-OSG: s6HFEQAVM1nUdVOEjyq_UlnfRr57iQpcGb9mMKWNZpdKU_b OPwp945LUT.rTD9TR.g4AcFzzzFRpw9YxpNbpD3LBLcM7rEBl3wkgdZ8DppZ 9PDpzKc92s4nN64UWWMEt3wzh.8_ueMk3JMMch9X4LLGDqpcfw.igUZZyXep GnHCYaJ7DaYViSMx9q30LM_gmsnrS5yMhy0bFmVZ3J7OoXyBmdCZksT4z5d_ l3tjMQCAxTti3Jj26JVRU9DBRPohcEVQUrq__ZvdALDPjU_XQf.IyBz.14iX WYQ2Ud3bIDTWjfo5iurDhrerCxqS8i02_U_b_jqF1rmu6Io7GRm7OZPIr41k .EIslIf24pajYN8J89J.fPcVo2Cyvj16rzPmOuXxDj.R5VlF0V1V2Kg9gmgL P6mzDDMdmidg7kdPf7VP0NlgNr375XNJ5uBZu8kqrcRoBg41TIcnvvzbMbso HjXlpzFTZwTAypgdjkDvY Received: from [209.131.62.115] by web125604.mail.ne1.yahoo.com via HTTP; Sun, 10 Feb 2013 08:55:00 PST X-Rocket-MIMEInfo: 001.001, T24gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb24gc3R1ZmYuLi7CoCBPbmUgb2YgdGhlIG51YW5jZXMgaGVyZSBpcyB0aGF0IHdlJ3JlIG1hcHBpbmcgYW4gYXV0aG9yaXphdGlvbiBtZWNoYW5pc20gKE9BdXRoIHRva2VuIHVzYWdlIGF0IGEgcHJvdGVjdGVkIHJlc291cmNlKSBvbnRvIGFuIGF1dGhlbnRpY2F0aW9uIGZyYW1ld29yayAoU0FTTCkuwqAgVGhhdCBtaWdodCBiZSB3b3J0aCBjYWxsaW5nIG91dC4KCkknbSB3aXRoIEhhbm5lcyBoZXJlIGluIHRoYXQgd2Ugd2FudCB0byByZWZlcmUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.132.503 References: <26027_1355766716_qBHHptmU008972_23F98B0F-9BC1-4717-9CB0-889676C898BE@gmx.net> <1355781348.2312.94.camel@minbar.fac.cs.cmu.edu> <05634A5BBACD435589A2C769AE0C4BC0@VerenaNetbook> Message-ID: <1360515300.77429.YahooMailNeo@web125604.mail.ne1.yahoo.com> Date: Sun, 10 Feb 2013 08:55:00 -0800 From: Bill Mills To: Hannes Tschofenig , Jeffrey Hutzelman In-Reply-To: <05634A5BBACD435589A2C769AE0C4BC0@VerenaNetbook> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-685807438-1744895807-1360515300=:77429" X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 515302000 Cc: "kitten@ietf.org" Subject: Re: [kitten] OAuth SASL Draft Update X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 16:55:15 -0000 ---685807438-1744895807-1360515300=:77429 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On the security considerations section stuff...=A0 One of the nuances here = is that we're mapping an authorization mechanism (OAuth token usage at a pr= otected resource) onto an authentication framework (SASL).=A0 That might be= worth calling out.=0A=0AI'm with Hannes here in that we want to reference = the extensive security discussion that's been done around OAuth and the dif= ferent possible token types, we don't want to include it directly, especial= ly as some are as yet to be written.=A0 I short we can't cover the entire r= ange of security considerations.=A0 Is it sufficient to add to the fist par= agraph (or modify the last sentence) to explicitly say "This SASL mechanism= is extensible to support OAuth token types that are not yet defined, imple= menters MUSTtake into account the security considerations for the specific = token types they implement and apply those to the context the SASL mechanis= m is being implemented for."=0A=0A=0A=0A________________________________=0A= From: Hannes Tschofenig =0ATo: Jeffrey Hutzelma= n =0ACc: kitten@ietf.org; jhutz@cmu.edu =0ASent: Sunday, Fe= bruary 10, 2013 4:17 AM=0ASubject: Re: [kitten] OAuth SASL Draft Update=0A = =0AHi Jeff,=0A=0Athanks for your review comments.=0A=0AI guess you are righ= t that we got the description of the GSS flags wrong. I can just speculate = why we made that mistake but it could be rooted in the complex relationship= between SASL and the GSS-API. Maybe that's just an excuse from my side. Un= fortunately, it seems that this is also the case for some previously publis= hed specifications (such as the SASL SAML document).=0AIn any case, your co= mments came at the right time and I will provide a text proposal with the c= orrect description in a separate mail.=0A=0ARegarding the security consider= ation section you are right that we could have provided more text. However,= that text already exists with RFC 6819 and we didn't want to repeat everyt= hing here again.=0AThe difference between the the SASL / GSS usage of OAuth= and the HTTP usage is fairly small (intentionally); we are actually only t= alking about a different layer of encapsulation for the communication betwe= en the client and the resource server (speaking in OAuth terms).=0A=0ASo, I= could instead just reference the respective documents that explain securit= y characteristics of OAuth.=0AI will also post a text proposal to the list = and then we can see which approach you like better.=0A=0ACiao=0AHannes=0A= =0A-----Original Message----- From: Jeffrey Hutzelman=0ASent: Monday, Decem= ber 17, 2012 9:55 PM=0ATo: Hannes Tschofenig=0ACc: jhutz@cmu.edu ; kitten@i= etf.org=0ASubject: Re: [kitten] OAuth SASL Draft Update=0A=0AOn Mon, 2012-1= 2-17 at 19:51 +0200, Hannes Tschofenig wrote:=0A> Hi all,=0A> =0A> I though= t I should submit the current draft snapshot. Here is the current version:= =0A> http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-09=0A=0A=0A=0A= =0A> OAuth mechanims security contexts always have the mutual_state flag=0A= >=A0 =A0 (GSS_C_MUTUAL_FLAG) set to TRUE.=A0 OAuth supports credential=0A>= =A0 =A0 delegation, therefore security contexts may have the deleg_state fl= ag=0A>=A0 =A0 (GSS_C_DELEG_FLAG) set to either TRUE or FALSE.=0A> =0A>=A0 = =A0 The mutual authentication property of this mechanism relies on=0A>=A0 = =A0 successfully comparing the TLS server identity with the negotiated=0A>= =A0 =A0 target name.=A0 Since the TLS channel is managed by the application= =0A>=A0 =A0 outside of the GSS-API mechanism, the mechanism itself is unabl= e to=0A>=A0 =A0 confirm the name while the application is able to perform t= his=0A>=A0 =A0 comparison for the mechanism.=A0 For this reason, applicatio= ns MUST=0A>=A0 =A0 match the TLS server identity with the target name using= the=0A>=A0 =A0 appropriate application profile, as discussed in [RFC6125].= =A0 For=0A>=A0 =A0 example, when SASL OAuth is run over IMAP then the IMAP = profile of=0A>=A0 =A0 RFC 6125 is used.=0A=0ASo in other words, this mechan= ism does _not_ provide mutual auth.=A0 The=0Amutual_state flag indicates th= at the _mechanism_ has authenticated the=0Aserver.=A0 Here, you are saying = that the mechanism cannot do so, and so it=0Ais up to the application to do= so.=A0 That's fine, but then you cannot set=0Amutual_auth, because that am= ounts to lying to the GSS-API application.=0A=0AThis is important, because = GSS applications depend on this flag to know=0Awhether they can depend on G= SS-API channel bindings to bind the=0Aenclosing channel to the server's ide= ntity.=A0 That is, they use it to=0Aknow whether it is OK that they are _no= t_ checking the TLS server cert=0A(or whatever other channel is in use).=0A= =0AYou're basically saying that when using this mechanism, the application= =0Ahas to ignore mutual_state and assume the server is not authenticated=0A= (and so, neither is the enclosing channel).=A0 But you don't get to do=0Ath= at; it violates the API abstraction.=0A=0A=0A=0ASeparately, I find the secu= rity considerations section in this document=0Ato be wholly inadequate.=A0 = It basically says "there might be issues", but=0Awith a couple of specific = exceptions does not explore what they are,=0Awhether or how the mechanism a= ddresses them, or what steps should be=0Ataken to mitigate them.=A0 Please = see RFC3552 for more information on what=0Ashould be in the Security Consid= erations section of an RFC.=A0 Please pay=0Aparticular attention to the dis= cussion in section 5, and especially to=0Athe comments on what must be cove= red in the specific case of=0Aauthentication mechanisms.=A0 IMHO the curren= t document falls short in=0Athis regard.=0A=0A-- Jeff=0A=0A________________= _______________________________=0AKitten mailing list=0AKitten@ietf.org=0Ah= ttps://www.ietf.org/mailman/listinfo/kitten ---685807438-1744895807-1360515300=:77429 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
On the se= curity considerations section stuff...  One of the nuances here is tha= t we're mapping an authorization mechanism (OAuth token usage at a protecte= d resource) onto an authentication framework (SASL).  That might be wo= rth calling out.

I'm with Hannes here in that we want to reference t= he extensive security discussion that's been done around OAuth and the diff= erent possible token types, we don't want to include it directly, especiall= y as some are as yet to be written.  I short we can't cover the entire= range of security considerations.  Is it sufficient to add to the fis= t paragraph (or modify the last sentence) to explicitly say "This SASL mech= anism is extensible to support OAuth token types that are not yet defined, = implementers MUST take into account the security considerations for the specific token types they implement and ap= ply those to the context the SASL mechanism is being implemented for."
<= br>
From:<= /span> Hannes Tschofenig <hannes.tschofenig@gmx.net>
To: Jeffrey Hutzelman <jhutz@cm= u.edu>
Cc: kitten@i= etf.org; jhutz@cmu.edu
Sent: Sunday, February 10, 2013 4:17 AM
Subject: Re: [kitten] OAuth SASL Draft Update

Hi Jeff,

thanks for your review comments.

I gue= ss you are right that we got the description of the GSS flags wrong. I can just specu= late why we made that mistake but it could be rooted in the complex relatio= nship between SASL and the GSS-API. Maybe that's just an excuse from my sid= e. Unfortunately, it seems that this is also the case for some previously p= ublished specifications (such as the SASL SAML document).
In any case, y= our comments came at the right time and I will provide a text proposal with= the correct description in a separate mail.

Regarding the security = consideration section you are right that we could have provided more text. = However, that text already exists with RFC 6819 and we didn't want to repea= t everything here again.
The difference between the the SASL / GSS usage= of OAuth and the HTTP usage is fairly small (intentionally); we are actual= ly only talking about a different layer of encapsulation for the communicat= ion between the client and the resource server (speaking in OAuth terms).

So, I could instead just reference the respective documents= that explain security characteristics of OAuth.
I will also post a text= proposal to the list and then we can see which approach you like better.
Ciao
Hannes

-----Original Message----- From: Jeffrey Hutzel= man
Sent: Monday, December 17, 2012 9:55 PM
To: Hannes Tschofenig
= Cc: jhutz= @cmu.edu ; kitten@ietf.org
Subject: Re: [kitten] OAuth SASL Draft Upd= ate

On Mon, 2012-12-17 at 19:51 +0200, Hannes Tschofenig wrote:
&= gt; Hi all,
>
> I thought I should submit the current draft sn= apshot. Here is the current version:
> http://tools.iet= f.org/html/draft-ietf-kitten-sasl-oauth-09




> OAut= h mechanims security contexts always have the mutual_state flag
> = ;   (GSS_C_MUTUAL_FLAG) set to TRUE.  OAuth supports credential>    delegation, therefore security contexts may have the de= leg_state flag
>    (GSS_C_DELEG_FLAG) set to either TRUE o= r FALSE.
>
>    The mutual authentication property o= f this mechanism relies on
>    successfully comparing the = TLS server identity with the negotiated
>    target name.&n= bsp; Since the TLS channel is managed by the application
>  &nbs= p; outside of the GSS-API mechanism, the mechanism itself is unable to
&= gt;    confirm the name while the application is able to perform = this
>    comparison for the mechanism.  For this reas= on, applications MUST
>    match the TLS server identity wi= th the target name using the
>    appropriate application profile, as discussed in [RFC6125].  For
>  &n= bsp; example, when SASL OAuth is run over IMAP then the IMAP profile of
= >    RFC 6125 is used.

So in other words, this mechanis= m does _not_ provide mutual auth.  The
mutual_state flag indicates = that the _mechanism_ has authenticated the
server.  Here, you are s= aying that the mechanism cannot do so, and so it
is up to the applicatio= n to do so.  That's fine, but then you cannot set
mutual_auth, beca= use that amounts to lying to the GSS-API application.

This is import= ant, because GSS applications depend on this flag to know
whether they c= an depend on GSS-API channel bindings to bind the
enclosing channel to t= he server's identity.  That is, they use it to
know whether it is O= K that they are _not_ checking the TLS server cert
(or whatever other ch= annel is in use).

You're basically saying that when using this mechanism, the application
has to ignore mutual_state and assume t= he server is not authenticated
(and so, neither is the enclosing channel= ).  But you don't get to do
that; it violates the API abstraction.<= br>


Separately, I find the security considerations section in th= is document
to be wholly inadequate.  It basically says "there migh= t be issues", but
with a couple of specific exceptions does not explore = what they are,
whether or how the mechanism addresses them, or what step= s should be
taken to mitigate them.  Please see RFC3552 for more in= formation on what
should be in the Security Considerations section of an= RFC.  Please pay
particular attention to the discussion in section= 5, and especially to
the comments on what must be covered in the specif= ic case of
authentication mechanisms.  IMHO the current document fa= lls short in
this regard.

-- Jeff

_______________________________________________
Kitten mail= ing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten<= /a>


---685807438-1744895807-1360515300=:77429-- From nico@cryptonector.com Mon Feb 11 12:25:46 2013 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 E412321F8A89 for ; Mon, 11 Feb 2013 12:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.43 X-Spam-Level: X-Spam-Status: No, score=-4.43 tagged_above=-999 required=5 tests=[AWL=-2.453, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TLjOMACxLeMY for ; Mon, 11 Feb 2013 12:25:46 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4A70621F8A84 for ; Mon, 11 Feb 2013 12:25:46 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 1099A350072 for ; Mon, 11 Feb 2013 12:25:46 -0800 (PST) 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=vvX1So2BRbbBSSw70wj/EC4F9Go=; b=FeJjOoDJsgn NecKwy3aw4D8gNpu3/XiAUsKOQSBJVg5FoPU1DxDWY/NzhN/z1kRLyLh6kIlJ4q8 Y+K2dboVphNvIvmEzy+gbGREYjSt48lnB0JCFvc72G2i2320fXHFutBAhRTDP6bC fvXC7Thl2aHE4AmerunnGjzoAtr8pb1E= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id AD262350058 for ; Mon, 11 Feb 2013 12:25:45 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id hm14so3604027wib.16 for ; Mon, 11 Feb 2013 12:25:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.216.5 with SMTP id om5mr26516890wjc.27.1360614344030; Mon, 11 Feb 2013 12:25:44 -0800 (PST) Received: by 10.217.39.133 with HTTP; Mon, 11 Feb 2013 12:25:43 -0800 (PST) Date: Mon, 11 Feb 2013 14:25:43 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 11 Feb 2013 20:25:47 -0000 I was looking at what it'd take to modify various HTTP client libraries to support channel binding. An issue comes up that has come up before: migration is hard. In effect we have to change the clients to do CB first, then when we're done we must change the servers. (Background: implementations of RFC4121 acceptors ignore initiator CB data when the acceptor application provided no CB data. The inverse is not true: if the initiator provides no CB data and the acceptor does then context establishment fails.) This is ETOOHARD in many cases. It's tempting to conclude that in such cases the problem is that there's too many implementations to modify, thus one may never finish at all -- and if one cannot finish then there's no point to trying. But I'm not so sure, and I think that it'd be nice to have an upgrade path that doesn't require any sort of flag day. IF the GSS-API had had a ret_flag by which to indicate that both parties provided CB data and CB succeeded, then we could have negotiated CB more easily. The idea is that if one peer did not provide CB data then this flag would not be set, and if both provided different CB data then context establishment would fail as today. BUT, it's too late to introduce such a flag: applications don't know to check for it. What can we do to improve this? Well, we could introduce such a flag but retain the traditional behavior, with the new behavior being enabled only when additional steps are taken (e.g., configuration, or perhaps a flag set on the acceptor credential handle, or on a duplicate of GSS_C_NO_CREDENTIAL). That's all I can think of. Other alternatives? Nico -- From mrex@sap.com Mon Feb 11 13:01:48 2013 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 28A3F21F886D for ; Mon, 11 Feb 2013 13:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.97 X-Spam-Level: X-Spam-Status: No, score=-9.97 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpEsQzm03Ruz for ; Mon, 11 Feb 2013 13:01:47 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 02DF921F86D9 for ; Mon, 11 Feb 2013 13:01:46 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r1BL1g4l002769 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Feb 2013 22:01:42 +0100 (MET) In-Reply-To: To: Nico Williams Date: Mon, 11 Feb 2013 22:01:42 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130211210142.9C75F1A54A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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: Mon, 11 Feb 2013 21:01:48 -0000 Nico Williams wrote: > I was looking at what it'd take to modify various HTTP client > libraries to support channel binding. An issue comes up that has come > up before: migration is hard. In effect we have to change the clients > to do CB first, then when we're done we must change the servers. > > (Background: implementations of RFC4121 acceptors ignore initiator CB > data when the acceptor application provided no CB data. The inverse > is not true: if the initiator provides no CB data and the acceptor > does then context establishment fails.) > > This is ETOOHARD in many cases. I mentioned that interop problem with MIT Kerberos in Nov-2011: http://www.ietf.org/mail-archive/web/kitten/current/msg02838.html Microsoft Kerberos does not seem to suffer from this problem. Ignoring CB which only the initiator asserts but not ignoring CB that only the acceptor asserts looks like an inconsistency and a bug to me. Rfc2743 clearly says, that _only_ when both peers assert the same type of channel bindings data, then gssapi mechanisms ought to validate that data. And even then, a mechanism implementation may decide to not implement channel bindings and ignore CB data entirely (without this being visible to the calling app, due to a lack of a respective context attribute flag). http://tools.ietf.org/html/rfc2743#page-16 1.1.6: Channel Bindings The GSS-API accommodates the concept of caller-provided channel binding ("chan_binding") information. Channel bindings are used to strengthen the quality with which peer entity authentication is provided during context establishment, by limiting the scope within which an intercepted context establishment token can be reused by an attacker. Specifically, they enable GSS-API callers to bind the establishment of a security context to relevant characteristics (e.g., addresses, transformed representations of encryption keys) of the underlying communications channel, of protection mechanisms applied to that communications channel, and to application-specific data. The caller initiating a security context must determine the appropriate channel binding values to provide as input to the *> GSS_Init_sec_context() call, and consistent values must be provided *> to GSS_Accept_sec_context() by the context's target, in order for *> both peers' GSS-API mechanisms to validate that received tokens *> possess correct channel-related characteristics. Use or non-use of the GSS-API channel binding facility is a caller option. GSS-API mechanisms can operate in an environment where NULL channel bindings are presented; mechanism implementors are encouraged, but not required, to make use of caller-provided channel binding data within their mechanisms. Callers should not assume that underlying mechanisms provide confidentiality protection for channel binding information. > > It's tempting to conclude that in > such cases the problem is that there's too many implementations to > modify, thus one may never finish at all -- and if one cannot finish > then there's no point to trying. But I'm not so sure, and I think > that it'd be nice to have an upgrade path that doesn't require any > sort of flag day. Implementations which do fail on the acceptor side for security contexts where the initiator did not assert any channel bindings are ignoring both, the underlying GSS-API specification, and the ramifications of the implemented behaviour with respect to migration from scenarios that do not use CB to the use of CB. > > IF the GSS-API had had a ret_flag by which to indicate that both > parties provided CB data and CB succeeded, then we could have > negotiated CB more easily. The idea is that if one peer did not > provide CB data then this flag would not be set, and if both provided > different CB data then context establishment would fail as today. > BUT, it's too late to introduce such a flag: applications don't know > to check for it. > > What can we do to improve this? Fix the server-side rfc1964 & rfc4121 implementations which got this wrong. Maybe you could add a new gss_inquire_context_ex() call that returns information about whether&which type of CB data the initiator asserted, whether&which type of CB data the acceptor asserted, and whether the CB data of initiator and acceptor was successfully validated. For context attributes (input as well as output) it might be difficult to distinguish whether a server is dealing with an old implementation that does not recognize and ignore (on input) or not assert (on output) that context attribute, or whether the client did not send CB data. -Martin From nico@cryptonector.com Mon Feb 11 13:22:23 2013 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 7CD7D21F8828 for ; Mon, 11 Feb 2013 13:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.826 X-Spam-Level: X-Spam-Status: No, score=-3.826 tagged_above=-999 required=5 tests=[AWL=-2.449, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwIi-eL7SmdF for ; Mon, 11 Feb 2013 13:22:22 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 75CB321F8659 for ; Mon, 11 Feb 2013 13:22:21 -0800 (PST) Received: from homiemail-a90.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a90.g.dreamhost.com (Postfix) with ESMTP id A28A42AC064 for ; Mon, 11 Feb 2013 13:22:21 -0800 (PST) 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=ojmIeewqkFEHcVLGiN1C rtLyVtU=; b=h4/RC1NGX8izxh3hO+RjaHpJj0YH09B6zM/DKmCexAVyoz3tbll9 SoKmiZ9b5d/yBNKatd6J+zfkgNp+gbzmiVvWozUdcO6lT5J5bGb8S/Uxt4g6gxKe yMkRcPSuHoypwqT5iwfDguuo+SQNkKB3/IJ6M6cecwkf6/ztxQVpzdE= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.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 3001C2AC058 for ; Mon, 11 Feb 2013 13:22:20 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so5333454wey.3 for ; Mon, 11 Feb 2013 13:22:19 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.99.227 with SMTP id et3mr18846804wib.6.1360617739599; Mon, 11 Feb 2013 13:22:19 -0800 (PST) Received: by 10.217.39.133 with HTTP; Mon, 11 Feb 2013 13:22:19 -0800 (PST) In-Reply-To: <20130211210142.9C75F1A54A@ld9781.wdf.sap.corp> References: <20130211210142.9C75F1A54A@ld9781.wdf.sap.corp> Date: Mon, 11 Feb 2013 15:22:19 -0600 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 11 Feb 2013 21:22:23 -0000 On Mon, Feb 11, 2013 at 3:01 PM, Martin Rex wrote: > Nico Williams wrote: >> This is ETOOHARD in many cases. > > I mentioned that interop problem with MIT Kerberos in Nov-2011: > http://www.ietf.org/mail-archive/web/kitten/current/msg02838.html > > Microsoft Kerberos does not seem to suffer from this problem. > > Ignoring CB which only the initiator asserts but not ignoring CB > that only the acceptor asserts looks like an inconsistency and a bug to me. > > Rfc2743 clearly says, that _only_ when both peers assert the same > type of channel bindings data, then gssapi mechanisms ought to > validate that data. And even then, a mechanism implementation > may decide to not implement channel bindings and ignore CB data entirely > (without this being visible to the calling app, due to a lack > of a respective context attribute flag). Golly, you're right, RFC2743 (and RFC2744 does not correct) does imply that CB are ignored when one party doesn't use them. However, without a return flag for indicating CB state this is uselessly broken: there's no way to enforce a CB requirement! If implementations had gotten that right then CB could never be added to existing GSS applications! And it'd be impossible to prevent cut-and-paste attacks where a target principal is used for multiple application protocols some of which use CB and some of which don't. Hmm, this is a serious bug in the spec! We must fix it. >> It's tempting to conclude that in >> such cases the problem is that there's too many implementations to >> modify, thus one may never finish at all -- and if one cannot finish >> then there's no point to trying. But I'm not so sure, and I think >> that it'd be nice to have an upgrade path that doesn't require any >> sort of flag day. > > Implementations which do fail on the acceptor side for security > contexts where the initiator did not assert any channel bindings > are ignoring both, the underlying GSS-API specification, and the > ramifications of the implemented behaviour with respect to > migration from scenarios that do not use CB to the use of CB. See above. It is not reasonable for acceptors to ignore initiator CB without signalling this to the application. >> What can we do to improve this? > > Fix the server-side rfc1964 & rfc4121 implementations which got this wrong. That would break existing applications. > Maybe you could add a new gss_inquire_context_ex() call that returns > information about whether&which type of CB data the initiator asserted, > whether&which type of CB data the acceptor asserted, and whether > the CB data of initiator and acceptor was successfully validated. This is not acceptable; see above. I'm writing an I-D that proposes the following solution: - add a GSS_C_CHANNEL_BOUND_FLAG as a ret_flag - standardize GSS_Set_cred_option() - specify a credential option for signalling that the application understands the new flag - retain existing implementation behavior when the application does not set this credential option Separately, implementations might also provide an env. var. to enable the new behavior. Nico -- From mrex@sap.com Mon Feb 11 13:38:30 2013 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 28C0B21F886C for ; Mon, 11 Feb 2013 13:38:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.254 X-Spam-Level: X-Spam-Status: No, score=-10.254 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P29dFXcDGDow for ; Mon, 11 Feb 2013 13:38:29 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF7E21F8871 for ; Mon, 11 Feb 2013 13:38:28 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r1BLcOEf007138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 11 Feb 2013 22:38:24 +0100 (MET) In-Reply-To: To: Nico Williams Date: Mon, 11 Feb 2013 22:38:24 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130211213824.B79001A54A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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: Mon, 11 Feb 2013 21:38:30 -0000 Nico Williams wrote: > Martin Rex wrote: >> >> Microsoft Kerberos does not seem to suffer from this problem. >> >> Ignoring CB which only the initiator asserts but not ignoring CB >> that only the acceptor asserts looks like an inconsistency and a bug to me. >> >> Rfc2743 clearly says, that _only_ when both peers assert the same >> type of channel bindings data, then gssapi mechanisms ought to >> validate that data. And even then, a mechanism implementation >> may decide to not implement channel bindings and ignore CB data entirely >> (without this being visible to the calling app, due to a lack >> of a respective context attribute flag). > > Golly, you're right, RFC2743 (and RFC2744 does not correct) does imply > that CB are ignored when one party doesn't use them. However, without > a return flag for indicating CB state this is uselessly broken: > there's no way to enforce a CB requirement! GSS-API CB are uselessly broken is misleading. GSS-API CB are useless is the correct determination. If your app-level protocol correctly uses the message protection facilities to protect all app-level communication, then GSS-API CB are unnecessary. If apps want to abuse a GSS-API context establishment handshake as a substitute for an OTP scheme, thats where rfc4559 is suddenly screaming for GSS-API CB... > > If implementations had gotten that right then CB could never be added > to existing GSS applications! And it'd be impossible to prevent > cut-and-paste attacks where a target principal is used for multiple > application protocols some of which use CB and some of which don't. > > Hmm, this is a serious bug in the spec! We must fix it. It's simply a feature that never existed. I'll note, however, that the description of Channel Bindings in GSS-API v1 (rfc1508) is much less clear about the desired behaviour, and rfc1964 may be have inherited the ambiguity (and the lack of conveying the type of CB that was assert) from the GSS-API v1 spec. -Martin From lukeh@padl.com Mon Feb 11 13:42:12 2013 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 6120621F8884 for ; Mon, 11 Feb 2013 13:42:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQtUYx3G8RKK for ; Mon, 11 Feb 2013 13:42:12 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id B479221F8871 for ; Mon, 11 Feb 2013 13:42:11 -0800 (PST) Received: by us.padl.com with ESMTP id r1BLg4IL028442; Mon, 11 Feb 2013 16:42:06 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: <20130211213824.B79001A54A@ld9781.wdf.sap.corp> Date: Tue, 12 Feb 2013 08:42:03 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <81CED6CB-71E9-4115-B235-E57C04E55C2C@padl.com> References: <20130211213824.B79001A54A@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1499) 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] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 11 Feb 2013 21:42:12 -0000 Windows has ASC_REQ_ALLOW_MISSING_BINDINGS / ASC_REQ_PROXY_BINDINGS = (although the documentation says that this is only for HTTP Digest, note = the documentation is often wrong). GSS doesn't have acceptor input flags as you point out. -- Luke= From nico@cryptonector.com Mon Feb 11 13:43:42 2013 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 C545921F887F for ; Mon, 11 Feb 2013 13:43:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.36 X-Spam-Level: X-Spam-Status: No, score=-4.36 tagged_above=-999 required=5 tests=[AWL=-2.383, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3RcX9OLSuaDE for ; Mon, 11 Feb 2013 13:43:42 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 25FE621F8682 for ; Mon, 11 Feb 2013 13:43:42 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 641DE54073 for ; Mon, 11 Feb 2013 13:43:31 -0800 (PST) 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=cyXew3MM6sbRVqmU4Ujg hAn9q/I=; b=jB0rDEw7MKW1NcGOA5ACN8+1kBuApxZjdLD3xCnhlCl0zmrTSUKd G7deOlt6m3Z2tEPG7E3FYTjRxBtjjW80uZExBusn74zNyGahI0W53QJwo1aT/RGL MRLgqR/Hkq074EKYDP4vhbOqSjwBjpaw4NLhiEcByOLeljRJIweDlKM= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 9DF2A5405B for ; Mon, 11 Feb 2013 13:43:30 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hm6so3672096wib.14 for ; Mon, 11 Feb 2013 13:43:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.99.227 with SMTP id et3mr18931485wib.6.1360619009285; Mon, 11 Feb 2013 13:43:29 -0800 (PST) Received: by 10.217.39.133 with HTTP; Mon, 11 Feb 2013 13:43:29 -0800 (PST) In-Reply-To: <20130211213824.B79001A54A@ld9781.wdf.sap.corp> References: <20130211213824.B79001A54A@ld9781.wdf.sap.corp> Date: Mon, 11 Feb 2013 15:43:29 -0600 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 11 Feb 2013 21:43:42 -0000 On Mon, Feb 11, 2013 at 3:38 PM, Martin Rex wrote: > GSS-API CB are uselessly broken is misleading. > GSS-API CB are useless is the correct determination. > > If your app-level protocol correctly uses the message protection > facilities to protect all app-level communication, then GSS-API CB > are unnecessary. If apps want to abuse a GSS-API context establishment > handshake as a substitute for an OTP scheme, thats where rfc4559 is > suddenly screaming for GSS-API CB... Thanks Martin, but that's not a useful answer. Anyone else? I will submit an I-D later today. > It's simply a feature that never existed. Well, no, it did exist in RFC2744, and it was used back when people used IP addresses for channel binding (*that* was useless). > I'll note, however, that the description of Channel Bindings in GSS-API v1 > (rfc1508) is much less clear about the desired behaviour, and rfc1964 > may be have inherited the ambiguity (and the lack of conveying the > type of CB that was assert) from the GSS-API v1 spec. OK, this is useful: we'll call it a bug in the spec and fix it. Thanks Martin. Nico -- From nico@cryptonector.com Mon Feb 11 20:51:54 2013 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 9935B21F8B8D for ; Mon, 11 Feb 2013 20:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.294 X-Spam-Level: X-Spam-Status: No, score=-4.294 tagged_above=-999 required=5 tests=[AWL=-2.317, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMOu3J9xvnkF for ; Mon, 11 Feb 2013 20:51:53 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 8093821F8B8B for ; Mon, 11 Feb 2013 20:51:52 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 91F086B0070 for ; Mon, 11 Feb 2013 20:51:50 -0800 (PST) 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=DauDMVdWxFKI340sc04KpNT iUgA=; b=QqgxaZ3ndmm7rCP77Il0quGWmJJESALBFW5rxkqMDI2cBhPy3jkjDb3 A6+p+k5eN51VBrTyf7hKHk1uU3zJqo6vGUYc118qxP+24ENZp5FOH/0jhE6gFXW6 EVisschtSvjMdlGa3sDAoccHsBrrmm3t1GYyj20oDf60J/HV7g50= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 463076B0059 for ; Mon, 11 Feb 2013 20:51:50 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so3917708wic.5 for ; Mon, 11 Feb 2013 20:51:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.60.5 with SMTP id d5mr11294521wjr.4.1360644708864; Mon, 11 Feb 2013 20:51:48 -0800 (PST) Received: by 10.217.39.133 with HTTP; Mon, 11 Feb 2013 20:51:48 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Feb 2013 22:51:48 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 04:51:54 -0000 I've submitted http://www.ietf.org/id/draft-williams-kitten-channel-bound-flag-00.txt to address this issue. Please review. Nico -- From lukeh@padl.com Mon Feb 11 21:29:23 2013 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 C7B9121F8B94 for ; Mon, 11 Feb 2013 21:29:23 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8oxjtXAx95f for ; Mon, 11 Feb 2013 21:29:22 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id BE7BC21F8B90 for ; Mon, 11 Feb 2013 21:29:22 -0800 (PST) Received: by us.padl.com with ESMTP id r1C5TE1I009550; Tue, 12 Feb 2013 00:29:17 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: Date: Tue, 12 Feb 2013 16:29:14 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1499) 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] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 05:29:23 -0000 Careful, said MS, you're stepping on my toes. #define GSS_C_DCE_STYLE 0x1000 #define GSS_C_IDENTIFY_FLAG 0x2000 #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 On 12/02/2013, at 3:51 PM, Nico Williams wrote: > I've submitted = http://www.ietf.org/id/draft-williams-kitten-channel-bound-flag-00.txt > to address this issue. >=20 > Please review. >=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 mrex@sap.com Mon Feb 11 21:34:34 2013 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 C946321F8BC0 for ; Mon, 11 Feb 2013 21:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.954 X-Spam-Level: X-Spam-Status: No, score=-9.954 tagged_above=-999 required=5 tests=[AWL=-0.305, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRzeVDswZApU for ; Mon, 11 Feb 2013 21:34:34 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 25A6E21F8BBC for ; Mon, 11 Feb 2013 21:34:33 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r1C5YTeN027375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Feb 2013 06:34:29 +0100 (MET) In-Reply-To: To: Nico Williams Date: Tue, 12 Feb 2013 06:34:29 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130212053429.C84B11A54D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 05:34:34 -0000 Wouldn't it be simple to use one single API call with an additional "critical" input parameter rather than these two with weirdly different API semantics (only the _critical variant with an option to create a modified copy of the handle). Btw. the use of expressions such as "const gss_OID" "const gss_buffer_t" is a historic defect of the GSS-API v2 C-Bindings spec (indicating that the author didn't know how "const" affects typedef'ed pointers -- it results in const pointers to mutable data, rather than a mutable pointers to const data. alternatives to choose from: (1) simply drop const gss_function( ... , gss_OID oid_param , ... ); (2) avoid the typedefed pointer gss_function( ... , const gss_OID_desc * oid_param , ... ); (3) define appropriate pointer-to-const-data types: typedef const gss_OID_desc * const_gss_OID; typedef const gss_buffer_desc * const_gss_buffer_t; gss_function( ... , const_gss_OID oid_param , ... ); -Martin From lukeh@padl.com Mon Feb 11 21:40:22 2013 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 B81EE21F8BAF for ; Mon, 11 Feb 2013 21:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIz0MYgR94gD for ; Mon, 11 Feb 2013 21:40:22 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1271621F8B9B for ; Mon, 11 Feb 2013 21:40:22 -0800 (PST) Received: by us.padl.com with ESMTP id r1C5eFA5009736; Tue, 12 Feb 2013 00:40:18 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: <20130212053429.C84B11A54D@ld9781.wdf.sap.corp> Date: Tue, 12 Feb 2013 16:40:14 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <22B103A5-1AAB-49A4-9843-56210DCB487D@padl.com> References: <20130212053429.C84B11A54D@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1499) 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] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 05:40:22 -0000 On 12/02/2013, at 4:34 PM, mrex@sap.com (Martin Rex) wrote: > Wouldn't it be simple to use one single API call with an additional > "critical" input parameter rather than these two with weirdly > different API semantics (only the _critical variant with an option > to create a modified copy of the handle). >=20 >=20 > Btw. the use of expressions such as > "const gss_OID" > "const gss_buffer_t" >=20 > is a historic defect of the GSS-API v2 C-Bindings spec (indicating > that the author didn't know how "const" affects typedef'ed pointers > -- it results in const pointers to mutable data, rather than a > mutable pointers to const data. True, we have gss_const_OID and gss_const_buffer_t now. However gss_set_cred_option has already shipped in MIT/Heimdal for some = years now, with that prototype. > typedef const gss_OID_desc * const_gss_OID; > typedef const gss_buffer_desc * const_gss_buffer_t; Namespace infraction. :-) See RFC 5587. -- Luke= From mrex@sap.com Mon Feb 11 21:40:59 2013 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 170BF21F8BDD for ; Mon, 11 Feb 2013 21:40:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.24 X-Spam-Level: X-Spam-Status: No, score=-10.24 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ-TTlIfm+Xv for ; Mon, 11 Feb 2013 21:40:58 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDE321F8BD9 for ; Mon, 11 Feb 2013 21:40:58 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r1C5etFX028640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Feb 2013 06:40:55 +0100 (MET) In-Reply-To: To: Luke Howard Date: Tue, 12 Feb 2013 06:40:55 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130212054055.23B021A54D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 05:40:59 -0000 Luke Howard wrote: > > Careful, said MS, you're stepping on my toes. > > #define GSS_C_DCE_STYLE 0x1000 > #define GSS_C_IDENTIFY_FLAG 0x2000 > #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 Correct. The "standardized" flags fill up from the low values, whereas the vendor flags fill up form the high values. http://tools.ietf.org/html/rfc4121#section-4.1.1.1 The context flags currently defined in rfc2744 are: http://tools.ietf.org/html/rfc2744#page-85 #define GSS_C_DELEG_FLAG 1 #define GSS_C_MUTUAL_FLAG 2 #define GSS_C_REPLAY_FLAG 4 #define GSS_C_SEQUENCE_FLAG 8 #define GSS_C_CONF_FLAG 16 #define GSS_C_INTEG_FLAG 32 #define GSS_C_ANON_FLAG 64 #define GSS_C_PROT_READY_FLAG 128 #define GSS_C_TRANS_FLAG 256 so the next free flag position from the standards range appears to be 512/0x200. -Martin From mrex@sap.com Mon Feb 11 21:54:33 2013 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 7AA4621F8BEB for ; Mon, 11 Feb 2013 21:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.94 X-Spam-Level: X-Spam-Status: No, score=-9.94 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2nd7grooB-Y for ; Mon, 11 Feb 2013 21:54:31 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6AA21F8BEA for ; Mon, 11 Feb 2013 21:54:31 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r1C5sQ1J009831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 12 Feb 2013 06:54:27 +0100 (MET) In-Reply-To: <22B103A5-1AAB-49A4-9843-56210DCB487D@padl.com> To: Luke Howard Date: Tue, 12 Feb 2013 06:54:26 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130212055426.D939C1A54D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 05:54:33 -0000 Luke Howard wrote: > > mrex@sap.com (Martin Rex) wrote: > > > Wouldn't it be simple to use one single API call with an additional > > "critical" input parameter rather than these two with weirdly > > different API semantics (only the _critical variant with an option > > to create a modified copy of the handle). > > > > > > Btw. the use of expressions such as > > "const gss_OID" > > "const gss_buffer_t" > > > > is a historic defect of the GSS-API v2 C-Bindings spec (indicating > > that the author didn't know how "const" affects typedef'ed pointers > > -- it results in const pointers to mutable data, rather than a > > mutable pointers to const data. > > True, we have gss_const_OID and gss_const_buffer_t now. Of course, reusing the typedefs from 5587 is perfectly OK. > > However gss_set_cred_option has already shipped in MIT/Heimdal > for some years now, with that prototype. How about using a slightly different name for the new call that gets standardized? You're free to implement the single new call as a thin wrapper to your old/existing interfaces. -Martin From nico@cryptonector.com Mon Feb 11 21:55:03 2013 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 CE1A021F8C00 for ; Mon, 11 Feb 2013 21:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.931 X-Spam-Level: X-Spam-Status: No, score=-3.931 tagged_above=-999 required=5 tests=[AWL=-2.555, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1QSOQLfJxx9 for ; Mon, 11 Feb 2013 21:55:02 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC3521F8C01 for ; Mon, 11 Feb 2013 21:55:02 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 8201476806A for ; Mon, 11 Feb 2013 21:55:01 -0800 (PST) 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=DwU9wgEmDVJekaJ1/GIy 6yfdpEI=; b=r/lsh9ZinQ6njrN5BtN7kTazNsXibZgWQ9DOpEdzKuThVTDiDthE yoltGJifa9CHcMg7y7udmKwMOOdFHk6hVBRRb0ROyZU5E0FKcd02rVU9ZMnum3Y+ X3Sh1vQX5DD99nVy9/lgALltfKyaaTn3TurSeem7YywI4ouI2b1r2K4= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 31884768064 for ; Mon, 11 Feb 2013 21:55:01 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so3978207wib.9 for ; Mon, 11 Feb 2013 21:55:00 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.103.163 with SMTP id fx3mr16316393wjb.58.1360648499958; Mon, 11 Feb 2013 21:54:59 -0800 (PST) Received: by 10.217.39.133 with HTTP; Mon, 11 Feb 2013 21:54:59 -0800 (PST) In-Reply-To: <20130212053429.C84B11A54D@ld9781.wdf.sap.corp> References: <20130212053429.C84B11A54D@ld9781.wdf.sap.corp> Date: Mon, 11 Feb 2013 23:54:59 -0600 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=089e010d84ec81126104d580aa6d Cc: "kitten@ietf.org" Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 05:55:03 -0000 --089e010d84ec81126104d580aa6d Content-Type: text/plain; charset=UTF-8 On Monday, February 11, 2013, Martin Rex wrote: > Wouldn't it be simple to use one single API call with an additional > "critical" input parameter rather than these two with weirdly > different API semantics (only the _critical variant with an option > to create a modified copy of the handle). Maybe, but we've got a lot of things to throw into a replacement for GSS_Init/Accept_sec_context(). If we tackle that now I'm afraid we'll get really bogged down. Btw. the use of expressions such as > "const gss_OID" > "const gss_buffer_t" > > is a historic defect of the GSS-API v2 C-Bindings spec (indicating > that the author didn't know how "const" affects typedef'ed pointers > -- it results in const pointers to mutable data, rather than a > mutable pointers to const data. That's why we introduced new typedefs for const types in RFC5587. Nico -- --089e010d84ec81126104d580aa6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Monday, February 11, 2013, Martin Rex wrote:
Wouldn't it be simple to use one single API call with an additi= onal
"critical" input parameter rather than these two with weirdly
different API semantics (only the _critical variant with an option
to create a modified copy of the handle).

M= aybe, but we've got a lot of things to throw into a replacement for GSS= _Init/Accept_sec_context(). =C2=A0If we tackle that now I'm afraid we&#= 39;ll get really bogged down.

Btw. the use of expressions such as
=C2=A0 "const gss_OID"
=C2=A0 "const gss_buffer_t"

is a historic defect of the GSS-API v2 C-Bindings spec (indicating
that the author didn't know how "const" affects typedef'e= d pointers
-- it results in const pointers to mutable data, rather than a
mutable pointers to const data.

That's = why we introduced new typedefs for const types in RFC5587.

Nico
--=C2=A0
--089e010d84ec81126104d580aa6d-- From nico@cryptonector.com Mon Feb 11 21:57:30 2013 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 8956C21F8BF1 for ; Mon, 11 Feb 2013 21:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.164 X-Spam-Level: X-Spam-Status: No, score=-4.164 tagged_above=-999 required=5 tests=[AWL=-2.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dkuh12Zp+4N for ; Mon, 11 Feb 2013 21:57:29 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE5721F8BED for ; Mon, 11 Feb 2013 21:57:29 -0800 (PST) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id D00F854058 for ; Mon, 11 Feb 2013 21:57:20 -0800 (PST) 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=Sx+HI01EELTM+Bo048gb TwyxSWc=; b=BfqhHLFvdZomepPmXCr3CdFIgdezKOmUTYDjkP1/zrDR38roFBuu AQeqNwH5dkUT8BRq69j0r2L5SGOPQPZWfCMB8++B1aTlelLdKOdkEJbkY3M6IC4I A5CF8OAEFz5BJi7MF/ldnht2C71TlMVdrBECkw3BOiUAsnRQfPVtbJA= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (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 7AA7954057 for ; Mon, 11 Feb 2013 21:57:20 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so3981473wid.5 for ; Mon, 11 Feb 2013 21:57:19 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.103.163 with SMTP id fx3mr16323736wjb.58.1360648639251; Mon, 11 Feb 2013 21:57:19 -0800 (PST) Received: by 10.217.39.133 with HTTP; Mon, 11 Feb 2013 21:57:19 -0800 (PST) In-Reply-To: <20130212053429.C84B11A54D@ld9781.wdf.sap.corp> References: <20130212053429.C84B11A54D@ld9781.wdf.sap.corp> Date: Mon, 11 Feb 2013 23:57:19 -0600 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=089e010d84ecce835b04d580b2c2 Cc: "kitten@ietf.org" Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 05:57:30 -0000 --089e010d84ecce835b04d580b2c2 Content-Type: text/plain; charset=UTF-8 Oh! oops, i screwed up constness for the OID and buffer types. Sigh. I'll fix that. Thanks for catching that. --089e010d84ecce835b04d580b2c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Oh! =C2=A0oops, i screwed up constness for the OID and buffer types. =C2=A0= Sigh. =C2=A0I'll fix that. =C2=A0Thanks for catching that. --089e010d84ecce835b04d580b2c2-- From nico@cryptonector.com Mon Feb 11 21:58:26 2013 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 5842721F8B47 for ; Mon, 11 Feb 2013 21:58:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.108 X-Spam-Level: X-Spam-Status: No, score=-4.108 tagged_above=-999 required=5 tests=[AWL=-2.132, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xP1D-e5YNeip for ; Mon, 11 Feb 2013 21:58:26 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id BC97C21F8B38 for ; Mon, 11 Feb 2013 21:58:25 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 2836677801F for ; Mon, 11 Feb 2013 21:58:25 -0800 (PST) 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=nKovmW1q5REb6URioYi7 ikpypdM=; b=ajN4YrKmZ4l+vFqkiCa4uBolWJQFwv1HOJ7xsmibgmeqo14lx/fP vcrCyy2Mywi7oASIKi1gs0MYMJlwcmL0XOur/PxhUbSnqKEa8L4IkWE/8xwkv0FD 7zxUNaNWyUOfBEqFr8guqyqmf/hsGP4bw1mLwOz+bjKZ/ubqblFdNnE= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id AD749778057 for ; Mon, 11 Feb 2013 21:58:24 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so4131885wie.2 for ; Mon, 11 Feb 2013 21:58:23 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.216.5 with SMTP id om5mr28481444wjc.27.1360648703365; Mon, 11 Feb 2013 21:58:23 -0800 (PST) Received: by 10.217.39.133 with HTTP; Mon, 11 Feb 2013 21:58:23 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Feb 2013 23:58:23 -0600 Message-ID: From: Nico Williams To: Luke Howard Content-Type: multipart/alternative; boundary=089e01493ccea0d40704d580b6d2 Cc: "kitten@ietf.org" Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 05:58:26 -0000 --089e01493ccea0d40704d580b6d2 Content-Type: text/plain; charset=UTF-8 On Monday, February 11, 2013, Luke Howard wrote: > Careful, said MS, you're stepping on my toes. > > #define GSS_C_DCE_STYLE 0x1000 > #define GSS_C_IDENTIFY_FLAG 0x2000 > #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 > I checked MIT and Heimdal. Did I miss 0x1000? What flag number do you suggest? --089e01493ccea0d40704d580b6d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, February 11, 2013, Luke Howard wrote:
Careful, said MS, you're stepping on my toes.

#define GSS_C_DCE_STYLE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 0x1000
#define GSS_C_IDENTIFY_FLAG =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0x200= 0
#define GSS_C_EXTENDED_ERROR_FLAG =C2=A0 =C2=A0 =C2=A0 0x4000

I checked MIT and Heimdal. =C2=A0Did I mis= s 0x1000? =C2=A0What flag number do you suggest?=C2=A0
--089e01493ccea0d40704d580b6d2-- From nico@cryptonector.com Mon Feb 11 22:01:05 2013 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 5698821F8C16 for ; Mon, 11 Feb 2013 22:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-2.123, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3vv5h6kgtC9 for ; Mon, 11 Feb 2013 22:01:04 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 959E621F8B47 for ; Mon, 11 Feb 2013 22:01:04 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id BB37D598065 for ; Mon, 11 Feb 2013 22:01:03 -0800 (PST) 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=t1DgBFRUf8ZXELoaAAKb 4mSNO/E=; b=hSj+NmHeCmLE5ydbAokV8ngRdMvtDoShz57oZUoBrjz4p3BSy3Ph LhdP2CwszDULMe3+LCuaHaHao0SHSG3JN+24vhUrZmzPDdErtdXtm9ShdR+cmp1U UOkXQhXcr0AhC3xNPXy6AScefStim12VVbdzB58gc5YP5s4ilPGgUXg= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 62C33598060 for ; Mon, 11 Feb 2013 22:01:03 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id fg15so5230791wgb.13 for ; Mon, 11 Feb 2013 22:01:02 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr779470wiz.6.1360648862129; Mon, 11 Feb 2013 22:01:02 -0800 (PST) Received: by 10.217.39.133 with HTTP; Mon, 11 Feb 2013 22:01:01 -0800 (PST) In-Reply-To: <20130212054055.23B021A54D@ld9781.wdf.sap.corp> References: <20130212054055.23B021A54D@ld9781.wdf.sap.corp> Date: Tue, 12 Feb 2013 00:01:01 -0600 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=f46d0418270e175ecc04d580c002 Cc: "kitten@ietf.org" Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 06:01:05 -0000 --f46d0418270e175ecc04d580c002 Content-Type: text/plain; charset=UTF-8 On Monday, February 11, 2013, Martin Rex wrote: > Luke Howard wrote: > > > > Careful, said MS, you're stepping on my toes. > > > > #define GSS_C_DCE_STYLE 0x1000 > > #define GSS_C_IDENTIFY_FLAG 0x2000 > > #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 > > > Correct. The "standardized" flags fill up from the low values, > whereas the vendor flags fill up form the high values. > > http://tools.ietf.org/html/rfc4121#section-4.1.1.1 We really need a registry. We only have 32 bits to work with here :( --f46d0418270e175ecc04d580c002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Monday, February 11, 2013, Martin Rex wrote:
Luke Howard wrote:
>
> Careful, said MS, you're stepping on my toes.
>
> #define GSS_C_DCE_STYLE =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 0x1000
> #define GSS_C_IDENTIFY_FLAG =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = 0x2000
> #define GSS_C_EXTENDED_ERROR_FLAG =C2=A0 =C2=A0 =C2=A0 0x4000


Correct. =C2=A0The "standardized" flags fill up from the low valu= es,
whereas the vendor flags fill up form the high values.

=C2=A0 http://tools.ietf.org/html/rfc4121#section-4.1.1.1

We really need a registry. =C2=A0We only have 32 b= its to work with here :(
--f46d0418270e175ecc04d580c002-- From lukeh@padl.com Mon Feb 11 22:03:36 2013 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 E46DF21F8BEC for ; Mon, 11 Feb 2013 22:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbdacJMW+rLp for ; Mon, 11 Feb 2013 22:03:34 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id BBDB921F8B9C for ; Mon, 11 Feb 2013 22:03:34 -0800 (PST) Received: by us.padl.com with ESMTP id r1C63RXE010045; Tue, 12 Feb 2013 01:03:30 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_B27EC11A-0288-4E22-822F-C06AFCB2ABF4" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: Date: Tue, 12 Feb 2013 17:03:26 +1100 Message-Id: <8578629E-EE68-4917-BE8D-25815BE2C255@padl.com> References: To: Nico Williams X-Mailer: Apple Mail (2.1499) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,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] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 06:03:36 -0000 --Apple-Mail=_B27EC11A-0288-4E22-822F-C06AFCB2ABF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12/02/2013, at 4:58 PM, Nico Williams wrote: >=20 >=20 > On Monday, February 11, 2013, Luke Howard wrote: > Careful, said MS, you're stepping on my toes. >=20 > #define GSS_C_DCE_STYLE 0x1000 > #define GSS_C_IDENTIFY_FLAG 0x2000 > #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 >=20 > I checked MIT and Heimdal. Did I miss 0x1000? What flag number do = you suggest?=20 gssapi_ext.h in MIT I suppose either start from the very top or use the next standards = available one as Martin pointed out. -- Luke --Apple-Mail=_B27EC11A-0288-4E22-822F-C06AFCB2ABF4 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
On 12/02/2013, at 4:58 PM, Nico Williams <nico@cryptonector.com> wrote:



On Monday, February 11, 2013, Luke Howard wrote:
Careful, said MS, you're stepping on my toes.

#define GSS_C_DCE_STYLE                 0x1000
#define GSS_C_IDENTIFY_FLAG             0x2000
#define GSS_C_EXTENDED_ERROR_FLAG       0x4000

I checked MIT and Heimdal.  Did I miss 0x1000?  What flag number do you suggest? 

gssapi_ext.h in MIT

I suppose either start from the very top or use the next standards available one as Martin pointed out.

-- Luke
--Apple-Mail=_B27EC11A-0288-4E22-822F-C06AFCB2ABF4-- From hartmans@mit.edu Tue Feb 12 05:40:02 2013 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 26B1521F8D2C for ; Tue, 12 Feb 2013 05:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.043 X-Spam-Level: X-Spam-Status: No, score=-103.043 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeJxA3OHGwdi for ; Tue, 12 Feb 2013 05:40:01 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A1C0621F8D0B for ; Tue, 12 Feb 2013 05:40:00 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 0BADE20115; Tue, 12 Feb 2013 08:35:38 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0210043FD; Tue, 12 Feb 2013 08:39:57 -0500 (EST) From: Sam Hartman To: Nico Williams References: <20130211210142.9C75F1A54A@ld9781.wdf.sap.corp> Date: Tue, 12 Feb 2013 08:39:57 -0500 In-Reply-To: (Nico Williams's message of "Mon, 11 Feb 2013 15:22:19 -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] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 13:40:02 -0000 With my chair hat on, may I suggest that phrases like "not acceptable," or "hopelessly broken," don't really add anything to the discussion. I think the discussion would be enhanced by a bit more verbosity. Obviously the currently implemented behavior is something that we've found quite useful in the GS2 SASL mechanism and in other contexts. There are applications that use and depend on channel binding today. Nico would like to expand channel binding to HTTP. Microsoft has done this in their implementation although they needed to use different API level semantics than GSS implementations provide. It's reasonable for this WG to agree with Nico that's a valuable thing to do and thus to work on doing it. It's also reasonable for us to say that we don't support that use case. Which isn't the same as saying the status quo is unacceptable. People are getting work done today with channel binding. Nico is hoping to standardize a way that channel bindings have been more useful to one implementation. So, I think one of the first questions to the WG is do we want to support this additional use case. From nico@cryptonector.com Tue Feb 12 08:08:21 2013 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 78D2621F8F1B for ; Tue, 12 Feb 2013 08:08:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.029 X-Spam-Level: X-Spam-Status: No, score=-4.029 tagged_above=-999 required=5 tests=[AWL=-2.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LYKUCq8bsat for ; Tue, 12 Feb 2013 08:08:20 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACB321F8E1B for ; Tue, 12 Feb 2013 08:08:19 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 260D4508091 for ; Tue, 12 Feb 2013 08:08:19 -0800 (PST) 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=pxRqfrnA4WkO1kxT0I3I 2L22+9s=; b=wHBfhK3GJyop9IyAiVRJQw8mEO2X5hrbpUr46d3kF48dXOBs8jRv fa4O7g5Vz9hIWeTBas8eN7L5trcWSUpjkVFJPI+9cPn0/twJN8qZy1VCKhgAVkp2 chr1cfaHP47qBP4xLBAKtC9DpCAk8cLVhctJaqOYorS20icEpczc+ZU= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id BFCC950808E for ; Tue, 12 Feb 2013 08:08:18 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t44so200009wey.40 for ; Tue, 12 Feb 2013 08:08:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.103.163 with SMTP id fx3mr20090740wjb.58.1360685297018; Tue, 12 Feb 2013 08:08:17 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 12 Feb 2013 08:08:16 -0800 (PST) In-Reply-To: References: <20130211210142.9C75F1A54A@ld9781.wdf.sap.corp> Date: Tue, 12 Feb 2013 10:08:16 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 16:08:21 -0000 On Tue, Feb 12, 2013 at 7:39 AM, Sam Hartman wrote: Thanks Sam. My view is that RFC2743 is broken with regards to CB as written and in any case it doesn't reflect what has actually been implemented and deployed. Given this it'd be better to update RFC2743 than leave it as-is. Whether it's worth doing anything to improve negotiation of CB is separate question. To summarize, I'm asking the WG two questions: a) do we want to update RFC2743 to reflect reality and correct a serious flaw in it? b) do we want to add any features to make negotiation of CB more feasible? My answer is -unsurprisingly- "yes" to both questions. > Nico would like to expand channel binding to HTTP. Microsoft has done > this in their implementation although they needed to use different API > level semantics than GSS implementations provide. Thanks for noting this. Microsoft depended on it for deployment of "IWA w/ EP", which is shorthand (roughly) for "GSS w/ CB". > It's reasonable for this WG to agree with Nico that's a valuable thing > to do and thus to work on doing it. I'd certainly appreciate it. > It's also reasonable for us to say that we don't support that use > case. Which isn't the same as saying the status quo is > unacceptable. People are getting work done today with channel > binding. Nico is hoping to standardize a way that channel bindings have > been more useful to one implementation. Right. > So, I think one of the first questions to the WG is do we want to > support this additional use case. I do. Nico -- From nico@cryptonector.com Tue Feb 12 09:15:49 2013 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 4ED5321F8D6A for ; Tue, 12 Feb 2013 09:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.026 X-Spam-Level: X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[AWL=-2.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Of6RPUbYFd2f for ; Tue, 12 Feb 2013 09:15:48 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 79D5621F8CF5 for ; Tue, 12 Feb 2013 09:15:48 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 085202C806B for ; Tue, 12 Feb 2013 09:15:48 -0800 (PST) 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=e4EMWC8CMH6zTf7Igf7t kzqQ2qo=; b=GhKs+Aj5Jmx3I/RSd1m9g5Xv0gYT7+NUT9ZXWrna1Naq5aObMg4N ZFMW1aVhttzIm9FRMGvBZkwJ+Mbr4ug8Y+ukVaPGPpeI02wDSVEQPUueuzRJYBf3 feJYYt70H9mZ0J6P8nhRBSgqfQf/lhtRoW5/Bb9kj8mGLrw+hz2SQRk= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 2A0F52C8094 for ; Tue, 12 Feb 2013 09:15:41 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id r6so261265wey.19 for ; Tue, 12 Feb 2013 09:15:40 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.8.130 with SMTP id r2mr4791230wia.28.1360689340046; Tue, 12 Feb 2013 09:15:40 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 12 Feb 2013 09:15:39 -0800 (PST) In-Reply-To: References: <20130212053429.C84B11A54D@ld9781.wdf.sap.corp> Date: Tue, 12 Feb 2013 11:15:39 -0600 Message-ID: From: Nico Williams To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 17:15:49 -0000 On Mon, Feb 11, 2013 at 11:57 PM, Nico Williams wrote: > Oh! oops, i screwed up constness for the OID and buffer types. Sigh. I'll > fix that. Thanks for catching that. That came from cutting-and-pasting the prototype from MIT krb5. Fortunately the constness issue can be fixed without breaking compatibility. I'll be submitting a -01 shortly. If anyone has links to the relevant SSPI docs for the similar feature in SSPI please share so I can add an informative reference to them. Nico -- From nico@cryptonector.com Tue Feb 12 09:30:13 2013 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 D9F9721F9007 for ; Tue, 12 Feb 2013 09:30:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.964 X-Spam-Level: X-Spam-Status: No, score=-3.964 tagged_above=-999 required=5 tests=[AWL=-1.987, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkT3VutE4QTt for ; Tue, 12 Feb 2013 09:30:13 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 52E0321F8FE6 for ; Tue, 12 Feb 2013 09:30:13 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id B716B7780A9 for ; Tue, 12 Feb 2013 09:29:55 -0800 (PST) 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=gQ2xqAAaEqHnf+/pRmeK KhhCQzA=; b=QqF4hRm/mACew6AP/hsxK0nMXUioxe0YQdAiM/HfPGX/rSwLhKx8 bhjAchCW/xgEUNRadrMq7dTxvpLJWGDqHt6O2+WrEco2VIGpvd3CAKyx7VDvArH9 wYQPGgvWzoBsjfbIR/ZLGwwSPc43gqkcXbfJ3PKVACMQ9FotYVhTlm8= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 8BC2577809E for ; Tue, 12 Feb 2013 09:27:51 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id x43so277444wey.10 for ; Tue, 12 Feb 2013 09:27:49 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.99.227 with SMTP id et3mr4917771wib.6.1360690069045; Tue, 12 Feb 2013 09:27:49 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 12 Feb 2013 09:27:48 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Feb 2013 11:27:48 -0600 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 17:30:14 -0000 On Mon, Feb 11, 2013 at 11:29 PM, Luke Howard wrote: > Careful, said MS, you're stepping on my toes. > > #define GSS_C_DCE_STYLE 0x1000 Aha! I missed this because I'd searched for GSS.*FLAG. Can we make sure that all flags follow the GSS_C_.*_FLAG pattern, or that they have aliases that do? Nico -- From nico@cryptonector.com Tue Feb 12 09:48:08 2013 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 2AC5821F8F0A for ; Tue, 12 Feb 2013 09:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.055 X-Spam-Level: X-Spam-Status: No, score=-4.055 tagged_above=-999 required=5 tests=[AWL=-2.078, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nViPM6ZlZ-ed for ; Tue, 12 Feb 2013 09:48:07 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 48D2F21F8F05 for ; Tue, 12 Feb 2013 09:48:07 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 27008B805B for ; Tue, 12 Feb 2013 09:48:06 -0800 (PST) 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=/4v/WhvitTtjdRD0wjOsjBY 3/ow=; b=cVpEVQ/HGGEyn4d2GQtYdZ7b4QedQUAUVx96EdMm+dp2UASuWfEhe5K QamFgH2yuRLw0Iozo9fSE4BA0351TrO6NgMDjQVkfGYT/Qlwx+ij7LsnAKMwRN6L Zh0lDn8Av7XDty88jR3bYeDhBvUBcCH75NRc5PLSxdH+vePZMyKk= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id A4EC3B8058 for ; Tue, 12 Feb 2013 09:48:05 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm11so4908556wib.3 for ; Tue, 12 Feb 2013 09:48:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.60.5 with SMTP id d5mr15943072wjr.4.1360691283284; Tue, 12 Feb 2013 09:48:03 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 12 Feb 2013 09:48:03 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Feb 2013 11:48:03 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 17:48:08 -0000 I've posted a -01. I've added some text about alternative designs, SSPI, changed the flag assignment, and cleaned up some things. Also added a recommendation for mechanisms. Nico -- From nico@cryptonector.com Tue Feb 12 09:49:19 2013 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 4452A21F9011 for ; Tue, 12 Feb 2013 09:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.004 X-Spam-Level: X-Spam-Status: No, score=-4.004 tagged_above=-999 required=5 tests=[AWL=-2.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jgUeJLUAFwW9 for ; Tue, 12 Feb 2013 09:49:18 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id C8B5421F8FF2 for ; Tue, 12 Feb 2013 09:49:18 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 984306B007B for ; Tue, 12 Feb 2013 09:49:18 -0800 (PST) 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=qQyS/l6fBLgURAvmk4EQkV2 QoDk=; b=yjeVkO8l8S9ISf1n9V2HvMkyrVWkBWaKUw3tUtJilpYrgHFwhbMCoc2 NHZ3NS/fkPEg2aG+6UUfrKWBz8D7lALmR8sxB3Cs7fJJTWlThbI4ND02cDLXn2Wh 8mK8NUFA49JqdfuFT4gpAer2ODcrHbi696i/1pVO57Q5j0y+hcdw= Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) (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 4C57A6B007E for ; Tue, 12 Feb 2013 09:49:18 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id hm6so444160wib.2 for ; Tue, 12 Feb 2013 09:49:17 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.97.166 with SMTP id eb6mr4931309wib.20.1360691357074; Tue, 12 Feb 2013 09:49:17 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 12 Feb 2013 09:49:16 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Feb 2013 11:49:16 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 17:49:19 -0000 http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-williams-kitten-channel-bound-flag-01.txt From jhutz@cmu.edu Tue Feb 12 10:58:10 2013 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 F22CA21F8FEA for ; Tue, 12 Feb 2013 10:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.377 X-Spam-Level: X-Spam-Status: No, score=-106.377 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZajpR4TcZLp for ; Tue, 12 Feb 2013 10:58:08 -0800 (PST) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 0D98121F8FE8 for ; Tue, 12 Feb 2013 10:58:07 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r1CIvtFa021627 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 13:57:55 -0500 (EST) Message-ID: <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: mrex@sap.com Date: Tue, 12 Feb 2013 13:57:55 -0500 In-Reply-To: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 18:58:11 -0000 On Tue, 2013-02-12 at 06:40 +0100, Martin Rex wrote: > Luke Howard wrote: > > > > Careful, said MS, you're stepping on my toes. > > > > #define GSS_C_DCE_STYLE 0x1000 > > #define GSS_C_IDENTIFY_FLAG 0x2000 > > #define GSS_C_EXTENDED_ERROR_FLAG 0x4000 > > > Correct. The "standardized" flags fill up from the low values, > whereas the vendor flags fill up form the high values. > > http://tools.ietf.org/html/rfc4121#section-4.1.1.1 Not quite. RFC4121 reserves the 8 bits 0xff000 for "legacy" vendor flags. I don't recall exactly what we were thinking at the time, but since there's no negotiation mechanism, the addition by vendors of _new_ flags in this range will almost certainly lead to bad results. This is a 32-bit space, so we should be careful about allocating new bits from among those that are currently reserved, and there really isn't room for vendor-specific bits (other than the legacy ones) at all. Nico suggests we need a registry, but I'm not convinced that's the case. As written, RFC4121 does not contemplate that new flags will be allocated by extensions; rather, they can be used only in new revisions of the base spec. It is also worth noting that while the existing mechanism represents these flags on the wire using the same bits that are used in the C API, there is no reason this must be the case. We absolutely can create flags in the API which do not correspond directly to bits on the wire, and vice versa. -- Jeff From hartmans@mit.edu Tue Feb 12 12:15:45 2013 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 BCB6A21F8A8E for ; Tue, 12 Feb 2013 12:15:45 -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 qHzqdcZunh7z for ; Tue, 12 Feb 2013 12:15:45 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 286AA21F8A84 for ; Tue, 12 Feb 2013 12:15:40 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 0662620115; Tue, 12 Feb 2013 15:11:18 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C40F543FD; Tue, 12 Feb 2013 15:15:39 -0500 (EST) From: Sam Hartman To: Jeffrey Hutzelman References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> Date: Tue, 12 Feb 2013 15:15:39 -0500 In-Reply-To: <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> (Jeffrey Hutzelman's message of "Tue, 12 Feb 2013 13:57:55 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 20:15:45 -0000 Nico needs a C API flag, not a wire flag, right? From nico@cryptonector.com Tue Feb 12 12:29:38 2013 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 5A21E21F8AC2 for ; Tue, 12 Feb 2013 12:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.905 X-Spam-Level: X-Spam-Status: No, score=-3.905 tagged_above=-999 required=5 tests=[AWL=-1.928, 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 MLDgPrBQTPY0 for ; Tue, 12 Feb 2013 12:29:37 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id BD34021F8A9B for ; Tue, 12 Feb 2013 12:29:37 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 819A935005B for ; Tue, 12 Feb 2013 12:29:37 -0800 (PST) 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=vImzzCWpiad5T21MOl3k HL0+sTQ=; b=gu3TP3U3SrJaQv3qnKqrq1dHugYtcDC2GFDsbaqeed8rxxlregaj zVE+GW5pU5JASrFcqxd6ZzjJqxTILlTCPCGwWmkf4lcsDvemHZnlSiE/h85xCBtO mT7fKkAv18Sj6x+P0ebZ6n+kCtYqV9ai3p5sIMAnc2VudD/qhqzc4S0= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 3381C350072 for ; Tue, 12 Feb 2013 12:29:37 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id 16so401365wgi.27 for ; Tue, 12 Feb 2013 12:29:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.101.98 with SMTP id ff2mr6094449wib.0.1360700975699; Tue, 12 Feb 2013 12:29:35 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 12 Feb 2013 12:29:35 -0800 (PST) In-Reply-To: <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> Date: Tue, 12 Feb 2013 14:29:35 -0600 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 20:29:38 -0000 On Tue, Feb 12, 2013 at 12:57 PM, Jeffrey Hutzelman wrote: Allow me to respond to this out of order. > It is also worth noting that while the existing mechanism represents > these flags on the wire using the same bits that are used in the C API, > there is no reason this must be the case. We absolutely can create > flags in the API which do not correspond directly to bits on the wire, > and vice versa. This is true. I don't think we have a rule about what the mechanism should do with flags it doesn't know about (the mechglue and app might, but in a plugin-style mechglue the mech might not). I don't need such a rule in this case because if the initiator app were to set this flag as a req_flag, and were the mechglue to pass it dumbly to the mech, and were the mech to pass it on the wire, no harm would result. > Not quite. RFC4121 reserves the 8 bits 0xff000 for "legacy" vendor > flags. I don't recall exactly what we were thinking at the time, but > since there's no negotiation mechanism, the addition by vendors of _new_ > flags in this range will almost certainly lead to bad results. Is there any evidence of "legacy" vendor flags, or that mechglues or mechanisms do anything to filter out flags in this range? If not then I think we can re-purpose them. > This is a 32-bit space, so we should be careful about allocating new > bits from among those that are currently reserved, and there really > isn't room for vendor-specific bits (other than the legacy ones) at all. > Nico suggests we need a registry, but I'm not convinced that's the case. > As written, RFC4121 does not contemplate that new flags will be > allocated by extensions; rather, they can be used only in new revisions > of the base spec. I want a registry to I can find the ones that are registered by means other than looking at multiple implementations' header files / docs. We may well want Standards Action to allocate them given their scarcity, but the point for me is having a place where I can find them all so I can allocate an as-yet unused one. BTW, I could add an extended security context inquiry function instead of using ret_flags. For the Java API there'd be no real difference. For the C API a flag is clearly easier to check. Nico -- From nico@cryptonector.com Tue Feb 12 12:45:42 2013 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 199C621F8698 for ; Tue, 12 Feb 2013 12:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.85 X-Spam-Level: X-Spam-Status: No, score=-3.85 tagged_above=-999 required=5 tests=[AWL=-1.873, 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 JTFQZMtXo5iK for ; Tue, 12 Feb 2013 12:45:41 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 984C421F8697 for ; Tue, 12 Feb 2013 12:45:41 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 453302C806C for ; Tue, 12 Feb 2013 12:45:41 -0800 (PST) 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=kfkMbGtzVxAKtJjMFuKo p5K4aLw=; b=p+GfsJHYC+czctAj/JTR/tCLIh0X2ovx6wIt4jEvr7JBGQOGrHeD 8MRNY7kh3l58qQpeMdBfGOjq4xBXD8QQ5HcI836mVGdZQ4tN1Fmf8KpETwBgHm7q PNpwRXZy/Ji0Z2mB9IOYBLCBDCj2LYZ3Qjnbnc548eWrvhlNFEQBzyI= Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id C16D42C806B for ; Tue, 12 Feb 2013 12:45:40 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id 15so403075wgd.28 for ; Tue, 12 Feb 2013 12:45:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.8.130 with SMTP id r2mr5833264wia.28.1360701939447; Tue, 12 Feb 2013 12:45:39 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 12 Feb 2013 12:45:39 -0800 (PST) In-Reply-To: References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> Date: Tue, 12 Feb 2013 14:45:39 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 20:45:42 -0000 On Tue, Feb 12, 2013 at 2:15 PM, Sam Hartman wrote: > Nico needs a C API flag, not a wire flag, right? In this case that distinction is irrelevant because setting this flag in req_flags and having it automatically copied (locally and on the wire) into ret_flags does no harm. BTW, maybe we should have a range of flags that must be transported by the mech regardless of the flags' semantics? I think that'd be overkill, but maybe I'm being unimaginative. Nico -- From hartmans@mit.edu Tue Feb 12 12:55:23 2013 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 32EB221F8B3A for ; Tue, 12 Feb 2013 12:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 KRv16JJ4VT5z for ; Tue, 12 Feb 2013 12:55:22 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A624821F8B37 for ; Tue, 12 Feb 2013 12:55:22 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id C1B4920115; Tue, 12 Feb 2013 15:50:59 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9802A43FD; Tue, 12 Feb 2013 15:55:21 -0500 (EST) From: Sam Hartman To: Nico Williams References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> Date: Tue, 12 Feb 2013 15:55:21 -0500 In-Reply-To: (Nico Williams's message of "Tue, 12 Feb 2013 14:45:39 -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, Jeffrey Hutzelman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 20:55:23 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Tue, Feb 12, 2013 at 2:15 PM, Sam Hartman wrote: >> Nico needs a C API flag, not a wire flag, right? Nico> In this case that distinction is irrelevant because setting Nico> this flag in req_flags and having it automatically copied Nico> (locally and on the wire) into ret_flags does no harm. Help me out here. I'm not seeing any reason to transport this flag over the wire nor have it as an input in req_flags. From nico@cryptonector.com Tue Feb 12 13:01:49 2013 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 9BBBF21F8BE2 for ; Tue, 12 Feb 2013 13:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.956 X-Spam-Level: X-Spam-Status: No, score=-3.956 tagged_above=-999 required=5 tests=[AWL=-1.979, 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 AT7QYFNjTHse for ; Tue, 12 Feb 2013 13:01:49 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD8921F8BDD for ; Tue, 12 Feb 2013 13:01:49 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id C9E0D76806A for ; Tue, 12 Feb 2013 13:01:48 -0800 (PST) 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=DL2+z+gQjOG6zH0i26fx +kqzpbk=; b=MKy/HrJm0zTRN8hQy4gHnN6GV1gnDAmu47gxq+k+R7udEl59zcEI hlk55HdJsBIbOqp4dO2gp+Hy42yVzAZOl+5U0pLnOuADAFkvtmEhWM72vp+2aUwF /lZ3N/O0JycUOsjwM5kGqBr+HwGfAIRXPjN1/U/29l0ZTsTj03Hm8lA= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 6844F768064 for ; Tue, 12 Feb 2013 13:01:48 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so646254wic.11 for ; Tue, 12 Feb 2013 13:01:47 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr5941760wiz.6.1360702907176; Tue, 12 Feb 2013 13:01:47 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 12 Feb 2013 13:01:46 -0800 (PST) In-Reply-To: References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> Date: Tue, 12 Feb 2013 15:01:46 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 21:01:49 -0000 On Tue, Feb 12, 2013 at 2:55 PM, Sam Hartman wrote: >>>>>> "Nico" == Nico Williams writes: > > Nico> On Tue, Feb 12, 2013 at 2:15 PM, Sam Hartman wrote: > >> Nico needs a C API flag, not a wire flag, right? > > Nico> In this case that distinction is irrelevant because setting > Nico> this flag in req_flags and having it automatically copied > Nico> (locally and on the wire) into ret_flags does no harm. > > Help me out here. > I'm not seeing any reason to transport this flag over the wire nor have > it as an input in req_flags. You misread :) I have no use for this flag to be sent over the wire or used as a req_flag. I only said that there's no need to forbid it as it does no harm -- it's only silly to use it as a req_flag. From jhutz@cmu.edu Tue Feb 12 13:08:51 2013 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 A9C4121F8C38 for ; Tue, 12 Feb 2013 13:08:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.414 X-Spam-Level: X-Spam-Status: No, score=-106.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 jfF5O6aSKdAw for ; Tue, 12 Feb 2013 13:08:51 -0800 (PST) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by ietfa.amsl.com (Postfix) with ESMTP id F04B521F8C16 for ; Tue, 12 Feb 2013 13:08:50 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r1CL8lXZ009327 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 16:08:47 -0500 (EST) Message-ID: <1360703327.17745.111.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Nico Williams Date: Tue, 12 Feb 2013 16:08:47 -0500 In-Reply-To: <7800_1360700981_r1CKTegh027242_CAK3OfOjACDXJ42mziDG+YU7F+j_n2gtUQqU+42Z2a5ZNdwapBA@mail.gmail.com> References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> <7800_1360700981_r1CKTegh027242_CAK3OfOjACDXJ42mziDG+YU7F+j_n2gtUQqU+42Z2a5ZNdwapBA@mail.gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 21:08:51 -0000 On Tue, 2013-02-12 at 14:29 -0600, Nico Williams wrote: > On Tue, Feb 12, 2013 at 12:57 PM, Jeffrey Hutzelman wrote: > > Allow me to respond to this out of order. > > > It is also worth noting that while the existing mechanism represents > > these flags on the wire using the same bits that are used in the C API, > > there is no reason this must be the case. We absolutely can create > > flags in the API which do not correspond directly to bits on the wire, > > and vice versa. > > This is true. I don't think we have a rule about what the mechanism > should do with flags it doesn't know about (the mechglue and app > might, but in a plugin-style mechglue the mech might not). The bits in the API and the bits on the wire are not the same thing, in the same way that KDC options and ticket flags are not the same thing. Yes, there are several cases where flags appear in both sets with similar names and related meanings and possibly even the same value, but that does not mean they are the same. The bits on the wire are an artifact of the particular mechanism spec. In the case of RFC4121, implementations certainly should not set undefined flags on the wire; the spec is quite clear on this. > > Not quite. RFC4121 reserves the 8 bits 0xff000 for "legacy" vendor > > flags. I don't recall exactly what we were thinking at the time, but > > since there's no negotiation mechanism, the addition by vendors of _new_ > > flags in this range will almost certainly lead to bad results. > > Is there any evidence of "legacy" vendor flags I assume we set them aside because we knew something was already using them. I don't really remember, but I bet there are archives of the mailing list. > I want a registry to I can find the ones that are registered by means > other than looking at multiple implementations' header files / docs. Ah, but there is no "registering", because there is no registry. The bits that are defined in the Kerberos GSS-API mechanism's flags on the wire are those that are listed in the latest version of the Kerberos GSS-API mechanism spec. The only way to add new ones is to rev the spec. > We may well want Standards Action to allocate them given their > scarcity, but the point for me is having a place where I can find them > all so I can allocate an as-yet unused one. The only way to allocate an as-yet-unused one is to publish a new version of the spec. We could decide to change that, of course. Note that this is all separate from adding flags to the abstract API, in which they have only names, or to the C bindings, whose number space is distinct -- Jeff From nico@cryptonector.com Tue Feb 12 13:28:44 2013 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 00A9B21F8A99 for ; Tue, 12 Feb 2013 13:28:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[AWL=-1.933, 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 LXkWfeJKGQir for ; Tue, 12 Feb 2013 13:28:43 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 56DE021F8A79 for ; Tue, 12 Feb 2013 13:28:43 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 25259BC049 for ; Tue, 12 Feb 2013 13:28:43 -0800 (PST) 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=IozrQ1gUgAHxKNmwsEO3 RXVYYjE=; b=uPkkidmwsCSZtYEKZQbugqEuF5YpUOcB+UYO/4/oiI8W4EljGm41 PIpRGVImoI7dtNfUQrO92xvGXtSdFhaEZKiU4i35/Trq2DVJIcRp0xHIHWrezRit oK9vjcYaBG5HApv5pD4UXMpLrodhVrw3njez2Dbu7XyRVUAQt6NJhqc= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 C2424BC041 for ; Tue, 12 Feb 2013 13:28:42 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id o1so667035wic.17 for ; Tue, 12 Feb 2013 13:28:41 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.103.163 with SMTP id fx3mr21816382wjb.58.1360704521488; Tue, 12 Feb 2013 13:28:41 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 12 Feb 2013 13:28:41 -0800 (PST) In-Reply-To: <1360703327.17745.111.camel@minbar.fac.cs.cmu.edu> References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> <7800_1360700981_r1CKTegh027242_CAK3OfOjACDXJ42mziDG+YU7F+j_n2gtUQqU+42Z2a5ZNdwapBA@mail.gmail.com> <1360703327.17745.111.camel@minbar.fac.cs.cmu.edu> Date: Tue, 12 Feb 2013 15:28:41 -0600 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 21:28:44 -0000 On Tue, Feb 12, 2013 at 3:08 PM, Jeffrey Hutzelman wrote: > On Tue, 2013-02-12 at 14:29 -0600, Nico Williams wrote: >> > It is also worth noting that while the existing mechanism represents >> > these flags on the wire using the same bits that are used in the C API, >> > there is no reason this must be the case. We absolutely can create >> > flags in the API which do not correspond directly to bits on the wire, >> > and vice versa. >> >> This is true. I don't think we have a rule about what the mechanism >> should do with flags it doesn't know about (the mechglue and app >> might, but in a plugin-style mechglue the mech might not). > > The bits in the API and the bits on the wire are not the same thing, in > the same way that KDC options and ticket flags are not the same thing. > Yes, [...] I am aware. But the mech still gets flags, and it's entirely possible that a mechglue and mech are out of sync and the mechglue passes in a flag that the mech doesn't know, and it's entirely possible that a mech implementation ends up doing something very naive with flags it doesn't know. I'm saying that I don't know of any hard and fast rule about that and that we could use one. >> > Not quite. RFC4121 reserves the 8 bits 0xff000 for "legacy" vendor >> > flags. I don't recall exactly what we were thinking at the time, but >> > since there's no negotiation mechanism, the addition by vendors of _new_ >> > flags in this range will almost certainly lead to bad results. >> >> Is there any evidence of "legacy" vendor flags > > I assume we set them aside because we knew something was already using > them. I don't really remember, but I bet there are archives of the > mailing list. I'm willing to say we can use them. I'm also willing to say that we can't. The main question is: are any such implementations around any longer? Martin might know. >> I want a registry to I can find the ones that are registered by means >> other than looking at multiple implementations' header files / docs. > > Ah, but there is no "registering", because there is no registry. The > [...] Isn't that what I said, or at least didn't I strongly imply that I'm aware that there's no registry? :) >> We may well want Standards Action to allocate them given their >> scarcity, but the point for me is having a place where I can find them >> all so I can allocate an as-yet unused one. > > The only way to allocate an as-yet-unused one is to publish a new > version of the spec. We could decide to change that, of course. No implementors have ever allocated flags without Standard Actions? I don't think so. Just the very first flag I checked just now (GSS_C_EXTENDED_ERROR_FLAG) is not allocated in any RFC. BTW, add flag numbering to the list of things we'd need to tighten up if we ever want to have standard ABIs for the C bindings. (And no, this is not a cue to have a debate in this thread about whether standard ABIs are desirable. Start a new thread if you must have that discussion :) > Note that this is all separate from adding flags to the abstract API, in > which they have only names, or to the C bindings, whose number space is > distinct Correct. Nico -- From jhutz@cmu.edu Tue Feb 12 13:40:57 2013 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 982F921F8C9F for ; Tue, 12 Feb 2013 13:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.441 X-Spam-Level: X-Spam-Status: No, score=-106.441 tagged_above=-999 required=5 tests=[AWL=0.159, 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 Xc5rApYqyO47 for ; Tue, 12 Feb 2013 13:40:57 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 141F521F8C9E for ; Tue, 12 Feb 2013 13:40:57 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r1CLesUZ010709 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 16:40:54 -0500 (EST) Message-ID: <1360705254.17745.121.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Nico Williams Date: Tue, 12 Feb 2013 16:40:54 -0500 In-Reply-To: References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> <7800_1360700981_r1CKTegh027242_CAK3OfOjACDXJ42mziDG+YU7F+j_n2gtUQqU+42Z2a5ZNdwapBA@mail.gmail.com> <1360703327.17745.111.camel@minbar.fac.cs.cmu.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 21:40:57 -0000 On Tue, 2013-02-12 at 15:28 -0600, Nico Williams wrote: > I am aware. But the mech still gets flags, and it's entirely possible > that a mechglue and mech are out of sync and the mechglue passes in a > flag that the mech doesn't know, and it's entirely possible that a > mech implementation ends up doing something very naive with flags it > doesn't know. I'm saying that I don't know of any hard and fast rule > about that and that we could use one. We _have_ one, from RFC4121 4.1.1.1: All other flag values not specified herein are reserved for future use. Future revisions of this mechanism may use these reserved flags and may rely on implementations of this version to not use such flags in order to properly negotiate mechanism versions. Undefined flag values MUST be cleared by the sender, and unknown flags MUST be ignored by the receiver. While the values for the six existing flags are copied from RFC2744 and the text even makes mention of that, it is quite clear from the above that unspecified flags... - Are reserved for future revisions _of this mechanism_ - MUST be zero - MUST be ignored > No implementors have ever allocated flags without Standard Actions? I > don't think so. Just the very first flag I checked just now > (GSS_C_EXTENDED_ERROR_FLAG) is not allocated in any RFC. It's one of the legacy-vendor bits. Using it was probably wrong, but the vendor can at least reasonably expect that the standard is never going to reuse that bit. > BTW, add flag numbering to the list of things we'd need to tighten up > if we ever want to have standard ABIs for the C bindings. Hm? The C bindings specify values for these flags. -- Jeff From nico@cryptonector.com Tue Feb 12 13:47:58 2013 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 1B33121F8B98 for ; Tue, 12 Feb 2013 13:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.866 X-Spam-Level: X-Spam-Status: No, score=-3.866 tagged_above=-999 required=5 tests=[AWL=-1.889, 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 2LJZVhPSx-2Q for ; Tue, 12 Feb 2013 13:47:57 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 8857C21F8B88 for ; Tue, 12 Feb 2013 13:47:57 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 249861F0085 for ; Tue, 12 Feb 2013 13:47:56 -0800 (PST) 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=ibI5Jhbozrk8NvLtwjG8 +oNMfKo=; b=Z78b2Z0y70VYkYi3AvDwzb6nKyh/c8DjrR0xYwXCneyoFAqjUxhZ OVSKojU7xE+BIzNf2r7IwK93LYzLZORsZVjitJiA7sfa1EBAKvHByb+5cAm804Wc Qy7ugfUJ2SJtPgbKF1f7lCy/sarm2ihUUbxQzPbqBjM1tnV5TNmBreM= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id BF3301F0081 for ; Tue, 12 Feb 2013 13:47:55 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hi18so688721wib.9 for ; Tue, 12 Feb 2013 13:47:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.99.227 with SMTP id et3mr6131093wib.6.1360705674510; Tue, 12 Feb 2013 13:47:54 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 12 Feb 2013 13:47:54 -0800 (PST) In-Reply-To: <1360705254.17745.121.camel@minbar.fac.cs.cmu.edu> References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> <7800_1360700981_r1CKTegh027242_CAK3OfOjACDXJ42mziDG+YU7F+j_n2gtUQqU+42Z2a5ZNdwapBA@mail.gmail.com> <1360703327.17745.111.camel@minbar.fac.cs.cmu.edu> <1360705254.17745.121.camel@minbar.fac.cs.cmu.edu> Date: Tue, 12 Feb 2013 15:47:54 -0600 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 21:47:58 -0000 On Tue, Feb 12, 2013 at 3:40 PM, Jeffrey Hutzelman wrote: > On Tue, 2013-02-12 at 15:28 -0600, Nico Williams wrote: >> I am aware. But the mech still gets flags, and it's entirely possible >> that a mechglue and mech are out of sync and the mechglue passes in a >> flag that the mech doesn't know, and it's entirely possible that a >> mech implementation ends up doing something very naive with flags it >> doesn't know. I'm saying that I don't know of any hard and fast rule >> about that and that we could use one. > > We _have_ one, from RFC4121 4.1.1.1: I meant a generic rule. One that should be in RFC2743 or an RFC that updates it. It's true that RFC2743 does not imply that mechanisms must transport flags. But some do and those should get some guidance. Additionally we may need to have some rules for req/ret_flags extensibility (though I don't think we need to have such rules in order for this flag to be added). (Part of the issue, of course, is that RFC2743 does not contemplate pluggable mechglues in much detail, and we might not ever reach consensus on whether to say much about mechglues in Standards-Track RFCs.) >> BTW, add flag numbering to the list of things we'd need to tighten up >> if we ever want to have standard ABIs for the C bindings. > > Hm? The C bindings specify values for these flags. Yes, but if we have flags that have been added without Standards-Actions... we need to make sure that implementors get the same flag numbers. Nico -- From lukeh@padl.com Tue Feb 12 14:01:47 2013 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 570DC21F8A6B for ; Tue, 12 Feb 2013 14:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Y4UMtJV9MvSZ for ; Tue, 12 Feb 2013 14:01:47 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id C8D9021F8A61 for ; Tue, 12 Feb 2013 14:01:46 -0800 (PST) Received: by us.padl.com with ESMTP id r1CM1exp007960; Tue, 12 Feb 2013 17:01:43 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: Date: Wed, 13 Feb 2013 09:01:40 +1100 Content-Transfer-Encoding: 7bit Message-Id: <543E1640-1635-4833-B52E-BD54818E79F1@padl.com> References: To: Nico Williams X-Mailer: Apple Mail (2.1499) 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] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 22:01:47 -0000 On 13/02/2013, at 4:27 AM, Nico Williams wrote: > On Mon, Feb 11, 2013 at 11:29 PM, Luke Howard wrote: >> Careful, said MS, you're stepping on my toes. >> >> #define GSS_C_DCE_STYLE 0x1000 > > Aha! I missed this because I'd searched for GSS.*FLAG. Can we make > sure that all flags follow the GSS_C_.*_FLAG pattern, or that they > have aliases that do? We can, but I thought it better to follow RFC4757 to the word. -- Luke From lukeh@padl.com Tue Feb 12 14:03:43 2013 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 0502421F8B26 for ; Tue, 12 Feb 2013 14:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 BzDRzVL3RHU2 for ; Tue, 12 Feb 2013 14:03:42 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7662421F8A67 for ; Tue, 12 Feb 2013 14:03:42 -0800 (PST) Received: by us.padl.com with ESMTP id r1CM3Zhk007972; Tue, 12 Feb 2013 17:03:38 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: Date: Wed, 13 Feb 2013 09:03:35 +1100 Content-Transfer-Encoding: 7bit Message-Id: <896AB589-4826-4323-BE80-0C1D5406DC3D@padl.com> References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> <7800_1360700981_r1CKTegh027242_CAK3OfOjACDXJ42mziDG+YU7F+j_n2gtUQqU+42Z2a5ZNdwapBA@mail.gmail.com> <1360703327.17745.111.camel@minbar.fac.cs.cmu.edu> To: Nico Williams X-Mailer: Apple Mail (2.1499) 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, Jeffrey Hutzelman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 22:03:43 -0000 On 13/02/2013, at 8:28 AM, Nico Williams wrote: > No implementors have ever allocated flags without Standard Actions? I > don't think so. Just the very first flag I checked just now > (GSS_C_EXTENDED_ERROR_FLAG) is not allocated in any RFC. RFC 4757 7.1 -- Luke Howard / lukeh@padl.com www.padl.com / www.lukehoward.com From jhutz@cmu.edu Tue Feb 12 14:12:06 2013 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 2567521F8BB5 for ; Tue, 12 Feb 2013 14:12:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.46 X-Spam-Level: X-Spam-Status: No, score=-106.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 2lAa7biBP8YT for ; Tue, 12 Feb 2013 14:12:05 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB8421F8BA2 for ; Tue, 12 Feb 2013 14:12:05 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r1CMC3fV011517 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 Feb 2013 17:12:03 -0500 (EST) Message-ID: <1360707123.17745.138.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Luke Howard Date: Tue, 12 Feb 2013 17:12:03 -0500 In-Reply-To: <24226_1360706625_r1CM3iao025358_896AB589-4826-4323-BE80-0C1D5406DC3D@padl.com> References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> <7800_1360700981_r1CKTegh027242_CAK3OfOjACDXJ42mziDG+YU7F+j_n2gtUQqU+42Z2a5ZNdwapBA@mail.gmail.com> <1360703327.17745.111.camel@minbar.fac.cs.cmu.edu> <24226_1360706625_r1CM3iao025358_896AB589-4826-4323-BE80-0C1D5406DC3D@padl.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 22:12:06 -0000 On Wed, 2013-02-13 at 09:03 +1100, Luke Howard wrote: > On 13/02/2013, at 8:28 AM, Nico Williams wrote: > > > No implementors have ever allocated flags without Standard Actions? I > > don't think so. Just the very first flag I checked just now > > (GSS_C_EXTENDED_ERROR_FLAG) is not allocated in any RFC. > > RFC 4757 7.1 Ah, right. In fact, this is probably the "legacy" use that RFC4121 was considering, given that it was widely deployed before 4121 was published but not documented until well after. From nico@cryptonector.com Tue Feb 12 14:16:46 2013 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 BC09121F8BAF for ; Tue, 12 Feb 2013 14:16:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.798 X-Spam-Level: X-Spam-Status: No, score=-3.798 tagged_above=-999 required=5 tests=[AWL=-1.821, 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 J2E2al36tv8Q for ; Tue, 12 Feb 2013 14:16:46 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6C521F8A93 for ; Tue, 12 Feb 2013 14:16:46 -0800 (PST) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 01DEA36008C for ; Tue, 12 Feb 2013 14:16:46 -0800 (PST) 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=Ky998Rd9FhSMwrkEPVzb 8J1YoE4=; b=k/10XOfPrvAPH99JsW5v76voMCOzrxG5RCLvTUAJwO458QmBbtLU B7NAVCCvCh8oh7rIH4YIAkgvLYs+3Qtq2hUmBWEDGGN+CF2gompVybbfn3uhM29f OmtIPqbZqu+tg7xN6e4pxYrwMR9TJR5KGFmHYYddWMOlHaQLVFapCOw= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 9BEF8360079 for ; Tue, 12 Feb 2013 14:16:45 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so3717488wgb.4 for ; Tue, 12 Feb 2013 14:16:43 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.99.227 with SMTP id et3mr6232618wib.6.1360707403916; Tue, 12 Feb 2013 14:16:43 -0800 (PST) Received: by 10.217.39.133 with HTTP; Tue, 12 Feb 2013 14:16:43 -0800 (PST) In-Reply-To: <1360707123.17745.138.camel@minbar.fac.cs.cmu.edu> References: <3714_1360647661_r1C5ext9003764_20130212054055.23B021A54D@ld9781.wdf.sap.corp> <1360695475.17745.95.camel@minbar.fac.cs.cmu.edu> <7800_1360700981_r1CKTegh027242_CAK3OfOjACDXJ42mziDG+YU7F+j_n2gtUQqU+42Z2a5ZNdwapBA@mail.gmail.com> <1360703327.17745.111.camel@minbar.fac.cs.cmu.edu> <24226_1360706625_r1CM3iao025358_896AB589-4826-4323-BE80-0C1D5406DC3D@padl.com> <1360707123.17745.138.camel@minbar.fac.cs.cmu.edu> Date: Tue, 12 Feb 2013 16:16:43 -0600 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 12 Feb 2013 22:16:46 -0000 On Tue, Feb 12, 2013 at 4:12 PM, Jeffrey Hutzelman wrote: > On Wed, 2013-02-13 at 09:03 +1100, Luke Howard wrote: >> On 13/02/2013, at 8:28 AM, Nico Williams wrote: >> >> > No implementors have ever allocated flags without Standard Actions? I >> > don't think so. Just the very first flag I checked just now >> > (GSS_C_EXTENDED_ERROR_FLAG) is not allocated in any RFC. >> >> RFC 4757 7.1 > > Ah, right. In fact, this is probably the "legacy" use that RFC4121 was > considering, given that it was widely deployed before 4121 was published > but not documented until well after. Yup, that must be it. I'll put out a -02 with a flag past the range reserved in RFC4121 (and with Security and IANA Considerations sections). Nico -- From Thomas.Maslen@quest.com Tue Feb 12 21:23:17 2013 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 C266F21F892E for ; Tue, 12 Feb 2013 21:23:17 -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 PvlRBw4quifs for ; Tue, 12 Feb 2013 21:23:16 -0800 (PST) Received: from alvetxw02.quest.com (alvetxw02.quest.com [12.106.87.94]) by ietfa.amsl.com (Postfix) with ESMTP id C90A821F892B for ; Tue, 12 Feb 2013 21:23:13 -0800 (PST) Received: from ALVHTXW10.prod.quest.corp (10.1.135.22) by alvetxw02.quest.com (10.1.100.94) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 12 Feb 2013 21:16:48 -0800 Received: from ALVMBXW01.prod.quest.corp ([fe80::48dd:e065:86b3:9cee]) by ALVHTXW10.prod.quest.corp ([::1]) with mapi id 14.01.0355.002; Tue, 12 Feb 2013 21:23:12 -0800 From: Thomas Maslen To: "kitten@ietf.org" Thread-Topic: We need a GSS_C_CHANNEL_BOUND_FLAG Thread-Index: AQHOCaMHZISew8YmLEWyndZEJFKK4A== Date: Wed, 13 Feb 2013 05:23:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 13 Feb 2013 05:23:17 -0000 This is a general comment on draft-williams-kitten-channel-bound-flag-01 fr= om the perspective of Java GSSAPI (RFC 5653).=0A= =0A= =0A= NOTE: This is just my personal 0.02. It doesn't necessarily reflect the v= iews of my employer (Quest, now part of Dell). Also, I have no affiliation= with Oracle, so I'm definitely not speaking for them. With that out of th= e way...=0A= =0A= =0A= To solve this problem for the Java GSSAPI (RFC 5653), I think that it would= be more natural to do any one of the following:=0A= =0A= (a) Add a new constructor to the ChannelBinding class (section 7.6.1) t= hat uses a new boolean parameter to convey the same information as Nico's G= SS_C_CHANNEL_BOUND_CRED_OPT_OID, or=0A= =0A= (b) Instead of adding a new constructor, add a boolean setter method, o= r=0A= =0A= (c) Create a new subclass of the ChannelBinding class [OK, that's proba= bly silly], or=0A= =0A= (d) Add a variant of the GSSContext.setChannelBinding(ChannelBinding cb= ) method (section 7.4.31) that includes the extra boolean=0A= =0A= To me, any of those feels much more natural than doing something tricky via= the GSSCredential.=0A= =0A= I think I understand why you have to resort to (from my perspective) somewh= at unnatural acts for the C bindings -- you can't add a field to the gss_ch= annel_bindings_struct because that would break badly, and you (very reasona= bly, per your section 1.2) don't want to change the signature of gss_accept= _sec_context() -- but IMO it would be unfortunate if a problem that is spec= ific to the C bindings led to a perverse design in the abstract GSSAPI (RFC= 2743) and in the Java bindings.=0A= =0A= For example, I don't think that the Java bindings really need GSS_C_CHANNEL= _BOUND_CRED_OPT_OID, and for that matter I'm not sure that the abstract GSS= API does either.=0A= From hartmans@mit.edu Wed Feb 13 02:17:33 2013 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 DC02921F86BA for ; Wed, 13 Feb 2013 02:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.963 X-Spam-Level: X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=-0.364, 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 BrMj3lFfHIcY for ; Wed, 13 Feb 2013 02:17:33 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2B721F86EC for ; Wed, 13 Feb 2013 02:17:33 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 05BD420115 for ; Wed, 13 Feb 2013 05:13:09 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CC23543FD; Wed, 13 Feb 2013 05:17:30 -0500 (EST) From: Sam Hartman To: kitten@ietf.org Cc: References: Date: Wed, 13 Feb 2013 05:17:30 -0500 In-Reply-To: (Thomas Maslen's message of "Wed, 13 Feb 2013 05:23:11 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 13 Feb 2013 10:17:34 -0000 Folks, we're in a position where several people are eagerly discussing the details but where no one has actually expressed support for doing the work besides Nico. The sorts of comments Jeff, Luke and even Thomas are making are the kinds of comments I'd expect from people working to solve a problem. However none of those people have even indicated that they want to either: 1) Update RFc 2743 to describe actual practice 2) Provide a solution for adding channel binding to acceptors that previously did not have it. I'd also like to hear from Martin as I don't know how to interpret his comments with regard to those two questions. Right now, we have Nico and crickets. Sam Hartman Kitten co-chair From ietf@augustcellars.com Wed Feb 13 05:09:44 2013 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 CBCBD21F8884 for ; Wed, 13 Feb 2013 05:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.506 X-Spam-Level: X-Spam-Status: No, score=-3.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 UwXCLhG5yI8i for ; Wed, 13 Feb 2013 05:09:43 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id E4CCB21F8881 for ; Wed, 13 Feb 2013 05:09:43 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id A93D12C9F5; Wed, 13 Feb 2013 05:09:43 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , References: In-Reply-To: Date: Wed, 13 Feb 2013 05:09:13 -0800 Message-ID: <025d01ce09eb$52609930$f721cb90$@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: AQJtdlh/2tycAV6dNbb11cTG7IcelgGyzUt9lytTPBA= Content-Language: en-us Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 13 Feb 2013 13:09:44 -0000 I don't have a full background, However I fully support this effort if, as the messages seem to imply, it is not currently possible for an initiator or an acceptor to know that channel binding has or has not occurred when requested. Jim > -----Original Message----- > From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of > Sam Hartman > Sent: Wednesday, February 13, 2013 2:18 AM > To: kitten@ietf.org > Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG > > > Folks, we're in a position where several people are eagerly discussing the > details but where no one has actually expressed support for doing the work > besides Nico. > > The sorts of comments Jeff, Luke and even Thomas are making are the kinds > of comments I'd expect from people working to solve a problem. However > none of those people have even indicated that they want to either: > > 1) Update RFc 2743 to describe actual practice > > 2) Provide a solution for adding channel binding to acceptors that previously > did not have it. > > I'd also like to hear from Martin as I don't know how to interpret his comments > with regard to those two questions. > > Right now, we have Nico and crickets. > > Sam Hartman > Kitten co-chair > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From hartmans@mit.edu Wed Feb 13 06:02:52 2013 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 8A9EE21F8703 for ; Wed, 13 Feb 2013 06:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.932 X-Spam-Level: X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 6tRpLaZhU56M for ; Wed, 13 Feb 2013 06:02:52 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 149E621F8700 for ; Wed, 13 Feb 2013 06:02:50 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 46E1A20178; Wed, 13 Feb 2013 08:58:26 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2867043FD; Wed, 13 Feb 2013 09:02:48 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <025d01ce09eb$52609930$f721cb90$@augustcellars.com> Date: Wed, 13 Feb 2013 09:02:48 -0500 In-Reply-To: <025d01ce09eb$52609930$f721cb90$@augustcellars.com> (Jim Schaad's message of "Wed, 13 Feb 2013 05:09:13 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, 'Sam Hartman' Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 13 Feb 2013 14:02:52 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> I don't have a full background, However I fully support this Jim> effort if, as the messages seem to imply, it is not currently Jim> possible for an initiator or an acceptor to know that channel Jim> binding has or has not occurred when requested. It's not possible for an acceptor to deal with initiators some of which support channel binding and some of which do not. In the case of HTTP, Microsoft found it incredibly useful to deploy channel binding in an existing protocol. It's not possible to do with GSS-API as specified. Nico proposes to 1) Fix areas where RFc 2743 differs from what implementations actually do. He proposes to decide the implemented behavior is correct rather than to argue the spec is correct. Nico also proposes to make it possible for an acceptor to support initiators without channel binding along-side initiators with channel binding. From hartmans@mit.edu Wed Feb 13 06:06:01 2013 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 35AEC21F8488 for ; Wed, 13 Feb 2013 06:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.907 X-Spam-Level: X-Spam-Status: No, score=-102.907 tagged_above=-999 required=5 tests=[AWL=-0.308, 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 59Go5UG6ClCt for ; Wed, 13 Feb 2013 06:06:00 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5685921F8202 for ; Wed, 13 Feb 2013 06:06:00 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id B305920178 for ; Wed, 13 Feb 2013 09:01:31 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8791443FD; Wed, 13 Feb 2013 09:05:53 -0500 (EST) From: Sam Hartman To: kitten@ietf.org Date: Wed, 13 Feb 2013 09:05:53 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2. 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, 13 Feb 2013 14:06:01 -0000 The chairs have received a request fromKelley Burgin to consider draft-burgin-kerberos-aes-cbc-hmac-sha2 as a kitten draft. The chairs would like to solicit comments on whether to adopt this draft and on whether it should be standards-track or informational. Please submit comments by March 2, 2013. From ietf@augustcellars.com Wed Feb 13 06:20:17 2013 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 13E1C21F86D3 for ; Wed, 13 Feb 2013 06:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 Mqq0YAxVa9-G for ; Wed, 13 Feb 2013 06:20:16 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD3521F8678 for ; Wed, 13 Feb 2013 06:20:16 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 0B9AB2CA17; Wed, 13 Feb 2013 06:20:15 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" References: <025d01ce09eb$52609930$f721cb90$@augustcellars.com> In-Reply-To: Date: Wed, 13 Feb 2013 06:19:46 -0800 Message-ID: <026101ce09f5$2d16ceb0$87446c10$@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: AQJtdlh/2tycAV6dNbb11cTG7IcelgGyzUt9Aojxp6ICU67mHZcEghSQ Content-Language: en-us Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 13 Feb 2013 14:20:17 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Wednesday, February 13, 2013 6:03 AM > To: Jim Schaad > Cc: 'Sam Hartman'; kitten@ietf.org > Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG > > >>>>> "Jim" == Jim Schaad writes: > > Jim> I don't have a full background, However I fully support this > Jim> effort if, as the messages seem to imply, it is not currently > Jim> possible for an initiator or an acceptor to know that channel > Jim> binding has or has not occurred when requested. > > It's not possible for an acceptor to deal with initiators some of which support > channel binding and some of which do not. In the case of HTTP, Microsoft > found it incredibly useful to deploy channel binding in an existing protocol. > It's not possible to do with GSS-API as specified. > Nico proposes to > > 1) Fix areas where RFc 2743 differs from what implementations actually do. > He proposes to decide the implemented behavior is correct rather than to > argue the spec is correct. > > Nico also proposes to make it possible for an acceptor to support initiators > without channel binding along-side initiators with channel binding. I think that he also makes it possible for the initiator and the acceptor to determine if the channel binding occurred. From hartmans@mit.edu Wed Feb 13 06:24:37 2013 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 BA31D21F86FF for ; Wed, 13 Feb 2013 06:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.885 X-Spam-Level: X-Spam-Status: No, score=-102.885 tagged_above=-999 required=5 tests=[AWL=-0.286, 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 TmzKelD12yQc for ; Wed, 13 Feb 2013 06:24:37 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 41F5021F86D4 for ; Wed, 13 Feb 2013 06:24:37 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id BA60020178; Wed, 13 Feb 2013 09:20:12 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8E00743FD; Wed, 13 Feb 2013 09:24:34 -0500 (EST) From: Sam Hartman To: "Jim Schaad" References: <025d01ce09eb$52609930$f721cb90$@augustcellars.com> <026101ce09f5$2d16ceb0$87446c10$@augustcellars.com> Date: Wed, 13 Feb 2013 09:24:34 -0500 In-Reply-To: <026101ce09f5$2d16ceb0$87446c10$@augustcellars.com> (Jim Schaad's message of "Wed, 13 Feb 2013 06:19:46 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, 'Sam Hartman' Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 13 Feb 2013 14:24:37 -0000 If the initiator and acceptor both pass in non-empty channel bindings they already have confidence that channel binding happened today. Even after Nico's proposal, it will be possible for an acceptor to explicitly ignore channel bindings. From mrex@sap.com Wed Feb 13 06:31:14 2013 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 C2E3121F860A for ; Wed, 13 Feb 2013 06:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=0.020, 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 ilM0R2YWpVx5 for ; Wed, 13 Feb 2013 06:31:14 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id C4D5321F8609 for ; Wed, 13 Feb 2013 06:31:13 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r1DEV70u018205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 15:31:07 +0100 (MET) In-Reply-To: To: Nico Williams Date: Wed, 13 Feb 2013 15:31:06 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130213143106.F164C1A55B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, Jeffrey Hutzelman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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: Wed, 13 Feb 2013 14:31:14 -0000 Nico Williams wrote: > > Jeffrey Hutzelman wrote: > > Allow me to respond to this out of order. > > > It is also worth noting that while the existing mechanism represents > > these flags on the wire using the same bits that are used in the C API, > > there is no reason this must be the case. We absolutely can create > > flags in the API which do not correspond directly to bits on the wire, > > and vice versa. > > This is true. I don't think we have a rule about what the mechanism > should do with flags it doesn't know about The rule in both, base GSS-API and Kerberos GSS-API v2 mechanism is: - set all bits you do not know about to zero on send - ignore all bits you do not know about on receive > > > Not quite. RFC4121 reserves the 8 bits 0xff000 for "legacy" vendor > > flags. I don't recall exactly what we were thinking at the time, but > > since there's no negotiation mechanism, the addition by vendors of _new_ > > flags in this range will almost certainly lead to bad results. > > Is there any evidence of "legacy" vendor flags, or that mechglues or > mechanisms do anything to filter out flags in this range? If not then > I think we can re-purpose them. I do remember from IETF CAT WG discussions that there were legacy/vendor flags in mechanism implementations in 1995/6, and they were using from the high value range. It was discussed, because GSS-APIv2 assigned three new context flags that did not exist in GSS-API v1: #define GSS_C_ANON_FLAG 64 /* (1<<6) */ #define GSS_C_PROT_READY_FLAG 128 /* (1<<7) */ #define GSS_C_TRANS_FLAG 256 /* (1<<8) */ and the idea was that future standardized flags would similarily continue to be assigned from the low end of the bits. While I did some superficial search on my CAT mailing list archives, I haven't found any specific mails so far. I do remember it was discussed. It may have been within IETF WG meetings, and not be part of the meeting minutes. I had not previously noticed the "legacy" assignments of such low bits as 2^12 (1<<12) in Microsoft Kerberos (rfc4121), and it's awful and short-sighted that they poached in the low bit number range. > > > This is a 32-bit space, so we should be careful about allocating new > > bits from among those that are currently reserved, and there really > > isn't room for vendor-specific bits (other than the legacy ones) at all. > > Nico suggests we need a registry, but I'm not convinced that's the case. > > As written, RFC4121 does not contemplate that new flags will be > > allocated by extensions; rather, they can be used only in new revisions > > of the base spec. > > I want a registry to I can find the ones that are registered by means > other than looking at multiple implementations' header files / docs. > We may well want Standards Action to allocate them given their > scarcity, but the point for me is having a place where I can find them > all so I can allocate an as-yet unused one. > > BTW, I could add an extended security context inquiry function instead > of using ret_flags. For the Java API there'd be no real difference. > For the C API a flag is clearly easier to check. In order to reduce the likelyhood of clashes of vendor-pilfered context attribute flags with standard-assigned ones in the (C-Bindings) 32-bit number range, an IANA registry seems appropriate. -Martin From mrex@sap.com Wed Feb 13 06:43:38 2013 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 18A5721F8738 for ; Wed, 13 Feb 2013 06:43:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=0.019, 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 dhBsAv3kS0U4 for ; Wed, 13 Feb 2013 06:43:37 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 45BA821F8721 for ; Wed, 13 Feb 2013 06:43:37 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r1DEhSqV021970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 15:43:28 +0100 (MET) In-Reply-To: To: Nico Williams Date: Wed, 13 Feb 2013 15:43:28 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130213144328.83CA81A55D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, Sam Hartman , Jeffrey Hutzelman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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: Wed, 13 Feb 2013 14:43:38 -0000 Nico Williams wrote: > > Sam Hartman wrote: > > > > Nico needs a C API flag, not a wire flag, right? > > In this case that distinction is irrelevant because setting this flag > in req_flags and having it automatically copied (locally and on the > wire) into ret_flags does no harm. > > BTW, maybe we should have a range of flags that must be transported by > the mech regardless of the flags' semantics? I think that'd be > overkill, but maybe I'm being unimaginative. No, no, no. As it says in rfc4121 Section 4.1.1.1: All other flag values not specified herein are reserved for future use. Future revisions of this mechanism may use these reserved flags and may rely on implementations of this version to not use such flags in order to properly negotiate mechanism versions. Undefined flag values MUST be cleared by the sender, and unknown flags MUST be ignored by the receiver. With the exception of the generic token framing of the initial context token, GSS-API itself specifies API semantics, not wire-level PDUs. Context attributes (req_flags inputs and ret_flags outputs) can have a meaning about strictly local API semantics (REPLAY,ANON,TRANS,PROT_READY), or they can refer to a feature/characteristic that both communiation peers have in common (DELEG,MUTUAL,SEQUENCE,CONF,INTEG). A simplified variant of data REPLAY protection may use enforced sequencing of data. A gssapi mechanism must not pass along context attributes from the API to the communication peer, for which it does not know the semantics, and it must not pass along the context attributes for which the meaning is limited to he local API (TRANS,PROT_READY,ANON and some variants of REPLAY). -Martin From lha@kth.se Wed Feb 13 07:22:52 2013 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 B198621F8842 for ; Wed, 13 Feb 2013 07:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.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 OPkuNWVMObjK for ; Wed, 13 Feb 2013 07:22:52 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfa.amsl.com (Postfix) with ESMTP id E9E6021F8838 for ; Wed, 13 Feb 2013 07:22:51 -0800 (PST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 596D114FA4F; Wed, 13 Feb 2013 16:22:20 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id IXrqktoTWZ4J; Wed, 13 Feb 2013 16:22:11 +0100 (CET) Received: from EXHUB2.ug.kth.se (exhub2.ug.kth.se [130.237.32.137]) by smtp-2.sys.kth.se (Postfix) with ESMTP id C02BD14FA20; Wed, 13 Feb 2013 16:22:08 +0100 (CET) Received: from EXDB1.ug.kth.se ([169.254.1.23]) by EXHUB2.ug.kth.se ([130.237.32.137]) with mapi id 14.02.0328.009; Wed, 13 Feb 2013 16:22:08 +0100 From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= To: Sam Hartman Thread-Topic: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2. Thread-Index: AQHOCfOQEIGCxtQKBEa4YQtBiypJ5Zh3591M Date: Wed, 13 Feb 2013 15:22:07 +0000 Message-ID: <48EB54C1-F693-492B-AFFD-F77FAD8211B4@kth.se> References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" Subject: Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2. 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, 13 Feb 2013 15:22:52 -0000 This dradt uses cbc. Is the considerations that made us use cts mode/paddin= g no longer important (dce/ms-rpc) ? Skickat fr=E5n min iPad 13 feb 2013 kl. 06:08 skrev "Sam Hartman" : >=20 > The chairs have received a request fromKelley Burgin to consider > draft-burgin-kerberos-aes-cbc-hmac-sha2 as a kitten draft. The chairs > would like to solicit comments on whether to adopt this draft and on > whether it should be standards-track or informational. > Please submit comments by March 2, 2013. > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From mrex@sap.com Wed Feb 13 07:39:35 2013 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 9D86721F88CC for ; Wed, 13 Feb 2013 07:39:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.23 X-Spam-Level: X-Spam-Status: No, score=-10.23 tagged_above=-999 required=5 tests=[AWL=0.019, 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 X4u641p4n1AL for ; Wed, 13 Feb 2013 07:39:35 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id A2AD021F887F for ; Wed, 13 Feb 2013 07:39:34 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r1DFd7Dv005927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 16:39:07 +0100 (MET) In-Reply-To: To: Sam Hartman Date: Wed, 13 Feb 2013 16:39:06 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130213153906.D962F1A55D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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: Wed, 13 Feb 2013 15:39:35 -0000 Sam Hartman wrote: > > If the initiator and acceptor both pass in non-empty channel bindings > they already have confidence that channel binding happened today. I'm terribly sorry to disappoint you, but this is not generally true. It may be true for specific implementations, though. There are gssapi mechanisms which do not implement support for channel bindings, and which will simply and silently ignore that parameter on gss_init_sec_context() and gss_accept_sec_context() -- and these are still compliant with rfc2743/rfc2744. > > Even after Nico's proposal, it will be possible for an acceptor > to explicitly ignore channel bindings. Correct. I agree with Nico that the existing GSS-API channel bindings semantics, as specified in rfc2743/rfc2744 are not useful. I believe it is worthwhile of adding the missing parts to make GSS-API channel bindings useful. Adding a context attribute flag that indicates successful channel bindings validation is reasonable. But I would appreciate if useful behaviour could be obtained without having to perform an new GSS-API call. The underlying principle of GSS-API in security context establishment is: (rfc2743, Section 1.2.1, page 20) http://tools.ietf.org/html/rfc2743#page-20 Some mechanisms may not support all optional services, and some mechanisms may only support some services in conjunction with others. Both GSS_Init_sec_context() and GSS_Accept_sec_context() inform the applications which services will be available from the context when the establishment phase is complete, via the ret_flags output parameter. In general, if the security mechanism is capable of providing a requested service, it should do so, even if additional services must be enabled in order to provide the requested service. If the mechanism is incapable of providing a requested service, it should proceed without the service, leaving the application to abort the context establishment process if it considers the requested service to be mandatory. And as Nico has properly noticed, _without_ a means for the application caller to know whether channel bindings were used and/or successfully verified during security context establishment, that last part does not compute: leaving the application to abort the context establishment process if it considers the requested service to be mandatory. Bottom line: the existing channel bindings support is underspecified/incomplete. And implementations that hard fail on the acceptor side when the client did not assert channel bindings are in conflict of the general GSS-API architecture as described above. -Martin From nico@cryptonector.com Wed Feb 13 07:41:33 2013 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 C54CE21F86F8 for ; Wed, 13 Feb 2013 07:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.824 X-Spam-Level: X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=-1.847, 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 Hb9oFEnssZbP for ; Wed, 13 Feb 2013 07:41:32 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id C0DF021F86FD for ; Wed, 13 Feb 2013 07:41:32 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id C1F8C6B0070 for ; Wed, 13 Feb 2013 07:41:30 -0800 (PST) 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=f4snrENd2c+zjQL88tPhp6xrMGA=; b=g6j1u6vZwvQ LsKx3g8ko9IFPk3eZepBPT85CAYbaCsNRF6BShqegmp9M71PvLIiFDjZARbkMohR LPKRTpIVJ3cTP/etoaemaKgs1NG2TgFUpD152IIckEO0ESaXwYBmZsm2zrWr7l9P PCjrg7Jkef9BRYpmXY2MLYKCU0LIdYvM= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (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 50D696B0059 for ; Wed, 13 Feb 2013 07:41:30 -0800 (PST) Received: by mail-wi0-f179.google.com with SMTP id ez12so1563056wid.12 for ; Wed, 13 Feb 2013 07:41:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.79.201 with SMTP id l9mr10831192wix.20.1360770088830; Wed, 13 Feb 2013 07:41:28 -0800 (PST) Received: by 10.217.39.133 with HTTP; Wed, 13 Feb 2013 07:41:28 -0800 (PST) In-Reply-To: References: Date: Wed, 13 Feb 2013 09:41:28 -0600 Message-ID: From: Nico Williams To: Thomas Maslen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 13 Feb 2013 15:41:33 -0000 On Tue, Feb 12, 2013 at 11:23 PM, Thomas Maslen w= rote: > This is a general comment on draft-williams-kitten-channel-bound-flag-01 = from the perspective of Java GSSAPI (RFC 5653). I really appreciate this comment. Thanks! > NOTE: This is just my personal 0.02. It doesn't necessarily reflect the= views of my employer (Quest, now part of Dell). Also, I have no affiliati= on with Oracle, so I'm definitely not speaking for them. With that out of = the way... Several years ago the JCP ceded ownership of the JGSS API to the IETF. This doesn't mean that Oracle will implement whatever we standardize, or any other Java implementor for that matter, but it does mean we can pursue JGSS extensions here. > To solve this problem for the Java GSSAPI (RFC 5653), I think that it wou= ld be more natural to do any one of the following: Sure, new methods make a lot more sense for the JGSS than a set cred option method on credentials. I completely agree. I'd probably go for a context method (your option (d)) rather than a new channel binding constructor, but it's roughly all the same, yes? > To me, any of those feels much more natural than doing something tricky v= ia the GSSCredential. Absolutely. The Java bindings of the GSS-API has a fairly different model from the abstract and C bindings. For Java we should follow the pattern already set for the Java bindings. > I think I understand why you have to resort to (from my perspective) some= what unnatural acts for the C bindings -- you can't add a field to the gss_= channel_bindings_struct because that would break badly, and you (very reaso= nably, per your section 1.2) don't want to change the signature of gss_acce= pt_sec_context() -- but IMO it would be unfortunate if a problem that is sp= ecific to the C bindings led to a perverse design in the abstract GSSAPI (R= FC 2743) and in the Java bindings. It's because there's no constructor for gss_ctx_id_t values. You have to call gss_init/accept_sec_context() with a null context initially. Also, we already have gss_set_cred_option() in several C implementations -- it made sense to re-use what we already had for this sort of extension. > For example, I don't think that the Java bindings really need GSS_C_CHANN= EL_BOUND_CRED_OPT_OID, and for that matter I'm not sure that the abstract G= SSAPI does either. Agreed as to the first part. As for the abstract API, it and the C bindings resemble each other fairly closely, so I'd rather keep that resemblance, but I'm open to alternatives. After all, this option is only a credential option in the sense that credentials are the convenient carrier for the option -- there are other options that are more like credential options (e.g., options related to cipher suite policies, but these too would exist primarily to affect cipher suite negotiation for security context establishment, so maybe this is a bad example). I have to agree too with the unstated sentiment that there are some flaws in the abstract API and C bindings, namely: - no app/library context handle - minor status is too small to encode desired error information - the lack of both an app/library context handle and a constructor for "empty" security contexts means that we don't get to pass in any kinds of options except via req_flags and then only in gss_init_sec_context() I could go on. That's a start. However, this is the API we have. I have toyed before with a version 3 of the API to correct all of these and many more problems (e.g., memory management issues in the C bindings). However, that would be a huge undertaking that I have neither the energy nor the funding for, and even if I did, I'd still have the immense task of getting the new API adopted. I've settled for accepting the flaws of the standard API and the barnacles that implementations have gathered over the years, though not without some sadness. Nico -- From nico@cryptonector.com Wed Feb 13 07:45:05 2013 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 D461321F877B for ; Wed, 13 Feb 2013 07:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=-1.772, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPowx2NN5Lbw for ; Wed, 13 Feb 2013 07:45:03 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 4449321F8754 for ; Wed, 13 Feb 2013 07:45:00 -0800 (PST) Received: from homiemail-a74.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTP id 0BAB967C06E for ; Wed, 13 Feb 2013 07:45:00 -0800 (PST) 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=NJR2Wy072rlveiB+nmsC Wq9gLtw=; b=vrns9EzWSKZ4aa6RMIGzwcxeEiEztJIZnRUr57tGU3MMu+Vxj24A 8n7GDUE+kimiMQUM3pxhhHrTV4N3XolRJNr5cH+q83mSla1msUOndOgITseRuPTS 3ZGEX+HTvLdN3c+sBx84j593l5uaPRu46FROI5E59cKYBqiCF2FIXZU= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a74.g.dreamhost.com (Postfix) with ESMTPSA id A97D167C06D for ; Wed, 13 Feb 2013 07:44:59 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id r6so1117975wey.19 for ; Wed, 13 Feb 2013 07:44:58 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.101.98 with SMTP id ff2mr11281459wib.0.1360770298225; Wed, 13 Feb 2013 07:44:58 -0800 (PST) Received: by 10.217.39.133 with HTTP; Wed, 13 Feb 2013 07:44:57 -0800 (PST) In-Reply-To: <20130213153906.D962F1A55D@ld9781.wdf.sap.corp> References: <20130213153906.D962F1A55D@ld9781.wdf.sap.corp> Date: Wed, 13 Feb 2013 09:44:57 -0600 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 13 Feb 2013 15:45:05 -0000 On Wed, Feb 13, 2013 at 9:39 AM, Martin Rex wrote: > Sam Hartman wrote: >> Even after Nico's proposal, it will be possible for an acceptor >> to explicitly ignore channel bindings. > > Correct. > > I agree with Nico that the existing GSS-API channel bindings semantics, > as specified in rfc2743/rfc2744 are not useful. > > I believe it is worthwhile of adding the missing parts to make > GSS-API channel bindings useful. Adding a context attribute flag > that indicates successful channel bindings validation is reasonable. > But I would appreciate if useful behaviour could be obtained without > having to perform an new GSS-API call. I don't see how we can avoid adding new function calls. A req_flag wouldn't help. And a new ret_flag does nothing to protect against apps that don't understand it. > And as Nico has properly noticed, _without_ a means for the application > caller to know whether channel bindings were used and/or successfully > verified during security context establishment, that last part does not > compute: Right. > Bottom line: the existing channel bindings support is > underspecified/incomplete. And implementations that hard fail > on the acceptor side when the client did not assert channel bindings > are in conflict of the general GSS-API architecture as described above. Whereas in my view the GSS-API specification (RFC2743) has a bug. You yourself agree that the specified behavior is not useful -- how is that not a specification bug? Nico -- From nico@cryptonector.com Wed Feb 13 07:57:56 2013 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 D59F121F87CC for ; Wed, 13 Feb 2013 07:57:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.634 X-Spam-Level: X-Spam-Status: No, score=-3.634 tagged_above=-999 required=5 tests=[AWL=-1.957, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Am15XzcOxH8V for ; Wed, 13 Feb 2013 07:57:56 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF5021F87A5 for ; Wed, 13 Feb 2013 07:57:56 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id B0CAF438072 for ; Wed, 13 Feb 2013 07:57:55 -0800 (PST) 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=kXlNt1RLZLqkwLCnm8+0hfOGvYs=; b=PKKpI/yKzps zNDLAeGmDoPqwsIgV7PNrBoh//Kzrwl6w77oWEwPoCgIWeBz5Vl3FfvFG5FmIuQL yz8StCdTMpoiX4aVW43aSn2frWbaTNa/Ci4qbEdaddxxsI8e42otCWqSL4H/Z2uk YD8biqeOaUvyiGGIcPxorXgOBjIfXGkE= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 5AE1443806C for ; Wed, 13 Feb 2013 07:57:55 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so5886135wid.17 for ; Wed, 13 Feb 2013 07:57:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.103.163 with SMTP id fx3mr27076859wjb.58.1360771074131; Wed, 13 Feb 2013 07:57:54 -0800 (PST) Received: by 10.217.39.133 with HTTP; Wed, 13 Feb 2013 07:57:53 -0800 (PST) In-Reply-To: <48EB54C1-F693-492B-AFFD-F77FAD8211B4@kth.se> References: <48EB54C1-F693-492B-AFFD-F77FAD8211B4@kth.se> Date: Wed, 13 Feb 2013 09:57:53 -0600 Message-ID: From: Nico Williams To: =?UTF-8?B?TG92ZSBIw7ZybnF1aXN0IMOFc3RyYW5k?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Sam Hartman , "Burgin, Kelley W." Subject: Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2. 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, 13 Feb 2013 15:57:56 -0000 On Wed, Feb 13, 2013 at 9:22 AM, Love H=C3=B6rnquist =C3=85strand wrote: > This dradt uses cbc. Is the considerations that made us use cts mode/padd= ing no longer important (dce/ms-rpc) ? The -02 seems to have switched to CTS, but the edits for that change are incomplete. I assume that a -03 will complete the switch to CTS. No motivation is given for the new enctypes, but I assume it's the obvious motivation: to move away from SHA-1. As for CBC vs. CTS, we really want CTS for reasons having to do with the SSPI -- we want the only ciphertext expansion to be of static size and to result from a) the use of a confounder (this is done in RFC3961, so this I-D needn't mention confounders any more than RFC3962), and b) the authentication tag (the MAC). CTS does have its problems, namely that it's hard to implement in terms of CBC: it's difficult to implement CTS using cryptographic coprocessors. The best one can do is use two (and sometimes three) AES-CBC cryptographic coprocessor operations The AES-NI instructions make this less of a concern. Nico -- From mrex@sap.com Wed Feb 13 08:02:58 2013 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 0477921F8770 for ; Wed, 13 Feb 2013 08:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.231 X-Spam-Level: X-Spam-Status: No, score=-10.231 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2oLukPTykAV for ; Wed, 13 Feb 2013 08:02:57 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2FBE721F876E for ; Wed, 13 Feb 2013 08:02:57 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r1DG2qkH011274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 17:02:52 +0100 (MET) In-Reply-To: To: Nico Williams Date: Wed, 13 Feb 2013 17:02:52 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130213160252.3E3731A55D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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: Wed, 13 Feb 2013 16:02:58 -0000 Nico Williams wrote: > Martin Rex wrote: > > > > Sam Hartman wrote: > >> Even after Nico's proposal, it will be possible for an acceptor > >> to explicitly ignore channel bindings. > > > > Correct. > > > > I agree with Nico that the existing GSS-API channel bindings semantics, > > as specified in rfc2743/rfc2744 are not useful. > > > > I believe it is worthwhile of adding the missing parts to make > > GSS-API channel bindings useful. Adding a context attribute flag > > that indicates successful channel bindings validation is reasonable. > > But I would appreciate if useful behaviour could be obtained without > > having to perform an new GSS-API call. > > I don't see how we can avoid adding new function calls. A req_flag > wouldn't help. And a new ret_flag does nothing to protect against > apps that don't understand it. You're misunderstanding the GSS-API architecture. The gssapi mechanism MUST NOT do that ("protect the application") In GSS-API, the "req_flags" are about desires of the caller, not about requirements (that is where GSS-API differs from Microsoft's SSPI). GSS-API mechanisms are expected to establish the security context, even if it does not meet all of the desires of the application, and it is the duty of the application caller to check whether the characteristics of the resulting security context are "sufficient". The exact same semantics applies to "gss_wrap(conf=TRUE)". If the gssapi mechanism can apply only integrity protection, but not confidentiality protection, then it MUST succeed anyhow, and return "conf_avail=FALSE": The conf_avail return value indicates whether the context supports per-message confidentiality services, and so informs the caller whether or not a request for encryption through the conf_req_flag input to GSS_Wrap() can be honored. > > > And as Nico has properly noticed, _without_ a means for the application > > caller to know whether channel bindings were used and/or successfully > > verified during security context establishment, that last part does not > > compute: > > Right. > > > Bottom line: the existing channel bindings support is > > underspecified/incomplete. And implementations that hard fail > > on the acceptor side when the client did not assert channel bindings > > are in conflict of the general GSS-API architecture as described above. > > Whereas in my view the GSS-API specification (RFC2743) has a bug. You > yourself agree that the specified behavior is not useful -- how is > that not a specification bug? The lack of an indicator that channel bindings were successfully validated is the defect. Failing security context establishment when the acceptor provided channel bindings but the initiator did not supply them is a bug of the server-side gssapi mechanism implementation. -Martin From nico@cryptonector.com Wed Feb 13 08:16:13 2013 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 05EE621F8A64 for ; Wed, 13 Feb 2013 08:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.702 X-Spam-Level: X-Spam-Status: No, score=-3.702 tagged_above=-999 required=5 tests=[AWL=-1.725, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bhoSvh7ZARRi for ; Wed, 13 Feb 2013 08:16:12 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD4621F8A5F for ; Wed, 13 Feb 2013 08:16:12 -0800 (PST) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 0089F42807A for ; Wed, 13 Feb 2013 08:16:12 -0800 (PST) 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=mxUSfoanY8wB2vO0v+YI DHKbRl8=; b=JoMPW/lpw4NMKtfaVE7LQDENoNn0/fgmRx2rrWady0AxidaVbAoK j3Pv2LH77yHWKwHsI6FddMvgBcO+UA9ALMQUYziDicRyirN11oCOjbb3md2exqHU O1R7wh4/MCkOUMfSFJ0WHLUd2vmIJ55S8xiOgjsZCI55lOgsR6mbsko= Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.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 97681428078 for ; Wed, 13 Feb 2013 08:16:11 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id dr12so1113209wgb.35 for ; Wed, 13 Feb 2013 08:16:07 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.60.5 with SMTP id d5mr22401663wjr.4.1360772167764; Wed, 13 Feb 2013 08:16:07 -0800 (PST) Received: by 10.217.39.133 with HTTP; Wed, 13 Feb 2013 08:16:07 -0800 (PST) In-Reply-To: <20130213160252.3E3731A55D@ld9781.wdf.sap.corp> References: <20130213160252.3E3731A55D@ld9781.wdf.sap.corp> Date: Wed, 13 Feb 2013 10:16:07 -0600 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 13 Feb 2013 16:16:13 -0000 On Wed, Feb 13, 2013 at 10:02 AM, Martin Rex wrote: > Nico Williams wrote: >> Martin Rex wrote: >> I don't see how we can avoid adding new function calls. A req_flag >> wouldn't help. And a new ret_flag does nothing to protect against >> apps that don't understand it. > > You're misunderstanding the GSS-API architecture. > The gssapi mechanism MUST NOT do that ("protect the application") I misunderstood nothing. The GSS-API *should* have had GSS_C_CHANNEL_BOUND_FLAG, and if it had had that from day zero there would be no question of "protect[ing] against apps that don't understand [that flag]." But *now* we cannot add this flag and otherwise retain the original channel binding behavior, implementing both in existing implementations that implement the alternative actually-deployed behavior -- doing so would break things. Nico -- From mrex@sap.com Wed Feb 13 08:23:40 2013 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 51D5821F8767 for ; Wed, 13 Feb 2013 08:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.232 X-Spam-Level: X-Spam-Status: No, score=-10.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8JA5MRpZZ70 for ; Wed, 13 Feb 2013 08:23:38 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7497F21F84D1 for ; Wed, 13 Feb 2013 08:23:21 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r1DGNG2g016149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 17:23:16 +0100 (MET) In-Reply-To: To: Nico Williams Date: Wed, 13 Feb 2013 17:23:16 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130213162316.70DAD1A55D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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: Wed, 13 Feb 2013 16:23:40 -0000 Nico Williams wrote: [ Charset UTF-8 unsupported, converting... ] > On Wed, Feb 13, 2013 at 10:02 AM, Martin Rex wrote: > > Nico Williams wrote: > >> Martin Rex wrote: > >> I don't see how we can avoid adding new function calls. A req_flag > >> wouldn't help. And a new ret_flag does nothing to protect against > >> apps that don't understand it. > > > > You're misunderstanding the GSS-API architecture. > > The gssapi mechanism MUST NOT do that ("protect the application") > > I misunderstood nothing. The GSS-API *should* have had > GSS_C_CHANNEL_BOUND_FLAG, and if it had had that from day zero there > would be no question of "protect[ing] against apps that don't > understand [that flag]." But *now* we cannot add this flag and > otherwise retain the original channel binding behavior, implementing > both in existing implementations that implement the alternative > actually-deployed behavior -- doing so would break things. I believe that you can add it now. We can add it as a flag for both, input _and_ output. For gssapi callers that do not pass that flag on input, you can retain the original behaviour. But gssapi callers that pass the new channel-bindings context attribute flag as a desire on input, the semantics should follow the original GSS-API architecture, and cause a successful context establishment when just one side asserted channel bindings -- and it is up to the calling application to check the resulting new context attribute flag (which it claimed to understand!!) whether it indicates successful channel bindings validation. -Martin From kwburgi@tycho.ncsc.mil Wed Feb 13 08:25:34 2013 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 B71DE21F84DF for ; Wed, 13 Feb 2013 08:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnikDNgSuPhB for ; Wed, 13 Feb 2013 08:25:31 -0800 (PST) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3759B21F8428 for ; Wed, 13 Feb 2013 08:25:30 -0800 (PST) X-TM-IMSS-Message-ID: <33d1f3f10000d414@nsa.gov> Received: from tarius.tycho.ncsc.mil ([144.51.31.2]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id 33d1f3f10000d414 ; Wed, 13 Feb 2013 11:25:57 -0500 Received: from [192.168.26.151] (rd6um-58422h [192.168.26.151]) by tarius.tycho.ncsc.mil (8.13.1/8.13.1) with ESMTP id r1DGO422017516; Wed, 13 Feb 2013 11:25:22 -0500 Message-Id: <5F3F1B73-646C-45F9-9804-942815023F69@tycho.ncsc.mil> From: Kelley Burgin To: Nico Williams In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 13 Feb 2013 11:28:05 -0500 References: <48EB54C1-F693-492B-AFFD-F77FAD8211B4@kth.se> X-Mailer: Apple Mail (2.936) Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2. 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, 13 Feb 2013 16:25:34 -0000 These enctypes are to support draft-burgin-kerberos-suiteb, so the =20 move from SHA-1 was the major motivation. We switched to CTS in -02 =20 after the discussion on DCE/MS-RPC a year or two ago. The other major =20= difference is we mac the ciphertext instead of the plaintext. I didn't intend for the draft to be incomplete in the switch to CTS =20 and would certainly appreciate more detailed comments on revisions =20 needed. Kelley On Feb 13, 2013, at 10:57 AM, Nico Williams wrote: > On Wed, Feb 13, 2013 at 9:22 AM, Love H=F6rnquist =C5strand = =20 > wrote: >> This dradt uses cbc. Is the considerations that made us use cts =20 >> mode/padding no longer important (dce/ms-rpc) ? > > The -02 seems to have switched to CTS, but the edits for that change > are incomplete. > > I assume that a -03 will complete the switch to CTS. > > No motivation is given for the new enctypes, but I assume it's the > obvious motivation: to move away from SHA-1. > > As for CBC vs. CTS, we really want CTS for reasons having to do with > the SSPI -- we want the only ciphertext expansion to be of static size > and to result from a) the use of a confounder (this is done in > RFC3961, so this I-D needn't mention confounders any more than > RFC3962), and b) the authentication tag (the MAC). > > CTS does have its problems, namely that it's hard to implement in > terms of CBC: it's difficult to implement CTS using cryptographic > coprocessors. The best one can do is use two (and sometimes three) > AES-CBC cryptographic coprocessor operations The AES-NI instructions > make this less of a concern. > > Nico > -- From nico@cryptonector.com Wed Feb 13 08:26:42 2013 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 4B6AB21F8881 for ; Wed, 13 Feb 2013 08:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.742 X-Spam-Level: X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[AWL=-1.765, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FxoGuxUmw0c for ; Wed, 13 Feb 2013 08:26:41 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8551D21F8771 for ; Wed, 13 Feb 2013 08:26:41 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 5FDBF26406C for ; Wed, 13 Feb 2013 08:26:41 -0800 (PST) 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=D+NoPFNS8k0eXiB9Aq/e 8yW8d3o=; b=l8TEWhJ1PvXHX5S+mLp82djq7zjn4BxfJOi2cK7C2uwKtJTqWddJ oBR9lCR7ahQFYadwbtJGjfM1K+quyiLw3Ze3zQH0Skgum/HPqoyFqCnxabJWlWuh 790FUFHx67WQfvLvADyr1Cpt1280MWqVB/55Tnso3dqfh7eT4KLWSdg= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (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 097FB264060 for ; Wed, 13 Feb 2013 08:26:40 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hi18so1627434wib.15 for ; Wed, 13 Feb 2013 08:26:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.60.5 with SMTP id d5mr22474163wjr.4.1360772799668; Wed, 13 Feb 2013 08:26:39 -0800 (PST) Received: by 10.217.39.133 with HTTP; Wed, 13 Feb 2013 08:26:39 -0800 (PST) In-Reply-To: <20130213162316.70DAD1A55D@ld9781.wdf.sap.corp> References: <20130213162316.70DAD1A55D@ld9781.wdf.sap.corp> Date: Wed, 13 Feb 2013 10:26:39 -0600 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 13 Feb 2013 16:26:42 -0000 On Wed, Feb 13, 2013 at 10:23 AM, Martin Rex wrote: > Nico Williams wrote: > [ Charset UTF-8 unsupported, converting... ] Really? That's kinda funny. It's 2013... >> On Wed, Feb 13, 2013 at 10:02 AM, Martin Rex wrote: >> > Nico Williams wrote: >> >> Martin Rex wrote: >> >> I don't see how we can avoid adding new function calls. A req_flag >> >> wouldn't help. And a new ret_flag does nothing to protect against >> >> apps that don't understand it. >> > >> > You're misunderstanding the GSS-API architecture. >> > The gssapi mechanism MUST NOT do that ("protect the application") >> >> I misunderstood nothing. The GSS-API *should* have had >> GSS_C_CHANNEL_BOUND_FLAG, and if it had had that from day zero there >> would be no question of "protect[ing] against apps that don't >> understand [that flag]." But *now* we cannot add this flag and >> otherwise retain the original channel binding behavior, implementing >> both in existing implementations that implement the alternative >> actually-deployed behavior -- doing so would break things. > > I believe that you can add it now. > > We can add it as a flag for both, input _and_ output. GSS_Accept_sec_context() has no flags inputs. In order to make the originally-specified behavior safe, the acceptor-side of the mechanisms need to know if the acceptor applications understand the new flag. Nico -- From nico@cryptonector.com Wed Feb 13 08:31:39 2013 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 8A6EB21F89EE for ; Wed, 13 Feb 2013 08:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.658 X-Spam-Level: X-Spam-Status: No, score=-3.658 tagged_above=-999 required=5 tests=[AWL=-1.681, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f51Cz3C6cfWb for ; Wed, 13 Feb 2013 08:31:39 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 2933421F8925 for ; Wed, 13 Feb 2013 08:31:35 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id C17A135007A for ; Wed, 13 Feb 2013 08:31:30 -0800 (PST) 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=OSIjHZr+CoeTUh2ehzsi EERK3+A=; b=CBJ2o9IybtmzpurtRbLv4bSddqk/uaySEmDWv0SFtKneTFfxBhyr A/fEGHW+oLRr26IiI6Z9FG8uSLfvWUJsnE1vRWGxyFdQUTv7HwK9nk32NXxdEVOq 32YovkFHNR24hAq1gJYjz874hmjo0Yqa6pbzlQ53ohdubjf2XTOSkd8= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 69322350079 for ; Wed, 13 Feb 2013 08:31:30 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so1147684wer.8 for ; Wed, 13 Feb 2013 08:31:28 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.97.166 with SMTP id eb6mr11160232wib.20.1360773088887; Wed, 13 Feb 2013 08:31:28 -0800 (PST) Received: by 10.217.39.133 with HTTP; Wed, 13 Feb 2013 08:31:28 -0800 (PST) In-Reply-To: <5F3F1B73-646C-45F9-9804-942815023F69@tycho.ncsc.mil> References: <48EB54C1-F693-492B-AFFD-F77FAD8211B4@kth.se> <5F3F1B73-646C-45F9-9804-942815023F69@tycho.ncsc.mil> Date: Wed, 13 Feb 2013 10:31:28 -0600 Message-ID: From: Nico Williams To: Kelley Burgin Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2. 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, 13 Feb 2013 16:31:39 -0000 On Wed, Feb 13, 2013 at 10:28 AM, Kelley Burgin wrote: > These enctypes are to support draft-burgin-kerberos-suiteb, so the move from > SHA-1 was the major motivation. We switched to CTS in -02 after the > discussion on DCE/MS-RPC a year or two ago. The other major difference is we > mac the ciphertext instead of the plaintext. > > I didn't intend for the draft to be incomplete in the switch to CTS and > would certainly appreciate more detailed comments on revisions needed. Well, the abstract still says "CBC"... :) Also: - the title says nothing about cipher mode - the footer still says CBC in the shortened form of the title - appendix A's title still says CBC - paragraph 2 of section 1 still says CBC... - ... You might want to do a global search and replace. Nico -- From mrex@sap.com Wed Feb 13 08:44:13 2013 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 3D01321F8A4E for ; Wed, 13 Feb 2013 08:44:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.232 X-Spam-Level: X-Spam-Status: No, score=-10.232 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6o7dNGHJCIE for ; Wed, 13 Feb 2013 08:44:12 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 759B421F89EF for ; Wed, 13 Feb 2013 08:44:12 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r1DGi8q9021580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 13 Feb 2013 17:44:08 +0100 (MET) In-Reply-To: To: Nico Williams Date: Wed, 13 Feb 2013 17:44:08 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130213164408.BD4A21A55E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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: Wed, 13 Feb 2013 16:44:13 -0000 Nico Williams wrote: [ Charset UTF-8 unsupported, converting... ] > On Wed, Feb 13, 2013 at 10:23 AM, Martin Rex wrote: > > Nico Williams wrote: > > [ Charset UTF-8 unsupported, converting... ] > > Really? That's kinda funny. It's 2013... > > >> On Wed, Feb 13, 2013 at 10:02 AM, Martin Rex wrote: > >> > Nico Williams wrote: > >> >> Martin Rex wrote: > >> >> I don't see how we can avoid adding new function calls. A req_flag > >> >> wouldn't help. And a new ret_flag does nothing to protect against > >> >> apps that don't understand it. > >> > > >> > You're misunderstanding the GSS-API architecture. > >> > The gssapi mechanism MUST NOT do that ("protect the application") > >> > >> I misunderstood nothing. The GSS-API *should* have had > >> GSS_C_CHANNEL_BOUND_FLAG, and if it had had that from day zero there > >> would be no question of "protect[ing] against apps that don't > >> understand [that flag]." But *now* we cannot add this flag and > >> otherwise retain the original channel binding behavior, implementing > >> both in existing implementations that implement the alternative > >> actually-deployed behavior -- doing so would break things. > > > > I believe that you can add it now. > > > > We can add it as a flag for both, input _and_ output. > > GSS_Accept_sec_context() has no flags inputs. In order to make the > originally-specified behavior safe, the acceptor-side of the > mechanisms need to know if the acceptor applications understand the > new flag. Ooops, you're right. I forgot about that. I'll think about it. -Martin From nico@cryptonector.com Wed Feb 13 08:44:22 2013 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 6452021F8A77 for ; Wed, 13 Feb 2013 08:44:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.616 X-Spam-Level: X-Spam-Status: No, score=-3.616 tagged_above=-999 required=5 tests=[AWL=-1.639, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ieCuLvgLj6R9 for ; Wed, 13 Feb 2013 08:44:16 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9727321F89D5 for ; Wed, 13 Feb 2013 08:44:16 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 66379B806D for ; Wed, 13 Feb 2013 08:43:57 -0800 (PST) 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=UEc8JhlxHrUH9XsZwhAQ HA5ZRzY=; b=aM/43M/vvHTyPb5r4tVWfFks4gydPqGNzW7piIiXUJpFg+nAMq1h Q82Bd7d/cgALZWHXbz6OrUC2pHeeWCro1O9bnBrPyzRZa0vNrW0vSasLBsUssoP3 36uioAceWyb4RpBJ4iFoS5YV5UXDb6b6aQrRZ3wu1vpQzd3TM0RvcAM= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 23F8DB8072 for ; Wed, 13 Feb 2013 08:43:50 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id 16so1108285wgi.15 for ; Wed, 13 Feb 2013 08:43:49 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.8.130 with SMTP id r2mr11389350wia.28.1360773829647; Wed, 13 Feb 2013 08:43:49 -0800 (PST) Received: by 10.217.39.133 with HTTP; Wed, 13 Feb 2013 08:43:49 -0800 (PST) In-Reply-To: References: <20130213162316.70DAD1A55D@ld9781.wdf.sap.corp> Date: Wed, 13 Feb 2013 10:43:49 -0600 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] We need a GSS_C_CHANNEL_BOUND_FLAG 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, 13 Feb 2013 16:44:22 -0000 I should also add that adding a new variant of GSS_Accept_sec_context() that takes req_flags sounds silly given the architecture of the API (namely that the application is to find out what features it got, and that it is the initiator's responsibility to request features needed by the application). I would, I suppose, settle for that, but we do have a long-term need for additional options, some of which cannot merely be flags, thus my interest in standardizing gss_set_cred_option(). My fear is that adding a variant of GSS_Accept_sec_context() will take us down a rabbit hole out of which we'll not get for a long time -- we'll have too much pressure to add other functionality and correct other base GSS-API flaws. Whereas adopting a widely deployed GSS extension from C implementations seems like a path that is likely to yield quick progress. Perhaps we should test consensus on this question of which approach to take to add this feature, but if we choose to go the new GSS_Accept_sec_context() variant then I'll want a commitment to not bikeshed it, otherwise I'll lose interest and move on to other problems. Nico -- From Josh.Howlett@ja.net Thu Feb 14 03:50:36 2013 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 51A4521F8799 for ; Thu, 14 Feb 2013 03:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjruqDIv7-+r for ; Thu, 14 Feb 2013 03:50:35 -0800 (PST) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 531CD21F878F for ; Thu, 14 Feb 2013 03:50:33 -0800 (PST) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 0011A20C7176_11CCF88B for ; Thu, 14 Feb 2013 11:50:31 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 0729C20C7145_11CCF87F for ; Thu, 14 Feb 2013 11:50:30 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Thu, 14 Feb 2013 11:50:30 +0000 From: Josh Howlett To: "kitten@ietf.org" Thread-Topic: Shepherding draft-ietf-krb-wg-pkinit-alg-agility Thread-Index: AQHOCql8PEBopdhdsUiE19nyCnqkvw== Date: Thu, 14 Feb 2013 11:50:29 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [kitten] Shepherding draft-ietf-krb-wg-pkinit-alg-agility 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, 14 Feb 2013 11:50:36 -0000 I'm picking up from Jeff in shepherding draft-ietf-krb-wg-pkinit-alg-agility. I've taken a look through the outstanding issues. My only substantial concern relates to the Kerberos error code 82 conflict: http://www.ietf.org/mail-archive/web/krb-wg/current/msg04016.html Sam claims that there shouldn't be a situation where an unknown well-known principal name is used in conjunction with PKINIT algorithm agility. Tom thinks this is possible, but unlikely. Greg has a preference to reassign the error code even though there is shipping code as (if I've understood him) the implications for deployers are likely to be modest. It's difficult to judge consensus from this, and so my proposal is that we reassign the error code. This may cause some short term pain for deployers, but avoid potential (if not necessarily likely) longer term consequences that could cause issues in the future. Please comment -- I would welcome feedback from deployers in particular. Thanks, Josh. Kitten WG co-chair Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From hartmans@mit.edu Thu Feb 14 04:30:02 2013 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 23CBD21F871D for ; Thu, 14 Feb 2013 04:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ToT2qL6PeNbk for ; Thu, 14 Feb 2013 04:30:01 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C074721F8533 for ; Thu, 14 Feb 2013 04:29:58 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 7A4B8201E2; Thu, 14 Feb 2013 07:25:31 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5435243FD; Thu, 14 Feb 2013 07:29:53 -0500 (EST) From: Sam Hartman To: Josh Howlett References: Date: Thu, 14 Feb 2013 07:29:53 -0500 In-Reply-To: (Josh Howlett's message of "Thu, 14 Feb 2013 11:50:29 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] Shepherding draft-ietf-krb-wg-pkinit-alg-agility 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, 14 Feb 2013 12:30:02 -0000 >>>>> "Josh" == Josh Howlett writes: Josh> Sam claims that there shouldn't be a situation where an Josh> unknown well-known principal name is used in conjunction with Josh> PKINIT algorithm agility. Tom thinks this is possible, but Josh> unlikely. Greg has a preference to reassign the error code Josh> even though there is shipping code as (if I've understood him) Josh> the implications for deployers are likely to be modest. Having evaluated the impact, I too have a preference to reassign the error code even given the deployed code. From stpeter@stpeter.im Thu Feb 14 08:07:04 2013 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 2F15721F8814 for ; Thu, 14 Feb 2013 08:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4cbqCrg75rFz for ; Thu, 14 Feb 2013 08:06:58 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E4B2421F8828 for ; Thu, 14 Feb 2013 08:06:57 -0800 (PST) Received: from [10.0.0.2] (unknown [24.9.182.250]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9824A4067B for ; Thu, 14 Feb 2013 09:13:58 -0700 (MST) Message-ID: <511D0B9C.7060102@stpeter.im> Date: Thu, 14 Feb 2013 09:06:52 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> In-Reply-To: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 16:07:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, we're still looking for feedback from the security / SASL community on this spec (which will obsolete RFC 4013). Thanks! Peter - -------- Original Message -------- Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.txt Date: Wed, 13 Feb 2013 20:24:43 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: precis@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Preparation and Comparison of Internationalized Strings Working Group of the IETF. Title : Preparation and Comparison of Internationalized Strings Representing Simple User Names and Passwords Author(s) : Peter Saint-Andre Alexey Melnikov Filename : draft-ietf-precis-saslprepbis-00.txt Pages : 12 Date : 2013-02-13 Abstract: This document describes how to handle Unicode strings representing simple user names and passwords, primarily for purposes of comparison. This profile is intended to be used by Simple Authentication and Security Layer (SASL) mechanisms (such as PLAIN and SCRAM-SHA-1), as well as other protocols that exchange simple user names or passwords. This document obsoletes RFC 4013. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ precis mailing list precis@ietf.org https://www.ietf.org/mailman/listinfo/precis -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHQucAAoJEOoGpJErxa2psGMQAI9tMnBRUfhcBZO1fcW/dYBn 7fhO2M9bjvRGga9OhUOqtJvP6d6TUMOXWdVZlf/cJvJ+OzaU58JyTZttuNqjihok 4JU/6WZ3wNjdsK8eGlWdzBOrVyDlyEynn3MinWPDmvzQmuO8aek4G6m8txvNKnE0 o26EhGjDk8Pb5Mz7pk/7ge6LyeI5lcXB//kw7Nv7TYT+NRrmRaP4zaBrbv+4LL1S lNnTQHSI52uii9XLiyEMZ6ygieqPu38AfOkYp13d/VOouK8IWGcYaACRiEc9GN2A bGzweg5Gl7taC2XR1cTXEYF0hy7xV+/0A6GqtiWOZBiM/ARKoWr05EFVeDpkrH/H sPP8fndG+G/Dv2suhtmHkDzGQiVsvzfZj2VIluwCkpDL2aoEVaO4mtvNLGP5sC27 aDLsmubBINyH8dYfJtaSpZZcQZas8rJ2a5G7HMtdlj5vrCd522ve151gkVT5jtmJ KMRjNTuQY84WxKvFeOErO8xuE38sQWT3nSeFbocMYX8c4uxIwdVHyucLVwhT57Il sMDyCkACyTkr++5dX9cXbUSFWIILadvSLCfBr14hdvITABA0XIMs24UDjqBwCDUE ejpxeUMuXEh08ELWpsgCZOM8EQALOKzMQvY8+EeI4JvIF5WJrPl5aUe4PhEzwDH6 fSVBx9JTy+ZBU96ouM48 =oF+B -----END PGP SIGNATURE----- From nico@cryptonector.com Thu Feb 14 09:30:00 2013 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 C95BA21F868F for ; Thu, 14 Feb 2013 09:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.633 X-Spam-Level: X-Spam-Status: No, score=-3.633 tagged_above=-999 required=5 tests=[AWL=-1.656, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uOKuNlvjtF2 for ; Thu, 14 Feb 2013 09:30:00 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id F41CC21F8600 for ; Thu, 14 Feb 2013 09:29:59 -0800 (PST) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 96FEA1F0083 for ; Thu, 14 Feb 2013 09:29:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=DZGm3tGnM08B35BiXqS9hnbcg2o=; b=WzKJm1b7JcZ rHKnbLR8pN+BBgHxFUwjf9xRU2HfQfhFMyNeOwYofiMBIV5IWGsDngiAMs6DNS+1 0AS1oB38Ras6y9+2kThPn3qoqw3sYOKTqi5sAR/+ZfbUjUdVkOCvSVcscvBds9zU qkjs317DYghzBVHnEpk4xKiFJt14J0eY= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 300E91F0081 for ; Thu, 14 Feb 2013 09:29:59 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id es5so2117078wgb.5 for ; Thu, 14 Feb 2013 09:29:57 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.79.201 with SMTP id l9mr837343wix.20.1360862997414; Thu, 14 Feb 2013 09:29:57 -0800 (PST) Received: by 10.217.39.133 with HTTP; Thu, 14 Feb 2013 09:29:57 -0800 (PST) Date: Thu, 14 Feb 2013 11:29:57 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: "Roland C. Dowdeswell" Subject: [kitten] New I-D: multiple round trips for the krb5 GSS mech: draft-williams-kitten-krb5-extra-rt 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, 14 Feb 2013 17:30:01 -0000 I've just submitted draft-williams-kitten-krb5-extra-rt-00, an I-D that proposes a multi-round trip extension to RFC4121. The motivations for this are various, but mainly the ability to recover from otherwise-fatal errors that lead to SSHv2 (when using gss-keyex) and other such connections to fail and clients having to reconnect. This I-D also adds user2user support to the Kerberos GSS mechanism. Finally! See forwarded e-mail below. (Yes, I know that I'm using '-' instead of '--' in the ASN.1 as comments. This is due to a missing feature in lyx2rfc, the remapping of em dash to two en dashes.) Nico ---------- Forwarded message ---------- From: Date: Thu, Feb 14, 2013 at 11:24 AM Subject: New Version Notification for draft-williams-kitten-krb5-extra-rt-00.txt To: nico@cryptonector.com Cc: elric@imrryr.org A new version of I-D, draft-williams-kitten-krb5-extra-rt-00.txt has been successfully submitted by Nicolas Williams and posted to the IETF repository. Filename: draft-williams-kitten-krb5-extra-rt Revision: 00 Title: Negotiation of Extra Round Trip for Kerberos V5 Generic Security Services Mechanism Creation date: 2013-02-14 Group: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-williams-kitten-krb5-extra-rt-00.txt Status: http://datatracker.ietf.org/doc/draft-williams-kitten-krb5-extra-rt Htmlized: http://tools.ietf.org/html/draft-williams-kitten-krb5-extra-rt-00 Abstract: This Internet-Draft proposes an extension to the Kerberos V5 security mechanism for the Generic Security Services Application Programming Interface (GSS-API) for using an extra pair of security context tokens in order to recover from certain errors. Other benefits include: user2user authentication, authenticated errors (in some cases), and more. The IETF Secretariat From chris.newman@oracle.com Thu Feb 14 11:37:41 2013 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 2BAEB21F85DF for ; Thu, 14 Feb 2013 11:37:41 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fev+vsF32YmT for ; Thu, 14 Feb 2013 11:37:40 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1BDE321F85DB for ; Thu, 14 Feb 2013 11:37:37 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1EJbZoJ027194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Feb 2013 19:37:36 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1EJbYuJ001359; Thu, 14 Feb 2013 19:37:35 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.97.193] (dhcp-amer-vpn-rmdc-anyconnect-10-159-97-193.vpn.oracle.com [10.159.97.193]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-28.16(7.0.5.28.0) 64bit (built Dec 16 2012)) with ESMTPA id <0MI800A516IK2300@gotmail.us.oracle.com>; Thu, 14 Feb 2013 11:37:34 -0800 (PST) Date: Thu, 14 Feb 2013 11:37:32 -0800 From: Chris Newman To: Peter Saint-Andre , kitten@ietf.org Message-id: <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> In-reply-to: <511D0B9C.7060102@stpeter.im> References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: Re: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 19:37:41 -0000 A common construction for user names on the Internet is the form "user@example.com", specifically, a subset of email-address syntax with an embedded domain name is commonly used for login identity strings (although theses login identity strings may or may not be usable as actual email addresses). As a result, the character class used for user names used for authentication needs to be a superset of the character class used for domain names. I was not able to tell from the specification if that was the case. If it isn't, I believe that should be fixed. Otherwise, this seems reasonable to me. - Chris --On February 14, 2013 9:06:52 -0700 Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Folks, we're still looking for feedback from the security / SASL > community on this spec (which will obsolete RFC 4013). > > Thanks! > > Peter > > > - -------- Original Message -------- > Subject: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.txt > Date: Wed, 13 Feb 2013 20:24:43 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > CC: precis@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Preparation and Comparison of > Internationalized Strings Working Group of the IETF. > > Title : Preparation and Comparison of Internationalized > Strings Representing Simple User Names and Passwords > Author(s) : Peter Saint-Andre > Alexey Melnikov > Filename : draft-ietf-precis-saslprepbis-00.txt > Pages : 12 > Date : 2013-02-13 > > Abstract: > This document describes how to handle Unicode strings representing > simple user names and passwords, primarily for purposes of > comparison. This profile is intended to be used by Simple > Authentication and Security Layer (SASL) mechanisms (such as PLAIN > and SCRAM-SHA-1), as well as other protocols that exchange simple > user names or passwords. This document obsoletes RFC 4013. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-precis-saslprepbis-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.18 (Darwin) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJRHQucAAoJEOoGpJErxa2psGMQAI9tMnBRUfhcBZO1fcW/dYBn > 7fhO2M9bjvRGga9OhUOqtJvP6d6TUMOXWdVZlf/cJvJ+OzaU58JyTZttuNqjihok > 4JU/6WZ3wNjdsK8eGlWdzBOrVyDlyEynn3MinWPDmvzQmuO8aek4G6m8txvNKnE0 > o26EhGjDk8Pb5Mz7pk/7ge6LyeI5lcXB//kw7Nv7TYT+NRrmRaP4zaBrbv+4LL1S > lNnTQHSI52uii9XLiyEMZ6ygieqPu38AfOkYp13d/VOouK8IWGcYaACRiEc9GN2A > bGzweg5Gl7taC2XR1cTXEYF0hy7xV+/0A6GqtiWOZBiM/ARKoWr05EFVeDpkrH/H > sPP8fndG+G/Dv2suhtmHkDzGQiVsvzfZj2VIluwCkpDL2aoEVaO4mtvNLGP5sC27 > aDLsmubBINyH8dYfJtaSpZZcQZas8rJ2a5G7HMtdlj5vrCd522ve151gkVT5jtmJ > KMRjNTuQY84WxKvFeOErO8xuE38sQWT3nSeFbocMYX8c4uxIwdVHyucLVwhT57Il > sMDyCkACyTkr++5dX9cXbUSFWIILadvSLCfBr14hdvITABA0XIMs24UDjqBwCDUE > ejpxeUMuXEh08ELWpsgCZOM8EQALOKzMQvY8+EeI4JvIF5WJrPl5aUe4PhEzwDH6 > fSVBx9JTy+ZBU96ouM48 > =oF+B > -----END PGP SIGNATURE----- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From stpeter@stpeter.im Thu Feb 14 13:12:53 2013 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 B039521F8878 for ; Thu, 14 Feb 2013 13:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRJzh8oz+xEx for ; Thu, 14 Feb 2013 13:12:51 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB3121F86DD for ; Thu, 14 Feb 2013 13:12:50 -0800 (PST) Received: from [10.0.0.2] (unknown [24.9.182.250]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1E1A240725; Thu, 14 Feb 2013 14:19:59 -0700 (MST) Message-ID: <511D5350.5000009@stpeter.im> Date: Thu, 14 Feb 2013 14:12:48 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Chris Newman References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> In-Reply-To: <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 21:12:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Chris, thank you for the review. On 2/14/13 12:37 PM, Chris Newman wrote: > A common construction for user names on the Internet is the form > "user@example.com", specifically, a subset of email-address syntax > with an embedded domain name is commonly used for login identity > strings (although theses login identity strings may or may not be > usable as actual email addresses). > > As a result, the character class used for user names used for > authentication needs to be a superset of the character class used > for domain names. I was not able to tell from the specification if > that was the case. If it isn't, I believe that should be fixed. It is the case, because all characters in the ASCII range are grandfathered into the PRECIS NameClass. Thus some examples are definitely in order! We'll add those to the next version. Peter -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHVNPAAoJEOoGpJErxa2pk7sP/RVaiEh4Yn5cURIPv5pmrk3G qtFLObajnwk7+r4QZGihtLDHp5u963HiK+ElXMyw+iepfvumrXr3XsLGk8k3Kbz1 cBrMrRSFxDGTNJUoPZQwM3sydbVzZ36OrRP5xfR6+r/EwHG/bCm1HqtAFztU4hqa Sb5KKxO5g8sY8xb4e/WYumifoKOdJJrg6j6JB0NdTWLvoeZ8TA4J2TvYt273IJ+I kyyRyqiasjF3xH/33xXzbB6NvetI9UaEFXHLnQepwRCa4WwRNaCGT9ETvczYz8rW gAYRbT/H2AoGSK2dM9yI5CHqtazkA95WYavPsQEz8duzkzvK4Oy0hNgEZjvjPV4J ce81SCwLA4yMVcXuZTu/T5l7qW1yNrCEGwFu+p9Vy/8KsOIYMZKx+bIJaGWhx3l/ Un26IfnnconoC/SBScxtFOJp3iJKGMYLv2cZEahdpnB8e/9OAu9fNkRTAtk66ZBI yRrtMn3cl5SCJxCqrnDMlZQBvNFUFVJCG1vyRjlJAtRYnGYXoN3qJNA3NdF21Qg7 FL+fa1AKAvph5lncTFZMsk7ayslm93WE7mgww8TsVGeipj2BJhTsQKxo41V+GtfT YWbrV5VRRVDDhl8pml1PnSqv6IHC/9/Rt0BYrnl9PML6CXNXRmvgtfDafBXLsG6m GlnMkY12Q05uKSx9sHnq =Rk59 -----END PGP SIGNATURE----- From stpeter@stpeter.im Thu Feb 14 13:24:36 2013 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 A377521F8534 for ; Thu, 14 Feb 2013 13:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROnXRROzD7Gd for ; Thu, 14 Feb 2013 13:24:30 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 067E621F8906 for ; Thu, 14 Feb 2013 13:24:26 -0800 (PST) Received: from [10.0.0.2] (unknown [24.9.182.250]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 546CF40725; Thu, 14 Feb 2013 14:31:29 -0700 (MST) Message-ID: <511D5601.4050509@stpeter.im> Date: Thu, 14 Feb 2013 14:24:17 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Chris Newman References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> In-Reply-To: <511D5350.5000009@stpeter.im> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 21:24:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/14/13 2:12 PM, Peter Saint-Andre wrote: > Hi Chris, thank you for the review. > > On 2/14/13 12:37 PM, Chris Newman wrote: >> A common construction for user names on the Internet is the form >> "user@example.com", specifically, a subset of email-address >> syntax with an embedded domain name is commonly used for login >> identity strings (although theses login identity strings may or >> may not be usable as actual email addresses). > >> As a result, the character class used for user names used for >> authentication needs to be a superset of the character class >> used for domain names. I was not able to tell from the >> specification if that was the case. If it isn't, I believe that >> should be fixed. > > It is the case, because all characters in the ASCII range are > grandfathered into the PRECIS NameClass. Thus some examples are > definitely in order! We'll add those to the next version. I propose adding the second paragraph shown below to the end of Section 2.1, which defines the handling of simple user names: Note well that all code points and blocks not explicitly allowed in the PRECIS NameClass are disallowed; this includes private use characters, surrogate code points, and the other code points and blocks defined as "Prohibited Output" in Section 2.3 of RFC 4013. However, all characters in the ASCII range are "grandfathered" into the PRECIS NameClass. As a result, common constructions such as "user@example.com" are allowed as simple user names when using software that conforms to this specification, as they were under [RFC4013]. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRHVYBAAoJEOoGpJErxa2pAI8P+wQOeNaJ3Gb6f6+TGu9mdkJf 01XNjARCypk4N/u5qekfZHVnp18PD71RT5sPqlPaBY4rUxgmRH6lnnIl6pPf6vFq 8Szih6ZYE5AqlMgCi9+RYTjJwwwr1HVNM/R8zqePawl/UTgLocUVVGORj5/W+v9U AaJGrjfeHJhuR/0q6WHBLnzVzRhKRPrIbF869ZYV+ojyIRmFoP8ZPKIxOEADAKql NGIGvy6vSXQioRvb/DDwczEsPm+qiTJSZDbX39/H1tLN3oW6buoIjYki4rWtPLRf 5lQjzARU4Lb0O3JrOuBRx+6POaPuUwq8sWzpD41usqFgIGTg1GU19aanVmHkSRHF qiQq686v+Eqg+l+F7SuzkHNGBeSiRzAaPm16bRovVTp1M7cM3nrxJFUTR9YegvL7 VTVcF6jvuo+UVc+gnQRESbyxP/brtCd5mmKqeTtAAz0cBfUIag4aMxT58l3rKX9K naw7I5biOi0mm8WOzPku+q3GSQ7e4YSl8B5RCSdkChuKvRZBCL2D4TyArCrtzm0X 7KVD/H0pLRBQuEM514ENnuPYoKY/3q4UIctd7CgUit+l3rM25EQol9KaX34bBxfr ih7MNkhfRbtivNjUi6jwPv7MJnd80GvjOJ30mlN+eShyc5eLVwwd25XKNWXZcmLM GfB5Z7+apEUape56etfS =zDY1 -----END PGP SIGNATURE----- From lukeh@padl.com Thu Feb 14 17:09:05 2013 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 4195621F8967 for ; Thu, 14 Feb 2013 17:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hug+d5FgerrJ for ; Thu, 14 Feb 2013 17:09:04 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id A966621F892D for ; Thu, 14 Feb 2013 17:09:04 -0800 (PST) Received: by us.padl.com with ESMTP id r1F18t1L010043; Thu, 14 Feb 2013 20:08:58 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: Date: Fri, 15 Feb 2013 12:08:55 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nico Williams X-Mailer: Apple Mail (2.1499) 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, "Roland C. Dowdeswell" Subject: Re: [kitten] New I-D: multiple round trips for the krb5 GSS mech: draft-williams-kitten-krb5-extra-rt 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, 15 Feb 2013 01:09:05 -0000 * Presumably all tokens have the pseudo-ASN.1 wrapping, not just the new = initiator token? * Why feature negotiation in both AD and AP options? -- Luke= From nico@cryptonector.com Thu Feb 14 17:41:04 2013 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 ECA0A21F845F for ; Thu, 14 Feb 2013 17:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[AWL=-1.672, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWEzZUYHSL89 for ; Thu, 14 Feb 2013 17:41:04 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 794E421F845E for ; Thu, 14 Feb 2013 17:41:04 -0800 (PST) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 0A96B1DE059 for ; Thu, 14 Feb 2013 17:41:04 -0800 (PST) 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=BrOxqOawX1mvj/6HP8QS EbZOvM8=; b=mNSgO+D/fkiTJwvBiQ8uoJ3WIRjqo3e39G5RKB45rm1uI+b8NzAF Ssy4gEYOa9r3XctW6Reaqd2szy+wqEJmY6rEfElqBzrBGROVelwctBrkzZ+0DW0+ Rmd6forgI+JEn/+5bZyztFCNNUKEKLcpc3QAoU7020VHteaZpnN9m4g= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id B19F71DE058 for ; Thu, 14 Feb 2013 17:41:03 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so2424947wer.36 for ; Thu, 14 Feb 2013 17:41:02 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.103.163 with SMTP id fx3mr1035286wjb.58.1360892462038; Thu, 14 Feb 2013 17:41:02 -0800 (PST) Received: by 10.217.39.133 with HTTP; Thu, 14 Feb 2013 17:41:01 -0800 (PST) In-Reply-To: References: Date: Thu, 14 Feb 2013 19:41:01 -0600 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, "Roland C. Dowdeswell" Subject: Re: [kitten] New I-D: multiple round trips for the krb5 GSS mech: draft-williams-kitten-krb5-extra-rt 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, 15 Feb 2013 01:41:05 -0000 On Thu, Feb 14, 2013 at 7:08 PM, Luke Howard wrote: > * Presumably all tokens have the pseudo-ASN.1 wrapping, not just the new initiator token? Yes (since RFC4121 mandates that). > * Why feature negotiation in both AD and AP options? Err, no real reason. Indeed, I think I can remove the AD for that. From nico@cryptonector.com Fri Feb 15 13:50:47 2013 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 91FB021F857A for ; Fri, 15 Feb 2013 13:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.752 X-Spam-Level: X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[AWL=-1.775, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOLNku9FxkY7 for ; Fri, 15 Feb 2013 13:50:46 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 98A1021F8467 for ; Fri, 15 Feb 2013 13:50:46 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 5B1982C806D for ; Fri, 15 Feb 2013 13:50:46 -0800 (PST) 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=Ztf9KQAnrQZ+9/HH/8+9 YTF4M50=; b=CbgM3iCFUVtD2tu5TLd5WXu4oGAqkbGSC/UwkHmgOQz+xjx44B7w SGZDhn/rdei+j/Unk3aGvcbBeiJCZE+5wOt2T8V04aaCaqCLkWNERdMKW6q7Aeh0 C9sIiiVO3gRMr54MbZrz2MgpYNyquVM1u0XPKwHcuVhrZ2kXtL1cWYE= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 083E62C8058 for ; Fri, 15 Feb 2013 13:50:45 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so1681532wib.15 for ; Fri, 15 Feb 2013 13:50:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.99.227 with SMTP id et3mr6888001wib.6.1360965044714; Fri, 15 Feb 2013 13:50:44 -0800 (PST) Received: by 10.217.39.133 with HTTP; Fri, 15 Feb 2013 13:50:44 -0800 (PST) In-Reply-To: References: Date: Fri, 15 Feb 2013 15:50:44 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: "Roland C. Dowdeswell" Subject: Re: [kitten] New I-D: multiple round trips for the krb5 GSS mech: draft-williams-kitten-krb5-extra-rt 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, 15 Feb 2013 21:50:47 -0000 Someone asked me, on IM I think, what's the difference between this and DC style. There are only two consequential differences: 1. DCE style is chosen by the initiator alone -the acceptor gets no say in the matter- while this extension is at the acceptor's choice. (see below though) 2. This extension allows for arbitrary round trips (though implementations should impose a reasonable limit), and is generic enough that it allows for various features that require more than one round-trip: error recovery, replay cache avoidance, and user-to-user authentication. If we ever build a PFS extension we can even have the acceptor issue a fast reauthentication ticket for itself that the initiator can use to re-authenticate quickly while retaining forward security from the initial authentication exchange with PFS. And all of this with the same mechanism OID! #1 means that DCE style can only be used when the initiator has reason to believe that the acceptor supports it, whereas this extension is optional and the acceptor is free to use it or not. This also means that no req_flag (nor ret_flag, nor flag in the 0x8003 structure) is needed -- you either get one round-trip or more, and at the acceptor mechanism's choice, transparent to the application. Mind you, apps that request DCE style could be compatible with acceptors that don't support it because the latter will respond with an AP-REP with the pseudo-ASN.1 header, and that distinguishes the response token from a DCE style response token. There's other lesser differences, like that the pseudo-ASN.1 header is always present in all the security context tokens in my proposal (as RFC4121 wants it). There is one important issue though: if there's another GSS mechanism (with different mech OID, of course) for doing user-to-user (and there is) then negotiation in the KDC_ERR_MUST_USE_USER2USER case could result in failure where without this new feature it could have resulted in success. We can address this via configuration, or by disallowing user-to-user in the KDC_ERR_MUST_USE_USER2USER case (the acceptor could still ask for u2u though). Nico -- From nico@cryptonector.com Fri Feb 15 14:13:47 2013 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 59D6F21E804E for ; Fri, 15 Feb 2013 14:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.612 X-Spam-Level: X-Spam-Status: No, score=-3.612 tagged_above=-999 required=5 tests=[AWL=-1.635, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JG4lNW4X51EL for ; Fri, 15 Feb 2013 14:13:46 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id D8C4721E8043 for ; Fri, 15 Feb 2013 14:13:46 -0800 (PST) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id A8C08678069 for ; Fri, 15 Feb 2013 14:13:46 -0800 (PST) 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=e2XkuhW4usi9KfWrNJek ITqTfXI=; b=qOntYcKqRZczB9zfjI/7Mvr4z+Pko3TW/HGndg6bf2dPGh28iarZ 4S9qL6L2vhMYi6sf9FYvTyTuVE6RYtt5qsvtJTGnr8hG1xpzppIm6x0pXUpWQfjC PMTrV8SReb/1dHN15/0UsBgcTKhldR2UOTeX4/g99YDXpbFg3lf1HmQ= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (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 5C0E4678063 for ; Fri, 15 Feb 2013 14:13:46 -0800 (PST) Received: by mail-we0-f169.google.com with SMTP id t11so3321439wey.14 for ; Fri, 15 Feb 2013 14:13:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.97.166 with SMTP id eb6mr8626461wib.20.1360966424834; Fri, 15 Feb 2013 14:13:44 -0800 (PST) Received: by 10.217.39.133 with HTTP; Fri, 15 Feb 2013 14:13:44 -0800 (PST) In-Reply-To: References: Date: Fri, 15 Feb 2013 16:13:44 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: "Roland C. Dowdeswell" Subject: Re: [kitten] New I-D: multiple round trips for the krb5 GSS mech: draft-williams-kitten-krb5-extra-rt 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, 15 Feb 2013 22:13:47 -0000 I've posted a -01. From mpeck@mitre.org Mon Feb 18 06:19:48 2013 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 1FB5821F88F0 for ; Mon, 18 Feb 2013 06:19:48 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mflu9X+FVaHk for ; Mon, 18 Feb 2013 06:19:47 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 06E4F21F87F9 for ; Mon, 18 Feb 2013 06:19:47 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 658A25310B93; Mon, 18 Feb 2013 09:19:46 -0500 (EST) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 45C9E5310B37; Mon, 18 Feb 2013 09:19:46 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.200]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 09:19:46 -0500 From: "Peck, Michael A" To: Kelley Burgin , Nico Williams Thread-Topic: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2. Thread-Index: AQHOCgLkrvKeEFzPmEWJkr3+xjfNiZh4Tf6AgAdhlNA= Date: Mon, 18 Feb 2013 14:19:44 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321E78B576@IMCMBX04.MITRE.ORG> References: <48EB54C1-F693-492B-AFFD-F77FAD8211B4@kth.se> <5F3F1B73-646C-45F9-9804-942815023F69@tycho.ncsc.mil> In-Reply-To: <5F3F1B73-646C-45F9-9804-942815023F69@tycho.ncsc.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2. 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, 18 Feb 2013 14:19:48 -0000 In the draft, rather than call it "CTS mode", we refer to it as "CBC mode w= ith ciphertext stealing" or the "CBC-CS3 variant to CBC mode" as defined by= the NIST SP 800-38A Addendum. I'm thinking we want to revise the draft to clarify that we do mean the sam= e CTS mode used by the other Kerberos enctypes, but while pointing to CBC-C= S3 defined by the NIST SP 800-38A Addendum as the normative reference for t= he mode. Any comments on that or the rest of the draft would be terrific. Thanks, Mike=20 >-----Original Message----- >From: Kelley Burgin [mailto:kwburgi@tycho.ncsc.mil] >Sent: Wednesday, February 13, 2013 11:28 AM >To: Nico Williams >Cc: Love H=F6rnquist =C5strand; Sam Hartman; kitten@ietf.org; Peck, Michae= l A >Subject: Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hm= ac- >sha2. > >These enctypes are to support draft-burgin-kerberos-suiteb, so the >move from SHA-1 was the major motivation. We switched to CTS in -02 >after the discussion on DCE/MS-RPC a year or two ago. The other major >difference is we mac the ciphertext instead of the plaintext. > >I didn't intend for the draft to be incomplete in the switch to CTS >and would certainly appreciate more detailed comments on revisions >needed. > >Kelley > >On Feb 13, 2013, at 10:57 AM, Nico Williams wrote: > >> On Wed, Feb 13, 2013 at 9:22 AM, Love H=F6rnquist =C5strand >> wrote: >>> This dradt uses cbc. Is the considerations that made us use cts >>> mode/padding no longer important (dce/ms-rpc) ? >> >> The -02 seems to have switched to CTS, but the edits for that change >> are incomplete. >> >> I assume that a -03 will complete the switch to CTS. >> >> No motivation is given for the new enctypes, but I assume it's the >> obvious motivation: to move away from SHA-1. >> >> As for CBC vs. CTS, we really want CTS for reasons having to do with >> the SSPI -- we want the only ciphertext expansion to be of static size >> and to result from a) the use of a confounder (this is done in >> RFC3961, so this I-D needn't mention confounders any more than >> RFC3962), and b) the authentication tag (the MAC). >> >> CTS does have its problems, namely that it's hard to implement in >> terms of CBC: it's difficult to implement CTS using cryptographic >> coprocessors. The best one can do is use two (and sometimes three) >> AES-CBC cryptographic coprocessor operations The AES-NI instructions >> make this less of a concern. >> >> Nico >> -- From hartmans@mit.edu Mon Feb 18 07:13:51 2013 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 C970521F8BD7 for ; Mon, 18 Feb 2013 07:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.849 X-Spam-Level: X-Spam-Status: No, score=-102.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xC5IuRnpzC3f for ; Mon, 18 Feb 2013 07:13:51 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7013B21F86CE for ; Mon, 18 Feb 2013 07:13:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 4111020183; Mon, 18 Feb 2013 10:09:01 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A5E8C43FD; Mon, 18 Feb 2013 10:13:32 -0500 (EST) From: Sam Hartman To: "Peck\, Michael A" References: <48EB54C1-F693-492B-AFFD-F77FAD8211B4@kth.se> <5F3F1B73-646C-45F9-9804-942815023F69@tycho.ncsc.mil> <8B4C063947CD794BB6FF90C78BAE9B321E78B576@IMCMBX04.MITRE.ORG> Date: Mon, 18 Feb 2013 10:13:32 -0500 In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321E78B576@IMCMBX04.MITRE.ORG> (Michael A. Peck's message of "Mon, 18 Feb 2013 14:19:44 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Sam Hartman , Kelley Burgin Subject: Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2. 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, 18 Feb 2013 15:13:52 -0000 >>>>> "Peck," == Peck, Michael A writes: Peck,> In the draft, rather than call it "CTS mode", we refer to it Peck,> as "CBC mode with ciphertext stealing" or the "CBC-CS3 Peck,> variant to CBC mode" as defined by the NIST SP 800-38A Peck,> Addendum. I'm thinking we want to revise the draft to Peck,> clarify that we do mean the same CTS mode used by the other Peck,> Kerberos enctypes, but while pointing to CBC-CS3 defined by Peck,> the NIST SP 800-38A Addendum as the normative reference for Peck,> the mode. Any comments on that or the rest of the draft Peck,> would be terrific. Note that I think people are more concerned about avoiding ciphertext expansion than which CTS mode you mean. It's find to clarify as you propose. However, I think for this community the important clarifications are to the areas Nico called out. From Josh.Howlett@ja.net Mon Feb 18 08:38:10 2013 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 C494721F8BE0 for ; Mon, 18 Feb 2013 08:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.289 X-Spam-Level: X-Spam-Status: No, score=-102.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8aGeN5lqkRlP for ; Mon, 18 Feb 2013 08:38:10 -0800 (PST) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id 25F6421F8AD4 for ; Mon, 18 Feb 2013 08:37:58 -0800 (PST) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 1019520C7268_12258E4B for ; Mon, 18 Feb 2013 16:37:56 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id DB24520C70FD_12258E3F for ; Mon, 18 Feb 2013 16:37:55 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Mon, 18 Feb 2013 16:37:55 +0000 From: Josh Howlett To: "kitten@ietf.org" Thread-Topic: [kitten] Shepherding draft-ietf-krb-wg-pkinit-alg-agility Thread-Index: AQHOCql8PEBopdhdsUiE19nyCnqkv5h5SLrCgAaOhIA= Date: Mon, 18 Feb 2013 16:37:55 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.0.121105 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [kitten] Shepherding draft-ietf-krb-wg-pkinit-alg-agility 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, 18 Feb 2013 16:38:11 -0000 >>>>>> "Josh" =3D=3D Josh Howlett writes: > > > Josh> Sam claims that there shouldn't be a situation where an > Josh> unknown well-known principal name is used in conjunction with > Josh> PKINIT algorithm agility. Tom thinks this is possible, but > Josh> unlikely. Greg has a preference to reassign the error code > Josh> even though there is shipping code as (if I've understood him) > Josh> the implications for deployers are likely to be modest. > > >Having evaluated the impact, I too have a preference to reassign the >error code even given the deployed code. Ok -- it sounds as though a rewrite is needed to fix that. There were a few other out-standing issues: * Jeff suggested that the RFC3766 and RFC6194 references should be informative. I agree. * Jeff suggested that an informative reference to the MD4 spec might be useful. I see no harm in adding this reference, but I am satisfied that the existing reference to RFC6150 meets the need if the authors would prefer to stay with that. * The OID id-pkinit-kdc has been assigned, but not defined in the module in Appendix A. In principle I'm happy with this, but I think Tom sounded a note of caution so I'd like to flag this again. Please pipe up if you have a concern here. Josh. -- IETF Kitten WG co-chair Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20 not-for-profit company which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238 From chris.newman@oracle.com Mon Feb 18 10:04:07 2013 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 251AB21F8A51 for ; Mon, 18 Feb 2013 10:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY3M6Vwruoua for ; Mon, 18 Feb 2013 10:04:06 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8766321F8890 for ; Mon, 18 Feb 2013 10:04:06 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1II42II022141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Feb 2013 18:04:03 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1II42Tr011969; Mon, 18 Feb 2013 18:04:02 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.97.193] (nifty-silver.us.oracle.com [10.145.239.205]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-28.16(7.0.5.28.0) 64bit (built Dec 16 2012)) with ESMTPA id <0MIF00B4FGUOB200@gotmail.us.oracle.com>; Mon, 18 Feb 2013 10:04:01 -0800 (PST) Date: Mon, 18 Feb 2013 10:04:03 -0800 From: Chris Newman To: Peter Saint-Andre Message-id: <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> In-reply-to: <511D5601.4050509@stpeter.im> References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: kitten@ietf.org Subject: Re: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 18:04:07 -0000 --On February 14, 2013 14:24:17 -0700 Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 2/14/13 2:12 PM, Peter Saint-Andre wrote: >> Hi Chris, thank you for the review. >> >> On 2/14/13 12:37 PM, Chris Newman wrote: >>> A common construction for user names on the Internet is the form >>> "user@example.com", specifically, a subset of email-address >>> syntax with an embedded domain name is commonly used for login >>> identity strings (although theses login identity strings may or >>> may not be usable as actual email addresses). >> >>> As a result, the character class used for user names used for >>> authentication needs to be a superset of the character class >>> used for domain names. I was not able to tell from the >>> specification if that was the case. If it isn't, I believe that >>> should be fixed. >> >> It is the case, because all characters in the ASCII range are >> grandfathered into the PRECIS NameClass. Thus some examples are >> definitely in order! We'll add those to the next version. > > I propose adding the second paragraph shown below to the end of > Section 2.1, which defines the handling of simple user names: > > Note well that all code points and blocks not explicitly allowed in > the PRECIS NameClass are disallowed; this includes private use > characters, surrogate code points, and the other code points and > blocks defined as "Prohibited Output" in Section 2.3 of RFC 4013. > > However, all characters in the ASCII range are "grandfathered" into > the PRECIS NameClass. As a result, common constructions such as > "user@example.com" are allowed as simple user names when using > software that conforms to this specification, as they were under > [RFC4013]. I don't see this as a necessary addition. It was quite clear from the specifications that the ASCII range was grandfathered in NameClass. It appears I was unclear in stating my concern, let me try again to explain my concern. My concern is that login identities should be able to contain a valid IDNA U-label. It is not clear to me if NameClass permits all valid U-labels. If it does not, then I believe using NameClass for login identities is a mistake. The user@exmaple.com form for login identities will continue to be useful as the infrastructure is expanded to allow UTF-8 characters in both the "user" part and the "example.com" part of that form. If we disallow valid U-labels in login identities then we break the multi-domain model for lots of software out there and will force that software to change its architecture when it adopts this technology or to choose not to adopt this technology. If valid IDNA U-labels are permitted in login identities then implementers can keep their current architecture and adopt saslprepbis. - Chris From mpeck@mitre.org Mon Feb 18 12:42:32 2013 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 097E121F8AFE for ; Mon, 18 Feb 2013 12:42:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dg3+eHHc-bOZ for ; Mon, 18 Feb 2013 12:42:31 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 605AD21F8835 for ; Mon, 18 Feb 2013 12:42:31 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C9B8F5310BF8; Mon, 18 Feb 2013 15:42:30 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id B15295310AA3; Mon, 18 Feb 2013 15:42:30 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.200]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Mon, 18 Feb 2013 15:42:30 -0500 From: "Peck, Michael A" To: Sam Hartman , Nico Williams Thread-Topic: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2. Thread-Index: AQHODeqDrvKeEFzPmEWJkr3+xjfNiZh/9y1A Date: Mon, 18 Feb 2013 20:42:30 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321E78BAA5@IMCMBX04.MITRE.ORG> References: <48EB54C1-F693-492B-AFFD-F77FAD8211B4@kth.se> <5F3F1B73-646C-45F9-9804-942815023F69@tycho.ncsc.mil> <8B4C063947CD794BB6FF90C78BAE9B321E78B576@IMCMBX04.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" , Kelley Burgin Subject: Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hmac-sha2. 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, 18 Feb 2013 20:42:32 -0000 Thanks. Nico, do you currently see any other necessary clarifications besi= des making it clear that we are using CTS aka CBC-CS3? Currently the ciphertext expansion is of static size. The final ciphertext length is the length of the IV (128 bits) + the length= of the plaintext + the length of the MAC (either 128 bits or 192 bits depe= nding on the enctype). We can make that clear in the draft. Also unlike RFC3961 the MAC is computed over the IV and ciphertext rather t= han over the plaintext. Mike >-----Original Message----- >From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >Sent: Monday, February 18, 2013 10:14 AM >To: Peck, Michael A >Cc: Kelley Burgin; Nico Williams; Love H=F6rnquist =C5strand; Sam Hartman; >kitten@ietf.org >Subject: Re: [kitten] Call for Adoption: draft-burgin-kerberos-aes-cbc- hm= ac- >sha2. > >>>>>> "Peck," =3D=3D Peck, Michael A writes: > > Peck,> In the draft, rather than call it "CTS mode", we refer to it > Peck,> as "CBC mode with ciphertext stealing" or the "CBC-CS3 > Peck,> variant to CBC mode" as defined by the NIST SP 800-38A > Peck,> Addendum. I'm thinking we want to revise the draft to > Peck,> clarify that we do mean the same CTS mode used by the other > Peck,> Kerberos enctypes, but while pointing to CBC-CS3 defined by > Peck,> the NIST SP 800-38A Addendum as the normative reference for > Peck,> the mode. Any comments on that or the rest of the draft > Peck,> would be terrific. > > >Note that I think people are more concerned about avoiding ciphertext >expansion than which CTS mode you mean. It's find to clarify as you >propose. However, I think for this community the important >clarifications are to the areas Nico called out. From stpeter@stpeter.im Mon Feb 18 13:20:34 2013 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 36B5B21F8C86; Mon, 18 Feb 2013 13:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvCYMBVP4wiW; Mon, 18 Feb 2013 13:20:33 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id EBF3721F8C84; Mon, 18 Feb 2013 13:20:29 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7ACC4403CD; Mon, 18 Feb 2013 14:27:51 -0700 (MST) Message-ID: <51229B19.1080703@stpeter.im> Date: Mon, 18 Feb 2013 14:20:25 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Chris Newman References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> In-Reply-To: <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, "precis@ietf.org" Subject: Re: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 21:20:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [ + precis@ietf.org ] On 2/18/13 11:04 AM, Chris Newman wrote: > --On February 14, 2013 14:24:17 -0700 Peter Saint-Andre > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 2/14/13 2:12 PM, Peter Saint-Andre wrote: >>> Hi Chris, thank you for the review. >>> >>> On 2/14/13 12:37 PM, Chris Newman wrote: >>>> A common construction for user names on the Internet is the >>>> form "user@example.com", specifically, a subset of >>>> email-address syntax with an embedded domain name is commonly >>>> used for login identity strings (although theses login >>>> identity strings may or may not be usable as actual email >>>> addresses). >>> >>>> As a result, the character class used for user names used >>>> for authentication needs to be a superset of the character >>>> class used for domain names. I was not able to tell from the >>>> specification if that was the case. If it isn't, I believe >>>> that should be fixed. >>> >>> It is the case, because all characters in the ASCII range are >>> grandfathered into the PRECIS NameClass. Thus some examples >>> are definitely in order! We'll add those to the next version. >> >> I propose adding the second paragraph shown below to the end of >> Section 2.1, which defines the handling of simple user names: >> >> Note well that all code points and blocks not explicitly allowed >> in the PRECIS NameClass are disallowed; this includes private >> use characters, surrogate code points, and the other code points >> and blocks defined as "Prohibited Output" in Section 2.3 of RFC >> 4013. >> >> However, all characters in the ASCII range are "grandfathered" >> into the PRECIS NameClass. As a result, common constructions >> such as "user@example.com" are allowed as simple user names when >> using software that conforms to this specification, as they were >> under [RFC4013]. > > I don't see this as a necessary addition. It was quite clear from > the specifications that the ASCII range was grandfathered in > NameClass. It appears I was unclear in stating my concern, let me > try again to explain my concern. Yes, I did misconstrue your question. > My concern is that login identities should be able to contain a > valid IDNA U-label. It is not clear to me if NameClass permits all > valid U-labels. If it does not, then I believe using NameClass for > login identities is a mistake. The user@exmaple.com form for login > identities will continue to be useful as the infrastructure is > expanded to allow UTF-8 characters in both the "user" part and the > "example.com" part of that form. If we disallow valid U-labels in > login identities then we break the multi-domain model for lots of > software out there and will force that software to change its > architecture when it adopts this technology or to choose not to > adopt this technology. If valid IDNA U-labels are permitted in > login identities then implementers can keep their current > architecture and adopt saslprepbis. Ah, I see. You raise a good question. The intent was that any code point allowed in IDNs would be allowed in the PRECIS NameClass, but looking closely at draft-ietf-precis-framework I realize that the intent might not be reflected in the spec right now. I will investigate further and post again when I have something definitive to report. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIpsYAAoJEOoGpJErxa2pUXsP/iwzE9yQtKkn0aeVaccNneVn xDNeWfXGjfdcKE9K5nqyQgH5WTVX180RMZ9p4TZk8C0E4k7o+8PxPZF2ua/Sth+w 4hg8DMGn0zPvoiQoL4gklMXxKZn5ADU5iMP6KTcdSnCXjZkHPezbZ7Q2CQDe3u5j pxQnR6rw6jL/jcUbDucvSMJ0mJKtoHMgG7LTxlmC3jhWZ+SZyUdk38HpDC1e71b3 LdnS77OgUEJdDkDoCdj89ByDNefVeC2FkD6a/MbnLr9TbcMNzGNtwX0dM4x5sTIB GUywXzzmwU409tf7xlurC5wcBtffFL8lhbkYziv0X2C5RHZ5waevrHG9Tkzl7f2F 0Vs8QgtwZqlCvR+9ByJzmT1FW966cOUGQaYahNLjNtzUzzgZ4Oyvfdw6g5NxxM3V jTBqW8YF/QOF2ZYYfwpw99Mc5hPuNzs6l65g8Q8R394+JmCtyh5MY5ycgmpykrIN qAMzCefbz0PnP1gwTsOyQG31JsmSXTu4FwB5rfCFZJqKgnvXFHUrDyuh/AbW/su0 RmlA5WOBhem1b2MgbttWD8sxNvWbkVhlRsOQZymZaJFeejlyCV2MTQIWvy4Q6G7g I2aSLpMSp01wNGDRTxMmloFg8tsWDyxUjaz8AE7BFCpPGjDAddzuuIYlPFVubD4A Z/e5nXrXsqAwOjIUQYai =I/k2 -----END PGP SIGNATURE----- From tlyu@mit.edu Mon Feb 18 15:41:00 2013 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 8245F21F8CED for ; Mon, 18 Feb 2013 15:41:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsnAyi0Ek5ql for ; Mon, 18 Feb 2013 15:40:59 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by ietfa.amsl.com (Postfix) with ESMTP id A103421F8CEC for ; Mon, 18 Feb 2013 15:40:58 -0800 (PST) X-AuditID: 12074423-b7f5b6d000007e03-5c-5122bc09ec43 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id DA.1B.32259.90CB2215; Mon, 18 Feb 2013 18:40:57 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r1INeve1019668 for ; Mon, 18 Feb 2013 18:40:57 -0500 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r1INeua1022262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 18 Feb 2013 18:40:57 -0500 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r1INetRF022850; Mon, 18 Feb 2013 18:40:55 -0500 (EST) To: kitten@ietf.org From: Tom Yu Date: Mon, 18 Feb 2013 18:40:55 -0500 Message-ID: Lines: 36 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUixCmqrMu5RynQ4Mg6HYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro/HRctaCf1wVs35sYG9gPMXRxcjJISFgIjF37jRGCFtM4sK9 9WxdjFwcQgL7GCXmPF/PDuEcZ5T4NfMqE4TzhEniy72jjBBOF6PEgnmHWED6RQSEJXZvfccM YgsL2Es86dsJVMTBwSYgLXF0cRlImEVAVWL5sQ6wcl4BC4nD3/pZQWweAU6J75+vQ8UFJU7O fAJmMwtoSdz495JpAiPfLCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6eVmluil ppRuYgSFE7uL8g7GPweVDjEKcDAq8fB+cFQKFGJNLCuuzD3EKMnBpCTKe34nUIgvKT+lMiOx OCO+qDQntfgQowQHs5IIb0c7UI43JbGyKrUoHyYlzcGiJM57LeWmv5BAemJJanZqakFqEUxW hoNDSYL33C6gRsGi1PTUirTMnBKENBMHJ8hwHqDhR0BqeIsLEnOLM9Mh8qcYFaXEeetAEgIg iYzSPLheWLy/YhQHekWY9y5IFQ8wVcB1vwIazAQ0eNVdRZDBJYkIKakGxpkcgTflvllrnDj/ bcmBvZ/vf9bZesfgfH0M5/3z356dabsye1X6mklh/el/tspLO1g7Cc5p/9m1S5+vpXhBgoFs /t+oNC7DHyaNYrdLbnDeTp/uufBqpJZ8ybdfK+bzhYefeyT3J1o6RJDtpS3LNx1r9xn2cscc LEKUCpIFz/7XW3vNJU+qT4mlOCPRUIu5qDgRAJJb667SAgAA Subject: [kitten] submitted draft-yu-kitten-kerberos-kdc-does-aliases-00 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, 18 Feb 2013 23:41:00 -0000 I've submitted this document as one component of the effort to remove dependence on insecure DNS for canonicalizing hostnames in service principal names. I would like the Working Group to consider it for adoption. From: internet-drafts@ietf.org Subject: New Version Notification for draft-yu-kitten-kerberos-kdc-does-aliases-00.txt To: tlyu@mit.edu Date: Mon, 18 Feb 2013 15:21:29 -0800 A new version of I-D, draft-yu-kitten-kerberos-kdc-does-aliases-00.txt has been successfully submitted by Tom Yu and posted to the IETF repository. Filename: draft-yu-kitten-kerberos-kdc-does-aliases Revision: 00 Title: Kerberos Ticket flag indicating KDC support for resolving hostname aliases Creation date: 2013-02-18 Group: Individual Submission Number of pages: 5 URL: http://www.ietf.org/internet-drafts/draft-yu-kitten-kerberos-kdc-does-aliases-00.txt Status: http://datatracker.ietf.org/doc/draft-yu-kitten-kerberos-kdc-does-aliases Htmlized: http://tools.ietf.org/html/draft-yu-kitten-kerberos-kdc-does-aliases-00 Abstract: This document specifies a Kerberos Ticket flag that indicates that the Key Distribution Center (KDC) can resolve hostname aliases in service principal names. This document updates RFC 4120. The IETF Secretariat From stpeter@stpeter.im Mon Feb 18 21:05:41 2013 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 77C0021F8DC3; Mon, 18 Feb 2013 21:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.283 X-Spam-Level: X-Spam-Status: No, score=-103.283 tagged_above=-999 required=5 tests=[AWL=0.716, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yb9p9dz75BIy; Mon, 18 Feb 2013 21:05:40 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C241121F8DB9; Mon, 18 Feb 2013 21:05:38 -0800 (PST) Received: from [192.168.1.3] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5C694403CD; Mon, 18 Feb 2013 22:13:01 -0700 (MST) Message-ID: <51230821.8080904@stpeter.im> Date: Mon, 18 Feb 2013 22:05:37 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Chris Newman References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> <51229B19.1080703@stpeter.im> In-Reply-To: <51229B19.1080703@stpeter.im> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, "precis@ietf.org" Subject: Re: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.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: Tue, 19 Feb 2013 05:05:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/18/13 2:20 PM, Peter Saint-Andre wrote: > [ + precis@ietf.org ] > > On 2/18/13 11:04 AM, Chris Newman wrote: >> --On February 14, 2013 14:24:17 -0700 Peter Saint-Andre >> wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> >>> On 2/14/13 2:12 PM, Peter Saint-Andre wrote: >>>> Hi Chris, thank you for the review. >>>> >>>> On 2/14/13 12:37 PM, Chris Newman wrote: >>>>> A common construction for user names on the Internet is >>>>> the form "user@example.com", specifically, a subset of >>>>> email-address syntax with an embedded domain name is >>>>> commonly used for login identity strings (although theses >>>>> login identity strings may or may not be usable as actual >>>>> email addresses). >>>> >>>>> As a result, the character class used for user names used >>>>> for authentication needs to be a superset of the character >>>>> class used for domain names. I was not able to tell from >>>>> the specification if that was the case. If it isn't, I >>>>> believe that should be fixed. >>>> >>>> It is the case, because all characters in the ASCII range are >>>> grandfathered into the PRECIS NameClass. Thus some examples >>>> are definitely in order! We'll add those to the next >>>> version. >>> >>> I propose adding the second paragraph shown below to the end of >>> Section 2.1, which defines the handling of simple user names: >>> >>> Note well that all code points and blocks not explicitly >>> allowed in the PRECIS NameClass are disallowed; this includes >>> private use characters, surrogate code points, and the other >>> code points and blocks defined as "Prohibited Output" in >>> Section 2.3 of RFC 4013. >>> >>> However, all characters in the ASCII range are "grandfathered" >>> into the PRECIS NameClass. As a result, common constructions >>> such as "user@example.com" are allowed as simple user names >>> when using software that conforms to this specification, as >>> they were under [RFC4013]. > >> I don't see this as a necessary addition. It was quite clear >> from the specifications that the ASCII range was grandfathered >> in NameClass. It appears I was unclear in stating my concern, let >> me try again to explain my concern. > > Yes, I did misconstrue your question. > >> My concern is that login identities should be able to contain a >> valid IDNA U-label. It is not clear to me if NameClass permits >> all valid U-labels. If it does not, then I believe using >> NameClass for login identities is a mistake. The user@exmaple.com >> form for login identities will continue to be useful as the >> infrastructure is expanded to allow UTF-8 characters in both the >> "user" part and the "example.com" part of that form. If we >> disallow valid U-labels in login identities then we break the >> multi-domain model for lots of software out there and will force >> that software to change its architecture when it adopts this >> technology or to choose not to adopt this technology. If valid >> IDNA U-labels are permitted in login identities then implementers >> can keep their current architecture and adopt saslprepbis. > > Ah, I see. You raise a good question. The intent was that any code > point allowed in IDNs would be allowed in the PRECIS NameClass, > but looking closely at draft-ietf-precis-framework I realize that > the intent might not be reflected in the spec right now. I will > investigate further and post again when I have something definitive > to report. Hi Chris, I've been thinking about this further... IMHO this is similar to the previous discussion about naming needing to include space characters (after all, your name is "Chris Newman", not "ChrisNewman"). After much discussion, participants in the PRECIS WG concluded that it would be safer to disallow space characters in the NameClass, and that application protocols would need to define their constructs as a space-separated series of NameClass instances. And in fact that's what we've done in draft-ietf-precis-saslprepbis: simpleusername = simplepart [1*(1*SP simplepart)] simplepart = 1*(namepoint) ; ; a "namepoint" is a UTF-8 encoded ; Unicode code point that conforms to ; the "NameClass" string class defined ; in draft-ietf-precis-framework ; Here I see something similar: in order to allow strings like user@host.tld, an application protocol would need to define its constucts along these lines: userathost = userpart '@' domainpart userpart = 1*(namepoint) ; ; a "namepoint" is a UTF-8 encoded ; Unicode code point that conforms to ; the "NameClass" string class defined ; in draft-ietf-precis-framework ; domainpart = IP-literal / IPv4address / ifqdn ifqdn = 1*64(domainpoint) ; ; a "domainpoint" is a UTF-8 encoded ; Unicode code point that conforms to ; RFC 5890 ; Or, naturally, we could allow both styles (and others). That said, we might want to allow some characters into the NameClass that are outside LetterDigits ("A") in RFC 5892. I'm thinking especially of some of the code points in Exceptions ("F"). This sounds like an appropriate topic for discussion in Orlando... Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRIwggAAoJEOoGpJErxa2pW5wP/jWNKPKRPSm9JX/pgP6e8SVx oxme9tEb/mw9ryW+bv343Ut46HX53EfVZnV1nUoxOexSP3TCJmViUQFgCTiD/wi5 r/UV8XqU0l1cSfxW0zyZEFG0BcFt64ggzg/e9GigKWEnKZBgZJqMNb3+urGmz9d3 BN6bIWEBBV57RSDcYPOTe10Wrq2H27AZerDxcYVn02BRM4iFM9RLSVIFfM0QwkeX d1JRjYt9lhtNJkxMhNV6BS17z5g8H0w/Fhl96DWpxdQTWAETiybgz9LI1bpNsS59 IFrxkPWThUvUB/NUyIK1mFIrQq5FkJ3owT6S+Xg4ude/uXLWoOcExA6141dpguoS 0WGesk7jeN/6NUiPKX4oNMc4dd1fVOQlu/rFCY3+0hACTdT5xVLtJ69dRlb4hrmx rmLKfOA8CljV/3NN4eYBDnQd6og66I1BanEJ/A9KuwWpTi8EEehbkejkc0B6FZyl K9HKbEcu4iWDoOMGlRoKb7ApLKi3sW5GN44aqpwQRiZw4goIzlNJReubp64HdtoZ mss9iPVY2V11JykVxKCGKMJ/WpnHLZtOmsrfIt6tjONsw9npQPlOm5XqktLjasR8 cobeV0qg9x8gJkT1oaZKbEjctPAZh7fz3H+i0EcTsTjOs0fjJTU30osUzAZTPIoq VM4sgvjRuE4vfbtnkJXw =6LeL -----END PGP SIGNATURE----- From nico@cryptonector.com Tue Feb 19 10:13:39 2013 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 A041A21F8B7E for ; Tue, 19 Feb 2013 10:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.676 X-Spam-Level: X-Spam-Status: No, score=-3.676 tagged_above=-999 required=5 tests=[AWL=-1.699, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkgqESqFDQny for ; Tue, 19 Feb 2013 10:13:39 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id E9F6F21F8B64 for ; Tue, 19 Feb 2013 10:13:38 -0800 (PST) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 9AC27594069 for ; Tue, 19 Feb 2013 10:13:38 -0800 (PST) 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=QrLrKm5fh+Gi9RG+VMtPLFUvHBU=; b=WhMrho4sSw8 a+ELYktCLGz81lInogLslxP6sQn1HnXWnhoSfUgccCN53DztIHMR1hfsd38sjLPR TdV4TO6+Y8HYJ1qhWFMVTvLhGBaEV37y7T/NK0P2ubB0lC0PDCPCQwRWhGYZRdrt fbh66HI0xUDRU2m3SJTzurir6kQmv/Gk= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (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 429BE594061 for ; Tue, 19 Feb 2013 10:13:38 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id dr13so5605444wgb.26 for ; Tue, 19 Feb 2013 10:13:37 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.108.229 with SMTP id hn5mr25677761wib.28.1361297616987; Tue, 19 Feb 2013 10:13:36 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 10:13:36 -0800 (PST) Date: Tue, 19 Feb 2013 12:13:36 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Alternative design (Re: We need a GSS_C_CHANNEL_BOUND_FLAG) 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, 19 Feb 2013 18:13:40 -0000 I've thought about this over the weekend. I think a better design would be to distinguish between "credential options" and "context options". An indication that the application understands the new ret_flag would be a context option. There's two ways I can think of setting arbitrary context options: a) set them on credential handles, or b) have a function to create "empty" security contexts to be passed to GSS_Init/Accept_sec_context(). I prefer (a) for the abstract API and the C bindings, but could be convinced to go with (b) (which is utterly natural for the Java bindings). The functions to be added then would be GSS_Set_context_option() and possibly GSS_Get_context_option(). If we go with (b) we might need an empty security context constructor, though we might also conflate construction into GSS_Set_context_option() (we have precedent for this in GSS_Add_cred()). Following recent tradition we'd use URNs instead of OIDs. This extension really is necessary. Consensus would be nice to have on some design. Please comment. Thanks, Nico -- From ghudson@mit.edu Tue Feb 19 11:57:46 2013 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 C5C6021F8E44 for ; Tue, 19 Feb 2013 11:57:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLFiKBYw34Qt for ; Tue, 19 Feb 2013 11:57:46 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id DCBF921F8E27 for ; Tue, 19 Feb 2013 11:57:45 -0800 (PST) X-AuditID: 12074422-b7f5c6d000000545-ef-5123d939427a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 67.79.01349.939D3215; Tue, 19 Feb 2013 14:57:45 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id r1JJviMc005415; Tue, 19 Feb 2013 14:57:44 -0500 Received: from [18.189.53.176] ([18.189.53.176]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r1JJvgvJ014815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 19 Feb 2013 14:57:44 -0500 Message-ID: <5123D936.3050005@mit.edu> Date: Tue, 19 Feb 2013 14:57:42 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR4hTV1rW8qRxoML1JyOLo5lUsFqeuHWFz YPJ4eeoco8eSJT+ZApiiuGxSUnMyy1KL9O0SuDJeTX3HUvCbq2LF8zlsDYx/OboYOTkkBEwk OhreMEHYYhIX7q1n62Lk4hAS2Mco0dx8ihXC2cgo8efmFWYIZy2TxJUPHxhBWngF1CT+rn4B ZrMIqEr8nTKfFcRmE1CWOHj2GwuILSoQIrHozHQ2iHpBiZMzn4DFRQQ0Ja7PWwoWZxYQlriw fS9Yr7BAoMTvDd/BZgoJBEis27CWGcTmBIrvWLWQHeJUSYlF0zpZIHp1JN71PWCGsOUltr+d wzyBUWgWknWzkJTNQlK2gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6pXm5miV5qSukmRlBo s7so7WD8eVDpEKMAB6MSD2/DQuVAIdbEsuLK3EOMkhxMSqK8Zy4DhfiS8lMqMxKLM+KLSnNS iw8xSnAwK4nw6i4DyvGmJFZWpRblw6SkOViUxHmvpdz0FxJITyxJzU5NLUgtgsnKcHAoSfDy 3ABqFCxKTU+tSMvMKUFIM3FwggznARrefx1keHFBYm5xZjpE/hSjopQ4rwFIswBIIqM0D64X lnpeMYoDvSLMKwhSxQNMW3Ddr4AGMwENXrscbHBJIkJKqoFx2cIL7Fou001v33rHe/7+kYnG 7w8kLtp2SfG17aZfEsdeZbhPsXrCWfUrLd9tnbxR5885nnvf8clLVX29fO7gbu557nzi/D67 TObmLU3+xKlrILSEr2lirHbI/8qLYRLvOUTs39VsO9b9svGV+Sr2CzxfEg/PCeB+kfH4lrWH 8s3L+1QfrJmaqcRSnJFoqMVcVJwIALya4KgYAwAA Cc: kitten@ietf.org Subject: Re: [kitten] Alternative design (Re: We need a GSS_C_CHANNEL_BOUND_FLAG) 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, 19 Feb 2013 19:57:46 -0000 On 02/19/2013 01:13 PM, Nico Williams wrote: > have a function to create > "empty" security contexts to be passed to > GSS_Init/Accept_sec_context(). After discussing this idea with Tom, I like it and wish GSSAPI had started out this way. If we had blank context constructors from the beginning, then: * gss_init_sec_context and gss_accept_context could have had far fewer parameters. Instead, if you wanted to provide an unusual argument like time_req, you would set an option on the blank context before establishing the context. * Extensions like gss_set_neg_mechs and gss_krb5_set_allowable_enctypes wouldn't have needed to abuse GSS creds. Of course, we can't get rid of anything old at this point. > The functions to be added then would be GSS_Set_context_option() and > possibly GSS_Get_context_option(). Do we really need to standardize generic mutators for context options? Can we instead standardize a new function every time we want to add a new kind of context option? I don't really like OID/buffer or URI/buffer dispatches. For this purpose, we could probably define GSS_Set_context_flags() and perhaps GSS_Get_context_flags(), where the flags are in the req_flags namespace. We'd have to decide what happens if you set flags on a blank context and then call GSS_Init_sec_context; simplest is to or the context flags into the call's req_flags. From nico@cryptonector.com Tue Feb 19 12:41:57 2013 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 1821421F8903 for ; Tue, 19 Feb 2013 12:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.642 X-Spam-Level: X-Spam-Status: No, score=-3.642 tagged_above=-999 required=5 tests=[AWL=-1.665, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LIvm+rtV0Uc for ; Tue, 19 Feb 2013 12:41:56 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 4154A21F88D8 for ; Tue, 19 Feb 2013 12:41:56 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 05E0D264082 for ; Tue, 19 Feb 2013 12:41:56 -0800 (PST) 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=+aMuAiz1XEWOrIIben/L W643d8g=; b=hxTQ1w1+knUfzTmOo9sXl6Bd8L2MvC/eXGeGBIa3v/priaFVxlZd s+5a1/lBNx1Q+zLNwTlhN/XlJqma+sX6AI361sZl6r2KA992Xyw9ED6xQPHMVuaJ MhLda3FZyL+WlZWCUAw/l0Ev4jrEvlkjbTjTHswXOhm3SkjDeV7jCK4= Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (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 92C9B264059 for ; Tue, 19 Feb 2013 12:41:55 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id t44so6043805wey.40 for ; Tue, 19 Feb 2013 12:41:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.97.166 with SMTP id eb6mr29804472wib.20.1361306514112; Tue, 19 Feb 2013 12:41:54 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 12:41:53 -0800 (PST) In-Reply-To: <5123D936.3050005@mit.edu> References: <5123D936.3050005@mit.edu> Date: Tue, 19 Feb 2013 14:41:53 -0600 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Alternative design (Re: We need a GSS_C_CHANNEL_BOUND_FLAG) 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, 19 Feb 2013 20:41:57 -0000 On Tue, Feb 19, 2013 at 1:57 PM, Greg Hudson wrote: > On 02/19/2013 01:13 PM, Nico Williams wrote: >> have a function to create >> "empty" security contexts to be passed to >> GSS_Init/Accept_sec_context(). > > After discussing this idea with Tom, I like it and wish GSSAPI had > started out this way. If we had blank context constructors from the > beginning, then: I too wish the GSS-API had been like this from the beginning. Note that the Java bindings were like this from the beginning. > * gss_init_sec_context and gss_accept_context could have had far fewer > parameters. Instead, if you wanted to provide an unusual argument like > time_req, you would set an option on the blank context before > establishing the context. Yes. > * Extensions like gss_set_neg_mechs and gss_krb5_set_allowable_enctypes > wouldn't have needed to abuse GSS creds. I'm not sure about set_neg_mechs -- I could go either way on that one. The allowable enctypes (or any cryptographic profiling) absolutely needs to be a credentials type option: so the application can know a priori what credentials meet the desired requirements! Think of a named cryptographic profile extension... you'll want to acquire credentials that can meet the desired profile. > Of course, we can't get rid of anything old at this point. No, but we can replace it and deprecate the old stuff. >> The functions to be added then would be GSS_Set_context_option() and >> possibly GSS_Get_context_option(). > > Do we really need to standardize generic mutators for context options? > Can we instead standardize a new function every time we want to add a > new kind of context option? I don't really like OID/buffer or > URI/buffer dispatches. Per-option functions means more build-time feature discovery; or more use of non-standard run-time discovery techniques (weak symbols, dlsym(), ...). That strikes me as a bit of a PITA. Whereas with URN/URI/OID + buffer type extensions there's a single extension to detect at build time, and the run-time detection of supported options need not rely on any non-standard functionality. I could live with per-option functions. But first I think I'd like to see what the rest of the WG thinks of this. Perhaps there really is no need for run-time feature tests? > For this purpose, we could probably define GSS_Set_context_flags() and > perhaps GSS_Get_context_flags(), where the flags are in the req_flags > namespace. We'd have to decide what happens if you set flags on a blank > context and then call GSS_Init_sec_context; simplest is to or the > context flags into the call's req_flags. Ah, see, already you don't really want per-option functions -- you're proposing aggregating those that can be handled as a set of flags. :) Thanks for the thoughtful comments! Nico -- From nico@cryptonector.com Tue Feb 19 14:46:30 2013 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 AFB9121E803A; Tue, 19 Feb 2013 14:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.776 X-Spam-Level: X-Spam-Status: No, score=-3.776 tagged_above=-999 required=5 tests=[AWL=-1.799, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICtgIP6PxKYo; Tue, 19 Feb 2013 14:46:30 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 2A28921F8873; Tue, 19 Feb 2013 14:46:30 -0800 (PST) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id EF19128605B; Tue, 19 Feb 2013 14:46:29 -0800 (PST) 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=01dFfScI5bq1IRDauVGV TOQISMg=; b=XxYkUMLGmwMTBStzGb2HYfCO9PbxP6dHPlcbTiDwM+dfcXJxRhG3 QFowVdripMtXhp8ZVssfZIZqoR3LFZ/qxXqzBn1Z9o213tpux1HFSMLGHuQ2o8qE I7EMud99ItOOM3p+Za/jcJFM8WoQjBpEiaUg3PDCCh7DfO7fcoXYDtY= Received: from mail-ia0-f178.google.com (mail-ia0-f178.google.com [209.85.210.178]) (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 B6C2B286057; Tue, 19 Feb 2013 14:46:29 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id y26so6519938iab.37 for ; Tue, 19 Feb 2013 14:46:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.88.168 with SMTP id bh8mr1028797igb.67.1361313989178; Tue, 19 Feb 2013 14:46:29 -0800 (PST) Received: by 10.64.102.201 with HTTP; Tue, 19 Feb 2013 14:46:29 -0800 (PST) In-Reply-To: <51230821.8080904@stpeter.im> References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> <51229B19.1080703@stpeter.im> <51230821.8080904@stpeter.im> Date: Tue, 19 Feb 2013 16:46:29 -0600 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, "precis@ietf.org" Subject: Re: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.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: Tue, 19 Feb 2013 22:46:30 -0000 On Mon, Feb 18, 2013 at 11:05 PM, Peter Saint-Andre wrote: > IMHO this is similar to the previous discussion about naming needing > to include space characters (after all, your name is "Chris Newman", > not "ChrisNewman"). After much discussion, participants in the PRECIS > WG concluded that it would be safer to disallow space characters in > the NameClass, and that application protocols would need to define > their constructs as a space-separated series of NameClass instances. > And in fact that's what we've done in draft-ietf-precis-saslprepbis: I think this is a mistake. There are plenty of online games where users are allowed to have fairly arbitrary names. E.g., bzflag (although in recent years I think additional restrictions have been added on the registration side). Online gaming is probably a desired customer for SASL -- why not? I think restrictions on user naming should be imposed primarily by the registrar, not by the client or server software. We might well advise against allowing whitespace in usernames, and we might need to map different whitespace codepoints to just one, and so on, but not prohibit. Nico -- From stpeter@stpeter.im Tue Feb 19 18:30:55 2013 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 703A321F8853; Tue, 19 Feb 2013 18:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.611 X-Spam-Level: X-Spam-Status: No, score=-102.611 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgkTJXRY+MNH; Tue, 19 Feb 2013 18:30:54 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 964F921F87BA; Tue, 19 Feb 2013 18:30:54 -0800 (PST) Received: from [192.168.1.6] (unknown [71.237.13.154]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 26B3E4004E; Tue, 19 Feb 2013 19:38:20 -0700 (MST) Message-ID: <5124355B.8000707@stpeter.im> Date: Tue, 19 Feb 2013 19:30:51 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: Nico Williams References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> <51229B19.1080703@stpeter.im> <51230821.8080904@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, "precis@ietf.org" Subject: Re: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.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, 20 Feb 2013 02:30:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/19/13 3:46 PM, Nico Williams wrote: > On Mon, Feb 18, 2013 at 11:05 PM, Peter Saint-Andre > wrote: >> IMHO this is similar to the previous discussion about naming >> needing to include space characters (after all, your name is >> "Chris Newman", not "ChrisNewman"). After much discussion, >> participants in the PRECIS WG concluded that it would be safer >> to disallow space characters in the NameClass, and that >> application protocols would need to define their constructs as a >> space-separated series of NameClass instances. And in fact >> that's what we've done in draft-ietf-precis-saslprepbis: > > I think this is a mistake. There are plenty of online games where > users are allowed to have fairly arbitrary names. E.g., bzflag > (although in recent years I think additional restrictions have been > added on the registration side). Online gaming is probably a > desired customer for SASL -- why not? > > I think restrictions on user naming should be imposed primarily by > the registrar, not by the client or server software. We might > well advise against allowing whitespace in usernames, and we might > need to map different whitespace codepoints to just one, and so on, > but not prohibit. Hi Nico, please (re-)read Section 4.3 of draft-ietf-precis-framework before concluding that the participants in the PRECIS WG are utterly misguided on the issue of whitespace. :-) Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRJDVbAAoJEOoGpJErxa2pq0QP/3AxlkOkRL6IDPWQ39ffcxnQ 3PqkH9PFUEIvD+S20kOZX2aVokGvcwQiZ0GiGXDumTkhTvMxNie47ZmNLaEikExY 4JENZWKZEhz/mfCJZ0PpM7CfpOelt1PCJ8Qne4BiyJObKYso4vFEr/9j43/9WNGL rUxCCkk6AjQ7dUx64bZOc7c+LBvmb1034XYY4HGRihfYCz+nWFSpaMSWtrD0o1Cj iYjZfPa+IUzEjF6QvEB22RkMhQgr3lnyRq++Rhl/iBV6N7Ul0Sie9or879d1/GU2 6iPb8HwAJT8NGBQlv9rp+T/A9XFwRe761NUR2qlLgBbzuO0He5UlyuRetHrVvM/q oZehWeX5wkRQWvwRFxF64A8JRRAoJxj6xOnzHI7yZo4M+75vWf8vrJsPWzU81OAk CTSAuanpwDhfhZpWWUtHNDiJgzFql0oc0/x1nXRrgA+hNtjyV98SWfveuk16tFUo XD7ETDDK+ION/G9QK0FJF6eidMuq6e++OEI/jBfTiUZ+5RpO1DE5VG2dzGRnl8sO SnMZhCcpuwZFoMitr3Hc/chPq9ai29xIt+rnLfghvrTVz36q0hEBjpBl7cCtnPS9 9g18zs03aNWQcOQpiRfmMvY0wLpBuSjOiuPTfx8cT/15htIQOTz/c1fhoY7Z65GZ RdmAKnIZFk7876ATpofQ =uys8 -----END PGP SIGNATURE----- From nico@cryptonector.com Tue Feb 19 19:16:38 2013 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 D9C4221F886F; Tue, 19 Feb 2013 19:16:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.654 X-Spam-Level: X-Spam-Status: No, score=-3.654 tagged_above=-999 required=5 tests=[AWL=-1.677, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Nn8po5Gu58Q; Tue, 19 Feb 2013 19:16:38 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2C25F21F8818; Tue, 19 Feb 2013 19:16:38 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 8EDC3598058; Tue, 19 Feb 2013 19:16:37 -0800 (PST) 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=QSNNWZJNPFtC+MhIxO6o yvZ39EE=; b=YGk2k8EFBeR8hv8bq0uYesQ9UW8WIbugQbjPt51LvEzJz+RGLE5S X78Oy0lG0nd2T84M/pZD5ujCzet2SPRdaifDm2Af14IBr9OiLiLqAtIImtlPePhN RzsKsjP3ygsGZYr1559WLAffeH8iDqCzvyuvCQ2XJ2yZvJAUP+fqUmQ= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 01A25598057; Tue, 19 Feb 2013 19:16:36 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm11so5898910wib.5 for ; Tue, 19 Feb 2013 19:16:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.58.202 with SMTP id t10mr22143734wjq.4.1361330195638; Tue, 19 Feb 2013 19:16:35 -0800 (PST) Received: by 10.216.254.217 with HTTP; Tue, 19 Feb 2013 19:16:35 -0800 (PST) In-Reply-To: <5124355B.8000707@stpeter.im> References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> <51229B19.1080703@stpeter.im> <51230821.8080904@stpeter.im> <5124355B.8000707@stpeter.im> Date: Tue, 19 Feb 2013 21:16:35 -0600 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, "precis@ietf.org" Subject: Re: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.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, 20 Feb 2013 03:16:39 -0000 On Tue, Feb 19, 2013 at 8:30 PM, Peter Saint-Andre wrote: > On 2/19/13 3:46 PM, Nico Williams wrote: >> On Mon, Feb 18, 2013 at 11:05 PM, Peter Saint-Andre >> wrote: >>> IMHO this is similar to the previous discussion about naming >>> needing to include space characters (after all, your name is >>> "Chris Newman", not "ChrisNewman"). After much discussion, >>> participants in the PRECIS WG concluded that it would be safer >>> to disallow space characters in the NameClass, and that >>> application protocols would need to define their constructs as a >>> space-separated series of NameClass instances. And in fact >>> that's what we've done in draft-ietf-precis-saslprepbis: >> >> I think this is a mistake. There are plenty of online games where >> users are allowed to have fairly arbitrary names. E.g., bzflag >> (although in recent years I think additional restrictions have been >> added on the registration side). Online gaming is probably a >> desired customer for SASL -- why not? >> >> I think restrictions on user naming should be imposed primarily by >> the registrar, not by the client or server software. We might >> well advise against allowing whitespace in usernames, and we might >> need to map different whitespace codepoints to just one, and so on, >> but not prohibit. > > Hi Nico, please (re-)read Section 4.3 of draft-ietf-precis-framework > before concluding that the participants in the PRECIS WG are utterly > misguided on the issue of whitespace. :-) I said what now? :) But OK, I read that, and I remain unconvinced. What am I missing? If they did have a clue then they didn't write text that I find convincing. Who cares if some devices produce whitespace other than ASCII space? That's what mappings are for. Or maybe I'm missing something. Assume I'm partly ignorant here. What am I missing? Nico -- From chris.newman@oracle.com Tue Feb 19 21:47:45 2013 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 9563A21F86FC; Tue, 19 Feb 2013 21:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.449 X-Spam-Level: X-Spam-Status: No, score=-107.449 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCTANxRKoncr; Tue, 19 Feb 2013 21:47:39 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 65FB021F8921; Tue, 19 Feb 2013 21:47:38 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1K5laNC023671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 20 Feb 2013 05:47:37 GMT Received: from gotmail.us.oracle.com (gotmail.us.oracle.com [10.133.152.174]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1K5laST014565; Wed, 20 Feb 2013 05:47:36 GMT MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from [10.159.103.84] (dhcp-amer-vpn-rmdc-anyconnect-10-159-103-84.vpn.oracle.com [10.159.103.84]) by gotmail.us.oracle.com (Oracle Communications Messaging Server 7u5-28.16(7.0.5.28.0) 64bit (built Dec 16 2012)) with ESMTPA id <0MII00B0C839RL00@gotmail.us.oracle.com>; Tue, 19 Feb 2013 21:47:35 -0800 (PST) Date: Tue, 19 Feb 2013 21:47:33 -0800 From: Chris Newman To: Peter Saint-Andre Message-id: In-reply-to: <51230821.8080904@stpeter.im> References: <20130214042443.5506.25683.idtracker@ietfa.amsl.com> <511D0B9C.7060102@stpeter.im> <06DA1F509463BB680806A11E@96B2F16665FF96BAE59E9B90> <511D5350.5000009@stpeter.im> <511D5601.4050509@stpeter.im> <29A69AF46F677183C2C75C29@96B2F16665FF96BAE59E9B90> <51229B19.1080703@stpeter.im> <51230821.8080904@stpeter.im> X-Mailer: Mulberry/4.0.8 (Mac OS X) X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Cc: kitten@ietf.org, precis@ietf.org Subject: Re: [kitten] Fwd: [precis] I-D Action: draft-ietf-precis-saslprepbis-00.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, 20 Feb 2013 05:47:45 -0000 --On February 18, 2013 22:05:37 -0700 Peter Saint-Andre wrote: > Here I see something similar: in order to allow strings like > user@host.tld, an application protocol would need to define its > constucts along these lines: Historically, Internet login identities have been freeform ASCII or UTF-8 strings. Widely deployed implementations have sometimes used other charsets such as ISO-8859-1 even when it violates the standards. This shows need for both UTF-8 support and validity enforcement in login identities. Identity systems can impose additional structure as needed. A site's identity system works best if it can span multiple protocols (e.g., IMAP, POP, SMTP, XMPP, web form logins, etc). Architecturally, I think identity systems are best viewed as independent of the consuming protocols even if a lot of software is not implemented that way today. So I'd prefer to avoid having application protocols imposing unnecessary constraints on identity systems. So we're balancing a need for validity enforcement for interoperability (which is the intent behind NameClass) with a need for application protocols to avoid breaking existing identity system models so it is possible for this standard to deploy. This looks like a good engineering problem to me. :-) > That said, we might want to allow some characters into the NameClass > that are outside LetterDigits ("A") in RFC 5892. I'm thinking > especially of some of the code points in Exceptions ("F"). This sounds > like an appropriate topic for discussion in Orlando... Yes, I think that would be a good discussion to have. I would propose that all the PVALID and CONTEXT characters from Exceptions (F) be added to NameClass and state that implementations MAY enforce the CONTEXT restrictions from RFC 5892. - Chris From shawn.emery@oracle.com Wed Feb 20 00:02:15 2013 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 B20CF21F893D for ; Wed, 20 Feb 2013 00:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnSnuOSfcxot for ; Wed, 20 Feb 2013 00:02:14 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id CF22A21F888B for ; Wed, 20 Feb 2013 00:02:14 -0800 (PST) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1K82DfL014441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Feb 2013 08:02:14 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1K82CEC013336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Feb 2013 08:02:13 GMT Received: from abhmt107.oracle.com (abhmt107.oracle.com [141.146.116.59]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1K82Cq8002658 for ; Wed, 20 Feb 2013 02:02:12 -0600 Received: from [10.159.102.43] (/10.159.102.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Feb 2013 00:02:12 -0800 Message-ID: <512482C3.5070106@oracle.com> Date: Wed, 20 Feb 2013 01:01:07 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.11) Gecko/20121204 Thunderbird/10.0.11 MIME-Version: 1.0 To: "kitten@ietf.org" References: <50873860.4060608@oracle.com> In-Reply-To: <50873860.4060608@oracle.com> X-Forwarded-Message-Id: <50873860.4060608@oracle.com> Content-Type: multipart/alternative; boundary="------------040104050808090508060109" X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Subject: [kitten] IETF 86 Agenda 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, 20 Feb 2013 08:02:15 -0000 This is a multi-part message in MIME format. --------------040104050808090508060109 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There should be lots of agenda items to put on the upcoming Orlando session given the combined areas of Kerberos, GSS-API, and SASL. Please submit thesetopics, with the expected time to discuss, to the list or co-chairs no later than 2/27. Shawn Emery kitten co-chair -- --------------040104050808090508060109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
There should be lots of agenda items to put on the upcoming Orlando session given the combined areas of Kerberos, GSS-API, and SASL.  Please submit these topics, with the expected time to discuss, to the list or co-chairs no later than 2/27.

Shawn Emery
kitten co-chair
--
--------------040104050808090508060109-- From nico@cryptonector.com Wed Feb 20 08:36:08 2013 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 B6FA421F8816 for ; Wed, 20 Feb 2013 08:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=-1.483, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oWPCHLXWi2qT for ; Wed, 20 Feb 2013 08:36:08 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0EC21F8700 for ; Wed, 20 Feb 2013 08:36:08 -0800 (PST) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 20DA5584077 for ; Wed, 20 Feb 2013 08:36:08 -0800 (PST) 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=CtqUzNRj6UAUA9ZiCrPE V3WUzC8=; b=qF2wiIW86KmJ877A4F9sNokEPhWMNFpBvgch8Xy9qXGNu8YRU5UH gT6ig2TypgXdlG29RdRLxIxXPjY/yg/W6uHxX8VwtsQ9Dg6DlNoGnZZjV/hEQNnI MCHnUsCDrvapUrHc4QXN6NrkSf2F1Z+WYqreS8jZqP3dO9GExPqvgLk= Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) (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 BE8B2584070 for ; Wed, 20 Feb 2013 08:36:07 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id z53so7141008wey.1 for ; Wed, 20 Feb 2013 08:36:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.87.98 with SMTP id w2mr33888883wiz.30.1361378160174; Wed, 20 Feb 2013 08:36:00 -0800 (PST) Received: by 10.216.148.193 with HTTP; Wed, 20 Feb 2013 08:36:00 -0800 (PST) In-Reply-To: <512482C3.5070106@oracle.com> References: <50873860.4060608@oracle.com> <512482C3.5070106@oracle.com> Date: Wed, 20 Feb 2013 10:36:00 -0600 Message-ID: From: Nico Williams To: Shawn Emery Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] IETF 86 Agenda 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, 20 Feb 2013 16:36:08 -0000 On Wed, Feb 20, 2013 at 2:01 AM, Shawn Emery wrote: > There should be lots of agenda items to put on the upcoming Orlando session > given the combined areas of Kerberos, GSS-API, and SASL. Please submit > these topics, with the expected time to discuss, to the list or co-chairs no > later than 2/27. I have at least three items to put on the agenda: - draft-williams-kitten-channel-bound-flag - draft-williams-kitten-krb5-extra-rt - draft-williams-kitten-krb5-rcache-avoidance (In order of importance to me.) Possibly also: - draft-williams-gss-profiles Nico -- From nico@cryptonector.com Thu Feb 21 11:50:34 2013 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 318A621F8F66 for ; Thu, 21 Feb 2013 11:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.622, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH5xudNhUxd2 for ; Thu, 21 Feb 2013 11:50:33 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 5477621F8F5F for ; Thu, 21 Feb 2013 11:50:33 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id D3F7926406B for ; Thu, 21 Feb 2013 11:50:32 -0800 (PST) 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=5Pkuy26e30NbQydfccf+ sJBo8vk=; b=ywtn4keTK2CKkySLeT7IszGB/c/MQ+Et108Qrz0mOfXiaS3u6AER GGLgeP+X6LFq62IkMzhGmqi/OtdnJPTPG8MKNFF4KMHrbAn9HPEOFMBr1fJDN4Nk ylF4YuGir86ZQgvGNTTJWCnLr3l+YNXfkASgKN776SMOdPdDhd/XSFA= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 B97D8264079 for ; Thu, 21 Feb 2013 11:50:30 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so73864wib.3 for ; Thu, 21 Feb 2013 11:50:29 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.87.98 with SMTP id w2mr42585990wiz.30.1361476229383; Thu, 21 Feb 2013 11:50:29 -0800 (PST) Received: by 10.216.148.193 with HTTP; Thu, 21 Feb 2013 11:50:29 -0800 (PST) In-Reply-To: References: <5123D936.3050005@mit.edu> Date: Thu, 21 Feb 2013 13:50:29 -0600 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Alternative design (Re: We need a GSS_C_CHANNEL_BOUND_FLAG) 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, 21 Feb 2013 19:50:34 -0000 Any further comments? It'd be nice to have consensus going into Orlando. It should be easy to get consensus on this. Also, I think this should be a WG work item. Pretty please dear chairs? Thanks! Nico -- From hannes.tschofenig@gmx.net Fri Feb 22 02:23:40 2013 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 47E0B21F8E19 for ; Fri, 22 Feb 2013 02:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.016 X-Spam-Level: X-Spam-Status: No, score=-102.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw5QqZ0sliOy for ; Fri, 22 Feb 2013 02:23:36 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id 64B5721F8CAB for ; Fri, 22 Feb 2013 02:23:36 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.35]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MT5dQ-1UFwTX1dzC-00S8QL for ; Fri, 22 Feb 2013 11:19:29 +0100 Received: (qmail 26317 invoked by uid 0); 22 Feb 2013 10:19:29 -0000 Received: from 194.251.119.197 by www005.gmx.net with HTTP; Fri, 22 Feb 2013 11:19:28 +0100 (CET) Content-Type: text/plain; charset="utf-8" Date: Fri, 22 Feb 2013 11:19:28 +0100 From: "Hannes Tschofenig" In-Reply-To: <1355781348.2312.94.camel@minbar.fac.cs.cmu.edu> Message-ID: <20130222101928.247930@gmx.net> MIME-Version: 1.0 References: <26027_1355766716_qBHHptmU008972_23F98B0F-9BC1-4717-9CB0-889676C898BE@gmx.net> <1355781348.2312.94.camel@minbar.fac.cs.cmu.edu> To: Jeffrey Hutzelman , hannes.tschofenig@gmx.net X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/EQL5jzwfEJJCyezh4tM4+jVTNytPBPJEb+G4ZDB Ikqrukr0FDG3DrOrii2YVOlmxyYl031NRzhA== Content-Transfer-Encoding: 8bit X-GMX-UID: ZyNVcb0BeSEqSpIAqXUh8nZ+IGRvb8Ac Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] OAuth SASL Draft Update 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, 22 Feb 2013 10:23:40 -0000 Hi Jeff, it's me again on the same review comments. Given the approaching draft submission deadline I tried to come up with a way to address your comments. So, I took a look at other published SASL mechanisms to sort of use an existing writeup as a template to meet the expectations from the working group. Here is the list of standardized mechanisms: http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xml To my surprise I had to notice that my text is not any worse that what others had written in their documents. In fact, I would even argue that the OAuth SASL writeup (if you consider the companion threat analysis from RFC 6819 http://tools.ietf.org/html/rfc6819) far exceeds any of the published mechanisms so far. What are the expectations regarding SASL methods when it comes to the security consideration section writeup and to the design of the mechanisms in general? In EAP, for example, the requirements are outlined in RFC 4017 http://www.ietf.org/rfc/rfc4017.txt. Many EAP method documents describe what properties their method offers based on the content of RFC 4017. I don't think RFC 4017 is directly applicable to SASL/GSS-API methods since the architecture is different. Is there something similar available? Ciao Hannes -------- Original-Nachricht -------- > Datum: Mon, 17 Dec 2012 16:55:48 -0500 > Von: Jeffrey Hutzelman > An: Hannes Tschofenig > CC: jhutz@cmu.edu, kitten@ietf.org > Betreff: Re: [kitten] OAuth SASL Draft Update > On Mon, 2012-12-17 at 19:51 +0200, Hannes Tschofenig wrote: > > Hi all, > > > > I thought I should submit the current draft snapshot. Here is the > current version: > > http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-09 > > > > > > OAuth mechanims security contexts always have the mutual_state flag > > (GSS_C_MUTUAL_FLAG) set to TRUE. OAuth supports credential > > delegation, therefore security contexts may have the deleg_state flag > > (GSS_C_DELEG_FLAG) set to either TRUE or FALSE. > > > > The mutual authentication property of this mechanism relies on > > successfully comparing the TLS server identity with the negotiated > > target name. Since the TLS channel is managed by the application > > outside of the GSS-API mechanism, the mechanism itself is unable to > > confirm the name while the application is able to perform this > > comparison for the mechanism. For this reason, applications MUST > > match the TLS server identity with the target name using the > > appropriate application profile, as discussed in [RFC6125]. For > > example, when SASL OAuth is run over IMAP then the IMAP profile of > > RFC 6125 is used. > > So in other words, this mechanism does _not_ provide mutual auth. The > mutual_state flag indicates that the _mechanism_ has authenticated the > server. Here, you are saying that the mechanism cannot do so, and so it > is up to the application to do so. That's fine, but then you cannot set > mutual_auth, because that amounts to lying to the GSS-API application. > > This is important, because GSS applications depend on this flag to know > whether they can depend on GSS-API channel bindings to bind the > enclosing channel to the server's identity. That is, they use it to > know whether it is OK that they are _not_ checking the TLS server cert > (or whatever other channel is in use). > > You're basically saying that when using this mechanism, the application > has to ignore mutual_state and assume the server is not authenticated > (and so, neither is the enclosing channel). But you don't get to do > that; it violates the API abstraction. > > > > Separately, I find the security considerations section in this document > to be wholly inadequate. It basically says "there might be issues", but > with a couple of specific exceptions does not explore what they are, > whether or how the mechanism addresses them, or what steps should be > taken to mitigate them. Please see RFC3552 for more information on what > should be in the Security Considerations section of an RFC. Please pay > particular attention to the discussion in section 5, and especially to > the comments on what must be covered in the specific case of > authentication mechanisms. IMHO the current document falls short in > this regard. > > -- Jeff > From nico@cryptonector.com Fri Feb 22 10:58:59 2013 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 9E96021F85EE for ; Fri, 22 Feb 2013 10:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=-1.596, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nW1fRQubZoxS for ; Fri, 22 Feb 2013 10:58:59 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE7F21F8A90 for ; Fri, 22 Feb 2013 10:58:59 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 47AA09406E for ; Fri, 22 Feb 2013 10:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=SvxXIlFZTpwjr2yMk7wU+j0uoCg=; b=T9TuLAnGRb1 SsaapD45d6wK95nwhWndHbx9CP8Ee6HtRGlsOGUhI/Z/trkRrvxyuz2fmzIn0mQG BPKckGGncV5uNnxkw1UV71bPCeuP8+owcpP2HhdT2/GQV7o+zWDkNlU1134qFoaI WvKkLFlutPr9SsPqKRgJomdB3Er11Gz8= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (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 E469D94065 for ; Fri, 22 Feb 2013 10:58:55 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so2532732wie.4 for ; Fri, 22 Feb 2013 10:58:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.63.109 with SMTP id f13mr5678700wjs.11.1361559533657; Fri, 22 Feb 2013 10:58:53 -0800 (PST) Received: by 10.216.148.193 with HTTP; Fri, 22 Feb 2013 10:58:53 -0800 (PST) Date: Fri, 22 Feb 2013 12:58:53 -0600 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: [kitten] -02 of GSS_C_CHANNEL_BOUND_FLAG I-D submitted 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, 22 Feb 2013 18:58:59 -0000 Version -02, using the "empty sec context constructor" design has been submitted. http://www.ietf.org/id/draft-williams-kitten-channel-bound-flag-02.txt http://tools.ietf.org/html/draft-williams-kitten-channel-bound-flag-02 http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-williams-kitten-channel-bound-flag-02.txt (Hmm, I just realized that we should say what happens when GSS_Delete_sec_context() is called on an empty sec context handle, namely that no deletion context token is to be generated.) Please review. Dear WG chairs, please approve submission as a WG work item. (Yes, it's too late to submit -00s for Orlando, so I'd have to do it after.) Nico -- From nico@cryptonector.com Fri Feb 22 14:31:20 2013 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 00E1521F8ABC for ; Fri, 22 Feb 2013 14:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.408 X-Spam-Level: X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[AWL=-1.431, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIwvDuwi766C for ; Fri, 22 Feb 2013 14:31:19 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 4817E21F89B9 for ; Fri, 22 Feb 2013 14:31:16 -0800 (PST) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id EB43A508084 for ; Fri, 22 Feb 2013 14:31:15 -0800 (PST) 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=EzfEna81JB97PzA7wPXJsdkYsho=; b=oeDyGf6K95z bopbBkAXVIUAnPxbnIWTsDEm9f//W0MEZrvOEvoe12keLHVFGnEXjcCSm+iaVT1n /WPRaRrK3cUmun0ASzVeJPXJMpZtG9NTdACWQDqBQsWH+CkbDmnDL30nXrz3jVc/ ymY7My8+5vhpCQRfcESCyjQLSu/Mq/+k= Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPSA id 9C213508072 for ; Fri, 22 Feb 2013 14:31:15 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id dr13so898214wgb.2 for ; Fri, 22 Feb 2013 14:31:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.77.129 with SMTP id s1mr6547751wjw.17.1361572274409; Fri, 22 Feb 2013 14:31:14 -0800 (PST) Received: by 10.216.148.193 with HTTP; Fri, 22 Feb 2013 14:31:14 -0800 (PST) Date: Fri, 22 Feb 2013 16:31:14 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Simplified and async API 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, 22 Feb 2013 22:31:20 -0000 Too late for submitting -00s. So here: https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt (also .unpg, .html, and .lyx) Enjoy. Yes, I'm trying to get the WG participants attention for the other I-Ds I've submitted recently, particularly the one about channel binding. Perhaps submitting something mildly controversial will help? Nico -- From ietf@augustcellars.com Fri Feb 22 19:49:15 2013 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 0E42421F85C9 for ; Fri, 22 Feb 2013 19:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94rOFvNvP03H for ; Fri, 22 Feb 2013 19:49:14 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75FB621F85C4 for ; Fri, 22 Feb 2013 19:49:14 -0800 (PST) Received: from Philemon (50-39-222-11.bvtn.or.frontiernet.net [50.39.222.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id BA8142C9FB; Fri, 22 Feb 2013 19:49:13 -0800 (PST) From: "Jim Schaad" To: Date: Fri, 22 Feb 2013 19:48:43 -0800 Message-ID: <007101ce1178$ad58f8c0$080aea40$@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: Ac4Rc2Ov0SPtCV/fT6CWjuAPMMv/KA== Content-Language: en-us Cc: kitten@ietf.org Subject: [kitten] Review comments on draft-williams-kitten-channel-bound-flag-02 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, 23 Feb 2013 03:49:15 -0000 Nico, 1. In section 1.1 you say that it would be useless to allow security context establishment if the acceptor provides context but the initiator does not, but the converse is not true. I need to have a greater explanation that is present about why this would be true. It seems to me that the both of them are equally useful or useless. The decision of which to enable first would appear to be an arbitrary one and not one with solid security reasoning. 2. In section 1.4 - I think that I like this idea and want to bounce a couple questions off of you. Would you expect that one could set mechanism specific security context values as well as generic ones? As an example, in ABFAB could this be used as a method for setting an authorization context SAML statement in the authenticator that the mechanism could later use in an appropriate manner. Since this would be tagged as being mechanism specific it would be ignored by any other mechanism. Would you expect that one could query about context values used that are not setup as return flags after authentication has completed? Thus one could ask if this security context value was used or not when establishing security context? 3. In section 1.4 - are the two required inputs supposed to be a security context handle and a credential handle? Currently it says a context handle and an input context token. This may be a deficiency on my part for understanding. It may also be that the word context should be removed and it should just be 'an input token' 4. In section 2 s/for setting a) creating/for a) creating/ Same sentence. There should be an and between the a)... and b)... as the currently existing and is two sub-clauses in b) 5. In section 2.2 - There is a problem with the text "Return flags understood by the caller" in that this is an input but the text is written as if it were an output. Suggest "Specify return flags understood by the caller" 6. In section 2.2 - does it make more sense to do an override or to do an OR on the request flags? It seems odd that one would ignore them based on passing in a value of 0, what if that is what they really want? Without the ability to query for them from the context it seems odd to potentially ignore flags set elsewhere - and thus introduce a bug - while doing the or (along with a query) might be more predictable. 7. In section 3 - Should there be some type of error if an application shall have a) not provided channel bindings to GSS_Init_sec_context() or GSS_Accept_sec_context() and b) indicated support for the ret-channel-bound-flag flag? This would indicate to me that some type of programming error occurred as the return should never have the flag set. 8. In section 4 - I think that it is worthwhile documenting that if an initiator passes in a channel binding and either you are in the current state or the mechanism has not implemented this document then there is a potential secrurity problem as the channel binding will not have occurred and the initiator might assume that it had. Also, If the selected mechanism does not implemented this feature then it will always appear as channel binding did not occur even if it did as the mechanism would not return the appropriate flag. Jim From ietf@augustcellars.com Fri Feb 22 20:02:22 2013 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 6CCAF21E803A for ; Fri, 22 Feb 2013 20:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id easzOTxxWSte for ; Fri, 22 Feb 2013 20:02:16 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id E1FA221E8030 for ; Fri, 22 Feb 2013 20:02:16 -0800 (PST) Received: from Philemon (50-39-222-11.bvtn.or.frontiernet.net [50.39.222.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 8FB6038F1C; Fri, 22 Feb 2013 20:02:16 -0800 (PST) From: "Jim Schaad" To: "'Nico Williams'" , References: In-Reply-To: Date: Fri, 22 Feb 2013 20:01:46 -0800 Message-ID: <007501ce117a$7ffbbe10$7ff33a30$@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: AQJgOS+30nxlvANXksj8zs5RqPclqZdignsQ Content-Language: en-us Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 04:02:22 -0000 Nico, Without appropriate methods for doing queries and potentially clearing things I would consider the API set to be incomplete. Jim > -----Original Message----- > From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf > Of Nico Williams > Sent: Friday, February 22, 2013 2:31 PM > To: kitten@ietf.org > Subject: [kitten] Simplified and async API > > Too late for submitting -00s. So here: > > https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt > > (also .unpg, .html, and .lyx) > > Enjoy. Yes, I'm trying to get the WG participants attention for the other I-Ds > I've submitted recently, particularly the one about channel binding. Perhaps > submitting something mildly controversial will help? > > Nico > -- > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nico@cryptonector.com Fri Feb 22 20:42:53 2013 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 7620421F84F5 for ; Fri, 22 Feb 2013 20:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.383 X-Spam-Level: X-Spam-Status: No, score=-3.383 tagged_above=-999 required=5 tests=[AWL=-1.406, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x22o0xPq9-u for ; Fri, 22 Feb 2013 20:42:52 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id D6A4221F84EB for ; Fri, 22 Feb 2013 20:42:52 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 3A4B56B0078 for ; Fri, 22 Feb 2013 20:42:51 -0800 (PST) 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=8lBMZ+ONCDT9sJdyRGVG Uf0Luxc=; b=ryNRj8Cav4A31DuA9wf94H2Fez4x7si4+pmPgJITcGLCKI1Zt1rK wYRyyOkKWwPogheJYAiQTrddfGL3disLvl4P8Mb24Uj6LrhydeKKD4hgGLd4Rv22 tJ/xJs0HnTZ0C3dyA1uCL4tlUItIX55a1Psc3vh69xDcCP5Dt1qmE3s= Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (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 D9B296B0059 for ; Fri, 22 Feb 2013 20:42:50 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id r6so1059451wey.33 for ; Fri, 22 Feb 2013 20:42:48 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.63.109 with SMTP id f13mr7690996wjs.11.1361594568674; Fri, 22 Feb 2013 20:42:48 -0800 (PST) Received: by 10.216.148.193 with HTTP; Fri, 22 Feb 2013 20:42:48 -0800 (PST) In-Reply-To: <007501ce117a$7ffbbe10$7ff33a30$@augustcellars.com> References: <007501ce117a$7ffbbe10$7ff33a30$@augustcellars.com> Date: Fri, 22 Feb 2013 22:42:48 -0600 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 04:42:53 -0000 On Friday, February 22, 2013, Jim Schaad wrote: > Without appropriate methods for doing queries and potentially clearing > things I would consider the API set to be incomplete. Jim, I'm quite glad you looked at this so soon after I posted (and the CB I-D, particularly the CB I-D; I'll respond to that review shortly) I'm a fan of reflection interfaces. I don't think we *need* them here, and since the GSS-API has a nasty reputation of having too many functions with too many arguments, I hesitate to add functions we don't clearly need. The only way we'd need reflection functions is if an app built a partial context and passed it to some library to finish -- and that clearly doesn't happen today, so we clearly don't need reflection interfaces. As for functions to unset things, there's no reason I can see why we'd ever need those. Nico -- From lukeh@padl.com Fri Feb 22 20:44:10 2013 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 AB4D721F84F5 for ; Fri, 22 Feb 2013 20:44:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OfLvHYi3-VCL for ; Fri, 22 Feb 2013 20:44:09 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 7529321F84EB for ; Fri, 22 Feb 2013 20:44:09 -0800 (PST) Received: by us.padl.com with ESMTP id r1N4hr92001190; Fri, 22 Feb 2013 23:43:56 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Luke Howard In-Reply-To: <007101ce1178$ad58f8c0$080aea40$@augustcellars.com> Date: Sat, 23 Feb 2013 15:43:52 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <007101ce1178$ad58f8c0$080aea40$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1499) 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, draft-williams-kietten-channel-bound-flag@tools.ietf.org Subject: Re: [kitten] Review comments on draft-williams-kitten-channel-bound-flag-02 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, 23 Feb 2013 04:44:10 -0000 > Would you expect that one could set mechanism specific security = context > values as well as generic ones? As an example, in ABFAB could this be = used > as a method for setting an authorization context SAML statement in the > authenticator that the mechanism could later use in an appropriate = manner. You can do something similar today by calling GSS_Set_name_attribute() = on a name passed to GSS_Acquire_cred(). I implemented something like = this a while ago, so that you could pass a SAML assertion in when doing = protocol transition (see = http://k5wiki.kerberos.org/wiki/Projects/SAMLInKerberos). -- Luke= From nico@cryptonector.com Fri Feb 22 20:54:55 2013 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 559D621E803A for ; Fri, 22 Feb 2013 20:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.359 X-Spam-Level: X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[AWL=-1.382, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YVI8agDEvyc for ; Fri, 22 Feb 2013 20:54:54 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id B871621E804A for ; Fri, 22 Feb 2013 20:54:54 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 60E9577805B for ; Fri, 22 Feb 2013 20:54:54 -0800 (PST) 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=AZjx8TbX87mh2ctjbCPg G6jRtJ8=; b=dw9tAn9BST1GPKs0S+t+YQke8btIcf8hSFn/8Bcc2SPybSF2Homs jlfxIYkkDJZjNpazK7G1qAH1PLEVl+6P1lw/k7yGzB4hRR81iNy+rZ6KtuvXOQXK LT2Vgs/1Ucktb3RDIf4wGoef98SfWeIPjCcXRUxa0I+w7GkU2nvj2BQ= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id 0B811778057 for ; Fri, 22 Feb 2013 20:54:53 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id es5so1067416wgb.29 for ; Fri, 22 Feb 2013 20:54:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.63.109 with SMTP id f13mr7720309wjs.11.1361595292830; Fri, 22 Feb 2013 20:54:52 -0800 (PST) Received: by 10.216.148.193 with HTTP; Fri, 22 Feb 2013 20:54:52 -0800 (PST) In-Reply-To: References: <007501ce117a$7ffbbe10$7ff33a30$@augustcellars.com> Date: Fri, 22 Feb 2013 22:54:52 -0600 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 04:54:55 -0000 Although I should have tackled your response to the CB I-D first. I see now what you probably had in mind w.r.t. querying context attributes. Yes, we have GSS_Inquire_context(), and this I-D adds a function to retrieve delegated credentials handles as well. And we should have additional such inquiry functions for any context attributes that can come from the other peer. So if an initiator sets some option that communicates some authorization data to the acceptor, the acceptor has to be able to extract that data from the context. What I think we don't need is inquiry functions for discovering what the local application has requested -- the app should already know. Nico -- From nico@cryptonector.com Fri Feb 22 21:18:48 2013 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 3429D21E8050 for ; Fri, 22 Feb 2013 21:18:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.548 X-Spam-Level: X-Spam-Status: No, score=-3.548 tagged_above=-999 required=5 tests=[AWL=-1.571, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg560dkhOCOa for ; Fri, 22 Feb 2013 21:18:47 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id C7DB021E804E for ; Fri, 22 Feb 2013 21:18:46 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id BBF6BBC041 for ; Fri, 22 Feb 2013 21:18:43 -0800 (PST) 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=xvkcynJDIga+LLGozxwo 32umuBw=; b=dTYxx9YTaSxcpM9Q/dLVXuaVRjextqRLHu6vsF4LauDddJzS1xqA ATBYYhKto0jJRVDEv+pLeWsm60yMKX6/tRa380/yT6ga7PSPjvcy4xjXWG0Bh1Wv c+XF8v2nnJt+y0kicpZcp+QfHW7FLmfYKpX61LTDCALhq25UUxeRAQA= Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (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 4AEFFBC032 for ; Fri, 22 Feb 2013 21:18:43 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l13so1682074wie.2 for ; Fri, 22 Feb 2013 21:18:42 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.63.109 with SMTP id f13mr7780750wjs.11.1361596722094; Fri, 22 Feb 2013 21:18:42 -0800 (PST) Received: by 10.216.148.193 with HTTP; Fri, 22 Feb 2013 21:18:41 -0800 (PST) In-Reply-To: <007101ce1178$ad58f8c0$080aea40$@augustcellars.com> References: <007101ce1178$ad58f8c0$080aea40$@augustcellars.com> Date: Fri, 22 Feb 2013 23:18:41 -0600 Message-ID: From: Nico Williams To: Jim Schaad Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org, draft-williams-kietten-channel-bound-flag@tools.ietf.org Subject: Re: [kitten] Review comments on draft-williams-kitten-channel-bound-flag-02 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, 23 Feb 2013 05:18:48 -0000 On Fri, Feb 22, 2013 at 9:48 PM, Jim Schaad wrote: > 1. In section 1.1 you say that it would be useless to allow security > context establishment if the acceptor provides context but the initiator s/context/CB/ ? I'll assume so. > does not, but the converse is not true. I need to have a greater > explanation that is present about why this would be true. It seems to me > that the both of them are equally useful or useless. The decision of which > to enable first would appear to be an arbitrary one and not one with solid > security reasoning. Well, no, it'd be useless if the acceptor provides CB, the initiator doesn't, and the acceptor doesn't find out. The way RFC2743 specifies the handling of CB callers only get to find out that both peers provided CB is when the CB did not match. There's no way for them to find out that both peers used CB and that the CB matched -- this is terrible! Fortunately the way implementations of RFC1964/4121 work acceptors fail when the acceptor provides CB and the initiator doesn't. But this creates problems for migration from not using CB to using CB: the acceptor needs to know early on if the initiator will be using CB, and in some application protocols that's not easy to do. The way to fix this, in the GSS tradition, is to have had a ret_flag to indicate whether both parties used CB and the CB matched. But we can't just add this ret_flag and otherwise revert to RFC2743 behavior, not safely. We need the acceptor mechanisms to know whether the app understands the new ret_flag. > 2. In section 1.4 - I think that I like this idea and want to bounce a > couple questions off of you. > > Would you expect that one could set mechanism specific security context > values as well as generic ones? As an example, in ABFAB could this be used > as a method for setting an authorization context SAML statement in the > authenticator that the mechanism could later use in an appropriate manner. > Since this would be tagged as being mechanism specific it would be ignored > by any other mechanism. Sure. Some such extensions strike me as more closely associated with credential handles, and some as more closely associated with security contexts. Therefore I think there's still room to standardize a GSS_Set_cred_option(). > Would you expect that one could query about context values used that are not > setup as return flags after authentication has completed? Thus one could > ask if this security context value was used or not when establishing > security context? Yes, but the goal here is to discover what results at the end of successful security context establishment. Ah, I now understand your comment about getter functions. Yes, anything that can result beyond what the application provided as inputs, and particularly those inputs that are provided by the other peer, should be made available via an inquiry function like the existing GSS_Inquire_context(). > 3. In section 1.4 - are the two required inputs supposed to be a security > context handle and a credential handle? Currently it says a context handle > and an input context token. This may be a deficiency on my part for > understanding. It may also be that the word context should be removed and > it should just be 'an input token' Credential handles can be defaulted, so they're not required as such. But context handles and input (and output) tokens are a sine qua non of GSS security context establishment. All other inputs to GSS_Init/Accept_sec_context() take default values, even the mech_type and target_name arguments -- all of them but context handle and input token. > 4. In section 2 s/for setting a) creating/for a) creating/ > Same sentence. There should be an and between the a)... and b)... as > the currently existing and is two sub-clauses in b) Will be fixed. > 5. In section 2.2 - There is a problem with the text "Return flags > understood by the caller" in that this is an input but the text is written > as if it were an output. Suggest "Specify return flags understood by the > caller" You're right, I intended "return flags" to be read as a noun phrase -- i.e., "return" is not a verb here. I'll fic it as "The set of return flags understood by the caller". > 6. In section 2.2 - does it make more sense to do an override or to do an > OR on the request flags? It seems odd that one would ignore them based on > passing in a value of 0, what if that is what they really want? Without the > ability to query for them from the context it seems odd to potentially > ignore flags set elsewhere - and thus introduce a bug - while doing the or > (along with a query) might be more predictable. Ah, here I'm looking forward to the simplified API I-D and so we end up with a case where the caller can set req_flags with this function *and* in GSS_Init_sec_context() (i.e., not using the rest of the simplified API). I needed to say something about this redundancy. I figured that allowing an empty req flag set in the call to GSS_Init_sec_context() to mean "use the req_flags specified in the GSS_Set_context_flags() call" would be useful in that it would allow call sites for GSS_Init_sec_context() to get lexically shorter. Perhaps I could re-phrase this better? > 7. In section 3 - Should there be some type of error if an application > shall have a) not provided channel bindings to GSS_Init_sec_context() or > GSS_Accept_sec_context() and b) indicated support for the > ret-channel-bound-flag flag? This would indicate to me that some type of > programming error occurred as the return should never have the flag set. Whether there are CB data may vary contextually, but whether the app understands the new flag should not. Since it's useful to be able to use a constant set of req_flags I think it's best to not consider this case an error. > 8. In section 4 - I think that it is worthwhile documenting that if an > initiator passes in a channel binding and either you are in the current > state or the mechanism has not implemented this document then there is a > potential secrurity problem as the channel binding will not have occurred > and the initiator might assume that it had. The Kerberos mechanism has no way for an acceptor to indicate CB success to the initiator. Is this a security problem? Back when we were designing RFC4121 I argued that it was, but Sam made a better argument that it wasn't. I still have misgivings about that, but I'll let Sam explain his argument. In any case, what I'll do is add a note (in section 2.3) that "some mechanisms have no way for the acceptor to signal CB success to the initiator, in which case GSS_Init_sec_context() MUST NOT output the ret_channel_bound_flag". > Also, If the selected mechanism does not implemented this feature then it > will always appear as channel binding did not occur even if it did as the > mechanism would not return the appropriate flag. True, but here we fall back on the as-currently-implemented behavior rather than the RFC2743 behavior, and that happens to work well enough. Migration is complicated, but then you just implement this and upgrade :) Nico -- From nico@cryptonector.com Fri Feb 22 21:22:55 2013 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 5897921E808F for ; Fri, 22 Feb 2013 21:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.336 X-Spam-Level: X-Spam-Status: No, score=-3.336 tagged_above=-999 required=5 tests=[AWL=-1.359, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YapkJM8HIU-L for ; Fri, 22 Feb 2013 21:22:54 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id C042F21E8084 for ; Fri, 22 Feb 2013 21:22:54 -0800 (PST) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 6EE1C674060 for ; Fri, 22 Feb 2013 21:22:54 -0800 (PST) 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=rnWMVLIYfduH//sliFr0jCTvapw=; b=nSB5T5BdK7N ftqk0NQGSSdObyiUL1dt5lnKNOEvkEiKMeHe5m3znApImFMLRbYglsXSi60WOQeK 2Q0t4ad0xGPyWJc9QVH5C7IWiWsUCRM6o7SZbOupAvqu5p5VVOFbjZiywcWNkHso oS1PAalMN9MbdzI/iOn4ONZjCvJpNSO0= Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 18FEE674058 for ; Fri, 22 Feb 2013 21:22:53 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so1089850wgb.9 for ; Fri, 22 Feb 2013 21:22:52 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.87.98 with SMTP id w2mr1226443wiz.30.1361596972722; Fri, 22 Feb 2013 21:22:52 -0800 (PST) Received: by 10.216.148.193 with HTTP; Fri, 22 Feb 2013 21:22:52 -0800 (PST) In-Reply-To: References: <007101ce1178$ad58f8c0$080aea40$@augustcellars.com> Date: Fri, 22 Feb 2013 23:22:52 -0600 Message-ID: From: Nico Williams To: Luke Howard Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org, draft-williams-kietten-channel-bound-flag@tools.ietf.org Subject: Re: [kitten] Review comments on draft-williams-kitten-channel-bound-flag-02 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, 23 Feb 2013 05:22:55 -0000 On Fri, Feb 22, 2013 at 10:43 PM, Luke Howard wrote: >> Would you expect that one could set mechanism specific security context >> values as well as generic ones? As an example, in ABFAB could this be u= sed >> as a method for setting an authorization context SAML statement in the >> authenticator that the mechanism could later use in an appropriate manne= r. > > You can do something similar today by calling GSS_Set_name_attribute() on= a name passed to GSS_Acquire_cred(). I implemented something like this a w= hile ago, so that you could pass a SAML assertion in when doing protocol tr= ansition (see http://k5wiki.kerberos.org/wiki/Projects/SAMLInKerberos). Right. Is some extension best represented as a name attribute, credential option, or security context option? It's a somewhat subjective call. Authorization data is seen as attributes of the NAME of the peer (and the local principal too), given the API we have, and this seems reasonable to me. I would say that things like "cryptographic profiles" should be attributes of credentials, but in some cases (e.g., when public keys are principals' names) they could also be attributes of names. Whether the app support the new ret_channel_bound_flag is... something I'd associate with a library context handle, if the GSS-API had one, but since it lacks it the only reasonable places to set it are: cred handles, or "empty" (primitive?) security context handles. Nico -- From metze@samba.org Fri Feb 22 22:32:36 2013 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 A032E21F8F1A for ; Fri, 22 Feb 2013 22:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4w5PXZ6XSYN5 for ; Fri, 22 Feb 2013 22:32:36 -0800 (PST) Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id C32A121F8EA7 for ; Fri, 22 Feb 2013 22:32:35 -0800 (PST) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h2IziqwDGkR4lBo2mGrr2y5FyCzLwkNmsegOxfIchrgnNjIQDvpeA= X-RZG-CLASS-ID: mo05 Received: from [IPv6:2001:4dd0:ff00:87f3:890b:e60a:50b:23c0] ([2001:4dd0:ff00:87f3:890b:e60a:50b:23c0]) by smtp.strato.de (jorabe mo19) (RZmta 31.17 AUTH) with ESMTPA id C00186p1N5SdS8 ; Sat, 23 Feb 2013 07:32:28 +0100 (CET) Message-ID: <5128626F.2040307@samba.org> Date: Sat, 23 Feb 2013 07:32:15 +0100 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig522954FF0565A9AB984CE1B1" Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 06:32:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig522954FF0565A9AB984CE1B1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Nico, > Too late for submitting -00s. So here: >=20 > https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt >=20 Note that if GSS_S_CONTINUE_NEEDED is returned but no security context is output, then the function must be called again upon async I/O completion notification. OM_uint32 gss_step_context(OM_uint32 *minor_status, gss_ctx_id_t context, gss_const_buffer_t input_token, gss_buffer_t output_token, gss_const_OID *actual_mech); When getting GSS_S_CONTINUE_NEEDED, how can the caller detect the differe= nce between an empty output_token and no output_token? metze --------------enig522954FF0565A9AB984CE1B1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEoYnMACgkQm70gjA5TCD9qPwCfRflSqpI5IeNQ0NsclFw4Ssme p4sAn3w5EA27lHwVjxr1Aa7yJUFIWjdY =vhgq -----END PGP SIGNATURE----- --------------enig522954FF0565A9AB984CE1B1-- From metze@samba.org Fri Feb 22 22:53:43 2013 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 0FD4321F8F5A for ; Fri, 22 Feb 2013 22:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLhqWtdWH7pi for ; Fri, 22 Feb 2013 22:53:42 -0800 (PST) Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id 262BF21F8F57 for ; Fri, 22 Feb 2013 22:53:41 -0800 (PST) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h2IziqwDGkR4lBo2mGrr2y5FyCzLwkNmsegOxfIchrgnNjIQDvpeA= X-RZG-CLASS-ID: mo05 Received: from [IPv6:2001:4dd0:ff00:87f3:890b:e60a:50b:23c0] ([2001:4dd0:ff00:87f3:890b:e60a:50b:23c0]) by smtp.strato.de (josoe mo23) (RZmta 31.17 AUTH) with ESMTPA id I04775p1N6ibo1 ; Sat, 23 Feb 2013 07:53:41 +0100 (CET) Message-ID: <51286770.2090508@samba.org> Date: Sat, 23 Feb 2013 07:53:36 +0100 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nico Williams References: <5128626F.2040307@samba.org> In-Reply-To: <5128626F.2040307@samba.org> X-Enigmail-Version: 1.4.6 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig31F1CF47A18E6DB19397242A" Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 06:53:43 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig31F1CF47A18E6DB19397242A Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 23.02.2013 07:32, schrieb Stefan (metze) Metzmacher: > Hi Nico, >=20 >> Too late for submitting -00s. So here: >> >> https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt >> >=20 > Note that if GSS_S_CONTINUE_NEEDED is returned but no security > context is output, then the function must be called again upon async= > I/O completion notification. >=20 > OM_uint32 > gss_step_context(OM_uint32 *minor_status, > gss_ctx_id_t context, > gss_const_buffer_t input_token, > gss_buffer_t output_token, > gss_const_OID *actual_mech); >=20 > When getting GSS_S_CONTINUE_NEEDED, how can the caller detect the diffe= rence > between an empty output_token and no output_token? I think an explicit return value would be better to indicate the need of an additional step. Something like GSS_S_INCOMPLETE_STEP, GSS_S_STEP_REQUIRED or GSS_S_STEP_NEEDED. This would make the required logic in the caller much easier as it only needs a simple if (ret =3D=3D GSS_S_INCOMPLETE_STEP) { } instead of a more complex statement that need to work out the condition based on multiple variables. metze --------------enig31F1CF47A18E6DB19397242A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEoZ3QACgkQm70gjA5TCD/SJgCgkEW7+LBC8CfsoDWFPfYDXmqm WXUAoMv7AGm5a/kdoWCzb6Lbw6EqVkc/ =Gpd6 -----END PGP SIGNATURE----- --------------enig31F1CF47A18E6DB19397242A-- From metze@samba.org Fri Feb 22 23:09:48 2013 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 E8CAF21F8F5C for ; Fri, 22 Feb 2013 23:09:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SIhMMuk0U-p for ; Fri, 22 Feb 2013 23:09:48 -0800 (PST) Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF8621F8F57 for ; Fri, 22 Feb 2013 23:09:47 -0800 (PST) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h2IziqwDGkR4lBo2mGrr2y5FyCzLwkNmsegOxfIchrgnNjIQDvpeA= X-RZG-CLASS-ID: mo05 Received: from [IPv6:2001:4dd0:ff00:87f3:890b:e60a:50b:23c0] ([2001:4dd0:ff00:87f3:890b:e60a:50b:23c0]) by smtp.strato.de (joses mo37) (RZmta 31.17 AUTH) with ESMTPA id 401d2fp1N5rlg6 ; Sat, 23 Feb 2013 08:09:41 +0100 (CET) Message-ID: <51286B31.7010605@samba.org> Date: Sat, 23 Feb 2013 08:09:37 +0100 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF409F41B68E5A627456F6A83" Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 07:09:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF409F41B68E5A627456F6A83 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 22.02.2013 23:31, schrieb Nico Williams: > Too late for submitting -00s. So here: >=20 > https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt The verto library has a lot of clever logic in it to find the event loop that the application might be using, as long as the application uses an event loop library known to verto, including: glib, libev, libevent, and tevent. Verto is portable to Unix and Unix-like systems (including Linux and BSDs) as well as to Windows. Where is that "clever logic"? This worries me a bit, the application should either explicitly tell the gss library which verto_ctx context to use or the gss library should create its own context. If the clever detection only tries to find out which verto backend is used, it's fine, but it should not try to find an explicit global verto_ctx. I'm not sure if the specification needs to include a function to set a verto_ctx on the gss_ctx_id_t, but it should at least mention that the specific implementation should have a function like that. metze --------------enigF409F41B68E5A627456F6A83 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEoazUACgkQm70gjA5TCD8T/gCfdL4PPbY7HHdXMtU6I935mSAU IPAAn1SajOFCQgusDycOSDVXdkqlkDvy =+al9 -----END PGP SIGNATURE----- --------------enigF409F41B68E5A627456F6A83-- From nico@cryptonector.com Sat Feb 23 00:19:03 2013 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 C1B5121F8DCB for ; Sat, 23 Feb 2013 00:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=-1.546, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHXZTH9nMu+F for ; Sat, 23 Feb 2013 00:19:03 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 1863E21F8D0B for ; Sat, 23 Feb 2013 00:19:03 -0800 (PST) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 2536777805B for ; Sat, 23 Feb 2013 00:18:52 -0800 (PST) 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=Olr+lijWJ7v3Y83Jqqig iBwgDeE=; b=U0zYYyVNUPSvJX1onV2CbdO6QQBzsqsjB170/K6r1mqPbgrBR8o1 bXj6L3RuZdak1wS5BCUlbT/U5IxP8ejM3vMwQjKgTnHYxPf9AMsnGuawwWpHYqVy 3RD4hVfk696TOwZn90aKwCGfTiS+kkLHRnNpQcaNx6MBsMVYUS+BSd8= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPSA id C33EA778057 for ; Sat, 23 Feb 2013 00:18:51 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so1745019wib.9 for ; Sat, 23 Feb 2013 00:18:50 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr8168155wjr.33.1361607530590; Sat, 23 Feb 2013 00:18:50 -0800 (PST) Received: by 10.216.148.193 with HTTP; Sat, 23 Feb 2013 00:18:50 -0800 (PST) In-Reply-To: <5128626F.2040307@samba.org> References: <5128626F.2040307@samba.org> Date: Sat, 23 Feb 2013 02:18:50 -0600 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 08:19:03 -0000 On Sat, Feb 23, 2013 at 12:32 AM, Stefan (metze) Metzmacher wrote: > Hi Nico, > >> Too late for submitting -00s. So here: >> >> https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt >> > > Note that if GSS_S_CONTINUE_NEEDED is returned but no security > context is output, then the function must be called again upon async > I/O completion notification. oops, that should read "...but no security context _token_ is output, ...". > OM_uint32 > gss_step_context(OM_uint32 *minor_status, > gss_ctx_id_t context, > gss_const_buffer_t input_token, > gss_buffer_t output_token, > gss_const_OID *actual_mech); > > When getting GSS_S_CONTINUE_NEEDED, how can the caller detect the difference > between an empty output_token and no output_token? The GSS-API does not allow empty tokens, thus making this a distinction without a difference :) Nico -- From nico@cryptonector.com Sat Feb 23 00:22:13 2013 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 17D2021F8DCB for ; Sat, 23 Feb 2013 00:22:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=-1.523, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id khrRFxebNZl5 for ; Sat, 23 Feb 2013 00:22:12 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 86B6421F8D0B for ; Sat, 23 Feb 2013 00:22:12 -0800 (PST) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 4BAE96B007B for ; Sat, 23 Feb 2013 00:22:12 -0800 (PST) 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=LokQAqi4+EMBxxKO7/q5 ynQqRpM=; b=pxzaw5sheg6oK0NBi6gP1jP/psbDIJSO1MCge/WyFrINt5OTwSa7 1vCC+Lwm7CHWxV+YVGkacHgbhriXw5sEWFyoHCgPiMMSDZAqNY0/68sGwAeq2ewm bKleB1saPo3rIEInP1Ya6sxz+F7Zds7CjHpOfxaLbkVZ2+5vNE22tDE= Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (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 EB2796B0059 for ; Sat, 23 Feb 2013 00:22:11 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hm11so2960840wib.1 for ; Sat, 23 Feb 2013 00:22:10 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.87.98 with SMTP id w2mr1719429wiz.30.1361607730485; Sat, 23 Feb 2013 00:22:10 -0800 (PST) Received: by 10.216.148.193 with HTTP; Sat, 23 Feb 2013 00:22:10 -0800 (PST) In-Reply-To: <51286770.2090508@samba.org> References: <5128626F.2040307@samba.org> <51286770.2090508@samba.org> Date: Sat, 23 Feb 2013 02:22:10 -0600 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 08:22:13 -0000 On Sat, Feb 23, 2013 at 12:53 AM, Stefan (metze) Metzmacher wrote: > I think an explicit return value would be better to indicate the need of > an additional step. Something like GSS_S_INCOMPLETE_STEP, > GSS_S_STEP_REQUIRED > or GSS_S_STEP_NEEDED. Maybe, but supplementary major status codes are in short supply (them being a bitmask of 10 bits, IIRC), so I figured if I could avoid it... But I tend to agree that a GSS_S_WOULDBLOCK (or whatever appropriate name) would be better, that perhaps I am being too cautious about burning a supplementary code bit. (Also, maybe this should not be considered a supplementary code...) Nico -- From nico@cryptonector.com Sat Feb 23 00:30:05 2013 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 C619421F87A3 for ; Sat, 23 Feb 2013 00:30:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.314 X-Spam-Level: X-Spam-Status: No, score=-3.314 tagged_above=-999 required=5 tests=[AWL=-1.337, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHx13bdRBFO1 for ; Sat, 23 Feb 2013 00:30:05 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADDA21F8722 for ; Sat, 23 Feb 2013 00:30:05 -0800 (PST) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id D430494065 for ; Sat, 23 Feb 2013 00:30:04 -0800 (PST) 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=s0RdJSPd1WD1HsevDVk0 00YP+8k=; b=BGeUwMYp98Nm6FwPxZzYLJ+Hu74XZhlwJ56xLm4tsPJM3lg6Fh6M /lfeZ+houZNa34vyA3axkxm7mbgO/Dsp5mqYHgbfqo3zn3rqxAR5vWxaV0/jPr4P I8YVbdSsgra0jnaXo2xXXu9hpKQJ0V/0SSTuiQdFhF/Ymgjvzuj8hb8= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (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 842DF9405E for ; Sat, 23 Feb 2013 00:30:04 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so1115252wey.21 for ; Sat, 23 Feb 2013 00:30:03 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.94.69 with SMTP id da5mr1733063wib.30.1361608203106; Sat, 23 Feb 2013 00:30:03 -0800 (PST) Received: by 10.216.148.193 with HTTP; Sat, 23 Feb 2013 00:30:03 -0800 (PST) In-Reply-To: <51286B31.7010605@samba.org> References: <51286B31.7010605@samba.org> Date: Sat, 23 Feb 2013 02:30:03 -0600 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 08:30:05 -0000 On Sat, Feb 23, 2013 at 1:09 AM, Stefan (metze) Metzmacher wrote: > Am 22.02.2013 23:31, schrieb Nico Williams: >> Too late for submitting -00s. So here: >> >> https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt > > The verto library has a lot of clever logic in it to find the > event loop that the application might be using, as long as the > application uses an event loop library known to verto, > including: glib, libev, libevent, and tevent. Verto is portable to > Unix and Unix-like systems (including Linux and BSDs) > as well as to Windows. > > Where is that "clever logic"? You'd have to look at the code. Basically verto looks through the process (using, e.g., dlinfo(), dladdr() and so on on Unix, and similar on Windows) for a supported library that implements an event loop and that has an event loop active. > This worries me a bit, the application should either explicitly > tell the gss library which verto_ctx context to use > or the gss library should create its own context. I think the mech should use the default loop. The problem here really is that if we want to have the app tell the mech what loop to use then we need to get extremely detailed, and probably provide many options, to make the result portable. It's not really a business I want to be in unless we were to agree that neither using something like verto nor starting a thread to run an event loop are acceptable. Since we have barely begun to discuss this (verto and/or bg threads) I think it's too soon to tackle a third alternative. I am also of the opinion that a) app developers should not be in the business of providing event loop wrappers or implementations, b) mech implementors will find either verto or starting a thread to run an event loop acceptable. > If the clever detection only tries to find out which verto backend is > used, it's fine, but it should not try to find an explicit global > verto_ctx. Why not? Assume you know more about verto than I do (a likely-correct assumption). > I'm not sure if the specification needs to include a > function to set a verto_ctx on the gss_ctx_id_t, > but it should at least mention that the specific implementation > should have a function like that. Possibly. But then someone will say they don't want to use verto, they want to use libevent. And someone else will complain and say they want libev, and so on. Where do we stop then? This is why I find an implicit event loop, a la grand central, so appealing. Nico -- From Volker.Lendecke@SerNet.DE Sat Feb 23 06:44:12 2013 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 AF3CD21F8F52 for ; Sat, 23 Feb 2013 06:44:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cTXxbaRRJaqz for ; Sat, 23 Feb 2013 06:44:11 -0800 (PST) Received: from mail.SerNet.de (mail1.SerNet.de [193.175.80.2]) by ietfa.amsl.com (Postfix) with ESMTP id B7A3C21F8F2E for ; Sat, 23 Feb 2013 06:44:11 -0800 (PST) Received: from intern.SerNet.DE by mail.SerNet.DE with esmtp (Exim 4.72 #1) id 1U9GKd-000083-TP; Sat, 23 Feb 2013 15:44:07 +0100 Received: by intern.SerNet.DE id 1U9GKd-006c37-LP; Sat, 23 Feb 2013 15:44:07 +0100 Received: by intern.SerNet.DE id 1U9GKd-006c2z-Gq; Sat, 23 Feb 2013 15:44:07 +0100 Date: Sat, 23 Feb 2013 15:44:07 +0100 From: Volker Lendecke To: Nico Williams References: <51286B31.7010605@samba.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Message-Id: Organization: SerNet GmbH, Goettingen, Germany Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Volker.Lendecke@SerNet.DE List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 14:44:12 -0000 On Sat, Feb 23, 2013 at 02:30:03AM -0600, Nico Williams wrote: > On Sat, Feb 23, 2013 at 1:09 AM, Stefan (metze) Metzmacher > wrote: > > Am 22.02.2013 23:31, schrieb Nico Williams: > >> Too late for submitting -00s. So here: > >> > >> https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt > > > > The verto library has a lot of clever logic in it to find the > > event loop that the application might be using, as long as the > > application uses an event loop library known to verto, > > including: glib, libev, libevent, and tevent. Verto is portable to > > Unix and Unix-like systems (including Linux and BSDs) > > as well as to Windows. > > > > Where is that "clever logic"? > > You'd have to look at the code. Basically verto looks through the > process (using, e.g., dlinfo(), dladdr() and so on on Unix, and > similar on Windows) for a supported library that implements an event > loop and that has an event loop active. Samba has multiple tevent context structs alive simultaneously. Only one really active and used at a time, but there are more than one allocated. Is that covered? Will it find the right one? With best regards, Volker Lendecke -- SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt@sernet.de ********************************************************** visit us at CeBIT: March 5th - 9th 2013, hall 6, booth E15 all about SAMBA and verinice, firewalls, Linux and Windows free tickets available via email here : cebit@sernet.com ! ********************************************************** From ghudson@mit.edu Sat Feb 23 07:53:04 2013 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 0887D21F88AC for ; Sat, 23 Feb 2013 07:53:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wmli8NEL5A1h for ; Sat, 23 Feb 2013 07:53:03 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 547C621F8853 for ; Sat, 23 Feb 2013 07:53:02 -0800 (PST) X-AuditID: 12074422-b7f5c6d000000545-2a-5128e5db73e9 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id F3.EE.01349.BD5E8215; Sat, 23 Feb 2013 10:52:59 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r1NFqxD1028428; Sat, 23 Feb 2013 10:52:59 -0500 Received: from [18.101.8.173] (VPN-18-101-8-173.MIT.EDU [18.101.8.173]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r1NFqvQ2016057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 23 Feb 2013 10:52:58 -0500 Message-ID: <5128E5D9.2010505@mit.edu> Date: Sat, 23 Feb 2013 10:52:57 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nico Williams References: <51286B31.7010605@samba.org> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT1739VCPQ4MV6S4ujm1exWFxc9pPF 4tS1I2wOzB4vT51j9Fiy5CeTx9xdfYwBzFFcNimpOZllqUX6dglcGadW7GEtaOCs+LDuBXMD 40L2LkYODgkBE4nVz5K6GDmBTDGJC/fWs3UxcnEICexjlDh67zwrhLORUeLU8rNMIFVCAkeY JHomKIDYvAJqEr1nV7KA2CwCqhL7NuwDq2ETUJY4ePYbWFxUIERi0ZnpbBD1ghInZz4Bi4sI aEpcn7cULM4s4CTx+N19NpCDhAX0JA7080Ps3cQoMXP7XFaQGk6BQIm1i08wQVwqKbFoWicL RK+OxLu+B8wQtrzE9rdzmCcwCs1Csm4WkrJZSMoWMDKvYpRNya3SzU3MzClOTdYtTk7My0st 0jXVy80s0UtNKd3ECA51F6UdjD8PKh1iFOBgVOLhXTFZPVCINbGsuDL3EKMkB5OSKO/DRxqB QnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4ra4B5XhTEiurUovyYVLSHCxK4rzXUm76CwmkJ5ak ZqemFqQWwWRlODiUJHj9nwA1ChalpqdWpGXmlCCkmTg4QYbzAA1PAKnhLS5IzC3OTIfIn2JU lBLnDXkMlBAASWSU5sH1wlLRK0ZxoFeEeXNB2nmAaQyu+xXQYCagwQ911EEGlyQipKQaGH1n 5M2eX3Vk4cvt8flu3m8m8Yruu+E4u2xqtckdA+b5F4tOrr0ccidLuOIla/DxdQsmcixqNDPb KHbWZvX5i3qc39fZF9U83+45o9kyQbGk1mGnXf7Lk3USz3wyL9YxFfEsr1xVopwmdaRwFvfS U48MeW9IH7v7Uyxz/9lckeiyGVvyucuWb1ZiKc5INNRiLipOBAA3O8yKIAMAAA== Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 15:53:04 -0000 On 02/23/2013 03:30 AM, Nico Williams wrote: > Possibly. But then someone will say they don't want to use verto, > they want to use libevent. They could use libevent. The application links against libverto-libevent, calls verto_convert_libevent() to produce a verto_ctx *, and passes that to GSSAPI. When the GSSAPI implementation calls verto_add_* functions on that context, events will be registered in the application's libevent loop. That's the whole point of libverto, and there's no linker magic required for that. Things get tougher if the application wants to use an event loop which libverto doesn't have a wrapper for, but I think even then it's possible for the application to provide a shim (which tends to be about 200 lines of code). libverto is not so magic that it can actually find the application's event loop, if such a thing were even well-defined. It used to have code to try to use the same event loop *library* as the application, just as a VM usage optimization, but I believe that's gone. libverto uses a small amount of linker magic to find its own module libraries at runtime, but that's it. From nico@cryptonector.com Sat Feb 23 13:41:38 2013 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 2A36621F8E58 for ; Sat, 23 Feb 2013 13:41:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.293 X-Spam-Level: X-Spam-Status: No, score=-3.293 tagged_above=-999 required=5 tests=[AWL=-1.316, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e-xD7dSsWVLp for ; Sat, 23 Feb 2013 13:41:37 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id AEE3621F8E50 for ; Sat, 23 Feb 2013 13:41:37 -0800 (PST) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 53F38350072 for ; Sat, 23 Feb 2013 13:41:37 -0800 (PST) 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=2vueH3//fM5qDYs7v3RM Vdt4Bzk=; b=XT59lHhkBTUw4UaiIpkPeyAC42XFqEoz+PyT2t3RzrOBNLVlaZtN IzX8Dg+ejjfyv90rFtpJOAmyA8KtDmiJJR8S719wP6fPOdsc/XzLjP2rz6VjfqsY RNzq5lEzIar8kIqGta3IypLJz5fsF8ebbonCSVoBV0kzm+Z4PieCh/s= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 06D7635005B for ; Sat, 23 Feb 2013 13:41:36 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id 12so1469095wgh.7 for ; Sat, 23 Feb 2013 13:41:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.76.84 with SMTP id i20mr4248765wiw.9.1361655695517; Sat, 23 Feb 2013 13:41:35 -0800 (PST) Received: by 10.216.148.193 with HTTP; Sat, 23 Feb 2013 13:41:35 -0800 (PST) In-Reply-To: <5128E5D9.2010505@mit.edu> References: <51286B31.7010605@samba.org> <5128E5D9.2010505@mit.edu> Date: Sat, 23 Feb 2013 15:41:35 -0600 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 21:41:38 -0000 OK, so we actually need to define C prototypes for event loop functions to be passed to the GSS-API, or otherwise make a normative reference to verto, libevent, or the like. Bummer. From nico@cryptonector.com Sat Feb 23 15:08:28 2013 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 2364821F84B6 for ; Sat, 23 Feb 2013 15:08:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=-1.295, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fg0YPo8EuZF5 for ; Sat, 23 Feb 2013 15:08:27 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id A6A4521F84B1 for ; Sat, 23 Feb 2013 15:08:27 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 702603B805C for ; Sat, 23 Feb 2013 15:08:27 -0800 (PST) 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=BS1AOr1wLztNM/91qVyx X0Efo/Q=; b=TaYowFqRpWZNOQq8eqCJJiX45HeuqbBBjtR9tYRSfCCdtObzsGU6 o5heuClQW1R8aGZVzuFK+GKDVfBR8bS3vm6aHRSA2gfxbUSSoANEcSRvyKGwgGum ST7fO726Ri2ebG/T+kY//UJTJyqygHnzkpY8jkFnuyH86dxktT9EbN8= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 1520D3B805B for ; Sat, 23 Feb 2013 15:08:26 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so1484393wey.31 for ; Sat, 23 Feb 2013 15:08:25 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.74.228 with SMTP id x4mr4486470wiv.0.1361660905632; Sat, 23 Feb 2013 15:08:25 -0800 (PST) Received: by 10.216.148.193 with HTTP; Sat, 23 Feb 2013 15:08:25 -0800 (PST) In-Reply-To: References: <51286B31.7010605@samba.org> <5128E5D9.2010505@mit.edu> Date: Sat, 23 Feb 2013 17:08:25 -0600 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 23:08:28 -0000 I will gladly take text (and co-authors) about how to pass an event loop to the mech. I will also gladly settle for having no standard way to do that, leaving threads as the only standard solution, but with actual implementations that support passing event loops to the mech. Nico -- From nico@cryptonector.com Sat Feb 23 15:16:09 2013 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 1976021F8E43 for ; Sat, 23 Feb 2013 15:16:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.251 X-Spam-Level: X-Spam-Status: No, score=-3.251 tagged_above=-999 required=5 tests=[AWL=-1.274, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-yHP8nNSfA1 for ; Sat, 23 Feb 2013 15:16:08 -0800 (PST) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 98C0021F8E3A for ; Sat, 23 Feb 2013 15:16:08 -0800 (PST) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 5B3C67E405D for ; Sat, 23 Feb 2013 15:16:08 -0800 (PST) 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=v9lS7uYZMFB6894sQqlP rPODRAw=; b=fLuvqZXYwrfebknsLI+E7Hzl5U7EF+SWEsC/OMi2pyqb/qEWNaOa KBZeFilkKvjiSsZF564tFGdV/KpD/5lVGTGeBvc2auXkUg56Yl1TT5f+3WEwnYWT azWpWT6WdIhmDGyW/nGZaDJjfRGflHVsZIie1Gigi/Zu8nECSWyy1vQ= Received: from mail-we0-f177.google.com (mail-we0-f177.google.com [74.125.82.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id 068527E4057 for ; Sat, 23 Feb 2013 15:16:07 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id d7so1509974wer.22 for ; Sat, 23 Feb 2013 15:16:06 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.109.82 with SMTP id hq18mr4512063wib.0.1361661366611; Sat, 23 Feb 2013 15:16:06 -0800 (PST) Received: by 10.216.148.193 with HTTP; Sat, 23 Feb 2013 15:16:06 -0800 (PST) In-Reply-To: <51286770.2090508@samba.org> References: <5128626F.2040307@samba.org> <51286770.2090508@samba.org> Date: Sat, 23 Feb 2013 17:16:06 -0600 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 23 Feb 2013 23:16:09 -0000 On Sat, Feb 23, 2013 at 12:53 AM, Stefan (metze) Metzmacher wrote: > I think an explicit return value would be better to indicate the need of > an additional step. Something like GSS_S_INCOMPLETE_STEP, > GSS_S_STEP_REQUIRED > or GSS_S_STEP_NEEDED. > > This would make the required logic in the caller > much easier as it only needs a simple > if (ret == GSS_S_INCOMPLETE_STEP) { > > } > instead of a more complex statement that need to work out the > condition based on multiple variables. We already have this sort of situation in the GSS-API: when GSS_S_COMPLETE is returned an output token can also be returned. So I don't feel too bad about adding another one of these :) From nico@cryptonector.com Sat Feb 23 16:38:25 2013 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 A958721F8EC5 for ; Sat, 23 Feb 2013 16:38:25 -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=[AWL=-2.649, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9k6kRZhIw2xD for ; Sat, 23 Feb 2013 16:38:24 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id C6FCB21F8BA6 for ; Sat, 23 Feb 2013 16:38:24 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 7B257BC041 for ; Sat, 23 Feb 2013 16:38:24 -0800 (PST) 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=G9N/0NDNsJYlFQxJWjN3+Yy7XBE=; b=WVNLiRfFhdI HN+GE+D8pK5VWn2nyGSMpHS9dCU0dycpzhN3eYH/sZNsYMi5PTWIkn0oyQIkVFzk t9rFapkiwYH/ZGsWURuayTEbcntsV3oyOr4c9EmCk5CzJ77HoI/GVPN1xusn8oOr atdU7eViMpqrg8R942l70ZEGxTcAlcgk= Received: from mail-ia0-f178.google.com (mail-ia0-f178.google.com [209.85.210.178]) (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 5FA72BC032 for ; Sat, 23 Feb 2013 16:38:24 -0800 (PST) Received: by mail-ia0-f178.google.com with SMTP id y26so1540254iab.37 for ; Sat, 23 Feb 2013 16:38:23 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.50.88.168 with SMTP id bh8mr1395688igb.67.1361666303677; Sat, 23 Feb 2013 16:38:23 -0800 (PST) Received: by 10.64.102.201 with HTTP; Sat, 23 Feb 2013 16:38:23 -0800 (PST) Date: Sat, 23 Feb 2013 18:38:23 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [kitten] Simplified and async API try #2 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, 24 Feb 2013 00:38:25 -0000 > https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt I've come up with an idea regarding event loops and how to pass them in: just abstract them. Indicate an event loop type and pass in a void *, as well as optionally also a void * for the module implementing the event loop and optionally also a pointer to a dlsym()-/GetProcAddress()-like function. Specify several event loop types, recommend/require one to be implemented. Now we might look at this and decide that we don't want to have any more than one event loop type (say, verto). Apps that don't use it can implement it as a shim on top of whatever they do use. I'd like this. Nico -- From hartmans@mit.edu Sat Feb 23 18:31:51 2013 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 B262C21F8EF2 for ; Sat, 23 Feb 2013 18:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.781 X-Spam-Level: X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ts+9VvK83+Xa for ; Sat, 23 Feb 2013 18:31:51 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 283CA21F8EE3 for ; Sat, 23 Feb 2013 18:31:43 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 9F9D020180; Sat, 23 Feb 2013 21:26:55 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 65281447B; Sat, 23 Feb 2013 21:31:36 -0500 (EST) From: Sam Hartman To: "Stefan \(metze\) Metzmacher" References: <51286B31.7010605@samba.org> Date: Sat, 23 Feb 2013 21:31:36 -0500 In-Reply-To: <51286B31.7010605@samba.org> (Stefan Metzmacher's message of "Sat, 23 Feb 2013 08:09:37 +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] Simplified and async API 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, 24 Feb 2013 02:31:51 -0000 >>>>> "Stefan" == Stefan (metze) Metzmacher writes: Stefan> I'm not sure if the specification needs to include a Stefan> function to set a verto_ctx on the gss_ctx_id_t, but it Stefan> should at least mention that the specific implementation Stefan> should have a function like that. I'm not at all sure this is true. I've been thinking about use cases. I can think of a lot of use cases for applications wanting an async interface to GSS. There are a lot of applications that call into GSS in a UI thread and block the entire application on GSS. That's undesirable. In some of these applications, an asynchronous interface would help. (Some of the applications just seem kind of hopeless) However, in many cases I think it would be fine an implementation handled this with threads and a blocking implementation of the GSS mechanisms. That is, I'd rather see this implemented in the mechglue calling into mechanisms using the synchronous interface. I'd like to get some experience with that before we start unwinding GSS implementations and turning them into async code. So, I'm sure it is not necessary that an implementation have a function to set an event loop context. I'm also unconvinced it is desirable to have such a function. I'd prefer to get experience with simpler implementations that do not involve event loops first. From nico@cryptonector.com Sat Feb 23 22:02:38 2013 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 2965021F88BD for ; Sat, 23 Feb 2013 22:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.231 X-Spam-Level: X-Spam-Status: No, score=-3.231 tagged_above=-999 required=5 tests=[AWL=-1.255, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBKjsxLSq6M5 for ; Sat, 23 Feb 2013 22:02:37 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 922FC21F87D3 for ; Sat, 23 Feb 2013 22:02:37 -0800 (PST) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 0981D2F4057 for ; Sat, 23 Feb 2013 22:02:37 -0800 (PST) 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=yRqSBjyUWiW0ekfNEry9 Bwkvzoo=; b=WknmbrcLYWB7/197vcVtEE9yOr2l4KGcQuXAZYebKNU4YmedwCmw SJh4fJg7J/9yPZcdUqzeWVReH/3fmWw0At5tmwr//sswwa4NuQFYGCEpVJ5boD7R G+yrk2dKKIS3YaL4RtGf5AcKgnEnxrqE+kcZRyskKdQk/UAwMEqwyyU= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id A29332F4059 for ; Sat, 23 Feb 2013 22:02:36 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id 8so1518772wgl.18 for ; Sat, 23 Feb 2013 22:02:35 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.94.69 with SMTP id da5mr5305920wib.30.1361685755108; Sat, 23 Feb 2013 22:02:35 -0800 (PST) Received: by 10.216.148.193 with HTTP; Sat, 23 Feb 2013 22:02:34 -0800 (PST) In-Reply-To: References: <51286B31.7010605@samba.org> Date: Sun, 24 Feb 2013 00:02:34 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: multipart/alternative; boundary=f46d0442694abaaa5204d6722b62 Cc: "kitten@ietf.org" Subject: Re: [kitten] Simplified and async API 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, 24 Feb 2013 06:02:38 -0000 --f46d0442694abaaa5204d6722b62 Content-Type: text/plain; charset=UTF-8 I agree with Sam. I've been playing with how to pass an event loop without getting in the business of either defining an event loop API in an RFC or needing a normative reference to such a thing in an RFC. I've yet to find a suitable solution. My proposal is that we only standardize an async interface that implies threading or implied event loops. We should still have C bindings extensions with explicit event loops if that's useful, but we should not standirdize them until we've gathered some experience with them. Nico -- --f46d0442694abaaa5204d6722b62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree with Sam. =C2=A0I've been playing with how to pass an event loo= p without getting in the business of either defining an event loop API in a= n RFC or needing a normative reference to such a thing in an RFC. =C2=A0I&#= 39;ve yet to find a suitable solution.

My proposal is that we only standardize an async interface t= hat implies threading or implied event loops. =C2=A0We should still have C = bindings extensions with explicit event loops if that's useful, but we = should not standirdize them until we've gathered some experience with t= hem.

Nico
--=C2=A0
--f46d0442694abaaa5204d6722b62-- From internet-drafts@ietf.org Sun Feb 24 11:34:32 2013 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 B8A1C21F90BF; Sun, 24 Feb 2013 11:34:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3g8BadBB0JLT; Sun, 24 Feb 2013 11:34:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B93D21F90C9; Sun, 24 Feb 2013 11:34:32 -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: 4.40 Message-ID: <20130224193432.31516.16122.idtracker@ietfa.amsl.com> Date: Sun, 24 Feb 2013 11:34:32 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-10.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: Sun, 24 Feb 2013 19:34:32 -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 Gen= eration Working Group of the IETF. Title : A set of SASL and GSS-API Mechanisms for OAuth Author(s) : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-10.txt Pages : 32 Date : 2013-02-24 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) or the Generic Security Service Application Program Interface (GSS-API) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP-based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a token. Tokens typically provided limited access rights and can be managed and revoked separately from the user's long-term credential (password). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wmills@yahoo-inc.com Sun Feb 24 14:38:08 2013 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 7D70521F8883 for ; Sun, 24 Feb 2013 14:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -18.099 X-Spam-Level: X-Spam-Status: No, score=-18.099 tagged_above=-999 required=5 tests=[AWL=0.501, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqheAXR8yGqU for ; Sun, 24 Feb 2013 14:38:07 -0800 (PST) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by ietfa.amsl.com (Postfix) with ESMTP id BE4CE21F841D for ; Sun, 24 Feb 2013 14:38:07 -0800 (PST) Received: from GQ1-EX10-CAHT06.y.corp.yahoo.com (gq1-ex10-caht06.corp.gq1.yahoo.com [10.73.118.85]) by mrout1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id r1OMc1h4079153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 24 Feb 2013 14:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1361745482; bh=I/Liem5odgVNLhxlyLOwGXPa8NB2v2AwszKYl2BRU1Q=; h=References:Message-ID:Date:From:Reply-To:Subject:To:CC: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gMwZQwL2LAOzaVMuaNcjIS/2pjsvClqo+dR0tFvFbh20gYhT6YZrnhNCuGACl0Ytf 7PMbxwBHVN7xZXC6cdstE7XfWIO8qGStRi2nxoB1AX3Sx67aZNfgEw2D3fokF7cG8r ribsV426h0elBHIQ6G5ocUNDQgRFJXZMzLz09Yyo= Received: from omp1054.mail.ne1.yahoo.com (98.138.89.196) by GQ1-EX10-CAHT06.y.corp.yahoo.com (10.72.228.24) with Microsoft SMTP Server id 14.2.342.3; Sun, 24 Feb 2013 14:38:01 -0800 Received: (qmail 26794 invoked by uid 1000); 24 Feb 2013 22:38:01 -0000 Received: (qmail 17370 invoked by uid 60001); 24 Feb 2013 22:38:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo-inc.com; s=ginc1024; t=1361745480; bh=iQjUdp9ghzv3e9hv/74EHWdPzO+r/+/iW80+I8fs6Ig=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=m+zt3Uo3halMwi5pDXbTZafU4HAH5Tdf1h2JjibSXR1g1XTwpaX06K4hhjBuGWD+LteauZs01iqR+7CU7enoi5wMXQT8m0iTa+2rhgoxutVoTS04CVOjI80SvDt+rkpadN1yEd08NDgIesiCm3pNcpL3cbanfEQd0GsxPhHYBMc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ginc1024; d=yahoo-inc.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=gGDTbjz10e9tAzrVc/WDiG4qVZCMrB+WVRD8RLk29xK6QQIa1F8bxIKJf0UjOBQrW4BaTKG3dgG8ovZXZpXrNuCRHKYPs257T+EVeUWimLK/nOKRoBdOHEJ7UbcwrhHluNZXOBuHJoCMnRUo+R4idV5Y0Ar1EfJgyGdpX0n92yE=; X-YMail-OSG: mU6_Zc4VM1lIlkuYpiiKUJtZUOBkpjN0VK2yFHQbR.galm5 EWPzu9Wj3ljBCqniyK7RVk4y54PNTKRK3_3xSzHzDzFuusMdKUjKOePLU099 kHBA2YEH817cUCixc.ZuNNYYQ8Mn7mYm2Qa.E36MVv6IIb58KXE3NCWlXdRi OU64Kf3.3mgrs22E.AERV2z6wbhiTgCJ9aItGKS5rhnRkbWy8XbdxcIXFVyL T2ta1V9W7ItbXYymr1UeHvIg.TSCSx67vmI_Mg98QYagWxlU9e1iBcv_cZ_c e52GVzTr4ruN8eNEZgqtpB73Bp1WptMZ4NDae66_hFmRHN9YRTym3OAFJwy9 m528phhOz.9._FudrswhY0VT3N15zp7FLRsdhh6dHyiK2zaBkzlLYnisfQae xBChgQyHJiKhswBVEOsCz.ioEK3l8SvUK8HtNkjjwftoZriwwMGTxOW.bNLC 54HCDp5Pt6KrsXURPEO3p Received: from [209.131.62.115] by web125606.mail.ne1.yahoo.com via HTTP; Sun, 24 Feb 2013 14:38:00 PST X-Rocket-MIMEInfo: 001.001, SW4gQXBwZW5kaXggQSAiIGRpcmVjdG9ycyB3YXMiIGNoYW5nZXMgdG8gImRpcmVjdG9yIHdhcyIuwqAgSSdtICsxIG9uIGV2ZXJ5dGhpZ24gZWxzZSBJIHRoaW5rLgoKCgoKLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQpGcm9tOiAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPgpUbzogaS1kLWFubm91bmNlQGlldGYub3JnCkNjOiBraXR0ZW5AaWV0Zi5vcmcKU2VudDogU3VuZGF5LCBGZWJydWFyeSAyNCwgMjAxMyAxMTozNCBBTQpTdWJqZWN0OiBba2l0dGUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 References: <20130224193432.31516.16122.idtracker@ietfa.amsl.com> Message-ID: <1361745480.1010.YahooMailNeo@web125606.mail.ne1.yahoo.com> Date: Sun, 24 Feb 2013 14:38:00 -0800 From: Bill Mills To: "hannes.tschofenig@gmx.net" In-Reply-To: <20130224193432.31516.16122.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Milter-Version: master.31+4-gbc07cd5+ X-CLX-ID: 745482003 Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 22:38:08 -0000 In Appendix A " directors was" changes to "director was".=A0 I'm +1 on ever= ythign else I think.=0A=0A=0A=0A=0A----- Original Message -----=0AFrom: "in= ternet-drafts@ietf.org" =0ATo: i-d-announce@ietf.= org=0ACc: kitten@ietf.org=0ASent: Sunday, February 24, 2013 11:34 AM=0ASubj= ect: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-10.txt=0A=0A=0AA New= Internet-Draft is available from the on-line Internet-Drafts directories.= =0AThis draft is a work item of the Common Authentication Technology Next G= eneration Working Group of the IETF.=0A=0A=A0=A0=A0 Title=A0 =A0 =A0 =A0 = =A0 : A set of SASL and GSS-API Mechanisms for OAuth=0A=A0=A0=A0 Author(s)= =A0 =A0 =A0 : William Mills=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 Tim Showalter=0A=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= Hannes Tschofenig=0A=A0=A0=A0 Filename=A0 =A0 =A0 =A0 : draft-ietf-kitten-= sasl-oauth-10.txt=0A=A0=A0=A0 Pages=A0 =A0 =A0 =A0 =A0 : 32=0A=A0=A0=A0 Da= te=A0 =A0 =A0 =A0 =A0 =A0 : 2013-02-24=0A=0AAbstract:=0A=A0 OAuth enables = a third-party application to obtain limited access to a=0A=A0 protected re= source, either on behalf of a resource owner by=0A=A0 orchestrating an app= roval interaction, or by allowing the third-party=0A=A0 application to obt= ain access on its own behalf.=0A=0A=A0 This document defines how an applic= ation client uses credentials=0A=A0 obtained via OAuth over the Simple Aut= hentication and Security Layer=0A=A0 (SASL) or the Generic Security Servic= e Application Program Interface=0A=A0 (GSS-API) to access a protected reso= urce at a resource serve.=0A=A0 Thereby, it enables schemes defined within= the OAuth framework for=0A=A0 non-HTTP-based application protocols.=0A=0A= =A0 Clients typically store the user's long-term credential.=A0 This does,= =0A=A0 however, lead to significant security vulnerabilities, for example,= =0A=A0 when such a credential leaks.=A0 A significant benefit of OAuth for= =0A=A0 usage in those clients is that the password is replaced by a token.= =0A=A0 Tokens typically provided limited access rights and can be managed= =0A=A0 and revoked separately from the user's long-term credential=0A=A0 = (password).=0A=0A=0AThe IETF datatracker status page for this draft is:=0Ah= ttps://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth=0A=0AThere's a= lso a htmlized version available at:=0Ahttp://tools.ietf.org/html/draft-iet= f-kitten-sasl-oauth-10=0A=0AA diff from the previous version is available a= t:=0Ahttp://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-10=0A= =0A=0AInternet-Drafts are also available by anonymous FTP at:=0Aftp://ftp.i= etf.org/internet-drafts/=0A=0A_____________________________________________= __=0AKitten mailing list=0AKitten@ietf.org=0Ahttps://www.ietf.org/mailman/l= istinfo/kitten=0A From metze@samba.org Mon Feb 25 06:29:29 2013 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 5D73421F92DC for ; Mon, 25 Feb 2013 06:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.45 X-Spam-Level: X-Spam-Status: No, score=-1.45 tagged_above=-999 required=5 tests=[AWL=-1.151, BAYES_00=-2.599, MANGLED_AVOID=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlRY21yQPGeL for ; Mon, 25 Feb 2013 06:29:26 -0800 (PST) Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E67821F91E2 for ; Mon, 25 Feb 2013 06:29:25 -0800 (PST) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h8JCY7ENneaZHjCDQ0Cg== X-RZG-CLASS-ID: mo05 Received: from [192.168.179.21] (xdsl-87-78-209-247.netcologne.de [87.78.209.247]) by smtp.strato.de (jorabe mo17) (RZmta 31.18 DYNA|AUTH) with ESMTPA id w04155p1PEEVp0 ; Mon, 25 Feb 2013 15:29:20 +0100 (CET) Message-ID: <512B753B.6020206@samba.org> Date: Mon, 25 Feb 2013 15:29:15 +0100 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig01D3124166F63B0BFCDB6BE0" Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API try #2 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, 25 Feb 2013 14:29:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig01D3124166F63B0BFCDB6BE0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Am 24.02.2013 01:38, schrieb Nico Williams: >> https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt >=20 > I've come up with an idea regarding event loops and how to pass them > in: just abstract them. Indicate an event loop type and pass in a > void *, as well as optionally also a void * for the module > implementing the event loop and optionally also a pointer to a > dlsym()-/GetProcAddress()-like function. Specify several event loop > types, recommend/require one to be implemented. >=20 > Now we might look at this and decide that we don't want to have any > more than one event loop type (say, verto). Apps that don't use it > can implement it as a shim on top of whatever they do use. I'd like > this. I think it's fine to have just a few, one or event no event loop type standardized, but indicate that implementations may want to offer more. Typically the implementation should have one function to specify an instance of its native event loop implementation. So one out of this: OM_uint32 gss_set_context_virto_ctx(OM_uint32 *minor_status, gss_ctx_id_t context, struct verto_ctx *ctx); OM_uint32 gss_set_context_tevent_context(OM_uint32 *minor_status, gss_ctx_id_t context, struct tevent_context *ctx); OM_uint32 gss_set_context_glib_loop(OM_uint32 *minor_status, gss_ctx_id_t context, GMainContext *mc, GMainLoop *ml); OM_uint32 gss_set_context_libevent_base(OM_uint32 *minor_status, gss_ctx_id_t context, struct event_base *ebase); I think if the application wants to share an event loop with the gss libraries, it should be indicated explicitly. The application should may use something like verto_convert_tevent(). Otherwise the gss libraries should use threads or don't offer the functionality. metze --------------enig01D3124166F63B0BFCDB6BE0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlErdT8ACgkQm70gjA5TCD9STQCfZP+vwAmMC9reEikTzJKKS85P NQ4AoMpwbSdLSIKrmr4BzASeLPDeLMRY =5WQg -----END PGP SIGNATURE----- --------------enig01D3124166F63B0BFCDB6BE0-- From metze@samba.org Mon Feb 25 06:58:27 2013 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 65F8021F925B for ; Mon, 25 Feb 2013 06:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.287, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DTUcDrr6RwK for ; Mon, 25 Feb 2013 06:58:26 -0800 (PST) Received: from mo6-p05-ob.rzone.de (mo6-p05-ob.rzone.de [IPv6:2a01:238:20a:202:5305::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A2F21F9227 for ; Mon, 25 Feb 2013 06:58:26 -0800 (PST) X-RZG-AUTH: :IWkQb0WIdvqIIwNfJfyiKBgoQwjwJ7eL6yL6M6h8JCY7ENneaZHjCDQ0Cg== X-RZG-CLASS-ID: mo05 Received: from [192.168.179.21] (xdsl-87-78-209-247.netcologne.de [87.78.209.247]) by smtp.strato.de (jored mo4) (RZmta 31.18 DYNA|AUTH) with ESMTPA id h0205ap1PELJ63 ; Mon, 25 Feb 2013 15:58:25 +0100 (CET) Message-ID: <512B7C0D.30703@samba.org> Date: Mon, 25 Feb 2013 15:58:21 +0100 From: "Stefan (metze) Metzmacher" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nico Williams References: <5128626F.2040307@samba.org> In-Reply-To: X-Enigmail-Version: 1.4.6 OpenPGP: id=0E53083F Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigB1B7A0A59CA9DA2A04DF5ADD" Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 25 Feb 2013 14:58:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB1B7A0A59CA9DA2A04DF5ADD Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 23.02.2013 09:18, schrieb Nico Williams: > On Sat, Feb 23, 2013 at 12:32 AM, Stefan (metze) Metzmacher > wrote: >> Hi Nico, >> >>> Too late for submitting -00s. So here: >>> >>> https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt >>> >> >> Note that if GSS_S_CONTINUE_NEEDED is returned but no security >> context is output, then the function must be called again upon asyn= c >> I/O completion notification. >=20 > oops, that should read "...but no security context _token_ is output, .= =2E.". >=20 >> OM_uint32 >> gss_step_context(OM_uint32 *minor_status, >> gss_ctx_id_t context, >> gss_const_buffer_t input_token, >> gss_buffer_t output_token, >> gss_const_OID *actual_mech); >> >> When getting GSS_S_CONTINUE_NEEDED, how can the caller detect the diff= erence >> between an empty output_token and no output_token? >=20 > The GSS-API does not allow empty tokens, thus making this a > distinction without a difference :) Where is that defined? At least over SMB spnego tokens can be fragmented,= and the GSS_S_CONTINUE_NEEDED may take or produce emtpy tokens. metze --------------enigB1B7A0A59CA9DA2A04DF5ADD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlErfBEACgkQm70gjA5TCD+plQCeJL0lhN/KYW2UCdnACXwzfIQ6 yZgAnRtPxxlkkhzzIl8ZiPtsmqbwkq/7 =MdBC -----END PGP SIGNATURE----- --------------enigB1B7A0A59CA9DA2A04DF5ADD-- From lha@kth.se Mon Feb 25 07:28:11 2013 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 6570621F947A for ; Mon, 25 Feb 2013 07:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gL3T9EkL5zJj for ; Mon, 25 Feb 2013 07:28:10 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfa.amsl.com (Postfix) with ESMTP id 6722D21F935F for ; Mon, 25 Feb 2013 07:28:07 -0800 (PST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 4836C14EA42; Mon, 25 Feb 2013 16:27:32 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id oJjAM8rFvcWU; Mon, 25 Feb 2013 16:27:29 +0100 (CET) X-KTH-Auth: lha [74.95.3.93] X-KTH-mail-from: lha@kth.se Received: from [10.0.1.3] (unknown [74.95.3.93]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 0400314F8CF; Mon, 25 Feb 2013 16:27:27 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_5207B235-C2F6-496F-9AC0-87A24007DBBF" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <512B753B.6020206@samba.org> Date: Mon, 25 Feb 2013 07:27:25 -0800 Message-Id: References: <512B753B.6020206@samba.org> To: "Stefan (metze) Metzmacher" X-Mailer: Apple Mail (2.1499) Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API try #2 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, 25 Feb 2013 15:28:11 -0000 --Apple-Mail=_5207B235-C2F6-496F-9AC0-87A24007DBBF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 25 feb 2013 kl. 06:29 skrev "Stefan (metze) Metzmacher" = : > I think if the application wants to share an event loop with the > gss libraries, it should be indicated explicitly. The application > should may use something like verto_convert_tevent(). > Otherwise the gss libraries should use threads or don't offer the > functionality. how would the application get notified when GSS framework have a new = token/new step is needed in this case since the step function doesn't = take a callback. Love --Apple-Mail=_5207B235-C2F6-496F-9AC0-87A24007DBBF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 metze@samba.org>
:
<= br class=3D"Apple-interchange-newline">
I think if the application = wants to share an event loop with the
gss libraries, it should be = indicated explicitly. The application
should may use something like = verto_convert_tevent().
Otherwise the gss libraries = should use threads or don't offer the
functionality.
Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API 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, 25 Feb 2013 16:34:31 -0000 On Mon, Feb 25, 2013 at 8:58 AM, Stefan (metze) Metzmacher wrote: > Am 23.02.2013 09:18, schrieb Nico Williams: >> The GSS-API does not allow empty tokens, thus making this a >> distinction without a difference :) > > Where is that defined? At least over SMB spnego tokens can be fragmented, > and the GSS_S_CONTINUE_NEEDED may take or produce emtpy tokens. RFC2743, section 1.1.2, fourth paragraph, third sentence: "Zero-length tokens are never returned by GSS routines for transfer to a peer." Can you tell me more about the SMB issue? Does SMB make the length of fragments and/or the reassembled tokens definite, or does it depend on GSS_Init/Accept_sec_context to somehow tell it where the end of a token is? If the former then there's no problem: just reassemble the tokens first, then pass them to the GSS-API. If the latter... how would the GSS-API indicate the end of the token?! Nico -- From nico@cryptonector.com Mon Feb 25 08:38:34 2013 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 ECDFF21F8922 for ; Mon, 25 Feb 2013 08:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=-1.460, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdoK5YKcB5ww for ; Mon, 25 Feb 2013 08:38:34 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id C041021F9573 for ; Mon, 25 Feb 2013 08:38:33 -0800 (PST) Received: from homiemail-a95.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTP id 7E2AB1E076 for ; Mon, 25 Feb 2013 08:38:33 -0800 (PST) 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=bZbvuvH9QGArkAPhDxrT ht3ERl0=; b=w0AOSeo76ACHGb13aAm1VZhYiAZdDFeXlF2PMmUycsp0B+FQbrk2 giEMlpJmJu7vKq+ezn/JCjY3+ez8A0Y5uCuDdtO0tK2fIS+RiA3XmgPMHP3HxpY0 YSE7tFaBi3QpyQXT+3lIuLHKcafWhGVqFGD2/k5gUJydcOnplFT2Pzs= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a95.g.dreamhost.com (Postfix) with ESMTPSA id 257E91E064 for ; Mon, 25 Feb 2013 08:38:32 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so3660078wib.9 for ; Mon, 25 Feb 2013 08:38:31 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.63.109 with SMTP id f13mr20526060wjs.11.1361810311885; Mon, 25 Feb 2013 08:38:31 -0800 (PST) Received: by 10.216.148.193 with HTTP; Mon, 25 Feb 2013 08:38:31 -0800 (PST) In-Reply-To: <512B753B.6020206@samba.org> References: <512B753B.6020206@samba.org> Date: Mon, 25 Feb 2013 10:38:31 -0600 Message-ID: From: Nico Williams To: "Stefan (metze) Metzmacher" Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API try #2 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, 25 Feb 2013 16:38:35 -0000 On Mon, Feb 25, 2013 at 8:29 AM, Stefan (metze) Metzmacher wrote: > I think it's fine to have just a few, one or event no event loop > type standardized, but indicate that implementations may want to > offer more. Typically the implementation should have one function > to specify an instance of its native event loop implementation. But we can't really standardize event loop APIs here. With the possible exception of verto I doubt any of them would give us (the IETF) change control. Conversely, I don't think we can have normative references to external definitions of event loop APIs without some SDO behind them that the IETF can recognize. > So one out of this: These explicitly refer to C types from external event loop APIs, and I don't see how we manage this in a standard (see above). To be sure, we don't need a standard for this either: we can just implement this in Heimdal and MIT and leave it at that. Nico -- From nico@cryptonector.com Mon Feb 25 08:45:01 2013 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 C287D21F9527 for ; Mon, 25 Feb 2013 08:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.044 X-Spam-Level: X-Spam-Status: No, score=-3.044 tagged_above=-999 required=5 tests=[AWL=-1.367, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YysJS3k-s7G for ; Mon, 25 Feb 2013 08:45:01 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 1630A21F951E for ; Mon, 25 Feb 2013 08:45:01 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id D242376806E for ; Mon, 25 Feb 2013 08:44:55 -0800 (PST) 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=ZsMV381Y2pfvk453kXnAjfJUtos=; b=jxVrglcX9vq N28HF3R5IGz2Atmd9THj1X95heM9seTlopp9oOoQHgO+1VTaXTA1l8O4+oYAmeJ8 RTymPtRZ0zOWdfjOB/GR075Y2sGwq+9j2j8C4d+oNpPn9QMqcRcdC6Ej83GDuOdK CP4Ogx1j6JHKngDkx5J6I5fgRpwIbjns= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 83A6576806D for ; Mon, 25 Feb 2013 08:44:55 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so2701395wey.17 for ; Mon, 25 Feb 2013 08:44:54 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.74.228 with SMTP id x4mr13719861wiv.0.1361810694225; Mon, 25 Feb 2013 08:44:54 -0800 (PST) Received: by 10.216.148.193 with HTTP; Mon, 25 Feb 2013 08:44:54 -0800 (PST) In-Reply-To: References: <512B753B.6020206@samba.org> Date: Mon, 25 Feb 2013 10:44:54 -0600 Message-ID: From: Nico Williams To: =?UTF-8?B?TG92ZSBIw7ZybnF1aXN0IMOFc3RyYW5k?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: kitten@ietf.org Subject: Re: [kitten] Simplified and async API try #2 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, 25 Feb 2013 16:45:01 -0000 On Mon, Feb 25, 2013 at 9:27 AM, Love H=C3=B6rnquist =C3=85strand wrote: > how would the application get notified when GSS framework have a new > token/new step is needed in this case since the step function doesn't tak= e a > callback. There's a separate function for setting a callback (or other signalling mechanism). From nico@cryptonector.com Mon Feb 25 11:49:45 2013 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 D4DB221E80A7 for ; Mon, 25 Feb 2013 11:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-1.197, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvm8E2X4wpM6 for ; Mon, 25 Feb 2013 11:49:45 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id EF65121E80A3 for ; Mon, 25 Feb 2013 11:49:44 -0800 (PST) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id AF0E92C80AA for ; Mon, 25 Feb 2013 11:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:date:message-id:subject:from:to:cc:content-type; s= cryptonector.com; bh=2DF0sxFv4aRXtglW/qVvSadLRU4=; b=rRNDTqsjEvU BoTCQ8ljpp4xemg62cp0sHtSOG9+mp1Z8US/Ri12qTbupCKTZfJKCO+b18ihXyDi FbU2Kx5+GtLEKSyk5b9j5XjtRcsjgSW/STvK8WMV3ZbBGQXk6eZeVgG9wsCVIt2l vlmpIfcZUuasvJgRyaRhJ3aP+tUHTvWs= Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPSA id 06F412C80A6 for ; Mon, 25 Feb 2013 11:49:43 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id ds1so3694397wgb.0 for ; Mon, 25 Feb 2013 11:49:42 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.76.84 with SMTP id i20mr14821802wiw.9.1361821782411; Mon, 25 Feb 2013 11:49:42 -0800 (PST) Received: by 10.216.148.193 with HTTP; Mon, 25 Feb 2013 11:49:42 -0800 (PST) Date: Mon, 25 Feb 2013 13:49:42 -0600 Message-ID: From: Nico Williams To: kitten@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: hartmans-ietf@mit.edu Subject: [kitten] The dog that didn't bark (Re: -02 of GSS_C_CHANNEL_BOUND_FLAG I-D submitted) 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, 25 Feb 2013 19:49:45 -0000 So, lots of reviews of the simplified and async interface, no comments on this one, and no comments complaining about the specific design (empty sec context constructor + a mutator to set the ret_flags understood by the app) that is extended in the simplified and async I-D. I think that means there's no objection to this approach. Given that I'd like us to proceed to the next step, which would be humming for adoption as a WG work item, and since it's pretty much ready, a WGLC. Since Orlando is coming up so soon let's start the WGLC at the KITTEN meeting, assuming there's no strong objections by the end of that meeting. Alternatively let's hear some barking! Nico -- From hartmans@mit.edu Mon Feb 25 12:11:43 2013 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 1F23B21F9239 for ; Mon, 25 Feb 2013 12:11:43 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3sUH572W6Ba for ; Mon, 25 Feb 2013 12:11:42 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 34E0221F866F for ; Mon, 25 Feb 2013 12:11:42 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id E525620118 for ; Mon, 25 Feb 2013 15:06:50 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CBECA447B; Mon, 25 Feb 2013 15:11:40 -0500 (EST) From: Sam Hartman To: kitten@ietf.org Date: Mon, 25 Feb 2013 15:11:40 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Consensus by Apathy: working on channel bindings 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, 25 Feb 2013 20:11:44 -0000 The chairs independently came to a similar conclusion to Nico. There's been a lot of discussion of the channel binding problem nNico proposed. In particular: 1) the description of channel binding in RFC 2743 is inconsistent with what a lot of implementations and later specifications describe. 2) There's no way for an acceptor to determine if channel bindings happened, especially in cases where the acceptor wants to make channel bindings optional. Martin has commented that he'd like to see us work on the problem. Several people have commented on the two solutions Nico proposed. No one besides Martin has responded to repeated calls asking whether this is of interest to the working group, but people continue to engage in discussions of the appropriate solutions. The chairs conclude that the active discussion of the solutions is strong evidence that we want to work on this problem. So, unless there is a strong objection, kitten will take on the problem. we don't see sufficient consensus to choose a particular solution at this time, but we do agree with Nico that discussion seems to be favoring the conclusion based on creating an empty security context and a flag setting routine. we'd appreciate comments on which solution the WG should adopt. I'd like to see us make a decision before or during IETF 86. --Sam From kaduk@mit.edu Mon Feb 25 12:22:02 2013 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 0778121F9100 for ; Mon, 25 Feb 2013 12:22:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkW3y4L0RNTj for ; Mon, 25 Feb 2013 12:21:59 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id EFB1A21F90F4 for ; Mon, 25 Feb 2013 12:21:57 -0800 (PST) X-AuditID: 1209190c-b7f046d00000094c-45-512bc7e52539 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 53.E9.02380.5E7CB215; Mon, 25 Feb 2013 15:21:57 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r1PKLvXJ021278; Mon, 25 Feb 2013 15:21:57 -0500 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r1PKLtZi026774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 15:21:56 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r1PKLsPW009418; Mon, 25 Feb 2013 15:21:54 -0500 (EST) Date: Mon, 25 Feb 2013 15:21:54 -0500 (EST) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixG6nrvv0uHagwcdb/BZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrw93awF8wQqTjxrY29gXMDbxcjJISFgItHav5sdwhaTuHBv PVsXIxeHkMA+Rol7s+ezgCSEBDYySpzvyoFIHGKSWHm1nQnCaWCU6D35B6yKRUBb4tqjr2Cj 2ARUJGa+2cgGYosISEoce3KeGcRmFhCWWH9uBpgtLOAnsezDOjCbU8BSonvbJlYQm1fAQeL0 kq1Qmy0kPvzpA4uLCuhIrN4/hQWiRlDi5MwnLBAzLSXO/bnONoFRcBaS1CwkqQWMTKsYZVNy q3RzEzNzilOTdYuTE/PyUot0DfVyM0v0UlNKNzGCwpJTkmcH45uDSocYBTgYlXh4NTq0A4VY E8uKK3MPMUpyMCmJ8vIdBQrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4eXMAMrxpiRWVqUW5cOk pDlYlMR5L6fc9BcSSE8sSc1OTS1ILYLJynBwKEnwfjsG1ChYlJqeWpGWmVOCkGbi4AQZzgM0 HKyGt7ggMbc4Mx0if4pRUUqc9zVIQgAkkVGaB9cLSxuvGMWBXhHmFQYmESEeYMqB634FNJgJ aPAiEbDBJYkIKakGxvVdbGnB/jdbtj/8N3fp1FvfHS1K4szuPl5nOC/1Xy6b3oS988vsDq3n vat7c3broZWCaabLNCbUVgdvvyco0Sdw2s5n6bFM14S98sJ5go1iVZPeif3/kLH+w5ytbTP4 Xk322Bsqe9hH/lXv35yfTN+2NQqqfQs/kecr+nvOMr1HO82XTppdV67EUpyRaKjFXFScCAAb rTcr9gIAAA== Cc: kitten@ietf.org Subject: Re: [kitten] submitted draft-yu-kitten-kerberos-kdc-does-aliases-00 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, 25 Feb 2013 20:22:02 -0000 Hi Tom, I just got a chance to give this a careful read. It certainly seems relevant to the working group, as part of our plan to provide a migration path away from relying on insecure DNS. I do wonder whether anyone thinks that the language in section 3 is confusing, referring to forward versus reverse resolution, as opposed to forward versus forward+reverse resolution, as the parentheticals state. I think that the parentheticals make it clear enough, but other input is welcome. -Ben On Mon, 18 Feb 2013, Tom Yu wrote: > I've submitted this document as one component of the effort to remove > dependence on insecure DNS for canonicalizing hostnames in service > principal names. I would like the Working Group to consider it for > adoption. > > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-yu-kitten-kerberos-kdc-does-aliases-00.txt > To: tlyu@mit.edu > Date: Mon, 18 Feb 2013 15:21:29 -0800 > > > A new version of I-D, draft-yu-kitten-kerberos-kdc-does-aliases-00.txt > has been successfully submitted by Tom Yu and posted to the > IETF repository. > > Filename: draft-yu-kitten-kerberos-kdc-does-aliases > Revision: 00 > Title: Kerberos Ticket flag indicating KDC support for resolving hostname aliases > Creation date: 2013-02-18 > Group: Individual Submission > Number of pages: 5 > URL: http://www.ietf.org/internet-drafts/draft-yu-kitten-kerberos-kdc-does-aliases-00.txt > Status: http://datatracker.ietf.org/doc/draft-yu-kitten-kerberos-kdc-does-aliases > Htmlized: http://tools.ietf.org/html/draft-yu-kitten-kerberos-kdc-does-aliases-00 > > > Abstract: > This document specifies a Kerberos Ticket flag that indicates that > the Key Distribution Center (KDC) can resolve hostname aliases in > service principal names. This document updates RFC 4120. > > > > > The IETF Secretariat > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From ghudson@mit.edu Mon Feb 25 12:52:22 2013 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 F190721F89AE for ; Mon, 25 Feb 2013 12:52:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkiWxIMQRnhf for ; Mon, 25 Feb 2013 12:52:18 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id D9DA121F890D for ; Mon, 25 Feb 2013 12:52:17 -0800 (PST) X-AuditID: 1209190c-b7f046d00000094c-38-512bcef97d7f Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 50.9C.02380.9FECB215; Mon, 25 Feb 2013 15:52:09 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id r1PKq9EW026231; Mon, 25 Feb 2013 15:52:09 -0500 Received: from [18.101.8.84] (VPN-18-101-8-84.MIT.EDU [18.101.8.84]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r1PKq7jW010068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 15:52:09 -0500 Message-ID: <512BCEF7.2040806@mit.edu> Date: Mon, 25 Feb 2013 15:52:07 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Tom Yu References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixG6nrvvznHagwbmHJhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqxXW5gKJjJXNFxuZW5g3MfUxcjJISFgItF4fQ8zhC0mceHe erYuRi4OIYF9jBKr799hgnA2MkrseHQDyjnIJHGrvYcNpIVXQE1i49KtYKNYBFQl3m9cARZn E1CWOHj2GwuILSoQIrHozHSoekGJkzOfgMVFBCQlvm2ayghiMwsIS1zYvpcVxBYW8JH4NmcJ WFxIwELiw58+sDingKVE97ZNrBCnSkosmtbJAtGrI/Gu7wEzhC0vsf3tHOYJjEKzkKybhaRs FpKyBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3QN9XIzS/RSU0o3MYLCmFOSZwfjm4NKhxgF OBiVeHg1OrQDhVgTy4orcw8xSnIwKYnyKp4BCvEl5adUZiQWZ8QXleakFh9ilOBgVhLh5cwA yvGmJFZWpRblw6SkOViUxHkvp9z0FxJITyxJzU5NLUgtgsnKcHAoSfBOOAvUKFiUmp5akZaZ U4KQZuLgBBnOAzR8FkgNb3FBYm5xZjpE/hSjopQ4ryjIRQIgiYzSPLheWJp5xSgO9IowbzFI Ow8wRcF1vwIazAQ0eJEI2OCSRISUVANjkFYPs73me7FN6w3YQtnudO19nc9UupB5luGV0Buy Kq9DeUS5eDt+vOd8XiobyNl5d0nqN/2Dm9doNq5mnvO1x3n2gTOlvW51vWdWitiveTe5YEJO o2vfmlLuc1/OralwEpvDfm7zk3nZbWy8nr6fYn3+O+xOtXDlWWX7wLF8mV5k2Semo5JKLMUZ iYZazEXFiQDsHUElDgMAAA== Cc: kitten@ietf.org Subject: Re: [kitten] submitted draft-yu-kitten-kerberos-kdc-does-aliases-00 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, 25 Feb 2013 20:52:22 -0000 On 02/18/2013 06:40 PM, Tom Yu wrote: > I've submitted this document as one component of the effort to remove > dependence on insecure DNS for canonicalizing hostnames in service > principal names. I would like the Working Group to consider it for > adoption. I'm in favor of adopting this item. I don't have any comments to make since the concept is simple and the draft is quite short. From nico@cryptonector.com Mon Feb 25 12:53:19 2013 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 EAF2221F91ED for ; Mon, 25 Feb 2013 12:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=-1.180, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n9BP1pRr6lZm for ; Mon, 25 Feb 2013 12:53:18 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 122F821F8A1D for ; Mon, 25 Feb 2013 12:53:18 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id BF9842640EE for ; Mon, 25 Feb 2013 12:53:17 -0800 (PST) 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=UBN3b9+d/z0sKobkZ5AC c4IDDHs=; b=IqN7+V7nJXtkbS3+PpiNWFKBw+amPIfTDPjrREyKC/SJ/o/xcE8x VzNnOMO/vEzg0qM2bl/XuFC6/VcWnmvO/MLfAA2HcfebHmuiw4/IxzSanxkWWRE9 K9CTiLRkPrnRyDt3r7NUBMTueKniw7+TfQYQXswNr2iXf7Uw8UnA480= Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) (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 63D302640ED for ; Mon, 25 Feb 2013 12:53:17 -0800 (PST) Received: by mail-we0-f182.google.com with SMTP id t57so2926878wey.13 for ; Mon, 25 Feb 2013 12:53:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.109.82 with SMTP id hq18mr15159436wib.0.1361825595141; Mon, 25 Feb 2013 12:53:15 -0800 (PST) Received: by 10.216.148.193 with HTTP; Mon, 25 Feb 2013 12:53:14 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 14:53:14 -0600 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] submitted draft-yu-kitten-kerberos-kdc-does-aliases-00 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, 25 Feb 2013 20:53:20 -0000 Hi Tom, This is a very good idea, but I'm curious how to implement this. Consider a case where the KDCs for the realm where a client will begin to search for some service name supports this feature, but it issues a referral to another realm that doesn't, and the subsequent TGS exchange fails because the referred-to realm's KDCs don't know that sname. How should a client recover? Should it attempt DNS canonicalization in that case and retry at the realm that did not know the original sname? Or should it give up? Or should it act according to local configuration? Other questions/comments: - what does the kdc-resolves-aliases flag mean when a service finds it set on a Ticket? Do we need a section indicating *service* behavior? - all KDCs for a given realm must support this feature before setting this flag. Section 4 should say this. (I.e., it must be possible to upgrade a realm's KDCs piecemeal.) Nico -- From nico@cryptonector.com Mon Feb 25 12:57:43 2013 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 2EF9321F8A1D for ; Mon, 25 Feb 2013 12:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrYXaamdSvWP for ; Mon, 25 Feb 2013 12:57:42 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 22FCE21F8DCB for ; Mon, 25 Feb 2013 12:57:40 -0800 (PST) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id C868B5980C9 for ; Mon, 25 Feb 2013 12:57:39 -0800 (PST) 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=WABMEN1hvB5PNWCnJoq0 tXev1uQ=; b=rGksfUEd5rSKVBBsmVhbqRHmZ+KA//agGDsQnlGV3kIOJ+vJRDUo Ky88kqbLXNWLi3V1x2gyaAQ30NfIOA/4HQFyGyAJ9Cs5i2NM3cQTYfve7tgvq80r qqgDN1Q7AcaoSRA0KMCVNgXxJ/8uaa8G94/5XW0s/CyE8LTIHiT6qlw= Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 71B105980D8 for ; Mon, 25 Feb 2013 12:57:39 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x8so2893224wey.6 for ; Mon, 25 Feb 2013 12:57:38 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.77.129 with SMTP id s1mr22041205wjw.17.1361825858185; Mon, 25 Feb 2013 12:57:38 -0800 (PST) Received: by 10.216.148.193 with HTTP; Mon, 25 Feb 2013 12:57:38 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 14:57:38 -0600 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] submitted draft-yu-kitten-kerberos-kdc-does-aliases-00 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, 25 Feb 2013 20:57:43 -0000 Also: - I suppose this flag really only means that the clients shouldn't bother with DNS canonicalization, but what about DNSSEC? - Must KDCs canonicalize aliases, or is it OK for a KDC to expect (or know that) services to know their own aliases and share the same key (or derived keys?) for the aliases of the canonical names? - Further to the last question, if the new flag is set in a service ticket, should services decide to stop trying all keys to decrypt service tickets for which they have no explicit keytab entry? (Heimdal has code to do that.) - How long can the meaning of this flag be cached for on clients? On servers? This gets to rollback issues. Nico -- From cantor.2@osu.edu Mon Feb 25 13:05:32 2013 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 ACF1521E80C7 for ; Mon, 25 Feb 2013 13:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6cItxi-E+iJ for ; Mon, 25 Feb 2013 13:05:31 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 55BF021E80D8 for ; Mon, 25 Feb 2013 13:05:30 -0800 (PST) Received: from mail226-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE013.bigfish.com (10.7.40.63) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Feb 2013 21:05:29 +0000 Received: from mail226-va3 (localhost [127.0.0.1]) by mail226-va3-R.bigfish.com (Postfix) with ESMTP id BD312500197; Mon, 25 Feb 2013 21:05:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.210; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf03; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzdb82hzz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2fh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail226-va3: domain of osu.edu designates 164.107.81.210 as permitted sender) client-ip=164.107.81.210; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf03 ; cio-krc-pf03 ; Received: from mail226-va3 (localhost.localdomain [127.0.0.1]) by mail226-va3 (MessageSwitch) id 136182632865725_25916; Mon, 25 Feb 2013 21:05:28 +0000 (UTC) Received: from VA3EHSMHS032.bigfish.com (unknown [10.7.14.240]) by mail226-va3.bigfish.com (Postfix) with ESMTP id 0D295BA021A; Mon, 25 Feb 2013 21:05:28 +0000 (UTC) Received: from cio-krc-pf03 (164.107.81.210) by VA3EHSMHS032.bigfish.com (10.7.99.42) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Feb 2013 21:05:19 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (localhost [127.0.0.1]) by cio-krc-pf03 (Postfix) with ESMTP id DD03BC0050; Mon, 25 Feb 2013 16:05:18 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.02.0328.009; Mon, 25 Feb 2013 16:05:18 -0500 From: "Cantor, Scott" To: Sam Hartman , "kitten@ietf.org" Thread-Topic: [kitten] Consensus by Apathy: working on channel bindings Thread-Index: AQHOE5RasAUVjv1lNU2I0H+aRUQkiZiLD4ig Date: Mon, 25 Feb 2013 21:05:18 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 25 Feb 2013 21:05:33 -0000 > 2) There's no way for an acceptor to determine if channel bindings > happened, especially in cases where the acceptor wants to make channel > bindings optional. Nico took as a given that there's some magic reason why initiators don't al= so get to know this, but I certainly don't see it. I don't think Nico's pro= posal, though, is limited to acceptors knowing, is it? > No one besides Martin has responded to repeated calls asking whether > this is of interest to the working group, but people continue to engage > in discussions of the appropriate solutions. I can only speak for myself, but most of us new to this space trying to wri= te mechanisms are trying to get the language right and understand how to pu= ll all of this off in a world of protocols that don't naturally provide key= s (which makes CB a lot more valuable to my mind). But it's a moving target= , and the details keep changing, or at least it seems so. We just want to do the right things, and assume that the experts can figure= out what the right things are. -- Scott From ghudson@mit.edu Mon Feb 25 13:15:55 2013 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 2A31721F929D for ; Mon, 25 Feb 2013 13:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1zUsJlkktpf for ; Mon, 25 Feb 2013 13:15:54 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (DMZ-MAILSEC-SCANNER-1.MIT.EDU [18.9.25.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9BE21E809D for ; Mon, 25 Feb 2013 13:15:54 -0800 (PST) X-AuditID: 1209190c-b7f046d00000094c-47-512bd4896de6 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 38.5E.02380.984DB215; Mon, 25 Feb 2013 16:15:53 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id r1PLEOUm006352; Mon, 25 Feb 2013 16:14:26 -0500 Received: from [18.101.8.84] (VPN-18-101-8-84.MIT.EDU [18.101.8.84]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r1PLEMq2021329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 25 Feb 2013 16:14:23 -0500 Message-ID: <512BD42E.3070009@mit.edu> Date: Mon, 25 Feb 2013 16:14:22 -0500 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nico Williams References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT0e28oh1ocOC+qcXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGW8m7SXueAuV0Xb7l+MDYzbOLoYOTkkBEwk Ds1fwARhi0lcuLeerYuRi0NIYB+jxI49DewQzkZGiWMLFjJDOAeZJD4v/AXWwiugJtE8dSUz iM0ioCoxZ+MvRhCbTUBZ4uDZbywgtqhAiMSiM9PZIOoFJU7OfAIWFxHQlLg+bylYnFlAS2LT ovXsILawgI/EtzlLGCGWHWKUeHrgG9AyDg5OgUCJh29jIE6VlFg0rZMFoldH4l3fA2YIW15i +9s5zBMYhWYhWTcLSdksJGULGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrq5WaW6KWmlG5i BIU2pyTPDsY3B5UOMQpwMCrx8Gp0aAcKsSaWFVfmHmKU5GBSEuXNPA8U4kvKT6nMSCzOiC8q zUktBjqeg1lJhJczAyjHm5JYWZValA+TkuZgURLnvZxy019IID2xJDU7NbUgtQgmK8PBoSTB a3gZqFGwKDU9tSItM6cEIc3EwQkynAdouDFIDW9xQWJucWY6RP4Uo6KUOK8WSEIAJJFRmgfX C0s9rxjFgV4R5hUEqeIBpi247ldAg5mABi8SARtckoiQkmpgNLxzbE9CTaXk+5UPrhh6P9IU PBX1/iTzX806odiHmd8nTrTpXvNC+HkXz70zHr3c/99fubKufbvlvIL6ojgtyWPb/q+QFeZo knb67bnf/jRvaecHZuO7pxLuu1vwz7Tr66n8V7aEcxaHpXCjeGNrsUWgWoBzyeRvb5pXcs9e 1H8nqiOC4/NuJZbijERDLeai4kQAJ5UB+BgDAAA= Cc: kitten@ietf.org Subject: Re: [kitten] submitted draft-yu-kitten-kerberos-kdc-does-aliases-00 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, 25 Feb 2013 21:15:55 -0000 On 02/25/2013 03:57 PM, Nico Williams wrote: > - Must KDCs canonicalize aliases, or is it OK for a KDC to expect (or > know that) services to know their own aliases and share the same key > (or derived keys?) for the aliases of the canonical names? > > - Further to the last question, if the new flag is set in a service > ticket, should services decide to stop trying all keys to decrypt > service tickets for which they have no explicit keytab entry? > (Heimdal has code to do that.) I don't think this draft intends to change the way KDCs perform service aliasing. It's only a hint to the client that DNS canonicalization of service names isn't desired. The way service aliasing is done today, the KDC returns a ticket for whatever server principal name the client requested, and the service has to figure out what to do with a ticket which might be for an alias of the service. In MIT krb5 and Heimdal, that means ignoring the ticket server principal name if the keytab is iterable. > - How long can the meaning of this flag be cached for on clients? On servers? > > This gets to rollback issues. I can't imagine the answer being anything other than "for the lifetime of the ticket." There's no reason a KDC has to start setting this ticket flag the moment it has service aliasing support, so I don't see a rollback issue. From nico@cryptonector.com Mon Feb 25 13:22:49 2013 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 342FB21F8E57 for ; Mon, 25 Feb 2013 13:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.124 X-Spam-Level: X-Spam-Status: No, score=-3.124 tagged_above=-999 required=5 tests=[AWL=-1.147, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9GPLcZGI-SZ for ; Mon, 25 Feb 2013 13:22:48 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 12C7821F8E1E for ; Mon, 25 Feb 2013 13:22:40 -0800 (PST) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 60F1721DEC6 for ; Mon, 25 Feb 2013 13:22:40 -0800 (PST) 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=NXPSRlxkfhH13OsDaUVLF809Jio=; b=k+WO+/0Nhh5 oPV+bqkC2n7AE8ps2AbpNsXOR611Ds+fEFygkTs5c9liiQHntZeLHStQtx9hgpKq lASBB4Z3UJbs4RMqs5WA5XWBPvo6SuhgMqudCfk6xSw/0Ry5KaQ65P8/vXNxn5v2 uvu0W7xuvhug984cc3RfLF7CQ+XwMYjM= Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) (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 D4D9821DEC1 for ; Mon, 25 Feb 2013 13:22:39 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id x10so2951413wey.17 for ; Mon, 25 Feb 2013 13:22:38 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.63.109 with SMTP id f13mr22177006wjs.11.1361827358491; Mon, 25 Feb 2013 13:22:38 -0800 (PST) Received: by 10.216.148.193 with HTTP; Mon, 25 Feb 2013 13:22:38 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 15:22:38 -0600 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 25 Feb 2013 21:22:49 -0000 On Mon, Feb 25, 2013 at 3:05 PM, Cantor, Scott wrote: >> 2) There's no way for an acceptor to determine if channel bindings >> happened, especially in cases where the acceptor wants to make channel >> bindings optional. > > Nico took as a given that there's some magic reason why initiators don't = also get to know this, but I certainly don't see it. I don't think Nico's p= roposal, though, is limited to acceptors knowing, is it? I didn't say anywhere that only acceptors should use the new interface. The problem is that acceptors need a) an option to succeed w/o CB, b) to know whether CB happened. Initiators need this too, but their need is lesser than the acceptors'. > I can only speak for myself, but most of us new to this space trying to w= rite mechanisms are trying to get the language right and understand how to = pull all of this off in a world of protocols that don't naturally provide k= eys (which makes CB a lot more valuable to my mind). But it's a moving targ= et, and the details keep changing, or at least it seems so. > > We just want to do the right things, and assume that the experts can figu= re out what the right things are. I get this. Part of me says: there aren't really enough security experts, so you have to consider becoming one yourself. Those of us who are experts in any aspect of security ought to make it easier for those who don't care to become similarly expert. This is something that has been on our plate for a long time: simplified GSS-API, documentation for application developers, and better documentation for mechanism implementors (better as in easier to approach than a set of RFCs starting with a lengthy RFC2743). I took a step in that direction with the simplified API draft -- still a far cry from nice docs, but I think we need the better APIs before the better docs, at least this particular API improvement. Nico -- From hartmans@mit.edu Mon Feb 25 13:34:01 2013 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 D896521F91F3 for ; Mon, 25 Feb 2013 13:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.766 X-Spam-Level: X-Spam-Status: No, score=-102.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pjPLEF+T-BUB for ; Mon, 25 Feb 2013 13:33:59 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE9221F91EE for ; Mon, 25 Feb 2013 13:33:59 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 59A5720118; Mon, 25 Feb 2013 16:29:08 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C4F94447B; Mon, 25 Feb 2013 16:33:58 -0500 (EST) From: Sam Hartman To: "Cantor\, Scott" References: Date: Mon, 25 Feb 2013 16:33:58 -0500 In-Reply-To: (Scott Cantor's message of "Mon, 25 Feb 2013 21:05:18 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 25 Feb 2013 21:34:02 -0000 Scott, I definitely think discussing initiator behavior is also in scope. There are some tricky questions A lot of existing mechanisms don't allow the initiator to distinguish an acceptor inputting empty channel bindings from one who agreed with the initiator's bindings. On the initiator side there are several outcomes: 1) Channel bindings? What are those? You've got to be kidding; I can't do that with this mechanism. 2) I sent channel bindings out into the world. You didn't ask for mutual authentication; I have no clue what happened to your channel bindings. 3) I sent channel bindings out into the world. If the other side was unhappy with channel bindings we would have failed by now. Either they ignored them or validated them. This is the most you get with GSS mechanisms I'm reasonably familiar with 4) I verified that the other side di something with channel bindings. I'm sure the acceptor didn't pass in empty channel bindings. From nico@cryptonector.com Mon Feb 25 13:34:49 2013 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 22D0B21E80F2 for ; Mon, 25 Feb 2013 13:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.415 X-Spam-Level: X-Spam-Status: No, score=-3.415 tagged_above=-999 required=5 tests=[AWL=-1.438, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1pADgl9O9vc for ; Mon, 25 Feb 2013 13:34:48 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4AB21E80EA for ; Mon, 25 Feb 2013 13:34:47 -0800 (PST) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 08637768099 for ; Mon, 25 Feb 2013 13:34:47 -0800 (PST) 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=ROdSFCI+/YWYV7oBrTmH 6WPPSC0=; b=xgo2bcMb0guENttp8Mmws6Gm1cNfRG1f5/zixBlaWGocWhVpwabu 1lFCQOn0uLhD6RsLuYpdDMLflZ+Jjn8lpe0T+ucyr2LnKx1aln3Z8Cu8zFZozSeg zuYT5fMRx0wufHhMTaobooxf367iOp1LfH+91/qhGsVh8+UYzKN/PWU= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id A62FE768097 for ; Mon, 25 Feb 2013 13:34:46 -0800 (PST) Received: by mail-wi0-f178.google.com with SMTP id hq4so1181269wib.11 for ; Mon, 25 Feb 2013 13:34:45 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.74.228 with SMTP id x4mr15322149wiv.0.1361828085286; Mon, 25 Feb 2013 13:34:45 -0800 (PST) Received: by 10.216.148.193 with HTTP; Mon, 25 Feb 2013 13:34:45 -0800 (PST) In-Reply-To: <512BD42E.3070009@mit.edu> References: <512BD42E.3070009@mit.edu> Date: Mon, 25 Feb 2013 15:34:45 -0600 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] submitted draft-yu-kitten-kerberos-kdc-does-aliases-00 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, 25 Feb 2013 21:34:49 -0000 On Mon, Feb 25, 2013 at 3:14 PM, Greg Hudson wrote: > On 02/25/2013 03:57 PM, Nico Williams wrote: >> - Must KDCs canonicalize aliases, or is it OK for a KDC to expect (or >> know that) services to know their own aliases and share the same key >> (or derived keys?) for the aliases of the canonical names? >> >> - Further to the last question, if the new flag is set in a service >> ticket, should services decide to stop trying all keys to decrypt >> service tickets for which they have no explicit keytab entry? >> (Heimdal has code to do that.) > > I don't think this draft intends to change the way KDCs perform service > aliasing. It's only a hint to the client that DNS canonicalization of > service names isn't desired. > > The way service aliasing is done today, the KDC returns a ticket for > whatever server principal name the client requested, and the service has > to figure out what to do with a ticket which might be for an alias of > the service. In MIT krb5 and Heimdal, that means ignoring the ticket > server principal name if the keytab is iterable. OK, got it. That's fair. >> - How long can the meaning of this flag be cached for on clients? On servers? >> >> This gets to rollback issues. > > I can't imagine the answer being anything other than "for the lifetime > of the ticket." There's no reason a KDC has to start setting this > ticket flag the moment it has service aliasing support, so I don't see a > rollback issue. OK, but note that this constrains rollback operations. This should be stated. Nico -- From nico@cryptonector.com Mon Feb 25 13:48:16 2013 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 30BEA1F0D0E for ; Mon, 25 Feb 2013 13:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.108 X-Spam-Level: X-Spam-Status: No, score=-3.108 tagged_above=-999 required=5 tests=[AWL=-1.131, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV9KN2sWViMD for ; Mon, 25 Feb 2013 13:48:15 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA441F0D0A for ; Mon, 25 Feb 2013 13:48:15 -0800 (PST) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 47542B807F for ; Mon, 25 Feb 2013 13:48:11 -0800 (PST) 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=lRqhrVl9xevGvRYoIyTP gO/4ZFg=; b=pgWPf0bbpVNa0GVuTURWxR7z5ouXFHsifeBkO9zkm+2QJKjQziIc LFtrJb784N70Ru7Juc3/a8hyr4m9YmBjX7du15fBC8LIFvdFAmk5eZ3HhLd5wPfo 3qBrwSNhglinZGmquDss3BktFRUTybBpPwIwNYOVv5OxXrh0MRqCgnk= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id E1BD6B8078 for ; Mon, 25 Feb 2013 13:48:10 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id 12so2899973wgh.7 for ; Mon, 25 Feb 2013 13:48:09 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.76.84 with SMTP id i20mr15344521wiw.9.1361828889664; Mon, 25 Feb 2013 13:48:09 -0800 (PST) Received: by 10.216.148.193 with HTTP; Mon, 25 Feb 2013 13:48:09 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 15:48:09 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 25 Feb 2013 21:48:16 -0000 On Mon, Feb 25, 2013 at 3:33 PM, Sam Hartman wrote: > On the initiator side there are several outcomes: > > 1) Channel bindings? What are those? You've got to be kidding; I can't > do that with this mechanism. Good point. We need to distinguish between "this mech can't do CB" and "this mech can do CB but can't report on final outcome" and "this mech can do CB and the acceptor didn't". We already distinguish CB failure, so that's not a concern. We could distinguish the first of those ("this mech can't do CB") by returning an error, but how would that be useful in a SPNEGO context? Right, it wouldn't. So maybe we need two or three new ret_flags. At which point I'd just opt for an inquiry function that can distinguish all of these without burning so many (or even any) ret_flags. > 2) I sent channel bindings out into the world. You didn't ask for > mutual authentication; I have no clue what happened to your channel > bindings. Unless you got mutual anyways. > 4) I verified that the other side di something with channel > bindings. I'm sure the acceptor didn't pass in empty channel bindings. You've argued before that we didn't really need to verify that CB happened on the initiator side. Would you summarize your argument once more? If we nonetheless conclude that we'd like the initiator to know whether the acceptor did do CB (and, obviously, succeeded), do we want to update RFC4121 to indicate this? Nico -- From cantor.2@osu.edu Mon Feb 25 13:54:42 2013 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 F403421E80DB for ; Mon, 25 Feb 2013 13:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poUEepMbdQEu for ; Mon, 25 Feb 2013 13:54:41 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id 23F4921E8096 for ; Mon, 25 Feb 2013 13:54:41 -0800 (PST) Received: from mail216-va3-R.bigfish.com (10.7.14.251) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Feb 2013 21:54:39 +0000 Received: from mail216-va3 (localhost [127.0.0.1]) by mail216-va3-R.bigfish.com (Postfix) with ESMTP id 793678402DF; Mon, 25 Feb 2013 21:54:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.216; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf02; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2fh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail216-va3: domain of osu.edu designates 164.107.81.216 as permitted sender) client-ip=164.107.81.216; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf02 ; cio-tnc-pf02 ; Received: from mail216-va3 (localhost.localdomain [127.0.0.1]) by mail216-va3 (MessageSwitch) id 1361829277351704_28113; Mon, 25 Feb 2013 21:54:37 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.238]) by mail216-va3.bigfish.com (Postfix) with ESMTP id 539B0180091; Mon, 25 Feb 2013 21:54:37 +0000 (UTC) Received: from cio-tnc-pf02 (164.107.81.216) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Feb 2013 21:54:27 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf02 (Postfix) with ESMTP id 17E002004B; Mon, 25 Feb 2013 16:54:27 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.02.0328.009; Mon, 25 Feb 2013 16:54:27 -0500 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [kitten] Consensus by Apathy: working on channel bindings Thread-Index: AQHOE5/RsAUVjv1lNU2I0H+aRUQkiZiLHPYQ Date: Mon, 25 Feb 2013 21:54:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 25 Feb 2013 21:54:42 -0000 > There are some tricky questions A lot of existing mechanisms don't allow > the initiator to distinguish an acceptor inputting empty channel > bindings from one who agreed with the initiator's bindings. That would seem make it impossible for me to know, as an application, wheth= er I can rely on the channel for my protection services instead of using GS= S primitives. Which I thought was the whole point of CB. > 3) I sent channel bindings out into the world. If the other side was > unhappy with channel bindings we would have failed by now. Either they > ignored them or validated them. This is the most you get with GSS > mechanisms I'm reasonably familiar with That's the one I'm unclear on the value of, given my earlier point above. -- Scott From cantor.2@osu.edu Mon Feb 25 14:00:45 2013 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 2B30221E80E6 for ; Mon, 25 Feb 2013 14:00:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n3RZHKaWsuR for ; Mon, 25 Feb 2013 14:00:44 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id 6F17B21E80E0 for ; Mon, 25 Feb 2013 14:00:44 -0800 (PST) Received: from mail132-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Feb 2013 22:00:43 +0000 Received: from mail132-va3 (localhost [127.0.0.1]) by mail132-va3-R.bigfish.com (Postfix) with ESMTP id 740F02C018D; Mon, 25 Feb 2013 22:00:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.220; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf06; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzzz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2fh668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail132-va3: domain of osu.edu designates 164.107.81.220 as permitted sender) client-ip=164.107.81.220; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf06 ; cio-tnc-pf06 ; Received: from mail132-va3 (localhost.localdomain [127.0.0.1]) by mail132-va3 (MessageSwitch) id 1361829640862255_31604; Mon, 25 Feb 2013 22:00:40 +0000 (UTC) Received: from VA3EHSMHS022.bigfish.com (unknown [10.7.14.235]) by mail132-va3.bigfish.com (Postfix) with ESMTP id C3D631A007A; Mon, 25 Feb 2013 22:00:40 +0000 (UTC) Received: from cio-tnc-pf06 (164.107.81.220) by VA3EHSMHS022.bigfish.com (10.7.99.32) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Feb 2013 22:00:37 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf06 (Postfix) with ESMTP id CA1A33C005B; Mon, 25 Feb 2013 17:00:37 -0500 (EST) 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 id 14.02.0328.009; Mon, 25 Feb 2013 17:00:37 -0500 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] Consensus by Apathy: working on channel bindings Thread-Index: AQHOE5RasAUVjv1lNU2I0H+aRUQkiZiLD4iggABZmQD//7U0wA== Date: Mon, 25 Feb 2013 22:00:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 25 Feb 2013 22:00:45 -0000 PiBJIGRpZG4ndCBzYXkgYW55d2hlcmUgdGhhdCBvbmx5IGFjY2VwdG9ycyBzaG91bGQgdXNlIHRo ZSBuZXcgaW50ZXJmYWNlLg0KDQpJIHNob3VsZCBoYXZlIHNhaWQgInRvb2sgYXMgZ2l2ZW4gdGhl eSBkb24ndCBuZWVkIHRvIGtub3cgdGhpcyB0byBtYWtlIENCIHVzYWJsZSIsIHdoaWNoIGlzIHJl bGF0ZWQgdG8gdGhlIHF1ZXN0aW9uIHlvdSBhc2tlZCBTYW0uDQoNCkkgZG9uJ3Qgc2VlIGhvdyBJ IGNhbiB3cml0ZSBhbiBhcHBsaWNhdGlvbiBhbmQga25vdyB3aGV0aGVyIHRvIHVzZSB0aGUgVExT IGxheWVyIG9yIHRoZSBHU1MgbGF5ZXIgZm9yIG15IHNlY3VyaXR5IHNlcnZpY2VzIGlmIEkgZG9u J3Qga25vdyB3aGV0aGVyIHRoZSBjaGFubmVsIHdhcyBib3VuZC4gVGhhdCdzIHRydWUgb24gYm90 aCBlbmRzLg0KDQo+IFRoZSBwcm9ibGVtIGlzIHRoYXQgYWNjZXB0b3JzIG5lZWQgYSkgYW4gb3B0 aW9uIHRvIHN1Y2NlZWQgdy9vIENCLCBiKQ0KPiB0byBrbm93IHdoZXRoZXIgQ0IgaGFwcGVuZWQu ICBJbml0aWF0b3JzIG5lZWQgdGhpcyB0b28sIGJ1dCB0aGVpciBuZWVkDQo+IGlzIGxlc3NlciB0 aGFuIHRoZSBhY2NlcHRvcnMnLg0KDQpOb3QgY2xlYXIgb24gd2h5LCBwZXIgdGhlIGFib3ZlLiBJ J20gc3VyZSB0aGVyZSBtYXkgYmUgZGVwbG95bWVudCBpc3N1ZXMgYXNzb2NpYXRlZCB3aXRoIHdo aWNoIGVuZCBoYXMgdG8ga25vdyB3aGF0IGJhc2VkIG9uIGV4aXN0aW5nIGJlaGF2aW9yLCBidXQg aWdub3JlIHRoYXQgZm9yIHRoZSBtb21lbnQuIEknbSBqdXN0IHRyeWluZyB0byB1bmRlcnN0YW5k IGhvdyB0byByZWx5IG9uIENCIGluIGFuIGFwcGxpY2F0aW9uLg0KDQo+IEkgZ2V0IHRoaXMuICBQ YXJ0IG9mIG1lIHNheXM6IHRoZXJlIGFyZW4ndCByZWFsbHkgZW5vdWdoIHNlY3VyaXR5DQo+IGV4 cGVydHMsIHNvIHlvdSBoYXZlIHRvIGNvbnNpZGVyIGJlY29taW5nIG9uZSB5b3Vyc2VsZi4NCg0K T25lIGNhbiBvbmx5IHNwZW5kIHRpbWUgZGV2ZWxvcGluZyBzbyBtdWNoIGV4cGVydGlzZSwgdGhv dWdoLiBJIGhhdmUgdG8gYXNzdW1lIHRoYXQgSSBjYW4gZm9jdXMgb24gdGhlIHRoaW5ncyBJIG5l ZWQgdG8gYmUgZXhwZXJ0IGluIGFuZCBhc2sgcXVlc3Rpb25zIG9mIGV4cGVydHMgd2hlbiBJJ20g b3V0IG9mIHRoYXQgdGVycml0b3J5LiBJIHdhcyBiYXNpY2FsbHkgYW5zd2VyaW5nIHRoZSAiYXBh dGh5IiBxdWVzdGlvbi4gSSBjYXJlLCBJIGp1c3QgZG9uJ3Qga25vdyBlbm91Z2ggdG8gY29tbWVu dCB1c2VmdWxseSBvdGhlciB0aGFuIHRvIGhhdmUgYSBzdHJvbmcgc3VzcGljaW9uIHRoYXQgdGhl cmUncmUgc29tZSBwaWVjZXMgbWlzc2luZyBoZXJlIHRoYXQgaGF2ZSBiZWVuIGJ1Z2dpbmcgbWUg c2luY2UgSSBmaXJzdCBzdGFydGVkIHRyeWluZyB0byB3cml0ZSB0aGlzIG1lY2guDQoNCi0tIFNj b3R0DQoNCg== From nico@cryptonector.com Mon Feb 25 15:31:59 2013 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 651A421E8148 for ; Mon, 25 Feb 2013 15:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.095 X-Spam-Level: X-Spam-Status: No, score=-3.095 tagged_above=-999 required=5 tests=[AWL=-1.718, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8SdIX1FDOJJ for ; Mon, 25 Feb 2013 15:31:56 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 930BB21E8179 for ; Mon, 25 Feb 2013 15:31:56 -0800 (PST) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 5C4071B40F9 for ; Mon, 25 Feb 2013 15:31:56 -0800 (PST) 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=OtPrPQj2HStXulcn2QsOXM//7HY=; b=wM/jmAXPPir mr+j/XST88cfhkfTU4Zeh4E6q5oOBrRb8PxxtQrKR3ktymwKDTja82C3jlZ0ofHT /IfcdsNZ5hYQBoD4rfeYY4xnriVYrsIIC1NW9vz5tzecXyMEMperC5BlBilmAXaN sI0xBXdiPFCWd2YjUtflV6Lma9SZ1NUM= Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPSA id 8D5881B40F1 for ; Mon, 25 Feb 2013 15:31:55 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so5365717wie.0 for ; Mon, 25 Feb 2013 15:31:53 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.76.84 with SMTP id i20mr15719091wiw.9.1361835113937; Mon, 25 Feb 2013 15:31:53 -0800 (PST) Received: by 10.216.148.193 with HTTP; Mon, 25 Feb 2013 15:31:53 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 17:31:53 -0600 Message-ID: From: Nico Williams To: "Cantor, Scott" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 25 Feb 2013 23:31:59 -0000 On Mon, Feb 25, 2013 at 4:00 PM, Cantor, Scott wrote: > I don't see how I can write an application and know whether to use the TL= S layer or the GSS layer for my security services if I don't know whether t= he channel was bound. That's true on both ends. Ah, that. The question is: must the TLS client validate the server's cert and/or can it continue at all if the cert cannot be validated (e.g., ibecause it's self-signed and not pre-shared, or because there's no trust path fromt he server cert to a trust anchor on the client side). Or you might skip just the CRL/OCSP checking (e.g., when there's no stapled OCSP). Or you might simply log about this because, say, you do have a decent PKI but you'd like to stop having to have one and so you're trying to migrate into a world where you always do CB and *then* you'll turn off the PKI or parts of it. >> The problem is that acceptors need a) an option to succeed w/o CB, b) >> to know whether CB happened. Initiators need this too, but their need >> is lesser than the acceptors'. > > Not clear on why, per the above. I'm sure there may be deployment issues = associated with which end has to know what based on existing behavior, but = ignore that for the moment. I'm just trying to understand how to rely on CB= in an application. See above. >> I get this. Part of me says: there aren't really enough security >> experts, so you have to consider becoming one yourself. > > One can only spend time developing so much expertise, though. I have to a= ssume that I can focus on the things I need to be expert in and ask questio= ns of experts when I'm out of that territory. I was basically answering the= "apathy" question. I care, I just don't know enough to comment usefully ot= her than to have a strong suspicion that there're some pieces missing here = that have been bugging me since I first started trying to write this mech. Got it. There's no need to comment on that which you don't feel comfortable commenting. In this case uou might, for example, have useful feedback on which of the two proposed APIs is best (credential options or context options) but no useful feedback on the security aspects of the proposal (or even the problem). Note that you may well be in a better position to tell us which API is more usable than others who are in a better position to tell us about the security aspects of this issue. Nico -- From cantor.2@osu.edu Mon Feb 25 15:40:53 2013 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 5A65F21E815E for ; Mon, 25 Feb 2013 15:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoecbJbjaBed for ; Mon, 25 Feb 2013 15:40:52 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id B040B21E815D for ; Mon, 25 Feb 2013 15:40:52 -0800 (PST) Received: from mail3-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Feb 2013 23:40:52 +0000 Received: from mail3-va3 (localhost [127.0.0.1]) by mail3-va3-R.bigfish.com (Postfix) with ESMTP id 04CD88010C; Mon, 25 Feb 2013 23:40:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.208; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf01; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Idb82hzz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2fh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail3-va3: domain of osu.edu designates 164.107.81.208 as permitted sender) client-ip=164.107.81.208; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf01 ; cio-krc-pf01 ; Received: from mail3-va3 (localhost.localdomain [127.0.0.1]) by mail3-va3 (MessageSwitch) id 1361835650279055_16972; Mon, 25 Feb 2013 23:40:50 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.245]) by mail3-va3.bigfish.com (Postfix) with ESMTP id 3FD0E32004B; Mon, 25 Feb 2013 23:40:50 +0000 (UTC) Received: from cio-krc-pf01 (164.107.81.208) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server id 14.1.225.23; Mon, 25 Feb 2013 23:40:49 +0000 Received: from CIO-KRC-HT02.osuad.osu.edu (localhost [127.0.0.1]) by cio-krc-pf01 (Postfix) with ESMTP id D96D7A0051; Mon, 25 Feb 2013 18:40:49 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT02.osuad.osu.edu ([fe80::8554:1787:2a7:72c9%12]) with mapi id 14.02.0328.009; Mon, 25 Feb 2013 18:40:50 -0500 From: "Cantor, Scott" To: Nico Williams Thread-Topic: [kitten] Consensus by Apathy: working on channel bindings Thread-Index: AQHOE5RasAUVjv1lNU2I0H+aRUQkiZiLD4iggABZmQD//7U0wIAAbumA//+uywA= Date: Mon, 25 Feb 2013 23:40:49 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.15] Content-Type: text/plain; charset="us-ascii" Content-ID: <90F6832F6E526F4F809BA5D7CD9F0343@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 25 Feb 2013 23:40:53 -0000 On 2/25/13 6:31 PM, "Nico Williams" wrote: > >Ah, that. The question is: must the TLS client validate the server's >cert and/or can it continue at all if the cert cannot be validated >(e.g., ibecause it's self-signed and not pre-shared, or because >there's no trust path fromt he server cert to a trust anchor on the >client side). Yes, if you expect me to care about this CB stuff at all. The whole point for me is to not have to do all that stuff. But if it's optional to get this from GSS-API, which it is, then I have to know whether it's something I can use or not at runtime. >Got it. There's no need to comment on that which you don't feel >comfortable commenting. In this case uou might, for example, have >useful feedback on which of the two proposed APIs is best (credential >options or context options) but no useful feedback on the security >aspects of the proposal (or even the problem). Note that you may well >be in a better position to tell us which API is more usable than >others who are in a better position to tell us about the security >aspects of this issue. I'm really not able to comment much on the API because I'm living primarily below all this. I do think it's obviously necessary to get application feedback, but my impression is that the real work on apps is being done now by various projects that are finally getting all the patches done that need to be applied to real world software to make newer mechanisms workable. So people hacking on openssh, et al are probably the ones that need to comment on that. -- Scott From internet-drafts@ietf.org Mon Feb 25 15:41:52 2013 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 718CD21E8176; Mon, 25 Feb 2013 15:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbub9dZDRZ06; Mon, 25 Feb 2013 15:41:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E378C21E8178; Mon, 25 Feb 2013 15:41:50 -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: 4.40 Message-ID: <20130225234150.5714.90921.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 15:41:50 -0800 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-kerberos-iana-registries-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 23:41:52 -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 Gen= eration Working Group of the IETF. Title : Move Kerberos protocol parameter registries to IANA Author(s) : Tom Yu Filename : draft-ietf-kitten-kerberos-iana-registries-01.txt Pages : 8 Date : 2013-02-25 Abstract: The Keberos 5 network authentication protocol has several numeric protocol parameters. Most of these parameters are not currently under IANA maintenance. This document requests that IANA take over the maintenance of the remainder of these Kerberos parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-kerberos-iana-registries There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-kerberos-iana-registries-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-kerberos-iana-registri= es-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lha@kth.se Tue Feb 26 08:01:57 2013 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 B679421F8930 for ; Tue, 26 Feb 2013 08:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPok6j+xPNUq for ; Tue, 26 Feb 2013 08:01:56 -0800 (PST) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfa.amsl.com (Postfix) with ESMTP id 91E3C21F8901 for ; Tue, 26 Feb 2013 08:01:55 -0800 (PST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id E69A014DCCE; Tue, 26 Feb 2013 17:01:23 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id jh0ued3tcJev; Tue, 26 Feb 2013 17:01:12 +0100 (CET) X-KTH-Auth: lha [74.95.3.93] X-KTH-mail-from: lha@kth.se Received: from [10.0.1.3] (unknown [74.95.3.93]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 8CFB814EA0E; Tue, 26 Feb 2013 17:01:10 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: Date: Tue, 26 Feb 2013 08:01:06 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Tom Yu X-Mailer: Apple Mail (2.1499) Cc: kitten@ietf.org Subject: Re: [kitten] submitted draft-yu-kitten-kerberos-kdc-does-aliases-00 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, 26 Feb 2013 16:01:58 -0000 >=20 > On Mon, 18 Feb 2013, Tom Yu wrote: >=20 >> I've submitted this document as one component of the effort to remove >> dependence on insecure DNS for canonicalizing hostnames in service >> principal names. I would like the Working Group to consider it for >> adoption. I support this document. As nico points out, the behavior in the cross realm case needs to be = clarified. I think "start domain" picks behavior make sense since its the "owner" = of the client principal and the admin whom should care how much to = "protect" the user. Love From jbasney@illinois.edu Tue Feb 26 08:21:51 2013 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 80FE321F888C for ; Tue, 26 Feb 2013 08:21:51 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y+Iub15Od2u9 for ; Tue, 26 Feb 2013 08:21:51 -0800 (PST) Received: from pps02.cites.illinois.edu (pps02.cites.illinois.edu [192.17.82.100]) by ietfa.amsl.com (Postfix) with ESMTP id 56D9A21F8788 for ; Tue, 26 Feb 2013 08:21:50 -0800 (PST) Received: from citesht4.cites.illinois.edu (citesht4.cites.illinois.edu [128.174.34.209]) by pps02.cites.illinois.edu (8.14.5/8.14.5) with ESMTP id r1QGJgKU030902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 26 Feb 2013 10:21:42 -0600 Received: from o2.ncsa.illinois.edu (141.142.220.178) by smtp.illinois.edu (128.174.34.209) with Microsoft SMTP Server (TLS) id 14.2.328.9; Tue, 26 Feb 2013 10:20:59 -0600 Message-ID: <512CE0ED.8020609@illinois.edu> Date: Tue, 26 Feb 2013 10:21:01 -0600 From: Jim Basney User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: References: In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=0A33BE15; url=http://www.ncsa.illinois.edu/~jbasney/pgp.asc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [141.142.220.178] X-Spam-Details: rule=cautious_plus_nq_notspam policy=cautious_plus_nq score=0 kscore.is_bulkscore=8.51565684634181e-09 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.234172431493871 suspectscore=1 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.234172431493871 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.234172431493871 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1211240000 definitions=main-1302260116 X-Spam-OrigSender: jbasney@illinois.edu X-Spam-Bar: Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 26 Feb 2013 16:21:51 -0000 On 2/25/13 5:40 PM, Cantor, Scott wrote: > I'm really not able to comment much on the API because I'm living > primarily below all this. I do think it's obviously necessary to get > application feedback, but my impression is that the real work on apps is > being done now by various projects that are finally getting all the > patches done that need to be applied to real world software to make newer > mechanisms workable. So people hacking on openssh, et al are probably the > ones that need to comment on that. RFC 4462 gives us the following recommendation regarding channel bindings for SSH GSS-API: This document recommends that channel bindings SHOULD NOT be specified in the calls during context establishment. This document does not specify any standard data to be used as channel bindings, and the use of network addresses as channel bindings may break SSH in environments where it is most useful. So as one of the people hacking on OpenSSH, the above paragraph leads me to immediately lose interest in GSS-API channel bindings, unless I'm missing something. -Jim From cantor.2@osu.edu Tue Feb 26 08:29:05 2013 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 1C20521F886C for ; Tue, 26 Feb 2013 08:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ii3ILrR9h1MX for ; Tue, 26 Feb 2013 08:29:04 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7A4C921F8846 for ; Tue, 26 Feb 2013 08:29:04 -0800 (PST) Received: from mail208-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Feb 2013 16:29:03 +0000 Received: from mail208-va3 (localhost [127.0.0.1]) by mail208-va3-R.bigfish.com (Postfix) with ESMTP id C350F720773 for ; Tue, 26 Feb 2013 16:29:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.220; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf06; RD:none; EFVD:NLI X-SpamScore: -3 X-BigFish: VPS-3(zzbb2dI98dI9371Izz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzzz2fh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail208-va3: domain of osu.edu designates 164.107.81.220 as permitted sender) client-ip=164.107.81.220; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf06 ; cio-tnc-pf06 ; Received: from mail208-va3 (localhost.localdomain [127.0.0.1]) by mail208-va3 (MessageSwitch) id 1361896141797947_9362; Tue, 26 Feb 2013 16:29:01 +0000 (UTC) Received: from VA3EHSMHS029.bigfish.com (unknown [10.7.14.239]) by mail208-va3.bigfish.com (Postfix) with ESMTP id BF79FD40191; Tue, 26 Feb 2013 16:29:01 +0000 (UTC) Received: from cio-tnc-pf06 (164.107.81.220) by VA3EHSMHS029.bigfish.com (10.7.99.39) with Microsoft SMTP Server id 14.1.225.23; Tue, 26 Feb 2013 16:29:01 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf06 (Postfix) with ESMTP id E96133C0060; Tue, 26 Feb 2013 11:29:00 -0500 (EST) 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 id 14.02.0328.009; Tue, 26 Feb 2013 11:29:00 -0500 From: "Cantor, Scott" To: Jim Basney , "kitten@ietf.org" Thread-Topic: [kitten] Consensus by Apathy: working on channel bindings Thread-Index: AQHOE5RasAUVjv1lNU2I0H+aRUQkiZiLD4iggABZmQD//7U0wIAAbumA//+uywCAAWsogP//rmkA Date: Tue, 26 Feb 2013 16:29:00 +0000 Message-ID: In-Reply-To: <512CE0ED.8020609@illinois.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <0A8E30EE39E76744B13D7A86D67AB0A6@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-FOPE-CRA-Verdict: 164.107.81.220$illinois.edu%0%1%osu.edu%False%False%0$ X-OriginatorOrg: osu.edu Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 26 Feb 2013 16:29:05 -0000 On 2/26/13 11:21 AM, "Jim Basney" wrote: >So as one of the people hacking on OpenSSH, the above paragraph leads me >to immediately lose interest in GSS-API channel bindings, unless I'm >missing something. Yes, probably a poor example on my part since there's no CB needed there. What I meant was just generally that the API feedback is important from the people working on top trying to fix existing issues with apps vs. me writing a mechanism. -- Scott From nico@cryptonector.com Tue Feb 26 08:30:21 2013 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 A51F621F88BE for ; Tue, 26 Feb 2013 08:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.37 X-Spam-Level: X-Spam-Status: No, score=-3.37 tagged_above=-999 required=5 tests=[AWL=-1.393, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95yqpAiIiFOP for ; Tue, 26 Feb 2013 08:30:20 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id C2BF321F88A0 for ; Tue, 26 Feb 2013 08:30:20 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 370F3BC074 for ; Tue, 26 Feb 2013 08:30:19 -0800 (PST) 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=/sqlxbD94N5kfvCRBT57 YByRou8=; b=Zk/od/yGJMkM8yLe+FN3Qb1rJRwjZuwrGKuEjwRbBBcc9GxVaLMm HJoLPbTYcFWd/YgIGcrd3WEfAlysIzwf4Ga8esBL03jpzvSvwYR1BuXjceOnvkSF NDNvoJ81zWaIo0tqOApdfogpp+DakyzJsILgZDtr3R2AsDfGd9OwJ3Q= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 E4C39BC096 for ; Tue, 26 Feb 2013 08:30:16 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id hm14so5111403wib.15 for ; Tue, 26 Feb 2013 08:30:15 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr27601894wjr.33.1361896215362; Tue, 26 Feb 2013 08:30:15 -0800 (PST) Received: by 10.216.148.193 with HTTP; Tue, 26 Feb 2013 08:30:14 -0800 (PST) In-Reply-To: <512CE0ED.8020609@illinois.edu> References: <512CE0ED.8020609@illinois.edu> Date: Tue, 26 Feb 2013 10:30:14 -0600 Message-ID: From: Nico Williams To: Jim Basney Content-Type: text/plain; charset=UTF-8 Cc: kitten@ietf.org Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 26 Feb 2013 16:30:21 -0000 On Tue, Feb 26, 2013 at 10:21 AM, Jim Basney wrote: > RFC 4462 gives us the following recommendation regarding channel > bindings for SSH GSS-API: > > This document recommends that channel bindings SHOULD NOT be > specified in the calls during context establishment. This document > does not specify any standard data to be used as channel bindings, > and the use of network addresses as channel bindings may break SSH in > environments where it is most useful. > > So as one of the people hacking on OpenSSH, the above paragraph leads me > to immediately lose interest in GSS-API channel bindings, unless I'm > missing something. No no no :) RFC4462 is saying that in order to implement the application protocol that it specifies, no CB inputs should be passed to GSS_Init/Accept_sec_context(). RFC4462 is NOT making a value judgement on CB. Nico -- From iesg-secretary@ietf.org Tue Feb 26 09:29:51 2013 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 66E5821F884F; Tue, 26 Feb 2013 09:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qo06UolU-c9A; Tue, 26 Feb 2013 09:29:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BBF21F887F; Tue, 26 Feb 2013 09:29:50 -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: 4.40p1 Message-ID: <20130226172950.13660.59791.idtracker@ietfa.amsl.com> Date: Tue, 26 Feb 2013 09:29:50 -0800 Cc: kitten WG Subject: [kitten] WG Action: Rechartered Common Authentication Technology Next Generation (kitten) 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, 26 Feb 2013 17:29:51 -0000 The Common Authentication Technology Next Generation (kitten) working group in the Security Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Common Authentication Technology Next Generation (kitten) ------------------------------------------------ Current Status: Active Working Group Chairs: Shawn Emery Josh Howlett Sam Hartman Secretaries: Simon Josefsson Assigned Area Director: Stephen Farrell Mailing list Address: kitten@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/kitten Archive: http://www.ietf.org/mail-archive/web/kitten/ Charter of Working Group: The purpose of the Common Authentication Technology Next Generation (Kitten) working group (WG) is to develop extensions/improvements to the GSS-API and to the Kerberos authentication system, shepherd specific GSS-API security mechanisms, and provide guidance for any new SASL-related submissions. This charter combines the work of the Kerberos WG and the kitten WG (under the aegis of the kitten WG). In places, it identifies which WG was previously home for that work. The working group will develop extensions and/or updates to the GSS-API, working on specific items regarding credential management, replay cache avoidance, error reporting, and supporting stateless and/or distributed acceptors. The working group will also maintain and improve upon the Kerberos protocol, working on items regarding internationalization considering alignment with the precis work, new initial authentication types, authorization framework/data, replay cache avoidance, cryptography advances, interop with 3rd party authentication, and identity management. In detail, both existing and new work items include: Existing Working Group Items --------------------------- SASL Mechanism for OAuth (draft-ietf-kitten-sasl-oauth) SASL Mechansim for SAML-EC (draft-ietf-kitten-sasl-saml-ec) GSS-API IANA Registry (draft-ietf-kitten-gssapi-extensions-iana) KDC Model (draft-ietf-krb-wg-kdc-model) PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility) Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries) Initial and Pass Through Authentication in Kerberos 5 (draft-ietf-krb-wg-iakerb) Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-extensions) GSS-API Related --------------- Provide new interfaces for credential management, which include the following: initializing credentials iterating credentials exporting/importing credentials Negotiable replay cache avoidance Define interfaces for better error message reporting. Specify an option for exporting partially-established security contexts and possibly a utility function for exporting security contexts in an encrypted form, as well as a corresponding utility function to decrypt and import such security context tokens. Specify one-time password / two-factor authentication needs for SASL applications. This could be achieved through an explicit new GSS-API/SASL mechanism (e.g., http://tools.ietf.org/html/draft-josefsson-kitten-crotp-00) or if the consensus is that due to usability reasons, it is preferable to do OTP/2FA through an higher level protocol (Kerberos/OpenID/SAML/SAML20EC/EAP?) then prepare a document explaining the usability problem and provide pointers for implementers. Kerberos Related ---------------- Prepare, review, and advance standards-track and informational specifications defining new authorization data types for carrying supplemental information about the client to which a Kerberos ticket has been issued and/or restrictions on what the ticket can be used for. To enhance this ongoing authorization data work, a container format supporting the use cases of draft-ietf-krb-wg-pad may be standardized. Prepare a standards-track protocol to solve the use cases addressed by draft-hotz-kx509-01 including new support for digital signatures. Today Kerberos requires a replay cache to be used in AP exchanges in almost all cases. Replay caches are quite complex to implement correctly, particularly in clustered systems. High-performance replay caches are even more difficult to implement. The WG will pursue extensions to minimize the need for replay caching, optimize replay caching, and/or elide the need for replay caching. Prepare, review, and advance standards-track and informational specifications defining use of new cryptographic algorithms in the Kerberos protocol using the RFC3961 framework, on an ongoing basis. Cryptographic algorithms intended for standards track status must be of good quality, have broad international support, and fill a definite need. Prepare, review, and advance standards-track and informational specifications of new pre-authentication types for the Kerberos protocol, on an ongoing basis. Prepare, review, and advance standards track updates and extensions to RFC4121, as needed and on an ongoing basis. Milestones: Mar 2013 - draft-ietf-kitten-sasl-oauth to IESG Mar 2013 - draft-ietf-krb-wg-pkinit-alg-agility to IESG Apr 2013 - draft-ietf-kitten-sasl-saml-ec to IESG Apr 2013 - draft-ietf-krb-wg-iakerb to IESG May 2013 - draft-ietf-kitten-gssapi-extensions-iana to IESG May 2013 - draft-ietf-krb-wg-cammac to IESG Jun 2013 - draft-ietf-kitten-kerberos-iana-registries to IESG Jun 2013 - draft-ietf-krb-wg-pad to IESG Jul 2013 - Adopt work on one or more items for GSS-API cred management Jul 2013 - Adopt work on better error reporting in the GSS-API Aug 2013 - Adopt work on exporting partially-established GSS-API contexts Aug 2013 - draft-ietf-krb-wg-ticket-extensions to IESG Sep 2013 - Adopt work on the GSS-API for replay cache avoidance From jhutz@cmu.edu Tue Feb 26 10:13:47 2013 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 BBA9F21F88A0 for ; Tue, 26 Feb 2013 10:13:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.488 X-Spam-Level: X-Spam-Status: No, score=-106.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzR++Zyj8M+D for ; Tue, 26 Feb 2013 10:13:46 -0800 (PST) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by ietfa.amsl.com (Postfix) with ESMTP id F0C6021F8633 for ; Tue, 26 Feb 2013 10:13:35 -0800 (PST) Received: from [128.2.193.239] (minbar.fac.cs.cmu.edu [128.2.193.239]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id r1QIDYle003398 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2013 13:13:34 -0500 (EST) Message-ID: <1361902414.9132.61.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Jim Basney Date: Tue, 26 Feb 2013 13:13:34 -0500 In-Reply-To: <22584_1361895714_r1QGLrB2023025_512CE0ED.8020609@illinois.edu> References: <22584_1361895714_r1QGLrB2023025_512CE0ED.8020609@illinois.edu> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.3-0ubuntu6 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] Consensus by Apathy: working on channel bindings 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, 26 Feb 2013 18:13:48 -0000 On Tue, 2013-02-26 at 10:21 -0600, Jim Basney wrote: > On 2/25/13 5:40 PM, Cantor, Scott wrote: > > I'm really not able to comment much on the API because I'm living > > primarily below all this. I do think it's obviously necessary to get > > application feedback, but my impression is that the real work on apps is > > being done now by various projects that are finally getting all the > > patches done that need to be applied to real world software to make newer > > mechanisms workable. So people hacking on openssh, et al are probably the > > ones that need to comment on that. > > RFC 4462 gives us the following recommendation regarding channel > bindings for SSH GSS-API: > > This document recommends that channel bindings SHOULD NOT be > specified in the calls during context establishment. This document > does not specify any standard data to be used as channel bindings, > and the use of network addresses as channel bindings may break SSH in > environments where it is most useful. > > So as one of the people hacking on OpenSSH, the above paragraph leads me > to immediately lose interest in GSS-API channel bindings, unless I'm > missing something. That text primarily warns you not to fill in the address information described in the GSS-API, which is basically useless and considered deprecated. These days, when we speak of channel binding, we're primarily talking about cryptographic binding to an underlying secure channel, which in GSS-API is accomplished through a field in the channel bindings structure that allows for protection of opaque channel-related data provided by the application. However, you're basically right -- the GSS-API keyex and userauth methods described in RFC4462 do not use GSS-API channel bindings, so this discussion is basically moot for SSH. -- Jeff From shawn.emery@oracle.com Wed Feb 27 14:03:59 2013 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 0EFDF21F84DC for ; Wed, 27 Feb 2013 14:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLLm5z9byN7Q for ; Wed, 27 Feb 2013 14:03:58 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 90ED621F84CD for ; Wed, 27 Feb 2013 14:03:58 -0800 (PST) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r1RM3vvI032222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 27 Feb 2013 22:03:58 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r1RM3u6g024214 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 27 Feb 2013 22:03:57 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r1RM3udV028472 for ; Wed, 27 Feb 2013 16:03:56 -0600 Received: from [10.159.68.204] (/10.159.68.204) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Feb 2013 14:03:56 -0800 Message-ID: <512E828C.7040004@oracle.com> Date: Wed, 27 Feb 2013 15:02:52 -0700 From: Shawn Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:10.0.11) Gecko/20121204 Thunderbird/10.0.11 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: multipart/alternative; boundary="------------030004010201040509010602" X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Subject: [kitten] IETF 86 Agenda 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, 27 Feb 2013 22:03:59 -0000 This is a multi-part message in MIME format. --------------030004010201040509010602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Here is the draft agenda for the kitten session at IETF 86: http://www.ietf.org/proceedings/86/agenda/agenda-86-kitten Please provide feed-back/additions no later than March 4th. Shawn Emery. -- kitten co-chair --------------030004010201040509010602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Here is the draft agenda for the kitten session at IETF 86:

    http://www.ietf.org/proceedings/86/agenda/agenda-86-kitten

 Please provide feed-back/additions no later than March 4th.

Shawn Emery.
--
kitten co-chair
 --------------030004010201040509010602-- From stpeter@stpeter.im Wed Feb 27 14:12:35 2013 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 ED0CA21F87F6 for ; Wed, 27 Feb 2013 14:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFT53L-isPKo for ; Wed, 27 Feb 2013 14:12:35 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id C32FE21F87E5 for ; Wed, 27 Feb 2013 14:12:34 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.234]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EEF464060C for ; Wed, 27 Feb 2013 15:20:25 -0700 (MST) Message-ID: <512E84CB.5040601@stpeter.im> Date: Wed, 27 Feb 2013 15:12:27 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: kitten@ietf.org References: <512E828C.7040004@oracle.com> In-Reply-To: <512E828C.7040004@oracle.com> X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [kitten] IETF 86 Agenda 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, 27 Feb 2013 22:12:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/27/13 3:02 PM, Shawn Emery wrote: > > Here is the draft agenda for the kitten session at IETF 86: > > http://www.ietf.org/proceedings/86/agenda/agenda-86-kitten > > Please provide feed-back/additions no later than March 4th. I'm hoping that folks who are interested in saslprepbis will join the PRECIS meeting on Thursday afternoon at 13:00. Full disclosure: it's opposite wpkops and sacm, both of which might be of interest to sec area folks. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRLoTKAAoJEOoGpJErxa2pqpsP/RxRwzBm6D5whBx62Zx1hEDP /z4AK6bfKvl7/wLggmM/y21OzzZSi9Y9hVPV+rMJ3rlo/dDztGCy0vdaaZ+rIsHJ MTZvXSGe2srYH9/lhcqW+JKS2oDaZfwP1M0dWPXA4z8duhpIQoQCvfNrNhYDB9dg qVjm110YLeh+oISSd/n5xUwmrdRqBp3u8EcLCPvAR9SqOunMIIF09vNhCly8f67M j7wlBiAsG/c6JoVke6pl+34Us3fxGQZXFi8W3DjDgBQVrz7MfMCw49anBiA6NVuQ L3BYLYkTw0R/gvislZNnRMpNjIGyzFe79LESUCm1kNGJHs+2+IOYsnCf6/WcaZr8 mVQhIVZbn4ys9vwRcKks/PqczrkDiVR2yX54+w2hSL+J72lHmHL7yAf2pzWCdkJc Yv/wim6JCmr5+/nbxd392G2rOcbblP1JyW8e+jn928IEKI3nSNGLSEu6GsyBvaig h8cQdbAXLmbCYa9U2PzZx2oYuwH8hNCGW96GccIFOzEF/wATJcg6u1r9id3yytaL d/rp3vAAHtk+C4tZmQxrk+DmXv0M/dDeG8wc1jIpIGhDBG0gE0zOj+lH79LlNHsX H72HwwMXsdH0PHes4YhH0V46IF9HYynGImw+u+/1+XFdKEE/37sTFs3Od7+l0HOz nWZ6npTVcgH3/CoYmyaQ =ps+0 -----END PGP SIGNATURE-----