From mpeck@mitre.org Tue Oct 1 05:34: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 D7C1E21E80EC for ; Tue, 1 Oct 2013 05:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0XJvScfULg8 for ; Tue, 1 Oct 2013 05:34:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id B640B11E80FE for ; Tue, 1 Oct 2013 05:34:17 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 211681F05D2; Tue, 1 Oct 2013 08:34:17 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D7C3D1F05E1; Tue, 1 Oct 2013 08:34:16 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.65]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0158.001; Tue, 1 Oct 2013 08:34:16 -0400 From: "Peck, Michael A" To: "Paul Miller (NT)" , Sam Hartman , Benjamin Kaduk Thread-Topic: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 Thread-Index: AQHOuTQq/YJPGZsjR5SXJRM51ZMV75nVs48AgAofGwA= Date: Tue, 1 Oct 2013 12:34:16 +0000 Message-ID: In-Reply-To: <1553bab817a2411c90c18aa4ffd2b1dc@BLUPR03MB279.namprd03.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [128.29.194.92] Content-Type: text/plain; charset="us-ascii" Content-ID: <1A6AE6C06F191344A6996BDB2C5EB964@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "kitten@ietf.org" , Michiko Short Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 01 Oct 2013 12:34:31 -0000 Hi Paul, Your example plaintexts below wouldn't result in ambiguous behavior with PKCS #7 padding. As described in RFC5652 Section 6.3, your second plaintext example would have a full block of padding added. Our reasoning for using an explicit IV: Comply with the definition of CBC in NIST SP 800-38A (or the definition of CTS in NIST SP 800-38A Addendum), it's the current standard cryptographic practice, and save an unnecessary encryption/decryption operation per message. Mike On 9/24/13 6:00 PM, "Paul Miller (NT)" wrote: >Through GSS_Wrap, the fact that we are encrypting at least the header per >RFC 4121 ensures that the message is not less than one block. The use of >the cipher suite in the context establishment could be a problem, however. > >Without the confounder to avoid the short message problem, there could be >ambiguity between what is CTS encoded to exact length and what is padded >when the cipher text is exactly one block length. That is to say that >the plain texts: > >01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd >01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd 01 > >Would end up encrypting the same and could not be distinguished as the >former would need to PKCS #7 pad and the latter would just CBC the single >block. > >I'm sorry I missed a lot of the context from prior discussions, but what >is the reason for using a traditional IV instead of the confounder? I >don't see a difference in security and using the confounder like cipher >text allows CTS for short inputs. > >-----Original Message----- >From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf >Of Sam Hartman >Sent: Tuesday, September 24, 2013 7:42 AM >To: Benjamin Kaduk >Cc: kitten@ietf.org; Michiko Short; Sam Hartman >Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 > >>>>>> "Benjamin" =3D=3D Benjamin Kaduk writes: > > Benjamin> On Mon, 23 Sep 2013, Sam Hartman wrote: > >> Hi. With my chair hat on, does anyone wish to re-open the > >> discussion of the CBC decision based on this late input? > > Benjamin> No comment on that particular question as of yet, but I > Benjamin> would ask for a clarification from Paul -- when he says > Benjamin> that "We use CTS today with AES so the complexity penalty > Benjamin> for using it is already paid. Using known-good code > Benjamin> reduces the chance of introducing new security holes.", > Benjamin> does this account for the difference between the existing > Benjamin> enctypes (17,18) and the propsed enctypes with respect to > Benjamin> the use of a confounder versus explicit initialization > Benjamin> vector, and the the corresponding need to special-case > Benjamin> short inputs in the new proposal? I could not tell what > Benjamin> Microsoft's position on the short-input behavior was from > Benjamin> Paul's initial message. > >well, I can't think of a way to get to a short-input case throguh SSPI. > >It seems like we're having the discussion, so that bar has been reached. >_______________________________________________ >Kitten mailing list >Kitten@ietf.org >https://www.ietf.org/mailman/listinfo/kitten >_______________________________________________ >Kitten mailing list >Kitten@ietf.org >https://www.ietf.org/mailman/listinfo/kitten From mpeck@mitre.org Tue Oct 1 06:10: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 0E08D21E80CE for ; Tue, 1 Oct 2013 06:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-c8oq8ez00c for ; Tue, 1 Oct 2013 06:10:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF3511E8204 for ; Tue, 1 Oct 2013 06:06:26 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B83441F0285; Tue, 1 Oct 2013 09:06:25 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A591B1F0601; Tue, 1 Oct 2013 09:06:25 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.65]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.03.0158.001; Tue, 1 Oct 2013 09:06:25 -0400 From: "Peck, Michael A" To: "Paul Miller (NT)" , "kitten@ietf.org" Thread-Topic: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 Thread-Index: Ac62VqJ6/YJPGZsjR5SXJRM51ZMV7wIUGS6A Date: Tue, 1 Oct 2013 13:06:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.7.130812 x-originating-ip: [128.29.194.92] Content-Type: multipart/alternative; boundary="_000_CE7039AD655Empeckmitreorg_" MIME-Version: 1.0 Cc: Michiko Short Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 01 Oct 2013 13:10:07 -0000 --_000_CE7039AD655Empeckmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I just uploaded our latest CBC draft. It's probably awaiting WG chair appr= oval. It's here temporarily: http://www.ietf.org/staging/draft-ietf-kitten= -aes-cbc-hmac-sha2-00.txt We're obviously happy to follow whatever the WG consensus ends up being for= CBC vs CTS. SHA-384 is in our drafts because it's one of the Suite B hash algorithms. = We'd be happy to add the AES-256 and HMAC-SHA-512 combination too. I believe there was some prior mailing list discussion about AES-CMAC. We = didn't use it because it only provides 128 bits. Mike From: "Paul Miller (NT)" = > Date: Friday, September 20, 2013 8:28 PM To: "kitten@ietf.org" > Cc: Michiko Short > Subject: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 I should first introduce myself as I am most likely unfamiliar to most of y= ou. My name is Paul Miller and I am the developer responsible for the Kerb= eros implementation in Windows. In addition to working on Kerberos, I also= am primarily responsible for the SSPI interface. Michiko Short is out of = office until November; in the interim I will be the Microsoft representativ= e to the working group. I apologize for the lateness of this communication= . Last month I met with Michiko and our cryptographer Niels Ferguson along wi= th a few other stakeholders to discuss the draft and the possibility of usi= ng the CBC cipher mode instead of CTS. Our conclusion is that the risk of = application compatibility when using a cipher suite that does not preserve = the length of the cipher text is too high. Most Windows consumers of SSPI = for user authentication call SPNEGO. This historically negotiates either K= erberos or NTLM. NTLM uses the RC4 stream cipher which preserves length, w= hile Kerberos between Windows systems would use either RC4 or AES-CTS, both= of which are length preserving. While it is true that most applications d= o not call into SSPI directly, instead going through a component like RPC t= hat will handle message encryption correctly, even the fraction of applicat= ions that call directly still represents thousands of pieces of software. = Of these, a non-trivial percentage are likely not to handle data expansion = correctly. It is true that DES has padding and that as a result callers sh= ould handle this correctly, but due to the fact that DES has never been neg= otiated by default between Windows systems (and is even disabled by default= in current versions) means that test coverage of third party applications = with DES encryption is essentially non-existent. Due to the application compatibility risk that we would face, we do not fee= l that CBC is worth the risk. CTS is proven to work for our callers. Here are some other unordered observations from that meeting: We use CTS today with AES so the complexity penalty for using it is already= paid. Using known-good code reduces the chance of introducing new securit= y holes. Using SHA-384 serves no purpose. It=92s the same operation as SHA-512 and = thus no cheaper to perform. Alternately, there as AES-CMAC which has the benefit of reusing the AES cod= e and can be accelerated with AES-NI, but it is only 128 bits of output. I would also offer that CTS is in fact CBC where the padding is cipher text= from the second to last block. The property of this padding where we can = then omit the cipher text that is absorbed into the last block of plain tex= t in order to preserve length is orthogonal to the properties of the cipher= mode. I do not see where using the CTS mode would then impact the ability= of cryptographic implementations to support AES or the compliance of those= implementations with security standards. Paul J. Miller --_000_CE7039AD655Empeckmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8BE64138B726DA469374AE01214D3DF5@imc.mitre.org> Content-Transfer-Encoding: quoted-printable
I just uploaded our latest CBC draft.  It's probably awaiting WG chair= approval.  It's here temporarily: http://www.ietf.org/st= aging/draft-ietf-kitten-aes-cbc-hmac-sha2-00.txt
We're obviously happy to follow whatever the WG consensus ends up being for= CBC vs CTS.

SHA-384 is in our drafts because it's one of the Suite B hash algorithms. &= nbsp;We'd be happy to add the AES-256 and HMAC-SHA-512 combination too.

I believe there was some prior mailing list discussion about AES-CMAC. &nbs= p;We didn't use it because it only provides 128 bits.

Mike


From: "Paul Miller (NT)" = <paumil@microsoft.com> Date: Friday, September 20, 2013 8:= 28 PM
To: "kitten@ietf.org" <= kitten@ietf.org>
Cc: Michiko Short <michikos@microsoft.com>
Subject: [kitten] draft-ietf-kitten= -aes-cts-hmac-sha2-01

I should first introduce myself as I am most likely = unfamiliar to most of you.  My name is Paul Miller and I am the develo= per responsible for the Kerberos implementation in Windows.  In additi= on to working on Kerberos, I also am primarily responsible for the SSPI interface.  Michiko Short is out of office u= ntil November; in the interim I will be the Microsoft representative to the= working group.  I apologize for the lateness of this communication.

 

Last month I met with Michiko and our cryptographer = Niels Ferguson along with a few other stakeholders to discuss the draft and= the possibility of using the CBC cipher mode instead of CTS.  Our con= clusion is that the risk of application compatibility when using a cipher suite that does not preserve the length = of the cipher text is too high.  Most Windows consumers of SSPI for us= er authentication call SPNEGO.  This historically negotiates either Ke= rberos or NTLM.  NTLM uses the RC4 stream cipher which preserves length, while Kerberos between Windows systems woul= d use either RC4 or AES-CTS, both of which are length preserving.  Whi= le it is true that most applications do not call into SSPI directly, instea= d going through a component like RPC that will handle message encryption correctly, even the fraction of applic= ations that call directly still represents thousands of pieces of software.=   Of these, a non-trivial percentage are likely not to handle data exp= ansion correctly.  It is true that DES has padding and that as a result callers should handle this correctly, but= due to the fact that DES has never been negotiated by default between Wind= ows systems (and is even disabled by default in current versions) means tha= t test coverage of third party applications with DES encryption is essentially non-existent.

 

Due to the application compatibility risk that we wo= uld face, we do not feel that CBC is worth the risk.  CTS is proven to= work for our callers.

 

Here are some other unordered observations from that= meeting:

 

We use CTS today with AES= so the complexity penalty for using it is already paid.  Using known-= good code reduces the chance of introducing new security holes.<= /p>

 

Using SHA-384 serves no p= urpose.  It=92s the same operation as SHA-512 and thus no cheaper to p= erform.

 

Alternately, there as AES= -CMAC which has the benefit of reusing the AES code and can be accelerated = with AES-NI, but it is only 128 bits of output.

 

I would also offer that CTS is in fact CBC where the= padding is cipher text from the second to last block.  The property o= f this padding where we can then omit the cipher text that is absorbed into= the last block of plain text in order to preserve length is orthogonal to the properties of the cipher mode.&nbs= p; I do not see where using the CTS mode would then impact the ability of c= ryptographic implementations to support AES or the compliance of those impl= ementations with security standards.

 

Paul J. Miller

 

 --_000_CE7039AD655Empeckmitreorg_-- From hartmans@mit.edu Tue Oct 1 12:54: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 C117921E80C5 for ; Tue, 1 Oct 2013 12:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100 X-Spam-Level: X-Spam-Status: No, score=-100 tagged_above=-999 required=5 tests=[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 hvTsP2nyHhO1 for ; Tue, 1 Oct 2013 12:54:22 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 0679421E818A for ; Tue, 1 Oct 2013 12:53:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6C24B2037F; Tue, 1 Oct 2013 15:52:40 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CH-KbCErneom; Tue, 1 Oct 2013 15:52:39 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 1 Oct 2013 15:52:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C866582B43; Tue, 1 Oct 2013 15:53:43 -0400 (EDT) From: Sam Hartman To: "Paul Miller \(NT\)" References: <68eb2a3d201548349da7634f867a46cc@BLUPR03MB279.namprd03.prod.outlook.com> Date: Tue, 01 Oct 2013 15:53:43 -0400 In-Reply-To: <68eb2a3d201548349da7634f867a46cc@BLUPR03MB279.namprd03.prod.outlook.com> (Paul Miller's message of "Fri, 27 Sep 2013 22:56:07 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "kitten@ietf.org" Subject: Re: [kitten] explicit CBC IVs vs confounders: covert channels (draft-ietf-kitten-aes-cts-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: Tue, 01 Oct 2013 19:54:35 -0000 >>>>> "Paul" == Paul Miller (NT) writes: Paul> While I agree with the analysis that the use of a confounder Paul> will limit the exposure of the state of a faulty PRNG, I don't Paul> see this as a problem that needs to be addressed by Kerberos. Paul> The RNG is a system service and not part of the Kerberos Paul> specification. RFC 4120 references RFC 4086 "Randomness Paul> Requirements for Security" so the condition not to use a PRNG Paul> that leaks state is already covered. Between nonces and Paul> randomly generated session keys, there are plenty of other Paul> avenues for insufficient randomness to manifest. This is not Paul> to say that I disagree with using a confounder. A confounder Paul> is quite useful as a source of cipher text from which to steal Paul> in order to make CTS work with short inputs. The issue here in my mind is that it seems like we as a community have paid inadequate attention to what the damage of a malicious RNG could do is. We've been focusing on the sorts of things described in RFC 4086, rather than RNGS maliciously affected either in implementation or standards. That class of attack having been pointed out, we should consider its impact on security systems we design. I agree that introducing another covert channel by which random data can leak is kind of uninteresting. However, an attacker who can predict your RNG state will now be much more able to predict future explicit IVs. Where as that attacker will find it difficult to predict explicit confounders without knowing the key. I have not yet figured out whether this matters. From nico@cryptonector.com Tue Oct 1 15:19: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 610F121E822B for ; Tue, 1 Oct 2013 15:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 dTys9-jqIAAp for ; Tue, 1 Oct 2013 15:19:43 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id C8E4C21E820E for ; Tue, 1 Oct 2013 15:19:33 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 9386C264060 for ; Tue, 1 Oct 2013 15:19:33 -0700 (PDT) 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=Bnx7ALp7PEF/8x0ZbUcV sLeZBOE=; b=OhHb8bgVBZvOM9NSAEkDwXJIPhkaB8wbNIxhF/2rjb/hiWFXSB3t +YjLVRV1YVqRfdhipeLrG+HN7FOBq/2XF1tyHcPlPl/mFkhBF8yc98IX02M9rgGd /FPNWBHe4twh+PaL/VDTCD5Kk7FfYp/46m3UGcKpRnaEv0oD+/4IZho= 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-a88.g.dreamhost.com (Postfix) with ESMTPSA id 47FCF264058 for ; Tue, 1 Oct 2013 15:19:33 -0700 (PDT) Received: by mail-we0-f174.google.com with SMTP id q58so7988475wes.19 for ; Tue, 01 Oct 2013 15:19:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=UCl9YF60heDofEdYLdNb2OJkBNmIdJ5nw3ixRWauZI4=; b=B73bbElWjO1fcz3hz1kzP8wm8/YlM4w+0l+gAhGFej5hS0asx7uhUKeupPF1dVPQiD u/o+s0p0tTiQDFLK1zpbrxjycaujo5KwfwIq7E4raYlqhW/aG9zAH8t8JHwxo9E5PhtN 7CAoMc0HFiWjzBD9VMQyrVaBwCa3clZh7vIRoh0UKpkwQplEiD9cpPCOiWSn0DG8GbmP x+v8+m1E7ycCROMG5PyYNl/vznaU6BxWtky7cX0Ip/Cz6bhFyYChE3Q+f0EB6mVu7gnL vR0AlAc2OxCR/14mhNH5tSV44jyo1Pt0lOS5sYpcOvlaUovle9cYJSi1g/8yZ2h5r1v8 /Oew== MIME-Version: 1.0 X-Received: by 10.180.19.169 with SMTP id g9mr20715134wie.39.1380665971612; Tue, 01 Oct 2013 15:19:31 -0700 (PDT) Received: by 10.216.240.70 with HTTP; Tue, 1 Oct 2013 15:19:31 -0700 (PDT) In-Reply-To: References: <68eb2a3d201548349da7634f867a46cc@BLUPR03MB279.namprd03.prod.outlook.com> Date: Tue, 1 Oct 2013 17:19:31 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] explicit CBC IVs vs confounders: covert channels (draft-ietf-kitten-aes-cts-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: Tue, 01 Oct 2013 22:19:54 -0000 For uses of RFC3961 without state chaining there's no way to prove that the confounder was obtained by encrypting a random IV... So confounding isn't necessarily sufficient to prevent leaking of RNG state or keys, at least not for GSS mechanism uses. And even where chaining is used, there is one initial state case where the sender might not have produced a confounder by encrypting a random IV, so confounding does little to prevent leakage of RNG state (or outright leakage of keys) via the confounder. In light of recent events, I would like us to design protocols that -as much as possible- have no public nonces, and where they are necessary, they should be as small as possible and their cryptographic purpose replaced/augmented by the plaintext of nonces sent enciphered as soon as appropriate key material is available. For Kerberos this may require a revamp of RFC3961, with attendant changes to implementations' APIs and to applications (so they may use the new enctypes), unless we get clever. If we're not prepared to do either (upate RFC3961 or get clever) at this time, then which I think I prefer to stick to confounding, with the security considerations involved noted. Of course, the right thing to do is to not leak RNG outputs by using them as random IVs directly. As various participants have pointed out in various crypto lists, we all assumed no one would do *that* (use a conjectured-backdoored RNG's outputs directly as nonces and keys), and this sentiment will be even stronger going forward. Preventing peers from compromising one's communications with them is desirable, but I think the best we can do is limit their covert channels for doing so, and since one must trust one's peers to a fairly large degree... I'm not too concerned here and I'm willing to settle for either random IVs or confounders if there's no support for doing something better. Nico -- From paumil@microsoft.com Tue Oct 1 16:06:24 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 C5CAA1F0D07 for ; Tue, 1 Oct 2013 16:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18QImvi+uPID for ; Tue, 1 Oct 2013 16:06:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0157.outbound.protection.outlook.com [207.46.163.157]) by ietfa.amsl.com (Postfix) with ESMTP id BB81D21F9E01 for ; Tue, 1 Oct 2013 16:06:02 -0700 (PDT) Received: from BLUPR03MB279.namprd03.prod.outlook.com (10.255.213.17) by BLUPR03MB277.namprd03.prod.outlook.com (10.255.213.15) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 1 Oct 2013 23:06:01 +0000 Received: from BLUPR03MB279.namprd03.prod.outlook.com ([169.254.1.181]) by BLUPR03MB279.namprd03.prod.outlook.com ([169.254.1.181]) with mapi id 15.00.0785.001; Tue, 1 Oct 2013 23:06:00 +0000 From: "Paul Miller (NT)" To: "Peck, Michael A" , Sam Hartman , Benjamin Kaduk Thread-Topic: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 Thread-Index: AQHOuTQqLL9iqiJfDEOixCgfmtSLk5nVbNDwgApl3ACAAKb/AA== Date: Tue, 1 Oct 2013 23:06:00 +0000 Message-ID: <0ed0b14528314630b9c500399497dcc2@BLUPR03MB279.namprd03.prod.outlook.com> References: <1553bab817a2411c90c18aa4ffd2b1dc@BLUPR03MB279.namprd03.prod.outlook.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e0:ee43::3] x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(479174003)(13464003)(24454002)(189002)(199002)(51704005)(31966008)(51856001)(19580395003)(74662001)(19580405001)(83322001)(47446002)(74502001)(49866001)(47976001)(76482001)(74366001)(63696002)(56776001)(561944002)(53806001)(54356001)(33646001)(80976001)(59766001)(47736001)(77982001)(83072001)(74316001)(4396001)(74706001)(74876001)(50986001)(65816001)(80022001)(79102001)(81342001)(81542001)(76796001)(46102001)(54316002)(81686001)(77096001)(81816001)(56816003)(76576001)(76786001)(69226001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB277; H:BLUPR03MB279.namprd03.prod.outlook.com; CLIP:2001:4898:80e0:ee43::3; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "kitten@ietf.org" , Michiko Short Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 01 Oct 2013 23:06:25 -0000 I omitted the critical context for my statement. We cannot follow the beha= vior in RFC3962 for short cipher texts if we are to use an IV instead of a = confounder. RFC3962 says this in section 5: Ciphertext stealing, as defined in [RC5], assumes that more than one block of plain text is available. If exactly one block is to be encrypted, that block is simply encrypted with AES (also known as ECB mode). Input smaller than one block is padded at the end to one block; the values of the padding bits are unspecified. This behavior of using padding for text shorter than one block and not padd= ing block sized inputs creates the ambiguity. We just never encountered an= y problems due to the use of the confounder which prevents inputs smaller t= han one block from occurring. The CTS behavior in draft-ietf-kitten-aes-cts-hmac-sha2 describes cipher te= xt stealing from the nonce handling short inputs. I do not have any strong= feelings on IV versus confounder so long as we keep using CTS in a mode th= at can steal from the IV to handle short inputs. -----Original Message----- From: Peck, Michael A [mailto:mpeck@mitre.org]=20 Sent: Tuesday, October 1, 2013 5:34 AM To: Paul Miller (NT); Sam Hartman; Benjamin Kaduk Cc: kitten@ietf.org; Michiko Short Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 Hi Paul, Your example plaintexts below wouldn't result in ambiguous behavior with PK= CS #7 padding. As described in RFC5652 Section 6.3, your second plaintext example would ha= ve a full block of padding added. Our reasoning for using an explicit IV: Comply with the definition of CBC in NIST SP 800-38A (or the definition of = CTS in NIST SP 800-38A Addendum), it's the current standard cryptographic p= ractice, and save an unnecessary encryption/decryption operation per messag= e. Mike On 9/24/13 6:00 PM, "Paul Miller (NT)" wrote: >Through GSS_Wrap, the fact that we are encrypting at least the header=20 >per RFC 4121 ensures that the message is not less than one block. The=20 >use of the cipher suite in the context establishment could be a problem, h= owever. > >Without the confounder to avoid the short message problem, there could=20 >be ambiguity between what is CTS encoded to exact length and what is=20 >padded when the cipher text is exactly one block length. That is to=20 >say that the plain texts: > >01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd >01 23 45 67 89 ab cd ef 01 23 45 67 89 ab cd 01 > >Would end up encrypting the same and could not be distinguished as the=20 >former would need to PKCS #7 pad and the latter would just CBC the=20 >single block. > >I'm sorry I missed a lot of the context from prior discussions, but=20 >what is the reason for using a traditional IV instead of the=20 >confounder? I don't see a difference in security and using the=20 >confounder like cipher text allows CTS for short inputs. > >-----Original Message----- >From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On=20 >Behalf Of Sam Hartman >Sent: Tuesday, September 24, 2013 7:42 AM >To: Benjamin Kaduk >Cc: kitten@ietf.org; Michiko Short; Sam Hartman >Subject: Re: [kitten] draft-ietf-kitten-aes-cts-hmac-sha2-01 > >>>>>> "Benjamin" =3D=3D Benjamin Kaduk writes: > > Benjamin> On Mon, 23 Sep 2013, Sam Hartman wrote: > >> Hi. With my chair hat on, does anyone wish to re-open the > >> discussion of the CBC decision based on this late input? > > Benjamin> No comment on that particular question as of yet, but I > Benjamin> would ask for a clarification from Paul -- when he says > Benjamin> that "We use CTS today with AES so the complexity penalty > Benjamin> for using it is already paid. Using known-good code > Benjamin> reduces the chance of introducing new security holes.", > Benjamin> does this account for the difference between the existing > Benjamin> enctypes (17,18) and the propsed enctypes with respect to > Benjamin> the use of a confounder versus explicit initialization > Benjamin> vector, and the the corresponding need to special-case > Benjamin> short inputs in the new proposal? I could not tell what > Benjamin> Microsoft's position on the short-input behavior was from > Benjamin> Paul's initial message. > >well, I can't think of a way to get to a short-input case throguh SSPI. > >It seems like we're having the discussion, so that bar has been reached. >_______________________________________________ >Kitten mailing list >Kitten@ietf.org >https://www.ietf.org/mailman/listinfo/kitten >_______________________________________________ >Kitten mailing list >Kitten@ietf.org >https://www.ietf.org/mailman/listinfo/kitten From internet-drafts@ietf.org Tue Oct 1 19:08: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 2775521E810A; Tue, 1 Oct 2013 19:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.311 X-Spam-Level: X-Spam-Status: No, score=-102.311 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lyjfEnsJlzsY; Tue, 1 Oct 2013 19:08:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E9621E827F; Tue, 1 Oct 2013 19:06:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.72.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131002020652.20702.59327.idtracker@ietfa.amsl.com> Date: Tue, 01 Oct 2013 19:06:52 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-aes-cbc-hmac-sha2-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2013 02:08:40 -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 : AES Encryption with HMAC-SHA2 for Kerberos 5 Author(s) : Michael J. Jenkins Michael A. Peck Kelley W. Burgin Filename : draft-ietf-kitten-aes-cbc-hmac-sha2-00.txt Pages : 15 Date : 2013-10-01 Abstract: This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CBC mode with plaintext padding for confidentiality and HMAC with a SHA-2 hash for integrity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cbc-hmac-sha2 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-aes-cbc-hmac-sha2-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alexey.melnikov@isode.com Fri Oct 4 05:58: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 B7C5B21F9A50; Fri, 4 Oct 2013 05:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QAgKX+tN9rD; Fri, 4 Oct 2013 05:58:37 -0700 (PDT) Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 37D5821F9C6C; Fri, 4 Oct 2013 05:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1380890798; d=isode.com; s=selector; i=@isode.com; bh=sO6LzNF9k6sRDyL4jDgNwqKUCf61u6HAzj/wHolx9js=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=UYCzZpMB59G6fEcqk98DvuVHpZL+LEA93aUnhnNQx4U3SpVhWaRaQ9lygIoXYer0mX/WT/ BuQ4iAsvPOGprUQzaq61CqJ/LNvxxIrKskA+zdqwaQ0lqb4w4B6lgrZ33uLjsirUgcid9Z Zu8r32iFpBWDiueLglFSKlW1jkEK2gY=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 4 Oct 2013 13:46:35 +0100 Message-ID: <524EB8B4.2000509@isode.com> Date: Fri, 04 Oct 2013 13:46:44 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: Simon Josefsson References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> <20130924231746.73c578b7@latte.josefsson.org> In-Reply-To: <20130924231746.73c578b7@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 12:58:50 -0000 On 24/09/2013 22:17, Simon Josefsson wrote: > You wrote: >>>>>>> "Simon" == Simon Josefsson writes: >> Simon> like HTTP, FTP, SMTP, SSH, etc could be revised. I don't >> Simon> believe any of that will happen, so we'll have to live with >> Simon> case sensitive usernames, and my take is that I18N >> Simon> documents should permit that. >> >> I'm not sure any of the above hase case sensitive usernames. >> They permit usernames to be case sensitive. >> However a lot of implementations treat the username as case >> insensitive. >> >> I do think this is an appropriate issue for an IETF an document, but I >> do think considering the impact on legacy systems is important. >> I don't think we need to require there be no impact, simply understand >> an accept it. > Agreed, but the devil is in the detail. For example, I would say that > any I18N effort that changes how ASCII usernames ([A-Za-z0-9...]) > behave have gone too far down the road that causes damage to legacy > systems. Case folding for usernames in draft-ietf-precis-saslprepbis-04.txt is a SHOULD, so I think you are Ok. I.e. compatibility with a legacy system is a good enough reason to violate the SHOULD. > For passwords, there are also security aspects, since case > folding reduces entropy. draft-ietf-precis-saslprepbis-04.txt recommends against case folding for passwords. > Maybe in some of these details we can find > were we agree and disagree. From hartmans@mit.edu Fri Oct 4 06:54: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 DB76B21F9C7D for ; Fri, 4 Oct 2013 06:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.555 X-Spam-Level: X-Spam-Status: No, score=-100.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, 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 HfFUOFjQ+-66 for ; Fri, 4 Oct 2013 06:54:43 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 088A321F8F61 for ; Fri, 4 Oct 2013 06:48:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 96BB620474 for ; Fri, 4 Oct 2013 09:47:10 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBTn0E9jT7EH for ; Fri, 4 Oct 2013 09:47:10 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Fri, 4 Oct 2013 09:47:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C5B2882B10; Fri, 4 Oct 2013 09:48:21 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Fri, 04 Oct 2013 09:48:21 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [kitten] Input on Paul's concerns about aes-cbc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2013 13:54:57 -0000 Folks, I'd really appreciate input from those who responded to the AES CBC consensus call. 1) Do you need any additional information to evaluate Paul's message? 2) Has Paul's message caused you to revise your opinions in any way? Comments from those who did not respond to the consensus call are also welcome. From ghudson@mit.edu Fri Oct 4 07:24: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 D373021F9C21 for ; Fri, 4 Oct 2013 07:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 T2+AjTKsk7tI for ; Fri, 4 Oct 2013 07:23:48 -0700 (PDT) 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 60CB521F99FD for ; Fri, 4 Oct 2013 07:17:47 -0700 (PDT) X-AuditID: 1209190c-b7fd38e0000009aa-3a-524ece0aafaa Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 8E.47.02474.A0ECE425; Fri, 4 Oct 2013 10:17:46 -0400 (EDT) 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 r94EHji1012880; Fri, 4 Oct 2013 10:17:46 -0400 Received: from [18.101.8.199] (vpn-18-101-8-199.mit.edu [18.101.8.199]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r94EHbxp023851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 4 Oct 2013 10:17:44 -0400 Message-ID: <524ECE01.3060401@mit.edu> Date: Fri, 04 Oct 2013 10:17:37 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Sam Hartman , kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrMt1zi/IYOlHDYuvbQ/YLI5uXsXi wOSxZMlPJo+VU0+zBzBFcdmkpOZklqUW6dslcGXMeX2GueAQX8Xem2dZGhgfcncxcnJICJhI LNxzgQnCFpO4cG89WxcjF4eQwD5GidMLz7JAOBsYJVY8nsIE4Rxmkvg7ewELSAuvgJrE2Wdd bCA2i4CqxN+FW5hBbDYBZYmDZ7+B1YgKBEkc3zqBCaJeUOLkzCdgcREBC4kPGy+B1QsL2Ej8 vrKEFcQWApqz+vtpsBpOoPmHnu5k7GLk4GAWsJb4trsIJMwsIC+x/e0c5gmMArOQTJ2FUDUL SdUCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuoZ6uZkleqkppZsYwWEqybOD8c1BpUOMAhyM Sjy8Fmf8goRYE8uKK3MPMUpyMCmJ8maBhPiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwHp8ElONN SaysSi3Kh0lJc7AoifPe5LAPEhJITyxJzU5NLUgtgsnKcHAoSfB+BhkqWJSanlqRlplTgpBm 4uAEGc4DNNwNpIa3uCAxtzgzHSJ/ilFRSpz3AEhCACSRUZoH1wtLI68YxYFeEeblOAtUxQNM QXDdr4AGMwENjpLwBRlckoiQkmpgZLydOuXO4ahSwVtScy4XPzBpXN96aP7ql8u+v+zT6DGo qAlkCeTLz23mr5n03tq9e/rBgI/sB9df7OU9IBXybCtX4PzyWX/lwpvX1jxmZt9dZijZs/K6 jn3Wa4nXZWE7W44LnTK28FY8EOK5Jlp1wat/qyeHNN4z7pdatd5haZKIwucVrkcrlViKMxIN tZiLihMBsekRgv4CAAA= Subject: Re: [kitten] Input on Paul's concerns about aes-cbc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2013 14:24:13 -0000 On 10/04/2013 09:48 AM, Sam Hartman wrote: > 1) Do you need any additional information to evaluate Paul's message? I don't think so. We are still curious about the details of legacy application risk (i.e. what kinds of things might a legacy SSPI application do wrong such that it works now but fails with a padded enctype), but the conclusion is pretty clear. > 2) Has Paul's message caused you to revise your opinions in any way? Yes; I think a CBC-padded enctype is more problematic for Microsoft than we had concluded based on previous input. However, I am still uncomfortable with the amount of novel cipher mode design in http://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-01 to handle short inputs. I am interested in the outcome of the discussion about using a confounder instead of an explicit IV. Although confounders are less efficient than explicit IVs and less consistent with current cryptographic practice, using them does have several advantages (simplifying the CTS short-input problem down to the case of zero-length inputs; reducing the impact of PRNG compromise under specific threat mdels; allowing more implementation sharing with RFC 3962). I have also spent some more time thinking about CTR mode as you suggested earlier (where we pick a random 128-bit nonce and use some function f(nonce, blocknum) to produce the counter for each block), and whether a nonce or block counter collision is any worse than a CBC cipher-block collision. I noted that a CTR nonce collision would leak the XOR of the entire plaintexts of two multi-block messages, while a CBC cipher-block collision or only leaks the XOR of the plaintexts of the two colliding blocks, and a CBC IV/confounder collision only leaks information about how many blocks of two messages are identical. From nico@cryptonector.com Fri Oct 4 14:10: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 02B9121F9E88 for ; Fri, 4 Oct 2013 14:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_15=0.6] 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 O4PuMAJ-QveP for ; Fri, 4 Oct 2013 14:09:59 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id 81B0921F9E6C for ; Fri, 4 Oct 2013 14:09:49 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id D78C6778071 for ; Fri, 4 Oct 2013 14:09:48 -0700 (PDT) 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=E6UNmsA/tGpuL5IcSoSI lktEHeA=; b=MKXkSwlRanBI8Bo+mWSNe9AXC3L7vFwRUoF4wFI7Ownfhn0b6EeL zh6sXilVKfeRflmiPtqpwyBjRQ5DWyAGMlOB+BRYgPAOSstb7pjXtYM+83iKRzgP 1NOtCJw4AyeSysr8o0k9O/uWt3jmG36zoNjxXxGQG7t0P/8jHLkNS3o= 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-a36.g.dreamhost.com (Postfix) with ESMTPSA id 870B6778070 for ; Fri, 4 Oct 2013 14:09:48 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id t60so5351579wes.0 for ; Fri, 04 Oct 2013 14:09:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZjdopGzdoMlnCgl+FyxJf8UAcNUJdHjaCoFqc+1NRck=; b=GVupzf+6F+tPiIPi0t0OJaFGF6hrR4VWfiSdzU3pmbOYKQ5D8rUaUvGfBWThAth628 6DfStzz/Euj3xegV1uCQbM9Dkhu3yg/0XGndCP+/AZ85SAJyKCAidcU7BmZhD8DokrC7 R2k2b7ZlOy5/y/5SSjLaIAu4rxe2uJSZv3CCTLX38/7hgnGQ+pkTOS27XJeKJQ34anlc lcr3A4ZgyfQ2olpfqkwud1eKeNynmLnrnb43CLPYgocnydfOiYEqB7X2KWH+acS/ikbJ JTP7vYkRuqGfGAA1hE3rP8CS5BSoMpHX6KMl0DOwl5SOH/CO2eI9nhGP6JzIxiTgh3jr vXPQ== MIME-Version: 1.0 X-Received: by 10.194.250.6 with SMTP id yy6mr14221169wjc.13.1380920986842; Fri, 04 Oct 2013 14:09:46 -0700 (PDT) Received: by 10.216.165.5 with HTTP; Fri, 4 Oct 2013 14:09:46 -0700 (PDT) In-Reply-To: <524ECE01.3060401@mit.edu> References: <524ECE01.3060401@mit.edu> Date: Fri, 4 Oct 2013 16:09:46 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Input on Paul's concerns about aes-cbc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 04 Oct 2013 21:10:04 -0000 On Fri, Oct 4, 2013 at 9:17 AM, Greg Hudson wrote: > On 10/04/2013 09:48 AM, Sam Hartman wrote: >> >> 1) Do you need any additional information to evaluate Paul's message? > > I don't think so. We are still curious about the details of legacy > application risk (i.e. what kinds of things might a legacy SSPI application > do wrong such that it works now but fails with a padded enctype), but the > conclusion is pretty clear. I can't tell if Paul is acting out of [quite reasonable] conservatism, or if he's really identified actual failure modes of existing applications (or likely ones), nor has he indicated whether there's any way to work around such failures (by, e.g., downgrading to CTS enctypes), nor whether any such workarounds are acceptable. I'm not going to insist on -say- proprietary evidence. Indeed, I like the random IV CTS mode we cooked up. I just think we need to understand the *actual* constraints, in so far as they can be published, so that we can a) not have this conversation again later, b) understand how those constraints might apply to future proposals, c) document how developers should write code so as not to impose these constraints on us. > I have also spent some more time thinking about CTR mode as you suggested > earlier (where we pick a random 128-bit nonce and use some function f(nonce, > blocknum) to produce the counter for each block), and whether a nonce or > block counter collision is any worse than a CBC cipher-block collision. I > noted that a CTR nonce collision would leak the XOR of the entire plaintexts > of two multi-block messages, while a CBC cipher-block collision or only > leaks the XOR of the plaintexts of the two colliding blocks, and a CBC > IV/confounder collision only leaks information about how many blocks of two > messages are identical. I'm now convinced that what we need in order to make certain cipher modes usable in Kerberos is a change to RFC3961 so that the API knows whether a given key is a sub-session key or not. I don't feel comfortable with CTR modes applied to long-term keys (or even Ticket session keys) without taking steps that would effectively kill performance for the GSS mechanism's per-msg tokens. I don't think we should have *this* discussion in the context of CTS vs. CBC: we should first decide that we don't want either CTS nor CBC. Nico -- From nico@cryptonector.com Fri Oct 4 14:16:31 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 877D021F9EA8; Fri, 4 Oct 2013 14:16:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=0.043, 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 uYsCYWhdBT6Y; Fri, 4 Oct 2013 14:16:26 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF7A21F9C52; Fri, 4 Oct 2013 14:16:23 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 316B76B007F; Fri, 4 Oct 2013 14:16:23 -0700 (PDT) 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=FGTHPMI1Swkub5gi/4ER ACmEZEA=; b=twvv7x67pFfy70TYrm2fO9EQ/D+39ZDW+GQq4x+OYFIgq3dgAaif SIUm2B4j90gwf0AwsB9pcm+jzMK1pjSL2EihbQf6ZLTHCNQtx1Mf5babE2FUOzB9 PnKMoJSss7NH4485X91Lf+DRSnrMLy8JF4D8pY5LY4ajDX8zTmVqxKw= 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-a72.g.dreamhost.com (Postfix) with ESMTPSA id A2F6E6B007E; Fri, 4 Oct 2013 14:16:22 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id m15so4658652wgh.21 for ; Fri, 04 Oct 2013 14:16:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=f1C+vcUSEUlGkJL5+bsDpCcEBuEYJjoGlHoOuxTdQcY=; b=ATyXGPr+FDCqto6/rYX+UfhJqzjWqZmpYBCMXj8gVkpIWaBNaJAB9xTowLARXg1OxW 5lx356oNvLxdSnIot8q0EmgOqb1+Bw412zM7x5oi+/yS83aRMsey5cu0HwtXgPlQd10Z c/NPjD2WGKx/6pFRvud2cUtKWYTwkPFoIuUXmZ+aAK/lBzRSdAZE2kRBKGFdVKMfRZ0X bhl4yID2YKbByepsG9sUi6O0LnLD3MddXnK+HSA2ogIb/luhr4uxZwm6xW7q+QhFN6Vw YFJyGnBj4eBlJGy9KYjhGEkeoBlFJF+LLL2ycP+fFA2dfL395wwX2HjU6DEXVG9C5fsY o5+g== MIME-Version: 1.0 X-Received: by 10.194.242.200 with SMTP id ws8mr15744wjc.60.1380921381178; Fri, 04 Oct 2013 14:16:21 -0700 (PDT) Received: by 10.216.165.5 with HTTP; Fri, 4 Oct 2013 14:16:21 -0700 (PDT) In-Reply-To: <87txharmne.fsf@latte.josefsson.org> References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> Date: Fri, 4 Oct 2013 16:16:21 -0500 Message-ID: From: Nico Williams To: Simon Josefsson Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" Subject: Re: [kitten] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2013 21:16:31 -0000 On Tue, Sep 24, 2013 at 3:27 PM, Simon Josefsson wrote: > I disagree that an I18N document is the appropriate way to move the > Internet to case-insensitive usernames. > > If case-sensitive usernames is a significant problem, then it should be > possible to publish a BCP recommending against that. Then existing > protocols with case-sensitive usernames like HTTP, FTP, SMTP, SSH, etc > could be revised. I don't believe any of that will happen, so we'll > have to live with case sensitive usernames, and my take is that I18N > documents should permit that. I agree. Also, there's a lot of work to do to get there, particularly enrollment (account creation) time work. We can't merely specify a case-insensitive stringprep profile. Nico -- From lukeh@padl.com Sun Oct 6 02:56: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 814C521F9E94 for ; Sun, 6 Oct 2013 02:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW7AFhMRR49U for ; Sun, 6 Oct 2013 02:56:34 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 44DA521F9E26 for ; Sun, 6 Oct 2013 02:56:34 -0700 (PDT) Received: by us.padl.com with ESMTP id r969uKGh032528; Sun, 6 Oct 2013 05:56:23 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Luke Howard In-Reply-To: <99e467bc-610f-4f61-bc3c-5f3094e4430f@email.android.com> Date: Sun, 6 Oct 2013 20:56:20 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <2B39A13E-D6E3-4D40-903E-1E867EFCF358@padl.com> References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> <99e467bc-610f-4f61-bc3c-5f3094e4430f@email.android.com> To: Sam Hartman X-Mailer: Apple Mail (2.1510) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Nico Williams , Sam Hartman Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 06 Oct 2013 09:56:38 -0000 To follow up on an old post. I've updated the draft to use RFC 4985 = SRVNames instead of URIs in the SAN. Service principal names encoded in context tokens are now prefixed with = urn:ietf:params:gss:spn instead of urn:x-gss. Link here: http://www.ietf.org/id/draft-howard-gss-browserid-05.txt -- Luke= From lukeh@padl.com Sun Oct 6 18:27: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 BE02621E811A for ; Sun, 6 Oct 2013 18:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoTaXlYwcO8E for ; Sun, 6 Oct 2013 18:27:04 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 90DA821E8108 for ; Sun, 6 Oct 2013 18:27:04 -0700 (PDT) Received: by us.padl.com with ESMTP id r971QqEn007669; Sun, 6 Oct 2013 21:26:55 -0400 From: Luke Howard Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 7 Oct 2013 12:26:52 +1100 To: "dev-identity@lists.mozilla.org" , "kitten@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Subject: [kitten] SPN audience claim for GSS BrowserID X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 07 Oct 2013 01:27:08 -0000 Apologies for the cross-post. A brief reminder: GSS BrowserID [1] profiles Mozilla Persona for = application protocols that use SASL or GSS-API, such as IMAP and SMTP. The audience in the generated assertion is the =93service principal = name=94, or SPN, which identifies the target service. This is of the = form service[/hostname[/instance]], for example =93imap/mail.example.com=94= . Currently we are encoding these as URIs with the prefix = urn:ietf:params:gss:spn: (so, in previous example, the =93aud=94 claim = would have the value =93urn:ietf:params:gss:spn:imap/mail.example.com=94).= Rereading draft-ietf-oauth-json-web-token, I note that the audience = claim is a StringOrURI, and there's nothing in the BrowserID code that = requires the audience to be a URI, at least for internal API consumers. Any thoughts thus on dropping the URN prefix and placing the unadorned = SPN in the audience claim? -- Luke [1] http://tools.ietf.org/html/draft-howard-gss-browserid-05= From lukeh@padl.com Sun Oct 6 22: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 E00B221F9FC3 for ; Sun, 6 Oct 2013 22:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM3Ap3Wjvti6 for ; Sun, 6 Oct 2013 22:30:17 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id EC2E421E814B for ; Sun, 6 Oct 2013 22:30:13 -0700 (PDT) Received: by us.padl.com with ESMTP id r975U2PS017767; Mon, 7 Oct 2013 01:30:04 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Luke Howard In-Reply-To: <2B39A13E-D6E3-4D40-903E-1E867EFCF358@padl.com> Date: Mon, 7 Oct 2013 16:30:01 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130415154204.679F31A6AF@ld9781.wdf.sap.corp> <1BF2FA2B-C54F-4C78-AD7E-52A409F234B0@padl.com> <32A1B85C-CB2B-4E9E-BC71-597E70199D01@padl.com> <17ADC929-0EAD-482D-AA4B-9F6B3E639871@padl.com> <29793AD7-8E18-4087-906C-4047CEFD1C66@padl.com> <99e467bc-610f-4f61-bc3c-5f3094e4430f@email.android.com> <2B39A13E-D6E3-4D40-903E-1E867EFCF358@padl.com> To: Sam Hartman X-Mailer: Apple Mail (2.1510) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Nico Williams , Sam Hartman Subject: Re: [kitten] BrowserID mutual auth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 07 Oct 2013 05:30:22 -0000 I published -06 which incorporates the change mentioned in my last mail = (as JWT specifies the audience claim as a StringOrURI, we will encode = the raw service principal name without a URN prefix). A few other nits = fixed (and introduced). The reference implementation (gss_browserid) has been updated to -06. On 06/10/2013, at 8:56 PM, Luke Howard wrote: > To follow up on an old post. I've updated the draft to use RFC 4985 = SRVNames instead of URIs in the SAN. >=20 > Service principal names encoded in context tokens are now prefixed = with urn:ietf:params:gss:spn > instead of urn:x-gss. >=20 > Link here: >=20 > http://www.ietf.org/id/draft-howard-gss-browserid-05.txt >=20 > -- Luke > _______________________________________________ > 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 paumil@microsoft.com Mon Oct 7 17:22: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 C4EDB21E80EA for ; Mon, 7 Oct 2013 17:22:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 uZIl-zANHcrT for ; Mon, 7 Oct 2013 17:22:13 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9A511E8136 for ; Mon, 7 Oct 2013 17:22:10 -0700 (PDT) Received: from BLUPR03MB279.namprd03.prod.outlook.com (10.255.213.17) by BLUPR03MB278.namprd03.prod.outlook.com (10.255.213.16) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 8 Oct 2013 00:22:08 +0000 Received: from BLUPR03MB279.namprd03.prod.outlook.com ([169.254.1.181]) by BLUPR03MB279.namprd03.prod.outlook.com ([169.254.1.181]) with mapi id 15.00.0785.001; Tue, 8 Oct 2013 00:22:08 +0000 From: "Paul Miller (NT)" To: Nico Williams , Greg Hudson Thread-Topic: [kitten] Input on Paul's concerns about aes-cbc Thread-Index: AQHOwQlTXptqPoViJUGgtI+QQU8PoJnkluGAgABzJwCABN8IkA== Date: Tue, 8 Oct 2013 00:22:08 +0000 Message-ID: <064ca7780d4943b1868670461c2c7184@BLUPR03MB279.namprd03.prod.outlook.com> References: <524ECE01.3060401@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:ed31::2] x-forefront-prvs: 0993689CD1 x-forefront-antispam-report: SFV:NSPM; SFS:(377454003)(479174003)(189002)(199002)(51704005)(24454002)(13464003)(65816001)(74706001)(80022001)(47976001)(50986001)(54316002)(4396001)(49866001)(47736001)(83072001)(74366001)(69226001)(79102001)(561944002)(77982001)(63696002)(59766001)(74876001)(56776001)(31966008)(74502001)(74662001)(56816003)(47446002)(77096001)(81542001)(81342001)(76482001)(76786001)(76576001)(33646001)(76796001)(85306002)(46102001)(51856001)(19580395003)(53806001)(54356001)(83322001)(19580405001)(15975445006)(74316001)(80976001)(81686001)(81816001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB278; H:BLUPR03MB279.namprd03.prod.outlook.com; CLIP:2001:4898:80e8:ed31::2; FPR:; RD:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Input on Paul's concerns about aes-cbc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 08 Oct 2013 00:22:20 -0000 I don't have any information about specific application failures with padde= d ciphers. If there were problems with a block cipher, it would not be pos= sible to do a fallback just for impacted callers as the cipher of the subse= ssion key is chosen during the context establishment which is before the fi= rst call to EncryptMessage (GSS_Wrap analogue). By the time we knew that t= he caller was not providing for padding, it would be too late to select dif= ferently. With the existing calling pattern used for DES in Windows, callers that did= not pass in the SECBUFFER_PADDING into the EncryptMessage call would just = fail when the buffer was not aligned. Additionally, if the buffer was a mu= ltiple of the block size then it would not get the PKCS#7 padding and then = would fail on the other end that expected the pad block. I suspect this wo= uld break a whole lot of callers. To reduce the application compatibility problem, I'd have to use the Rotate= Right Count in the header to move padding into the header. Up front, Kerb= eros on Windows would tell callers that they needed to allocate for the hea= der one block more than they actually need. Then, on output we would short= en the length to whatever portion was actually used. This would fix the ca= llers that do not handle padding for the first encryption, but making the h= eader variable length causes a different set of problems. Today, the heade= r is always the same length so the caller can allocate that buffer and then= reuse it throughout multiple encryption calls. Making it variable length = would require the caller to take the additional step of resetting the lengt= h field to the allocated size between calls, which not all applications may= be doing today. There are several reasons that I think this is a significant risk. First o= f all, the documentation that Microsoft has for the EncryptMessage function= for Kerberos has very little bearing on how the function should actually b= e used. In fact, most of the document is incorrectly copied and pasted fro= m SSL's documentation. It'd be highly optimistic to expect developers to h= ave used the API correctly while the documentation was incorrect. This mak= es the risk that some application is broken quite high. The second factor is that we only have the ability to control supported enc= ryption types at the machine level. This means that if there is one applic= ation in an enterprise, all impacted machines will have the new cipher supp= orted. This means that if a LOB app is impacted, the enterprise is likely= to disable the new cipher on all machines via policy. If the problem is likely to occur and the impact of the problem is the disa= blement of the new ciphers for the entire realm, the objective of introduci= ng the new cipher is compromised. It is much safer to move forward with a = cipher that is more likely broadly to be used. -----Original Message----- From: kitten-bounces@ietf.org [mailto:kitten-bounces@ietf.org] On Behalf Of= Nico Williams Sent: Friday, October 4, 2013 2:10 PM To: Greg Hudson Cc: kitten@ietf.org; Sam Hartman Subject: Re: [kitten] Input on Paul's concerns about aes-cbc On Fri, Oct 4, 2013 at 9:17 AM, Greg Hudson wrote: > On 10/04/2013 09:48 AM, Sam Hartman wrote: >> >> 1) Do you need any additional information to evaluate Paul's message? > > I don't think so. We are still curious about the details of legacy=20 > application risk (i.e. what kinds of things might a legacy SSPI=20 > application do wrong such that it works now but fails with a padded=20 > enctype), but the conclusion is pretty clear. I can't tell if Paul is acting out of [quite reasonable] conservatism, or i= f he's really identified actual failure modes of existing applications (or = likely ones), nor has he indicated whether there's any way to work around s= uch failures (by, e.g., downgrading to CTS enctypes), nor whether any such = workarounds are acceptable. I'm not going to insist on -say- proprietary evidence. Indeed, I like the = random IV CTS mode we cooked up. I just think we need to understand the *a= ctual* constraints, in so far as they can be published, so that we can a) n= ot have this conversation again later, b) understand how those constraints might apply to future proposals, c) document how developers should write code so as not to impose these cons= traints on us. > I have also spent some more time thinking about CTR mode as you=20 > suggested earlier (where we pick a random 128-bit nonce and use some=20 > function f(nonce, > blocknum) to produce the counter for each block), and whether a nonce=20 > or block counter collision is any worse than a CBC cipher-block=20 > collision. I noted that a CTR nonce collision would leak the XOR of=20 > the entire plaintexts of two multi-block messages, while a CBC=20 > cipher-block collision or only leaks the XOR of the plaintexts of the=20 > two colliding blocks, and a CBC IV/confounder collision only leaks=20 > information about how many blocks of two messages are identical. I'm now convinced that what we need in order to make certain cipher modes u= sable in Kerberos is a change to RFC3961 so that the API knows whether a gi= ven key is a sub-session key or not. I don't feel comfortable with CTR mod= es applied to long-term keys (or even Ticket session keys) without taking s= teps that would effectively kill performance for the GSS mechanism's per-ms= g tokens. I don't think we should have *this* discussion in the context of= CTS vs. CBC: we should first decide that we don't want either CTS nor CBC. Nico -- _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From nico@cryptonector.com Mon Oct 7 21:00: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 1CF5621E8128 for ; Mon, 7 Oct 2013 21:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=0.025, 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 WR6zh4aXdLjD for ; Mon, 7 Oct 2013 21:00:51 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcbhh.dreamhost.com [208.97.132.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5C921E81F9 for ; Mon, 7 Oct 2013 21:00:45 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id BA54E59805F for ; Mon, 7 Oct 2013 21:00:44 -0700 (PDT) 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=GcVb2pSVvaHKrP00wZh9 65y7VAk=; b=AQyvJ72NOA6PR7byhgVZqEmGccz5s8DHN12SSbioyOiHm/S6FmoA EvClQKD+bGFP0ASfPZh7ZGlGSfX+cvazP1iJnhHGMeFF5dPAJ2wfbd4iFNuGTaYR cwWaAC1J1QTIhSHvB61UA8g1rIvnt4AqFj2t8tB3FfpZ60F9z8DWd5c= Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (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 6577E598058 for ; Mon, 7 Oct 2013 21:00:44 -0700 (PDT) Received: by mail-wg0-f45.google.com with SMTP id y10so8295147wgg.12 for ; Mon, 07 Oct 2013 21:00:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GbDP6YXvjfYgYjNwsw9Vono5aCFV9NGiAeeVNCLv3i4=; b=liJKfpTQNz1At/9KODS30hlYIPT+LXqbiXWoWA/G45NbEVrZW7yV4ThPWlSpQSOOKl ur4UwvyuFZBsEdSHrx+Wve29qPS+4c6gtHUG1nsAGYjOgh1Pg4mdJSPn1cnjKX+RIPl6 KJzltroWj56IVWNahzOKAVGCKZPmqA6fl2p1yAV02elek1oK36p2HnKyVwkxFxhXuvNM MmsHZA0Ie4kdThWUygVSeesaKjybMXb02CiQ9IqHWZMU+Le6prOPB6okIesc8RjXXL6Q MQdzF9M1nyDAN/g4e8x/FZNPnRE5EBZ7CStim6CNEqF2x+2047du+SQF6FHtUrUlaosV mUVA== MIME-Version: 1.0 X-Received: by 10.194.193.4 with SMTP id hk4mr27431866wjc.29.1381204533322; Mon, 07 Oct 2013 20:55:33 -0700 (PDT) Received: by 10.216.165.5 with HTTP; Mon, 7 Oct 2013 20:55:33 -0700 (PDT) In-Reply-To: <064ca7780d4943b1868670461c2c7184@BLUPR03MB279.namprd03.prod.outlook.com> References: <524ECE01.3060401@mit.edu> <064ca7780d4943b1868670461c2c7184@BLUPR03MB279.namprd03.prod.outlook.com> Date: Mon, 7 Oct 2013 22:55:33 -0500 Message-ID: From: Nico Williams To: "Paul Miller (NT)" Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Input on Paul's concerns about aes-cbc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 08 Oct 2013 04:00:56 -0000 On Mon, Oct 7, 2013 at 7:22 PM, Paul Miller (NT) wrote: > [...] Thanks, that was exactly what I was looking for. That's convincing. We need the new enctype to require no padding. I'm not a fan of coutner modes for Kerberos, but if someone has a specific proposal I would review it; the same goes for just about any cipher modes other than CTS. Assuming nobody proposes such a thing that leaves us with confounded CTS or random IV CTS (including short-plaintext cases because of non-GSS RFC3961 applications). Nico -- From lukeh@padl.com Mon Oct 7 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 A436C21E8149 for ; Mon, 7 Oct 2013 21:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqmE5Rjookqc for ; Mon, 7 Oct 2013 21:18:43 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 8405B21F9D0D for ; Mon, 7 Oct 2013 21:18:43 -0700 (PDT) Received: by us.padl.com with ESMTP id r984ITur023726; Tue, 8 Oct 2013 00:18:32 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Luke Howard In-Reply-To: <064ca7780d4943b1868670461c2c7184@BLUPR03MB279.namprd03.prod.outlook.com> Date: Tue, 8 Oct 2013 15:18:28 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <5FB494E4-FD47-48EF-B3E6-3831D5CAC27C@padl.com> References: <524ECE01.3060401@mit.edu> <064ca7780d4943b1868670461c2c7184@BLUPR03MB279.namprd03.prod.outlook.com> To: Paul Miller (NT) X-Mailer: Apple Mail (2.1510) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Input on Paul's concerns about aes-cbc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 08 Oct 2013 04:18:48 -0000 > To reduce the application compatibility problem, I'd have to use the = Rotate Right Count in the header to move padding into the header. Up = front, Kerberos on Windows would tell callers that they needed to = allocate for MIT scatter/gather APIs do this. There are not the same compatibility = issues as there are (to my knowledge) few consumers. The only consumer = I'm aware of, DCE RPC, can deal with extra bytes in the header, because = its PDUs contain explicit lengths. It's unfortunate about the documentation... -- Luke= From hartmans@mit.edu Tue Oct 8 12:09: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 4364A21F8168 for ; Tue, 8 Oct 2013 12:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLKLz9dCcB9J for ; Tue, 8 Oct 2013 12:09:09 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 781C021F95D0 for ; Tue, 8 Oct 2013 12:08:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id DC91A204C5; Tue, 8 Oct 2013 15:07:29 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqoHVMSVpvBA; Tue, 8 Oct 2013 15:07:28 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [18.189.9.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 8 Oct 2013 15:07:28 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5F12F831F9; Tue, 8 Oct 2013 15:08:50 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org Date: Tue, 08 Oct 2013 15:08:50 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: kitten-ads@tools.ietf.org, lha@h5l.org Subject: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 08 Oct 2013 19:09:14 -0000 --=-=-= Folks, when working on the MIT implementation of RFC 6112 I got the capitalization of one of the cryptographic inputs wrong. Love found this while interop testing against MIT. As we (myself, MIT and Love) understand, MIT is the only shipping implementation. We propose to change the spec rather than the implementations. This would presumably involve: 1) accepting this erata 2) Fairly quickly reissuing RFC 6112 and moving the existing spec to historic. Thoughts/comments? --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 8bit Return-Path: Received: from mail.painless-security.com ([unix socket]) by mail.suchdamage.org (Cyrus v2.4.16-Debian-2.4.16-4) with LMTPA; Tue, 08 Oct 2013 14:13:11 -0400 X-Sieve: CMU Sieve 2.4 Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 1533B20412 for ; Tue, 8 Oct 2013 14:13:11 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzCdh6pVX716 for ; Tue, 8 Oct 2013 14:13:09 -0400 (EDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by mail.painless-security.com (Postfix) with ESMTP for ; Tue, 8 Oct 2013 14:13:09 -0400 (EDT) Received: from mailhub-dmz-1.mit.edu ( [18.9.21.41]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id CC.DD.02474.58B44525; Tue, 8 Oct 2013 14:14:30 -0400 (EDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) by mailhub-dmz-1.mit.edu (8.13.8/8.9.2) with ESMTP id r98ICR3Q005383 for ; Tue, 8 Oct 2013 14:14:29 -0400 X-AuditID: 12074424-b7f528e0000009aa-c9-52544b851a8c Authentication-Results: symauth.service.identifier Received: from rfc-editor.org (rfc-editor.org [12.22.58.47]) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 72.4E.02503.48B44525; Tue, 8 Oct 2013 14:14:28 -0400 (EDT) Received: by rfc-editor.org (Postfix, from userid 30) id A427CB1E011; Tue, 8 Oct 2013 11:06:46 -0700 (PDT) To: larry.zhu@microsoft.com, paulle@microsoft.com, hartmans-ietf@mit.edu, stephen.farrell@cs.tcd.ie, turners@ieca.com, shawn.emery@oracle.com, josh.howlett@ja.net, hartmans-ietf@mit.edu Subject: [Technical Errata Reported] RFC6112 (3743) From: RFC Errata System Cc: lha@apple.com, ietf-krb-wg@lists.anl.gov, rfc-editor@rfc-editor.org Message-Id: <20131008180646.A427CB1E011@rfc-editor.org> Date: Tue, 8 Oct 2013 11:06:46 -0700 (PDT) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKIsWRmVeSWpSXmKPExsUixCmqqdvmHRJkcOiXpsXXtgdsDoweK6ee Zg9gjOKySUnNySxLLdK3S+DK2LnyM3PBAZ6K9Y9WsDcwvuHsYuTkkBAwkZjTMZkNwhaTuHBv PZDNxSEksJdR4vyOO6wQzj1GiSsbjjJ1MXKAdax7ag/SwChgJLH73CtWEFtI4CijxJ79xhB2 rkTHs8csIL0iAqcZJZZM28gIkhAWMJZ4sPw8M4jNBmRfW/IObDOzgLtE69I2JhCbV8Bc4u6q Y2A2i4C2xNVrDWBHSAh8Z5OY8Gci6wRG/gWMDKsYZVNyq3RzEzNzilOTdYuTE/PyUot0zfVy M0v0UlNKNzGCwobdRWUHY/MhpUOMAhyMSjy8nbwhQUKsiWXFlbmHGCU5mJREeR+7AYX4kvJT KjMSizPii0pzUosPMUpwMCuJ8JrIAuV4UxIrq1KL8mFSMhwcShK8m7yAUoJFqempFWmZOcDo gEkzcXCCtPMAtWt4grQXFyTmFmemQ+RPMSpKifN2gCQEQBIZpXlwvbDYfMUoDnSsMO9FkBU8 wLiG634FNJgJaLAueyDI4JJEhJRUA2NYdXrk0y1sGitKCrN63jkf+/imv6lo3VLpzuebzktu CInyedGcucPQ5YNkW3ft2fcW9sIsAhdfmWz+J8PpeYLpGdfNeL6+zV6q+a/SFt2Yc25lpcEW 5V17lvH+2Bz5eevm76JC2ievrwvvn36k6MDX9wv238jhPtS45GnC+itWiZNmvvGWLt2ixFKc kWioxVxUnAgATFmlTKgCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRWlGSWpSXmKPExsXCI2alr9viHRJk0HLd1GLO19VsDoweTWeO MgcwRnHZpKTmZJalFunbJXBl7Fz5mbngAE/F+kcr2BsY33B2MXJwSAiYSKx7at/FyMnBKGAk sfvcK1YQW0JATOLCvfVsILaQwFFGiT37jSHsXImOZ49Zuhi5OEQEdjJK7J17hQkkISxgLPFg +XlmEJsNyL625B1YM7OAu0Tr0jawGl4Bc4m7q46B2SwC2hJXrzWwTmDkXsDIsIpRNiW3Sjc3 MTOnODVZtzg5MS8vtUjXQi83s0QvNaV0EyPQo0LsLqo7GCccUjrEKMDBqMTD28EbEiTEmlhW XJl7iFGSg0lJlPexG1CILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK+JLFCONyWxsiq1KB8mJc3B oiTOe4vDPkhIID2xJDU7NbUgtQgmy8TBfohRhoNDSYLXyguoW7AoNT21Ii0zpwRZDSeI4AJZ wwO0JgykkLe4IDG3ODMdougUo6KUOK8rSEIAJJFRmgc3ABaFlxhlpYR5GRkYGIR4gC4AehxV /hWjONDTwrwRIFN4MvNK4Ka/AlrMBLRYlz0QZHFJIkJKqoHRLf2QbBDnr5m31i419pt5xH9/ SpdX5akrjjN36SnMD1NYms3emat4Zm/Omn9n6o8qnZa9URLpsi2I7+qr95H3Lz3cNavpidp1 59k3O9omrF9sb1+7KeGcsueD298sf10su61ht+CD1JSaJ+93fA15XFvXqlCVKPWpRKfu6L2V t78W/N7V15T9R4mlOCPRUIu5qDgRACekCLy9AgAA MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit The following errata report has been submitted for RFC6112, "Anonymity Support for Kerberos". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6112&eid=3743 -------------------------------------- Type: Technical Reported by: Love Hörnquist Åstrand Section: 7 Original Text ------------- "is ASCII string "KeyExchange" Corrected Text -------------- "is ASCII string "KEYEXCHANGE" Notes ----- MIT Kerberos is the only public implementation of this draft and when I created the second implementation I noticed that the MIT folks had used the wrong constant in their code. After talking to them it makes more sense to change the specification then break backward compatibility with old clients since there no other implementations that we know about. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6112 (draft-ietf-krb-wg-anon-12) -------------------------------------- Title : Anonymity Support for Kerberos Publication Date : April 2011 Author(s) : L. Zhu, P. Leach, S. Hartman Category : PROPOSED STANDARD Source : Kerberos WG Area : Security Stream : IETF Verifying Party : IESG --=-=-=-- From ghudson@mit.edu Tue Oct 8 12:14: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 F236A21F85E0 for ; Tue, 8 Oct 2013 12:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bPb2xVM0Ur9X for ; Tue, 8 Oct 2013 12:14:23 -0700 (PDT) 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 8C78821F8FB6 for ; Tue, 8 Oct 2013 12:14:18 -0700 (PDT) X-AuditID: 12074422-b7f5a8e000000a34-32-52545989cde6 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 01.D3.02612.98954525; Tue, 8 Oct 2013 15:14:17 -0400 (EDT) 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 r98JEFZP003873; Tue, 8 Oct 2013 15:14:16 -0400 Received: from [18.18.15.68] (west-ninetytwo-five-ninety-five.mit.edu [18.18.15.68]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r98JEDcs003417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Oct 2013 15:14:14 -0400 Message-ID: <52545985.70308@mit.edu> Date: Tue, 08 Oct 2013 15:14:13 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Sam Hartman , kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUixCmqrNsZGRJksKrH1OJr2wM2i5NfzrJZ HN28isVi2tZ97A4sHsc+X2H0WLLkJ5PHyqmn2T2+XP7MFsASxWWTkpqTWZZapG+XwJXxcP98 xoKdjBU/D+Q0MPYzdjFyckgImEhsXdrKDmGLSVy4t56ti5GLQ0hgH6PEzD+foJwNjBIf5jSw QzgXmCQWvLvNDNLCK6AicWTPZzYQm0VAVWL69n6wUWwCyhIHz35jAbFFBYIkjm+dwARRLyhx cuYTsLiIgIXEh42XwOYwC2hJPO9+CHaSsECYREvnNrAaIaCZp5v7gWo4ODgF1CS6VyiAmMwC 1hLfdhdBdMpLbH87h3kCo+AsJAtmIVTNQlK1gJF5FaNsSm6Vbm5iZk5xarJucXJiXl5qka6p Xm5miV5qSukmRlCIs7so7WD8eVDpEKMAB6MSD+8D/pAgIdbEsuLK3EOMkhxMSqK8ZqFAIb6k /JTKjMTijPii0pzU4kOMEhzMSiK8JrJAOd6UxMqq1KJ8mJQ0B4uSOO8tDvsgIYH0xJLU7NTU gtQimKwMB4eSBO+acKBGwaLU9NSKtMycEoQ0EwcnyHAeoOFPIkCGFxck5hZnpkPkTzHqcry4 ufIroxBLXn5eqpQ47x2QQQIgRRmleXBzYKnpFaM40FvCvK9ARvEA0xrcpFdAS5iAluiyB4Is KUlESEkBE83tIx25F8WW8DBe0ttbn6/8t8bNwLH5z0fOxksWUjqdv2ZdZyg+ci9rSrOt847f CRaz2jubfi+sbVwx2V2r/O4/BZe5GoaeZjIMs+T+JUcJpaiUXzU9m2M31cajZ+05M8bu11bS N572TpdWlp1SsO6icNDdyyVrNGe9t/f4d+vEqlUFYtU3lFiKMxINtZiLihMBa4gviigDAAA= Cc: kitten-ads@tools.ietf.org, lha@h5l.org Subject: Re: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 08 Oct 2013 19:14:30 -0000 On 10/08/2013 03:08 PM, Sam Hartman wrote: > 1) accepting this erata > > 2) Fairly quickly reissuing RFC 6112 and moving the existing spec to > historic. I support this plan. From stephen.farrell@cs.tcd.ie Tue Oct 8 13:29: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 E27EB21F9E52 for ; Tue, 8 Oct 2013 13:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.901 X-Spam-Level: X-Spam-Status: No, score=-101.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 Uj9yXFk0M-xJ for ; Tue, 8 Oct 2013 13:29:47 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DB27221F9CE3 for ; Tue, 8 Oct 2013 13:28:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E99F2BE59; Tue, 8 Oct 2013 21:28:46 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8igUInkB6n-b; Tue, 8 Oct 2013 21:28:45 +0100 (IST) Received: from [10.87.48.11] (unknown [86.41.48.16]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 55856BE58; Tue, 8 Oct 2013 21:28:45 +0100 (IST) Message-ID: <52546AFD.3040207@cs.tcd.ie> Date: Tue, 08 Oct 2013 21:28:45 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Greg Hudson , Sam Hartman , kitten@ietf.org References: <52545985.70308@mit.edu> In-Reply-To: <52545985.70308@mit.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten-ads@tools.ietf.org, lha@h5l.org Subject: Re: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 08 Oct 2013 20:29:56 -0000 Hiya, On 10/08/2013 08:14 PM, Greg Hudson wrote: > On 10/08/2013 03:08 PM, Sam Hartman wrote: >> 1) accepting this erata >> >> 2) Fairly quickly reissuing RFC 6112 and moving the existing spec to >> historic. > > I support this plan. That does sound like the right outcome. However... The IESG often sees suggestions for "improvements" to RFCs posted as errata and we reject those on the basis that the errata process is intended to handle cases where a WG/authors/whoever made a mistake and that process is just *not* intended to change what the WG wanted to see in the RFC. Can you make a case that this really is an erratum and does not really represent a change of mind? Thanks, Stephen. From mrex@sap.com Tue Oct 8 19:23: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 D420911E8112 for ; Tue, 8 Oct 2013 19:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.716 X-Spam-Level: X-Spam-Status: No, score=-9.716 tagged_above=-999 required=5 tests=[AWL=0.533, 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 76byN03cPG4M for ; Tue, 8 Oct 2013 19:23:11 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6F621F9B12 for ; Tue, 8 Oct 2013 19:23:10 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r992N5eI010151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 9 Oct 2013 04:23:06 +0200 (MEST) In-Reply-To: <064ca7780d4943b1868670461c2c7184@BLUPR03MB279.namprd03.prod.outlook.com> To: "Paul Miller (NT)" Date: Wed, 9 Oct 2013 04:23:05 +0200 (CEST) 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: <20131009022305.BD1FB1A9E6@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Input on Paul's concerns about aes-cbc 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, 09 Oct 2013 02:23:17 -0000 Paul Miller (NT) wrote: > > ... it would not be possible to do a fallback just for impacted > callers as the cipher of the subsession key is chosen during the > context establishment which is before the first call to > EncryptMessage (GSS_Wrap analogue). By the time we knew that the > caller was not providing for padding, it would be too late to > select differently. That fallback isn't possible has been intuitively obvious, at least to me. > > With the existing calling pattern used for DES in Windows, callers that > did not pass in the SECBUFFER_PADDING into the EncryptMessage call would > just fail when the buffer was not aligned. Hmmm. While I did write my code that calls SSPI's EncryptMessage() in 1999 (during W2K beta), and don't exactly remeber which documentation I used, The "MDSN Library October 2001 Platform SDK" contains a description titled "SSPI/Kerberos Interoperability with GSS-API with this code sample: // Need 3 descriptors - 2 for the SSP and one to hold the application data in_buf_desc.cBuffers = 3; in_buf_desc.pBuffers = wrap_bufs; in_buf_desc.ulVersion = SECBUFFER_VERSION; wrap_bufs[0].cbBuffer = sizes.cbSecurityTrailer; wrap_bufs[0].BufferType = SECBUFFER_TOKEN; wrap_bufs[0].pvBuffer = malloc(sizes.cbSecurityTrailer); // This buffer holds the application data wrap_bufs[1].BufferType = SECBUFFER_DATA; wrap_bufs[1].cbBuffer = in_buf.cbBuffer; wrap_bufs[1].pvBuffer = malloc(wrap_bufs[1].cbBuffer); memcpy(wrap_bufs[1].pvBuffer, in_buf.pvBuffer, in_buf.cbBuffer); wrap_bufs[2].BufferType = SECBUFFER_PADDING; wrap_bufs[2].cbBuffer = sizes.cbBlockSize; wrap_bufs[2].pvBuffer = malloc(wrap_bufs[2].cbBuffer); maj_stat = EncryptMessage(&context, SignOnly ? KERB_WRAP_NO_ENCRYPT : 0, &in_buf_desc, 0); // Send message to server > > There are several reasons that I think this is a significant risk. > First of all, the documentation that Microsoft has for the > EncryptMessage function for Kerberos has very little bearing on how > the function should actually be used. In fact, most of the document > is incorrectly copied and pasted from SSL's documentation. Would the above code really fail to work? -Martin From lukeh@padl.com Tue Oct 8 19: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 75A0C21F995A for ; Tue, 8 Oct 2013 19:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDYELnh3RnHH for ; Tue, 8 Oct 2013 19:34:44 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 03AFF21F9C68 for ; Tue, 8 Oct 2013 19:34:39 -0700 (PDT) Received: by us.padl.com with ESMTP id r992YRKt029754; Tue, 8 Oct 2013 22:34:29 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Luke Howard In-Reply-To: <20131009022305.BD1FB1A9E6@ld9781.wdf.sap.corp> Date: Wed, 9 Oct 2013 13:34:26 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131009022305.BD1FB1A9E6@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1510) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Input on Paul's concerns about aes-cbc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 09 Oct 2013 02:34:49 -0000 > While I did write my code that calls SSPI's EncryptMessage() in 1999 > (during W2K beta), and don't exactly remeber which documentation > I used, The "MDSN Library October 2001 Platform SDK" contains > a description titled "SSPI/Kerberos Interoperability with GSS-API > with this code sample: Because this sample was geared towards GSS-API interoperability (which = was DES only at the time, hence required PKCS#7 padding), it's no = surprise that it correctly uses SECBUFFER_PADDING. That sample code works fine with both truncated token and padding = buffers. Paul's point, I guess, is that not all applications follow = this. =20 -- Luke= From lukeh@padl.com Tue Oct 8 19:39: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 553BF11E8120 for ; Tue, 8 Oct 2013 19:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obRilW2YZP-l for ; Tue, 8 Oct 2013 19:39:05 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id B467621F995A for ; Tue, 8 Oct 2013 19:39:05 -0700 (PDT) Received: by us.padl.com with ESMTP id r992cqqr029865; Tue, 8 Oct 2013 22:38:54 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Luke Howard In-Reply-To: <064ca7780d4943b1868670461c2c7184@BLUPR03MB279.namprd03.prod.outlook.com> Date: Wed, 9 Oct 2013 13:38:51 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <524ECE01.3060401@mit.edu> <064ca7780d4943b1868670461c2c7184@BLUPR03MB279.namprd03.prod.outlook.com> To: Paul Miller (NT) X-Mailer: Apple Mail (2.1510) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Input on Paul's concerns about aes-cbc X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 09 Oct 2013 02:39:11 -0000 On 08/10/2013, at 11:22 AM, Paul Miller (NT) = wrote: > With the existing calling pattern used for DES in Windows, callers = that did not pass in the SECBUFFER_PADDING into the EncryptMessage call = would just fail when the buffer was not aligned. Additionally, if the = buffer was a multiple of the block size then it would not get the PKCS#7 = padding and then would fail on the other end that expected the pad = block. I suspect this would break a whole lot of callers. Are you saying that even for RC4 (where there is one byte of PKCS#7 = padding per RFC 4757 7.3), padding would be omitted entirely if the = buffer was a multiple of the block size? Isn't this a bug? I noticed = this was the case when building an interoperable DCE RPC implementation, = but I assumed it was special-cased for GSS_C_DCE_STYLE. [1] -- Luke [1] = https://github.com/krb5/krb5/blob/master/src/lib/gssapi/krb5/k5sealiov.c#L= 89= From tlyu@mit.edu Wed Oct 9 06:12: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 766E321F9A50 for ; Wed, 9 Oct 2013 06:12:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xXl6ur4OyT5 for ; Wed, 9 Oct 2013 06:12:20 -0700 (PDT) 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 CDB1321F9A3B for ; Wed, 9 Oct 2013 06:12:19 -0700 (PDT) X-AuditID: 12074422-b7f5a8e000000a34-14-5255563269d0 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id EA.F8.02612.23655525; Wed, 9 Oct 2013 09:12:18 -0400 (EDT) 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 r99DCGR3014698; Wed, 9 Oct 2013 09:12:17 -0400 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 r99DCCWc026073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Oct 2013 09:12:15 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r99DCC7w019269; Wed, 9 Oct 2013 09:12:12 -0400 (EDT) To: Luke Howard References: <20131009022305.BD1FB1A9E6@ld9781.wdf.sap.corp> From: Tom Yu Date: Wed, 09 Oct 2013 09:12:12 -0400 In-Reply-To: (Luke Howard's message of "Wed, 9 Oct 2013 13:34:26 +1100") Message-ID: Lines: 18 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT0TUKCw0yuLdKzeJr2wM2i6ObV7FY 3L30n92i9/cOZgcWjyVLfjJ5zP0wjcVjyuetjB4rp55mD2CJ4rJJSc3JLEst0rdL4Mr4uPIU c8EW9oqZf5vYGxi72LoYOTkkBEwktm5dAWWLSVy4tx7I5uIQEtjHKHG7YwELhLOBUeJw2xJG COcsk8S+zZ2sEE4no0T34b2sIP0iAgoSk/evZQaxmQWSJboWHQWLCwskShzZPQXMFhLIlWj6 sQhoEgcHm4C0xNHFZSBhFgFViRlPPrCChDkFKiQer9AACfMKWEss/bwVbCKPAKfEr78T2CDi ghInZz5hgdikJXHj30umCYyCs5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRrqpeb WaKXmlK6iREc0C5KOxh/HlQ6xCjAwajEw/uAPyRIiDWxrLgy9xCjJAeTkijv/YDQICG+pPyU yozE4oz4otKc1OJDjBIczEoivL4WQDnelMTKqtSifJiUNAeLkjjvLQ77ICGB9MSS1OzU1ILU IpisDAeHkgSvQShQo2BRanpqRVpmTglCmomDE2Q4D9DwYJAa3uKCxNzizHSI/ClGXY5Fa1Z9 ZRRiycvPS5US51UCKRIAKcoozYObA0tErxjFgd4S5rUDqeIBJjG4Sa+AljABLdn+PQRkSUki QkqqgZG94n3P2UO+R+f6bamXX8/5YlJwzreJZuUlmnZXLmh6dLLtSEhqmbPh8ZWWya8Oq6UX 7/t7wYDxoNMC8/3XPz5i7OVyWS76ODjlyu8O1UirJVs2TIj+2cU42XmhbfMvEbXLblz9luY2 WtE/TS4YHn633aOr/sCrRU7THHrO7F/Llc1masd7casSS3FGoqEWc1FxIgDHESeRHwMAAA== Cc: "kitten@ietf.org" , Sam Hartman Subject: [kitten] DES enctypes are not PKCS#7 padded (Re: Input on Paul's concerns about aes-cbc) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 09 Oct 2013 13:12:26 -0000 Luke Howard writes: >> While I did write my code that calls SSPI's EncryptMessage() in 1999 >> (during W2K beta), and don't exactly remeber which documentation >> I used, The "MDSN Library October 2001 Platform SDK" contains >> a description titled "SSPI/Kerberos Interoperability with GSS-API >> with this code sample: > > Because this sample was geared towards GSS-API interoperability (which was DES only at the time, hence required PKCS#7 padding), it's no surprise that it correctly uses SECBUFFER_PADDING. The DES enctypes used in Kerberos are not PKCS#7 padding. When the plaintext is an exact multiple of the block size, there is no padding for DES. PKCS#7 type padding requires a full block of padding in that case, because it is self-describing. This could be an important distinction, but I haven't fully analyzed how this affects the usability of the AES-SHA2 proposal with SSPI EncryptMessage. From lukeh@padl.com Wed Oct 9 06:21: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 336C211E8183 for ; Wed, 9 Oct 2013 06:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zU1liJNZHLg for ; Wed, 9 Oct 2013 06:21:18 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 1517C21F841A for ; Wed, 9 Oct 2013 06:21:17 -0700 (PDT) Received: by us.padl.com with ESMTP id r99DL64b028522; Wed, 9 Oct 2013 09:21:08 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Luke Howard In-Reply-To: Date: Thu, 10 Oct 2013 00:21:05 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131009022305.BD1FB1A9E6@ld9781.wdf.sap.corp> To: Tom Yu X-Mailer: Apple Mail (2.1510) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,RDNS_NONE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] DES enctypes are not PKCS#7 padded (Re: Input on Paul's concerns about aes-cbc) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 09 Oct 2013 13:21:23 -0000 >> Because this sample was geared towards GSS-API interoperability = (which was DES only at the time, hence required PKCS#7 padding), it's no = surprise that it correctly uses SECBUFFER_PADDING. >=20 > The DES enctypes used in Kerberos are not PKCS#7 padding. When the > plaintext is an exact multiple of the block size, there is no padding > for DES. PKCS#7 type padding requires a full block of padding in that > case, because it is self-describing. Ah, my (long-term) bad. What about RFC 4757? Greg: in the MIT implementation, = make_seal_token_v1_iov()/kg_fixup_padding_iov() may be wrong then for = DES, I believe I assumed PKCS#7 when implementing it. -- Luke= From kaduk@mit.edu Wed Oct 9 06:22: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 D20C811E8198 for ; Wed, 9 Oct 2013 06:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC+vGrvnC2Nv for ; Wed, 9 Oct 2013 06:22:02 -0700 (PDT) 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 8C98011E8196 for ; Wed, 9 Oct 2013 06:21:53 -0700 (PDT) X-AuditID: 1209190c-b7fd38e0000009aa-2c-52555870c7fe Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 11.DB.02474.07855525; Wed, 9 Oct 2013 09:21:52 -0400 (EDT) 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 r99DLm9c028644; Wed, 9 Oct 2013 09:21:50 -0400 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 r99DLjSF029725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Oct 2013 09:21:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r99DLiPw011356; Wed, 9 Oct 2013 09:21:44 -0400 (EDT) Date: Wed, 9 Oct 2013 09:21:44 -0400 (EDT) From: Benjamin Kaduk To: Stephen Farrell In-Reply-To: <52546AFD.3040207@cs.tcd.ie> Message-ID: References: <52545985.70308@mit.edu> <52546AFD.3040207@cs.tcd.ie> 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+NgFupmleLIzCtJLcpLzFFi42IRYrdT1y2ICA0y2DVLw+Jr2wM2i5NfzrJZ HN28isVi2tZ97BbT915jd2D1WNt9lc3j2OcrjB5Llvxk8lg59TS7x5fLn9kCWKO4bFJSczLL Uov07RK4MvYvX8NScJar4u7RTrYGxkUcXYycHBICJhLrFj9jhrDFJC7cW88GYgsJ7GOUeLDb oYuRC8jewChxZ/JMVgjnIJPEniNLWCGq6iW+3NrEAmKzCGhJnN93ByzOJqAiMfPNRrBJIgL6 Ens3n2MHaWYW6GCU+DR3IjtIQlggTKKlcxtYM6eApsTj5Y/BzuAVcJS4f24JE8SCaIl/7T/B BokK6Eis3j+FBaJGUOLkzCdgNrOApcS5P9fZJjAKzkKSmoUktYCRaRWjbEpulW5uYmZOcWqy bnFyYl5eapGuoV5uZoleakrpJkZQmHNK8uxgfHNQ6RCjAAejEg9vB29IkBBrYllxZe4hRkkO JiVR3vfhoUFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgfhALleFMSK6tSi/JhUtIcLErivDc5 7IOEBNITS1KzU1MLUotgsjIcHEoSvNFhQI2CRanpqRVpmTklCGkmDk6Q4TxAwytAFvMWFyTm FmemQ+RPMSpKifPKgDQLgCQySvPgemFp6BWjONArwryxIO08wBQG1/0KaDAT0ODt30NABpck IqSkGhhlUgoEWPsfP83i4vI9/LhZz1P1FsNpbZOCXeduTVYPlSrO5RTjkZ5y4tljv1eLY90C TD1fpV/O2NZey+56ysCzueXpueCsT1bXj/Ef8PfJ/y/2VZ3jhMhEtd/q7XmqStY3drxc+tL8 hGuUEctp5b591vWuTwLULdi3zXMqFaxe8ZW3czcrrxJLcUaioRZzUXEiAD3MUjEeAwAA Cc: kitten@ietf.org, kitten-ads@tools.ietf.org, Sam Hartman , lha@h5l.org Subject: Re: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 09 Oct 2013 13:22:11 -0000 On Tue, 8 Oct 2013, Stephen Farrell wrote: > > > Hiya, > > On 10/08/2013 08:14 PM, Greg Hudson wrote: >> On 10/08/2013 03:08 PM, Sam Hartman wrote: >>> 1) accepting this erata >>> >>> 2) Fairly quickly reissuing RFC 6112 and moving the existing spec to >>> historic. >> >> I support this plan. > > That does sound like the right outcome. It sounds good to me, too. > However... > > The IESG often sees suggestions for "improvements" to RFCs posted as > errata and we reject those on the basis that the errata process is > intended to handle cases where a WG/authors/whoever made a mistake and > that process is just *not* intended to change what the WG wanted to > see in the RFC. > > Can you make a case that this really is an erratum and does not > really represent a change of mind? My perspective (as someone who only started participating in the WG after this document was published) is that there was an arbitrary choice that had to be made in the creation of the document, and the implementors used (for whatever reason) an equally valid selection of that arbitrary choice. It's not really that there's a change of mind so much as there's no reason to care one way or the other until there is something to interoperate with. I'm not sure whether that would help with the IESG or not, though. -Ben From tlyu@mit.edu Wed Oct 9 06:46: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 9299B21F91B7 for ; Wed, 9 Oct 2013 06:46:34 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dy7H51HIRRuD for ; Wed, 9 Oct 2013 06:46:28 -0700 (PDT) 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 D9BA811E8183 for ; Wed, 9 Oct 2013 06:46:05 -0700 (PDT) X-AuditID: 12074422-b7f5a8e000000a34-b5-52555e1dfde6 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 83.7B.02612.D1E55525; Wed, 9 Oct 2013 09:46:05 -0400 (EDT) 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 r99Dk2SY019231; Wed, 9 Oct 2013 09:46:02 -0400 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 r99Dk0nN009101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Oct 2013 09:46:01 -0400 Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id r99Dk046019366; Wed, 9 Oct 2013 09:46:00 -0400 (EDT) To: Luke Howard References: <20131009022305.BD1FB1A9E6@ld9781.wdf.sap.corp> From: Tom Yu Date: Wed, 09 Oct 2013 09:46:00 -0400 In-Reply-To: (Luke Howard's message of "Thu, 10 Oct 2013 00:21:05 +1100") Message-ID: Lines: 19 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT0ZWNCw0yWPKf1eJr2wM2i6ObV7FY 3L30n92i9/cOZgcWjyVLfjJ5zP0wjcVjyuetjB4rp55mD2CJ4rJJSc3JLEst0rdL4MpYvP84 c8FJ9oqnpxewNDBOYuti5OSQEDCRWHZtDjuELSZx4d56oDgXh5DAPkaJ5lWfwRJCAhsYJRae ZoFInGWS2P3/FDOE08ko0frmPdgoEQEFicn71zKD2MwCyRJdi46ygtjCAqkSn36+hmq4yCgx YUcjUAMHB5uAtMTRxWUgNSwCqhJbPu1nBLE5BSolTjRdA7N5BSwkdr34A3YFjwCnRM+GX6wQ cUGJkzOfsEDs0pK48e8l0wRGwVlIUrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdXL zSzRS00p3cQIDmkXpR2MPw8qHWIU4GBU4uF9wB8SJMSaWFZcmXuIUZKDSUmUd3tMaJAQX1J+ SmVGYnFGfFFpTmrxIUYJDmYlEV7jaKAcb0piZVVqUT5MSpqDRUmc9xaHfZCQQHpiSWp2ampB ahFMVoaDQ0mC9w/IUMGi1PTUirTMnBKENBMHJ8hwHqDhr0FqeIsLEnOLM9Mh8qcYdTkWrVn1 lVGIJS8/L1VKnPcXSJEASFFGaR7cHFgqesUoDvSWMO8rkCoeYBqDm/QKaAkT0JLt30NAlpQk IqSkGhjLzr4LKN/evsrvpl1awJMYAbcPk/78jxCofp9QlZ5y76jQ6me73CaITzVty/RaLVao qbPgQembX3npfpttExr2NHwW0jebqf+7/J6sUu/8gFcnPLaGLP338O7LSEsFaw01nQmXfOIb GAL5N2srWjGnyxgbTmvRvlCQOV1dSn9i2I5+Z41sDyWW4oxEQy3mouJEAHImIjwgAwAA Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] DES enctypes are not PKCS#7 padded (Re: Input on Paul's concerns about aes-cbc) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 09 Oct 2013 13:46:34 -0000 Luke Howard writes: >>> Because this sample was geared towards GSS-API interoperability (which was DES only at the time, hence required PKCS#7 padding), it's no surprise that it correctly uses SECBUFFER_PADDING. >> >> The DES enctypes used in Kerberos are not PKCS#7 padding. When the >> plaintext is an exact multiple of the block size, there is no padding >> for DES. PKCS#7 type padding requires a full block of padding in that >> case, because it is self-describing. > > Ah, my (long-term) bad. > > What about RFC 4757? > > Greg: in the MIT implementation, make_seal_token_v1_iov()/kg_fixup_padding_iov() may be wrong then for DES, I believe I assumed PKCS#7 when implementing it. Greg has reminded me that RFC 1964 uses PKCS#7 padding for single-DES; I was mistakenly recalling that the DES CBC padding used in the RFC 1510 protocol (which is not PKCS#7) was the same used with DES for GSS-Wrap. Sorry for any confusion. From stephen.farrell@cs.tcd.ie Wed Oct 9 06:50: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 612AF11E816E for ; Wed, 9 Oct 2013 06:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 2bAVQ-A5rJE5 for ; Wed, 9 Oct 2013 06:50:46 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D718211E818A for ; Wed, 9 Oct 2013 06:50:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2DE7EBE38; Wed, 9 Oct 2013 14:50:44 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUQDyWLbyBOK; Wed, 9 Oct 2013 14:50:44 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id EEF7FBE29; Wed, 9 Oct 2013 14:50:39 +0100 (IST) Message-ID: <52555F30.2050600@cs.tcd.ie> Date: Wed, 09 Oct 2013 14:50:40 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <52545985.70308@mit.edu> <52546AFD.3040207@cs.tcd.ie> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten@ietf.org, kitten-ads@tools.ietf.org, Sam Hartman , lha@h5l.org Subject: Re: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 09 Oct 2013 13:50:58 -0000 On 10/09/2013 02:21 PM, Benjamin Kaduk wrote: > > I'm not sure whether that would help with the IESG or not, though. I'm checking if anyone will yell if we approve this. While I guess they won't mind about the kerberos change, its possible that someone will strongly dislike the precedent. But we'll see. S. From lha@h5l.org Wed Oct 9 06:56: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 851EE11E8183 for ; Wed, 9 Oct 2013 06:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLEQnUPpDhwj for ; Wed, 9 Oct 2013 06:56:12 -0700 (PDT) Received: from smtp-3.sys.kth.se (smtp-3.sys.kth.se [IPv6:2001:6b0:1:1300:250:56ff:fea6:2de2]) by ietfa.amsl.com (Postfix) with ESMTP id 5D0E521E808A for ; Wed, 9 Oct 2013 06:56:08 -0700 (PDT) Received: from mailscan-3.sys.kth.se (mailscan-3.sys.kth.se [130.237.48.170]) by smtp-3.sys.kth.se (Postfix) with ESMTP id 4E0141DBC; Wed, 9 Oct 2013 15:56:03 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-3.sys.kth.se ([130.237.48.192]) by mailscan-3.sys.kth.se (mailscan-3.sys.kth.se [130.237.48.170]) (amavisd-new, port 10024) with LMTP id DFXgJw6PRPue; Wed, 9 Oct 2013 15:55:58 +0200 (CEST) X-KTH-Auth: lha [80.216.20.112] X-KTH-mail-from: lha@h5l.org Received: from [192.168.0.51] (c80-216-20-112.bredband.comhem.se [80.216.20.112]) by smtp-3.sys.kth.se (Postfix) with ESMTPSA id 760F2839; Wed, 9 Oct 2013 15:55:55 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1812\)) From: =?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?= In-Reply-To: <52555F30.2050600@cs.tcd.ie> Date: Wed, 9 Oct 2013 15:55:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91688B1D-A421-4EB0-AF02-05264F61435D@h5l.org> References: <52545985.70308@mit.edu> <52546AFD.3040207@cs.tcd.ie> <52555F30.2050600@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.1812) Cc: " " , kitten-ads@tools.ietf.org, Sam Hartman Subject: Re: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 09 Oct 2013 13:56:30 -0000 9 okt 2013 kl. 15:50 skrev Stephen Farrell : >=20 >=20 > On 10/09/2013 02:21 PM, Benjamin Kaduk wrote: >>=20 >> I'm not sure whether that would help with the IESG or not, though. >=20 > I'm checking if anyone will yell if we approve this. While I > guess they won't mind about the kerberos change, its possible > that someone will strongly dislike the precedent. But we'll > see. I this either way is fine wrt approving the errata. Now the kerberos community will know that there is an issue in RFC6112. IESG can approve a new version of RFC6112 which a a one word change once = there is a new draft published. Love From hartmans@mit.edu Wed Oct 9 10:35: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 76E8F21E805F for ; Wed, 9 Oct 2013 10:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU5k8GS1R1JU for ; Wed, 9 Oct 2013 10:35:01 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id AB0F821E811C for ; Wed, 9 Oct 2013 10:35:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C157A204D7; Wed, 9 Oct 2013 13:33:35 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wB1ieIWftKxi; Wed, 9 Oct 2013 13:33:35 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Wed, 9 Oct 2013 13:33:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 45B46834E7; Wed, 9 Oct 2013 13:34:59 -0400 (EDT) From: Sam Hartman To: Stephen Farrell References: <52545985.70308@mit.edu> <52546AFD.3040207@cs.tcd.ie> <52555F30.2050600@cs.tcd.ie> Date: Wed, 09 Oct 2013 13:34:59 -0400 In-Reply-To: <52555F30.2050600@cs.tcd.ie> (Stephen Farrell's message of "Wed, 09 Oct 2013 14:50:40 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten-ads@tools.ietf.org, lha@h5l.org, kitten@ietf.org, Sam Hartman Subject: Re: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 09 Oct 2013 17:35:06 -0000 Sure. It's really a rules lawyer question about the erata. the interesting and important thing is to go issue a new spec. I won't be able to put together a draft before Vancouver but I will work promptly on this. From stpeter@stpeter.im Mon Oct 14 11:10: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 0FC5B11E818E; Mon, 14 Oct 2013 11:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.188 X-Spam-Level: X-Spam-Status: No, score=-102.188 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82kl6aGnjlY2; Mon, 14 Oct 2013 11:10:37 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F3B8C21F9A19; Mon, 14 Oct 2013 11:10:36 -0700 (PDT) Received: from sjc-vpn2-1003.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AD13340FA9; Mon, 14 Oct 2013 12:16:50 -0600 (MDT) Message-ID: <525C339A.20407@stpeter.im> Date: Mon, 14 Oct 2013 12:10:34 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Alexey Melnikov References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> <20130924231746.73c578b7@latte.josefsson.org> <524EB8B4.2000509@isode.com> In-Reply-To: <524EB8B4.2000509@isode.com> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Simon Josefsson , Sam Hartman , "precis@ietf.org" Subject: Re: [kitten] [precis] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.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, 14 Oct 2013 18:10:42 -0000 On 10/4/13 6:46 AM, Alexey Melnikov wrote: > On 24/09/2013 22:17, Simon Josefsson wrote: >> You wrote: >>>>>>>> "Simon" == Simon Josefsson writes: >>> Simon> like HTTP, FTP, SMTP, SSH, etc could be revised. I don't >>> Simon> believe any of that will happen, so we'll have to live with >>> Simon> case sensitive usernames, and my take is that I18N >>> Simon> documents should permit that. >>> >>> I'm not sure any of the above hase case sensitive usernames. >>> They permit usernames to be case sensitive. >>> However a lot of implementations treat the username as case >>> insensitive. >>> >>> I do think this is an appropriate issue for an IETF an document, but I >>> do think considering the impact on legacy systems is important. >>> I don't think we need to require there be no impact, simply understand >>> an accept it. >> Agreed, but the devil is in the detail. For example, I would say that >> any I18N effort that changes how ASCII usernames ([A-Za-z0-9...]) >> behave have gone too far down the road that causes damage to legacy >> systems. > Case folding for usernames in draft-ietf-precis-saslprepbis-04.txt is a > SHOULD, so I think you are Ok. I.e. compatibility with a legacy system > is a good enough reason to violate the SHOULD. Correct. Here is proposed text for Section 4 on usernames. I've provided proposed text for the entire section so that folks on both the PRECIS and KITTEN lists have the complete context. Please review this proposed text and provide comments. ### 4. Usernames 4.1. Definition This document specifies that a username is a string of Unicode code points [UNICODE], encoded using UTF-8 [RFC3629], and structured either as an ordered sequence of "userparts" (where the complete username can consist of a single userpart or a space-separated sequence of userparts) or as a userpart@domainpart (where the domainpart is an IP literal, an IPv4 address, or a fully-qualified domain name). The syntax for a username is defined as follows using the Augmented Backus-Naur Form (ABNF) [RFC5234]. username = userpart [1*(1*SP userpart)] / userpart '@' domainpart userpart = 1*(idpoint) ; ; an "idpoint" is a UTF-8 encoded Unicode code point ; that conforms to the PRECIS "IdentifierClass" ; domainpart = IP-literal / IPv4address / ifqdn ; ; the "IPv4address" and "IP-literal" rules are ; defined in RFC 3986, and the first-match-wins ; (a.k.a. "greedy") algorithm described in RFC 3986 ; applies ; ; reuse of the IP-literal rule from RFC 3986 implies ; that IPv6 addresses are enclosed in square brackets ; (i.e., beginning with '[' and ending with ']') ; ifqdn = 1*1023(domainpoint) ; ; a "domainpoint" is a UTF-8 encoded Unicode code ; point that conforms to RFC 5890 ; All code points and blocks not explicitly allowed in the PRECIS IdentifierClass are disallowed; this includes private use characters, surrogate code points, and the other code points and blocks that were defined as "Prohibited Output" in [RFC4013]. In addition, common constructions such as "user@example.com" are allowed as usernames under this specification, as they were under [RFC4013]. 4.2. Preparation Each userpart of a username MUST conform to the "UsernameIdentifierClass" profile of the PRECIS IdentifierClass, which is defined as follows: 1. The base string class is the "IdentifierClass" specified in [I-D.ietf-precis-framework]. 2. Fullwidth and halfwidth characters MUST be mapped to their decomposition equivalents. 3. So-called additional mappings MAY be applied, such as those defined in [I-D.ietf-precis-mappings]. 4. Uppercase and titlecase characters might be mapped to their lowercase equivalents (see Section 4.2.1 below). 5. Unicode Normalization Form C (NFC) MUST be applied to all characters. With regard to directionality, the "Bidi Rule" provided in [RFC5893] applies. A username MUST NOT be zero bytes in length. This rule is to be enforced after any normalization and mapping of code points. In protocols that provide usernames as input to a cryptographic algorithm such as a hash function, the client will need to perform proper preparation of the username before applying the algorithm. 4.2.1. Case Mapping Case mapping is a matter for the application protocol, protocol implementation, or end deployment. In general, this document suggests that it is preferable to perform case mapping, since not doing so can lead to false positives during authentication and authorization (as described in [RFC6943]) and can result in confusion among end users given the prevalence of case mapping in many existing protocols and applications. However, there can be good reasons to not perform case mapping, such as backward compatibility with deployed infrastructure. In particular: o SASL mechanisms that directly re-use this profile MUST specify whether and when case mapping is to be applied to authentication identifiers. SASL mechanisms SHOULD delay any case mapping to the last possible moment, such as when doing a lookup by username, username comparisons, or generating a cryptographic salt from a username. In keeping with RFC4422, SASL mechanisms are not to apply this or any other profile to authorization identifiers. o Application protocols that use SASL (such as IMAP [RFC3501] and XMPP [RFC6120]) and that directly re-use this profile MUST specify whether case mapping is to be applied to authorization identifiers. Such "SASL application protocols" SHOULD delay any case mapping of authorization identifiers to the last possible moment, which happens to necessarily be on the server side. In keeping with RFC4422, SASL application protocols are not to apply this or any other profile to authentication identifiers. o Application protocols that do not use SASL (such as HTTP authentication with the Basic and Digest schemes [RFC2617]) MUST specify whether and when case mapping is to be applied to authentication identifiers and authorization identifiers. Such "non-SASL application protocols" SHOULD delay any case mapping to the last possible moment, such as when doing a lookup by username, username comparisons, or generating a cryptographic salt from a username. If the specification for a SASL mechanism, SASL application protocol, or non-SASL application protocol specifies the handling of case mapping for strings that conform to the UsernameIdentifierClass, it MUST clearly describe whether case mapping is required, recommended, or optional at the level of the protocol itself, implementations thereof, or service deployments. ### Peter -- Peter Saint-Andre https://stpeter.im/ From shawn.emery@oracle.com Mon Oct 14 22:20: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 8688411E8100 for ; Mon, 14 Oct 2013 22:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pze72Hk6oaZH for ; Mon, 14 Oct 2013 22:20:30 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8F72B21E808A for ; Mon, 14 Oct 2013 22:20:29 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9F5KSRS018657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 15 Oct 2013 05:20:29 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9F5KQaA015354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Oct 2013 05:20:28 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9F5KQK9023568 for ; Tue, 15 Oct 2013 05:20:26 GMT Received: from [10.159.123.40] (/10.159.123.40) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 14 Oct 2013 22:20:26 -0700 Message-ID: <525CD0D2.1020504@oracle.com> Date: Mon, 14 Oct 2013 23:21:22 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6 MIME-Version: 1.0 To: kitten@ietf.org References: <522A3B89.1010307@oracle.com> In-Reply-To: <522A3B89.1010307@oracle.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 05:20:35 -0000 The consensus results from the 9-6-13 call (ending 9-20-13) was: 1. Consensus to progress the sasl-oauth draft with the GS2 related text removed. However, Nico, had brought up during the call that CB related text should also removed until the base GS2 spec allows for mutual authentication outside of the mechanism. Alexey had mentioned interest in having this support, but this is something that the long-term solution should provide. I believe that we need further discussions on this point before we can determine if any other consensus call needs to be made here. 2. Consensus on adopting generic-naming-attributes. 3. No consensus on adopting krb5-pkcross. We can always revisit this in the future as demand, interest, or resources change. Shawn. -- kitten co-chair On 09/ 6/13 02:31 PM, Shawn M Emery wrote: > > The WG is making the following consensus calls (which were formulated > from Berlin's meeting held on August 1st): > > 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the > GS2 related text from the draft and continue the proceed to shepherd > this as an RFC? > > a. Yes > b. No > c. Don't care or need more information > > 2. Should the WG recharter and adopt the > draft-williams-kitten-generic-naming-attributes draft? > > a. Yes > b. No > c. Don't care or need more information > > 3. Should the WG recharter and adopt the > draft-williams-kitten-krb5-pkcross draft? > > a. Yes > b. No > c. Don't care or need more information > > Please provide your input before September 20th. Thank you. > > Shawn. > -- > kitten co-chair > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > From stephen.farrell@cs.tcd.ie Tue Oct 15 03:53: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 5D8DA11E81D1 for ; Tue, 15 Oct 2013 03:53:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 R5RCfLuDvRM6 for ; Tue, 15 Oct 2013 03:53:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE9C11E817D for ; Tue, 15 Oct 2013 03:53:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E27C3BE47; Tue, 15 Oct 2013 11:53:38 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIYhOtgd9ceE; Tue, 15 Oct 2013 11:53:38 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C0F3EBE39; Tue, 15 Oct 2013 11:53:38 +0100 (IST) Message-ID: <525D1EB3.5060900@cs.tcd.ie> Date: Tue, 15 Oct 2013 11:53:39 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: kitten@ietf.org References: <52545985.70308@mit.edu> <52546AFD.3040207@cs.tcd.ie> <52555F30.2050600@cs.tcd.ie> In-Reply-To: <52555F30.2050600@cs.tcd.ie> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten-ads@tools.ietf.org Subject: Re: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 15 Oct 2013 10:53:44 -0000 On 10/09/2013 02:50 PM, Stephen Farrell wrote: > > > On 10/09/2013 02:21 PM, Benjamin Kaduk wrote: >> >> I'm not sure whether that would help with the IESG or not, though. > > I'm checking if anyone will yell if we approve this. While I > guess they won't mind about the kerberos change, its possible > that someone will strongly dislike the precedent. But we'll > see. I asked and was asked back: how widely is this one implementation deployed? I also got a non-IESG comment that this wasn't the first time we've ended up changing things due to coding glitches so maybe we need to think about that as well. S. > > S. > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > From ghudson@mit.edu Tue Oct 15 07:01: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 9B73811E817B for ; Tue, 15 Oct 2013 07:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 95Hb9oADC7un for ; Tue, 15 Oct 2013 07:01:45 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id BB0B721E8157 for ; Tue, 15 Oct 2013 07:01:42 -0700 (PDT) X-AuditID: 1209190e-b7f828e0000009cf-d4-525d4ac6a9fd Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id BC.34.02511.6CA4D525; Tue, 15 Oct 2013 10:01:42 -0400 (EDT) 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 r9FE1efa026816; Tue, 15 Oct 2013 10:01:41 -0400 Received: from [18.101.8.215] (vpn-18-101-8-215.mit.edu [18.101.8.215]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r9FE1cnd028404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Oct 2013 10:01:39 -0400 Message-ID: <525D4AC1.9070105@mit.edu> Date: Tue, 15 Oct 2013 10:01:37 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Stephen Farrell , kitten@ietf.org References: <52545985.70308@mit.edu> <52546AFD.3040207@cs.tcd.ie> <52555F30.2050600@cs.tcd.ie> <525D1EB3.5060900@cs.tcd.ie> In-Reply-To: <525D1EB3.5060900@cs.tcd.ie> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYrdT1z3mFRtksHQRr8XJL2fZLI5uXsVi MX3vNXYHZo+13VfZPJYs+cnk8eXyZ7YA5igum5TUnMyy1CJ9uwSujDevzrAWPGSumNnI28DY yNzFyMkhIWAiseDMS0YIW0ziwr31bF2MXBxCAvsYJRpWXGSBcDYySix4P48VwjnCJPHn00Ww Fl4BNYm/vSdYQWwWAVWJB9O+MYHYbALKEgfPfmMBsUUFgiSOb53ABFEvKHFy5hOwuIiAg8TT M7OA5nBwMAvISqw6VAcSFhYIk2jp3Aa1+DSjxMH358B2cQpoSrT3LWOFOFVSYtuiY+wgNrOA jsS7vgfMELa8xPa3c5gnMArNQrJuFpKyWUjKFjAyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI1 1svNLNFLTSndxAgKdk5Jvh2MXw8qHWIU4GBU4uH9wRsTJMSaWFZcmXuIUZKDSUmUN8ozNkiI Lyk/pTIjsTgjvqg0J7X4EKMEB7OSCO8fK6Acb0piZVVqUT5MSpqDRUmc9yaHfZCQQHpiSWp2 ampBahFMVoaDQ0mCdyXIUMGi1PTUirTMnBKENBMHJ8hwHqDhaSA1vMUFibnFmekQ+VOMilLi vLtBEgIgiYzSPLheWDJ6xSgO9IowrwtIFQ8wkcF1vwIazAQ0+NvtGJDBJYkIKakGRr+1jY73 d56q57gif+vq+tZdRZcu6Yp1OxkEs8Tle98teL3+rtskg6DLNRKPJV6cPmjc5B/7aooOT8OD 7m9XPaOest1sUv2uaGi3fdM394C4+bcEb3Z9v8fuu9HOwuXN7C+7WH77rnyg3aC389n2M+H/ OG66nOna3D+/Yqq5wvzINT0ecaqM7EosxRmJhlrMRcWJABNCEpYhAwAA Cc: kitten-ads@tools.ietf.org Subject: Re: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 15 Oct 2013 14:01:51 -0000 On 10/15/2013 06:53 AM, Stephen Farrell wrote: > I asked and was asked back: how widely is this one > implementation deployed? RFC 6112 was first implemented in MIT krb5 version 1.8, which was released in March 2010. We never have any solid idea how widely krb5 features are being used since we don't have a close relationship with most of our users. I have seen at least one question about anonymous PKINIT on kerberos@mit.edu, so it's being used at least somewhat. From stephen.farrell@cs.tcd.ie Tue Oct 15 07:06: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 E55DC21F9DC9 for ; Tue, 15 Oct 2013 07:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 JuyNhgbwGx7q for ; Tue, 15 Oct 2013 07:05:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 33E7121F9C9A for ; Tue, 15 Oct 2013 07:04:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7C931BE39; Tue, 15 Oct 2013 15:04:51 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X05527jVuk8w; Tue, 15 Oct 2013 15:04:51 +0100 (IST) Received: from [134.226.36.180] (stephen-think.dsg.cs.tcd.ie [134.226.36.180]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3DE32BE59; Tue, 15 Oct 2013 15:04:51 +0100 (IST) Message-ID: <525D4B83.80601@cs.tcd.ie> Date: Tue, 15 Oct 2013 15:04:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Greg Hudson , kitten@ietf.org References: <52545985.70308@mit.edu> <52546AFD.3040207@cs.tcd.ie> <52555F30.2050600@cs.tcd.ie> <525D1EB3.5060900@cs.tcd.ie> <525D4AC1.9070105@mit.edu> In-Reply-To: <525D4AC1.9070105@mit.edu> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: kitten-ads@tools.ietf.org Subject: Re: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 15 Oct 2013 14:06:03 -0000 On 10/15/2013 03:01 PM, Greg Hudson wrote: > On 10/15/2013 06:53 AM, Stephen Farrell wrote: >> I asked and was asked back: how widely is this one >> implementation deployed? > > RFC 6112 was first implemented in MIT krb5 version 1.8, which was > released in March 2010. We never have any solid idea how widely krb5 > features are being used since we don't have a close relationship with > most of our users. I have seen at least one question about anonymous > PKINIT on kerberos@mit.edu, so it's being used at least somewhat. Would asking about the erratum on that list therefore be useful? Ta, S. > > > From ghudson@mit.edu Tue Oct 15 07:30: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 BEA5321E81B3 for ; Tue, 15 Oct 2013 07:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 cpESe-7vE-ir for ; Tue, 15 Oct 2013 07:30:41 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) by ietfa.amsl.com (Postfix) with ESMTP id 1823121E81AB for ; Tue, 15 Oct 2013 07:30:40 -0700 (PDT) X-AuditID: 1209190e-b7f828e0000009cf-25-525d5190cf52 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id C8.A6.02511.0915D525; Tue, 15 Oct 2013 10:30:40 -0400 (EDT) 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 r9FEUcbD008818; Tue, 15 Oct 2013 10:30:39 -0400 Received: from [18.101.8.215] (vpn-18-101-8-215.mit.edu [18.101.8.215]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r9FEUarN008781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 15 Oct 2013 10:30:37 -0400 Message-ID: <525D518C.3050907@mit.edu> Date: Tue, 15 Oct 2013 10:30:36 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Stephen Farrell , kitten@ietf.org References: <52545985.70308@mit.edu> <52546AFD.3040207@cs.tcd.ie> <52555F30.2050600@cs.tcd.ie> <525D1EB3.5060900@cs.tcd.ie> <525D4AC1.9070105@mit.edu> <525D4B83.80601@cs.tcd.ie> In-Reply-To: <525D4B83.80601@cs.tcd.ie> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hTV1p0QGBtk0PhS0eLkl7NsFkc3r2Kx mL73GrsDs8fa7qtsHkuW/GTy+HL5M1sAcxSXTUpqTmZZapG+XQJXxq3rjewFL1grjl14y9zA eIOli5GTQ0LARKLl6RF2CFtM4sK99WxdjFwcQgL7GCV2v9jDDOFsZJT4equRCcI5wiRx50oL M0gLr4CaxKPtnWDtLAKqEjcOvAYbyyagLHHw7DcwW1QgSOL41glMEPWCEidnPgGLiwg4SDw9 M4uxi5GDg1lAVmLVoTqQsLBAmERL5zYWiF2NTBIv/21lBElwCqhLHOs9xwRxqqTEtkXHwPYy C+hIvOt7wAxhy0tsfzuHeQKj0Cwk62YhKZuFpGwBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQi XWO93MwSvdSU0k2M4HCX5NvB+PWg0iFGAQ5GJR7eH7wxQUKsiWXFlbmHGCU5mJREed/4xwYJ 8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuF9AZLjTUmsrEotyodJSXOwKInz3uSwDxISSE8sSc1O TS1ILYLJynBwKEnwHgoAahQsSk1PrUjLzClBSDNxcIIM5wEa/hKkhre4IDG3ODMdIn+KUVFK nPcWSEIAJJFRmgfXC0tHrxjFgV4R5j0GUsUDTGVw3a+ABjMBDf52OwZkcEkiQkqqgVGgQJ37 6DaROQ+9Op60ioaUhVQdjPrRYeQswbHI20qY4W/vtMY1CqHma+p6JKuWrRd5d3x3/q43Wl/+ HrpRHVOcyvTM6/GMlwUnP9j+4PFbc1OwefsFi8m5rA7vFr482enL6/BmURbj1ytLShIOBPV8 Tj7S2f1z9Yd3+1LuGIQ+bWm7fN1ON16JpTgj0VCLuag4EQCxrpTUIgMAAA== Cc: kitten-ads@tools.ietf.org Subject: Re: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 15 Oct 2013 14:30:47 -0000 On 10/15/2013 10:04 AM, Stephen Farrell wrote: > Would asking about the erratum on that list therefore be > useful? I assume you mean, would it be useful to ask on kerberos@mit.edu whether people are using anonymous PKINIT? The list is not by any means a reliably way of canvassing users, so I don't think it would be. I'm also not sure where we would go with such a question. I think implementors have decided that we are going to use "KEYEXCHANGE" instead of "KeyExchange" as the pepper going forward. There is no obvious way to change the existing implementation to use "KeyExchange" without creating interoperability issues, and there is no merit to one string over another aside from its likelihood of interoperating. From nico@cryptonector.com Tue Oct 15 10:17: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 3D49211E8141; Tue, 15 Oct 2013 10:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=-0.137, 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 zmc1ZcMVyrcB; Tue, 15 Oct 2013 10:17:02 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id F06C311E8186; Tue, 15 Oct 2013 10:16:52 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 7450E59807B; Tue, 15 Oct 2013 10:16:42 -0700 (PDT) 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=62vYhxeOj+yfom9jQAmX KZ5FThQ=; b=CNOoDEsGSkhSGGAteTZsMJFLzYHfXq6L4oRJyG5QYJQxgZ8o5uoO wLm5mjd656fLn4VsEaPXGABmE82kRdCV29XuuiBgS8JL4cU8dW8ARfl+yUTVETED +77xD0utbwZZyctlac/zhucnoXY1+tRlaiKa1zcakkYM30qs/Z7fRCQ= 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 D6E1B59806A; Tue, 15 Oct 2013 10:16:41 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t61so8769359wes.20 for ; Tue, 15 Oct 2013 10:16:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IY0aeA5+xTkixTXntBDXXSWowsiVRNyFXQ3JDMYHelQ=; b=D45c/WjVDZ8Rv+qOU+qBva3wwzLyiLhiMAa5UdXzwuajz1PVSSBvIfn3tmQWzhw/tT 7opjGcTYlI4TUSFCtrKUP+s95OQQU2quJ1brz3E5MS5H+lWAARBKp8a3twWc1+8c06Et 5iZu55LH8BbAksgMvCtP0auiJVZdi5jGcmKgUT3GRKUHyXWP9FcG71RuKm6mc6e+3bXO hnYt5XS68xGjVdc7ocie6kphvIVcdvt33rbHjy/Rwv8lSFgxyfQ0rJR412QZEk+tGnd6 iouvuXw4rP1OGt+AR4R8arTgoW5I7erJmqMXXm1aBbZ0R2Wc+IisKK/qLlkhOx1be/QU rxhg== MIME-Version: 1.0 X-Received: by 10.194.248.130 with SMTP id ym2mr2698689wjc.61.1381857400192; Tue, 15 Oct 2013 10:16:40 -0700 (PDT) Received: by 10.216.151.136 with HTTP; Tue, 15 Oct 2013 10:16:40 -0700 (PDT) In-Reply-To: <525C339A.20407@stpeter.im> References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> <20130924231746.73c578b7@latte.josefsson.org> <524EB8B4.2000509@isode.com> <525C339A.20407@stpeter.im> Date: Tue, 15 Oct 2013 12:16:40 -0500 Message-ID: From: Nico Williams To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" , Simon Josefsson Subject: Re: [kitten] [precis] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.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, 15 Oct 2013 17:17:07 -0000 On Mon, Oct 14, 2013 at 1:10 PM, Peter Saint-Andre wrote: I'm OK with this. I would add that if a mechanism allows the "last possible moment" to always be on the server side then the choice of whether to case fold can be left to the deployer. Also, mechanisms that have enough round trips can always leave this to the deployer as well. Even mechanisms that don't -- one could always indicate this via DNS, but I won't go there. Nico -- From stpeter@stpeter.im Tue Oct 15 10:39: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 AE70D1F0D5C; Tue, 15 Oct 2013 10:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.482 X-Spam-Level: X-Spam-Status: No, score=-102.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 WQYWyo3p--Tu; Tue, 15 Oct 2013 10:39:30 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 991881F0D57; Tue, 15 Oct 2013 10:39:27 -0700 (PDT) Received: from ergon.local (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0AEA341019; Tue, 15 Oct 2013 11:45:43 -0600 (MDT) Message-ID: <525D7DCC.6020609@stpeter.im> Date: Tue, 15 Oct 2013 11:39:24 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Nico Williams References: <51FEEC99.1020901@stpeter.im> <52090F96.30700@stpeter.im> <522E5CAA.5010902@stpeter.im> <5230B3B3.3040805@babelmonkeys.de> <87zjr2pmhs.fsf@latte.josefsson.org> <87txharmne.fsf@latte.josefsson.org> <20130924231746.73c578b7@latte.josefsson.org> <524EB8B4.2000509@isode.com> <525C339A.20407@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" , Sam Hartman , "precis@ietf.org" , Simon Josefsson Subject: Re: [kitten] [precis] Fwd: Re: I-D Action: draft-ietf-precis-saslprepbis-04.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, 15 Oct 2013 17:39:36 -0000 On 10/15/13 11:16 AM, Nico Williams wrote: > On Mon, Oct 14, 2013 at 1:10 PM, Peter Saint-Andre wrote: > > I'm OK with this. I would add that if a mechanism allows the "last > possible moment" to always be on the server side then the choice of > whether to case fold can be left to the deployer. Also, mechanisms > that have enough round trips can always leave this to the deployer as > well. True. I'll try to formulate some text along those lines. > Even mechanisms that don't -- one could always indicate this > via DNS, but I won't go there. Agreed. Peter -- Peter Saint-Andre https://stpeter.im/ From nico@cryptonector.com Tue Oct 15 16:20: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 A8A0611E819A for ; Tue, 15 Oct 2013 16:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.104 X-Spam-Level: X-Spam-Status: No, score=-2.104 tagged_above=-999 required=5 tests=[AWL=-0.127, 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 y7395V9U9PTX for ; Tue, 15 Oct 2013 16:20:40 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id AC2F721F9B5A for ; Tue, 15 Oct 2013 16:20:40 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id E03C69405C for ; Tue, 15 Oct 2013 16:20:39 -0700 (PDT) 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=cQV3KZNXT0hGQveM6kNm alc2VFM=; b=ktX1BzA77I50Nei0eN2IUYEDov8udUcbp2Xm/FiiYbFqD6iZW2y6 a1CihBeBiMDYPTxtrPNQYsbJFgtfoAzNz+gc6sjolLp/6AbFV+/cnEMhE91zUOLt wrqb+JkQeUHYV6SA063SpG9bJW3y1wA4bptxi3DNwz5w2UE4b2JZMOc= 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-a77.g.dreamhost.com (Postfix) with ESMTPSA id 8855694059 for ; Tue, 15 Oct 2013 16:20:39 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id n12so8337036wgh.23 for ; Tue, 15 Oct 2013 16:20:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tk0TbvSqf3i0/MoASEYI0toxTAbDwti14xBnrovdEqk=; b=L8hHLI7tZMt4ERZtHzYHlzHfeUjKH78BvmgaJEbeH+YJIn+9C8ZxmrJYHfLmFoV+V+ oH3crpm3nra7kMVWtBkEHmzei5Mn6m3eVcaaGVBR4VVSrHfDkfUc2w0QUO6JUggyNPgn 4n2yHyrGv0t5O3MBEDRUM3v3f/gQmYxEFsjpUzb/WiaGxEEcFybzp/PNFgAt0/HsIOxh oQH//grR3qnjUbCAyJI8xFA8cgJ1KY24vRPHkYoppPivI6cyIoE5HO9tN7aqhmkUYqu9 15qCYeznU3hg7FilbXVuR491IKl/To0q2ZvcJvLdP2mAicNNa1RmlqiNSe9V4+XYGfEx c+3Q== MIME-Version: 1.0 X-Received: by 10.180.99.3 with SMTP id em3mr22092429wib.4.1381879238116; Tue, 15 Oct 2013 16:20:38 -0700 (PDT) Received: by 10.216.151.136 with HTTP; Tue, 15 Oct 2013 16:20:38 -0700 (PDT) In-Reply-To: <525CD0D2.1020504@oracle.com> References: <522A3B89.1010307@oracle.com> <525CD0D2.1020504@oracle.com> Date: Tue, 15 Oct 2013 18:20:38 -0500 Message-ID: From: Nico Williams To: Shawn M Emery Content-Type: text/plain; charset=UTF-8 Cc: "kitten@ietf.org" Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 23:20:45 -0000 On Tue, Oct 15, 2013 at 12:21 AM, Shawn M Emery wrote: > > The consensus results from the 9-6-13 call (ending 9-20-13) was: > > 1. Consensus to progress the sasl-oauth draft with the GS2 related text > removed. However, Nico, had brought up during the call that CB related text > should also removed until the base GS2 spec allows for mutual authentication > outside of the mechanism. Alexey had mentioned interest in having this > support, but this is something that the long-term solution should provide. > I believe that we need further discussions on this point before we can > determine if any other consensus call needs to be made here. What was the consensus from the conference call we had about this? Was there any and did we then fail to confirm on the list? > 2. Consensus on adopting generic-naming-attributes. > > 3. No consensus on adopting krb5-pkcross. We can always revisit this in the > future as demand, interest, or resources change. I thought there were similar support/don't-care positions for (2) and (3). What was different in each case? Nico -- From internet-drafts@ietf.org Wed Oct 16 08:33: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 EC20411E82EE; Wed, 16 Oct 2013 08:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fG-Rmirn3-UP; Wed, 16 Oct 2013 08:33:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF9311E817B; Wed, 16 Oct 2013 08:33:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131016153312.32211.9525.idtracker@ietfa.amsl.com> Date: Wed, 16 Oct 2013 08:33:12 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-gssapi-extensions-iana-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 15:33:13 -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 : Namespace Considerations and Registries for GSS-API Exte= nsions Author(s) : Cryptonector LLC Alexey Melnikov Filename : draft-ietf-kitten-gssapi-extensions-iana-08.txt Pages : 10 Date : 2013-10-16 Abstract: This document describes the ways in which the GSS-API may be extended and directs the creation of an IANA registry for various GSS-API namespaces. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-gssapi-extensions-iana There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-gssapi-extensions-iana-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-gssapi-extensions-iana= -08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rra@stanford.edu Wed Oct 16 08:51: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 8C0AE21F9FCA for ; Wed, 16 Oct 2013 08:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKm-JHbMYJnb for ; Wed, 16 Oct 2013 08:51:01 -0700 (PDT) Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by ietfa.amsl.com (Postfix) with ESMTP id A990211E8317 for ; Wed, 16 Oct 2013 08:50:47 -0700 (PDT) Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D0DA91023A2; Wed, 16 Oct 2013 08:50:42 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 8181110241A; Wed, 16 Oct 2013 08:50:35 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 6DA0E2F4C7; Wed, 16 Oct 2013 08:50:35 -0700 (PDT) From: Russ Allbery To: Greg Hudson In-Reply-To: <525D4AC1.9070105@mit.edu> (Greg Hudson's message of "Tue, 15 Oct 2013 10:01:37 -0400") Organization: The Eyrie References: <52545985.70308@mit.edu> <52546AFD.3040207@cs.tcd.ie> <52555F30.2050600@cs.tcd.ie> <525D1EB3.5060900@cs.tcd.ie> <525D4AC1.9070105@mit.edu> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) Date: Wed, 16 Oct 2013 08:50:35 -0700 Message-ID: <87a9i9fc50.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kitten@ietf.org, kitten-ads@tools.ietf.org Subject: Re: [kitten] [RFC Errata System] [Technical Errata Reported] RFC6112 (3743) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 16 Oct 2013 15:51:06 -0000 Greg Hudson writes: > On 10/15/2013 06:53 AM, Stephen Farrell wrote: >> I asked and was asked back: how widely is this one implementation >> deployed? > RFC 6112 was first implemented in MIT krb5 version 1.8, which was > released in March 2010. We never have any solid idea how widely krb5 > features are being used since we don't have a close relationship with > most of our users. I have seen at least one question about anonymous > PKINIT on kerberos@mit.edu, so it's being used at least somewhat. Anonymous PKINIT is supported by my Kerberos PAM module for obtaining FAST armor. I don't know how many people actually use it, though. -- Russ Allbery (rra@stanford.edu) From alexey.melnikov@isode.com Wed Oct 16 09:01: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 2092321F9E4F for ; Wed, 16 Oct 2013 09:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.266 X-Spam-Level: X-Spam-Status: No, score=-103.266 tagged_above=-999 required=5 tests=[AWL=-0.667, 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 JEmCNtbP-1Rc for ; Wed, 16 Oct 2013 09:00:35 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id A987C11E831E for ; Wed, 16 Oct 2013 08:59:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1381939188; d=isode.com; s=selector; i=@isode.com; bh=v2zGuwNWGYFxCQ7UOpigwtjl3PAJ5eWh2tH66CshUXE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Y7pueEc1YtlW7CLvSbc+BxdP2SU/AR9Ls3M7xfoBs+TYWgTVfVgwDoQwSTio1bVtW7hI2h sII5LEIzrgIPtGG4I9s/fONfOBtOZAxFy4tWH6DJS04ts4ZZyjnuN4KYaqzKPNxPawAMOm llZqepjjWRguHCWVuXj/4v1vTQv/n0w=; Received: from [172.16.1.29] (richard.isode.com [62.3.217.249]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 16 Oct 2013 16:59:48 +0100 Message-ID: <525EB7EF.2000808@isode.com> Date: Wed, 16 Oct 2013 16:59:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 To: Benjamin Kaduk References: <50992138.9030200@sunet.se> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "kitten@ietf.org" Subject: Re: [kitten] review of draft-ietf-kitten-gssapi-extensions-iana-07 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 16:01:01 -0000 On 05/08/2013 19:47, Benjamin Kaduk wrote: > On Tue, 6 Nov 2012, Leif Johansson wrote: > >> >> Folks, >> >> I've reviewed version -07. I general I think the document is in good >> shape. >> Reading through it I've found a small set of relatively minor nits. >> >> - Object Type: A long list of things like "Function" and "Integer" is >> given >> but the description text basically sais these are just examples. I >> suggest >> replacing the list with the following text >> >> defined by the binding language >> >> - Registration Rules: Suggest change to say: >> >> " to Policy defined by [RFC5226] or an RFC that >> updates [RFC5226], for instance ..." >> >> Finally, I find the guidelines to Expert reviewers to be somewhat >> hard to >> follow. The final paragraph in section 8.2.2 to me basically reads as >> "use >> your good judgement". >> >> Personally I would find it difficult to draw any guidance from that text >> but I >> fully understand if this horse has been flogged enough. > > I've also reviewed version -07, and don't see anything particularly > objectionable. Hi, Thank you for the review. I believe I addressed most of the editorial comments from you and Leif. > > Minor nits: > > In the table in section 7, in the entry for "Registration Rules", my > first reading left me confused as to which sub-namespace "items that > fall in this sub-namespace" referred to. Re-reading makes it clear > that the sub-namespace is the one which has this Registration Rules > attribute, and I don't have any ideas for how to reword the text to be > clearer. The capitalization of "sub-namespace" is a bit inconsistent > throughout the document. > > The table entry for "Reference" should add an 'a' in "Reference to a > document". > > The "Expert Reviewer" entry is internally inconsistent about how many > reviewers can be listed in a single field. Multiple instances are > allowed, which would seem to indicate that one-reviewer-per-instance > is the correct disambiguation. Yes, this is how it typically works. Do you think this needs to be clarified? > In section 8, the meaning might be more clear with a comma between > "multiple registries" and "each". > > In the first paragraph of 8.2.2, "there is are any IETF Working > Groups" has an unnecessary "is". From kaduk@mit.edu Wed Oct 16 10:12: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 3E45E11E8192 for ; Wed, 16 Oct 2013 10:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHxcRDGp07Fp for ; Wed, 16 Oct 2013 10:12:31 -0700 (PDT) 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 6A49411E8109 for ; Wed, 16 Oct 2013 10:12:31 -0700 (PDT) X-AuditID: 12074422-b7f5a8e000000a34-fe-525ec8febe10 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 6B.09.02612.EF8CE525; Wed, 16 Oct 2013 13:12:30 -0400 (EDT) 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 r9GHCTve014467; Wed, 16 Oct 2013 13:12:30 -0400 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 r9GHCRxI032157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 16 Oct 2013 13:12:28 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r9GHCQcd018372; Wed, 16 Oct 2013 13:12:26 -0400 (EDT) Date: Wed, 16 Oct 2013 13:12:26 -0400 (EDT) From: Benjamin Kaduk To: Alexey Melnikov In-Reply-To: <525EB7EF.2000808@isode.com> Message-ID: References: <50992138.9030200@sunet.se> <525EB7EF.2000808@isode.com> 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+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrPvvRFyQwZxJQhYzVhdZHN28isWB yWPJkp9MHqeaDQOYorhsUlJzMstSi/TtErgynp84zVZwk71izoQb7A2ME9m6GDk5JARMJC70 LmeBsMUkLtxbDxTn4hAS2Mcoce/aT1YIZyOjxNsJS6Eyh5gkrnw5yw7hNDBKfDh5hR2kn0VA W2Lp2Z1gNpuAisTMNxvBdogI6EusfjULbAezgLrEtzNvGEFsYQFvicOtc4FWcHBwCmhKLPyt DhLmFXCQ+LH3LSPE/FZGiV2/W1hBEqICOhKr909hgSgSlDg58wnUTEuJc3+us01gFJyFJDUL SWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXVO93MwSvdSU0k2MoEBld1HawfjzoNIhRgEO RiUe3hnL44KEWBPLiitzDzFKcjApifLqHAMK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuH9tBUo x5uSWFmVWpQPk5LmYFES573FYR8kJJCeWJKanZpakFoEk5Xh4FCS4FUERqSQYFFqempFWmZO CUKaiYMTZDgP0HAOkBre4oLE3OLMdIj8KUZFKXFeFZCEAEgiozQPrheWSF4xigO9IswrA1LF A0xCcN2vgAYzAQ0Wngg2uCQRISXVwNg6f2vkEuveW7yfDt+UT73Qbvfd6sQUPyauk9X3PKK1 XCelJH7Iuvpe6NkGyX3LHR2EV4l2K6d7n+7quTTh+aT+MyJZz6wXPz7U/lakQjAvMuOQ5/XL X3SfCjUK/p+34+h2FlOl00d+7NeZ0yTz7lXaXc0TJp4c4su2q1/+4zbHeyUT76+0zQpKLMUZ iYZazEXFiQBhaLFp/wIAAA== Cc: "kitten@ietf.org" Subject: Re: [kitten] review of draft-ietf-kitten-gssapi-extensions-iana-07 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2013 17:12:41 -0000 On Wed, 16 Oct 2013, Alexey Melnikov wrote: > On 05/08/2013 19:47, Benjamin Kaduk wrote: > >> I've also reviewed version -07, and don't see anything particularly >> objectionable. > > Thank you for the review. I believe I addressed most of the editorial > comments from you and Leif. Thanks. >> The "Expert Reviewer" entry is internally inconsistent about how many >> reviewers can be listed in a single field. Multiple instances are allowed, >> which would seem to indicate that one-reviewer-per-instance is the correct >> disambiguation. > > Yes, this is how it typically works. Do you think this needs to be clarified? Looking back at this, I think I just wanted the text in the "possible values" column for the "expert reviewer" entry to say "Name of expert reviewer" (singular) rather than "Name of expert reviewers" (plural). The description notes that multiple instances of the field are allowed, so everything else would be okay. -Ben From internet-drafts@ietf.org Thu Oct 17 00:19: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 7A90021F9EC4; Thu, 17 Oct 2013 00:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.597 X-Spam-Level: X-Spam-Status: No, score=-102.597 tagged_above=-999 required=5 tests=[AWL=0.003, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gagMsBQzepyV; Thu, 17 Oct 2013 00:19:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B28FD21F9EB6; Thu, 17 Oct 2013 00:19:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131017071942.4820.78473.idtracker@ietfa.amsl.com> Date: Thu, 17 Oct 2013 00:19:42 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-11.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 07:19:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Author(s) : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-11.txt Pages : 22 Date : 2013-10-16 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) 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 shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hannes.tschofenig@gmx.net Thu Oct 17 00:24: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 2DF0221F8C3E for ; Thu, 17 Oct 2013 00:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ALfIsma1rGEJ for ; Thu, 17 Oct 2013 00:24:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 418CE21F8E3D for ; Thu, 17 Oct 2013 00:24:52 -0700 (PDT) Received: from [172.16.254.200] ([80.92.116.76]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0M8axL-1Vizyb3fLn-00wGpG for ; Thu, 17 Oct 2013 09:24:51 +0200 Message-ID: <525F90DF.6020506@gmx.net> Date: Thu, 17 Oct 2013 09:25:19 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:MQGls2h2C8U6Xpgym7IGdidVioHQkAIphpfNZDJ8h28LVoISH8H ayrFyTzuqy0GmfNLX3EQaotImA/jvvWkbTHK86vuFgSUvhddbwGLlLXpPQF5qDv96i1En3b 1cgqa3x7XFi9NomWXciuLVZaNZI0ENge673R9nWPiXlG8wdP66/K6HzKrDCTJuzFOXOjAUj P3bBDcuRo7KSLf9fyKy/Q== Subject: [kitten] draft-ietf-kitten-sasl-oauth-11 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 07:24:57 -0000 Hi all, I have just submitted an updated version of the OAuth SASL draft: http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-11 As discussed earlier I have removed the GSS-API parts due to the problems we found earlier this year. Consequently, the document now only focuses on SASL. I believe that this document is ready to get advanced. Ciao Hannes From shawn.emery@oracle.com Sun Oct 20 23:10: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 CA3E111E8359 for ; Sun, 20 Oct 2013 23:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 VOYETq4O5WVn for ; Sun, 20 Oct 2013 23:10:28 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 34ABD11E8345 for ; Sun, 20 Oct 2013 23:10:28 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9L6ARRw018639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 21 Oct 2013 06:10:27 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9L6AQGo007027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 21 Oct 2013 06:10:27 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9L6AQtY007022 for ; Mon, 21 Oct 2013 06:10:26 GMT Received: from [10.159.83.97] (/10.159.83.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 20 Oct 2013 23:10:26 -0700 Message-ID: <5264C584.2070105@oracle.com> Date: Mon, 21 Oct 2013 00:11:16 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6 MIME-Version: 1.0 To: "kitten@ietf.org" References: <522A3B89.1010307@oracle.com> <525CD0D2.1020504@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [kitten] Consensus Calls X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 06:10:34 -0000 On 10/15/13 05:20 PM, Nico Williams wrote: > On Tue, Oct 15, 2013 at 12:21 AM, Shawn M Emery wrote: >> The consensus results from the 9-6-13 call (ending 9-20-13) was: >> >> 1. Consensus to progress the sasl-oauth draft with the GS2 related text >> removed. However, Nico, had brought up during the call that CB related text >> should also removed until the base GS2 spec allows for mutual authentication >> outside of the mechanism. Alexey had mentioned interest in having this >> support, but this is something that the long-term solution should provide. >> I believe that we need further discussions on this point before we can >> determine if any other consensus call needs to be made here. > What was the consensus from the conference call we had about this? We did not have a consensus call on this during the interim meeting. The question is do you think that we need another consensus call to clarify that; GS2 mechanisms that don't support mutual authentication can not claim support for CB. Therefore such mechanisms can not advertise -PLUS and therefore the draft should remove related text. If this is noncontroversial or implied with the GS2 removal then I don't see the need to have another consensus call related to this. > Was there any and did we then fail to confirm on the list? See above. >> 2. Consensus on adopting generic-naming-attributes. >> >> 3. No consensus on adopting krb5-pkcross. We can always revisit this in the >> future as demand, interest, or resources change. > I thought there were similar support/don't-care positions for (2) and > (3). What was different in each case? There were private responses as well. For reference here were the consensus calls: 1. In regards to draft-ietf-kitten-sasl-oauth; should we remove the GS2 related text from the draft and continue the proceed to shepherd this as an RFC? a. Yes b. No c. Don't care or need more information 2. Should the WG recharter and adopt the draft-williams-kitten-generic-naming-attributes draft? a. Yes b. No c. Don't care or need more information 3. Should the WG recharter and adopt the draft-williams-kitten-krb5-pkcross draft? a. Yes b. No c. Don't care or need more information The following were the results from the consensus calls: 1.a: 8 1.c: 4 2.a: 5 2.c: 5 3.a: 4 3.c: 7 As you can see there were a few people more people that didn't care for the krb5-pkcross. In addition I think that we are having difficulties in gathering resources to do what existing WG items that we have on the charter, as well as fixing the base specification for GS2. I would love to be proved wrong. Shawn. -- From kaduk@mit.edu Mon Oct 21 11:53: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 D150F11E8234 for ; Mon, 21 Oct 2013 11:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XQPjn6XMpLr for ; Mon, 21 Oct 2013 11:53:21 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1936C11E851C for ; Mon, 21 Oct 2013 11:52:28 -0700 (PDT) X-AuditID: 1209190d-b7f528e0000009b4-76-526577ecc65e Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 5B.2A.02484.CE775625; Mon, 21 Oct 2013 14:52:28 -0400 (EDT) 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 r9LIqRUk012499 for ; Mon, 21 Oct 2013 14:52:28 -0400 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 r9LIqPQX030827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 21 Oct 2013 14:52:27 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r9LIqOBq004942; Mon, 21 Oct 2013 14:52:25 -0400 (EDT) Date: Mon, 21 Oct 2013 14:52:24 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> Message-ID: References: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> 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+NgFrrGIsWRmVeSWpSXmKPExsUixCmqrPumPDXI4PJSMYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY/anD2wFLbwVU299Z2xg3MTVxcjJISFgIrF+/VpGCFtM4sK9 9WxdjFwcQgL7GCUmrVjNAuEcZ5S4+nIGM4Rzg0li8+S5jBBOA6NE++vFzCD9LALaElO/fmcH sdkEVCRmvtnIBmKLCAhL7N76DqxGWMBJ4vWlvUA2BwcnkL3qth6IySvgIDFrczVIhZCAo8Tz G11gU0QFdCRW75/CAmLzCghKnJz5BMxmFrCUOPfnOtsERoFZSFKzkKQWMDKtYpRNya3SzU3M zClOTdYtTk7My0st0jXSy80s0UtNKd3ECA4+Sd4djO8OKh1iFOBgVOLhzbRKDRJiTSwrrsw9 xCjJwaQkystZCBTiS8pPqcxILM6ILyrNSS0+xCjBwawkwiuQDJTjTUmsrEotyodJSXOwKInz 3uSwDxISSE8sSc1OTS1ILYLJynBwKEnwzi4DahQsSk1PrUjLzClBSDNxcIIM5wEavgOkhre4 IDG3ODMdIn+KUVFKnHcpSEIAJJFRmgfXC0sOrxjFgV4R5j0DUsUDTCxw3a+ABjMBDXZmBBtc koiQkmpgbFu15twzvciJFl4cO6f5LP7x2dCbecZe7axJfKL5r9bxxu9aOi/iT3ijXV9t1U2O xf+2tm78I//2umfQ9mvXP08zvK/kwHDv1I8tjHvvz2qW5YlkXLXwRej24Ou88TFHgx8Ez87X i3mv+dt4sz2P44m3S65yMJsZn+w9IPyTZ86D7vo/NX+PzlBiKc5INNRiLipOBADLKHli6QIA AA== Subject: [kitten] I-D documenting the structure of the GSS negotiation loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 21 Oct 2013 18:53:27 -0000 Hi all, I asked Nico for review of a draft which included (among other things) a description of the structure of the GSS negotiation loop. Part of the comments I received were that it would be nice to have a separate document that anyone writing a protocol spec using the GSS-API could refer to (instead of having to document the loop for each application protocol). So, here's the -00 version of such a document. Comments welcome! -Ben On Mon, 21 Oct 2013, internet-drafts@ietf.org wrote: > > A new version of I-D, draft-kaduk-kitten-gss-loop-00.txt > has been successfully submitted by Benjamin Kaduk and posted to the > IETF repository. > > Filename: draft-kaduk-kitten-gss-loop > Revision: 00 > Title: Structure of the GSS Negotiation Loop > Creation date: 2013-10-21 > Group: Individual Submission > Number of pages: 9 > URL: http://www.ietf.org/internet-drafts/draft-kaduk-kitten-gss-loop-00.txt > Status: http://datatracker.ietf.org/doc/draft-kaduk-kitten-gss-loop > Htmlized: http://tools.ietf.org/html/draft-kaduk-kitten-gss-loop-00 > > > Abstract: > This document specifies the generic structure of the negotiation loop > to establish a GSS security context between initiator and acceptor. > The control flow of the loop is indicated for both parties, including > error conditions, and indications are given for where application- > specific behavior must be specified. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > From internet-drafts@ietf.org Mon Oct 21 12:02: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 292EC21E809E; Mon, 21 Oct 2013 12:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mp+OmmFTaxQB; Mon, 21 Oct 2013 12:02:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9059011E8557; Mon, 21 Oct 2013 12:00:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.80.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131021190003.32574.46426.idtracker@ietfa.amsl.com> Date: Mon, 21 Oct 2013 12:00:03 -0700 Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-krb-wg-cammac-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.12 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:02:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. Title : Kerberos Authorization Data Container Authenticated by M= ultiple MACs Author(s) : Simo Sorce Tom Yu Thomas Hardjono Filename : draft-ietf-krb-wg-cammac-06.txt Pages : 9 Date : 2013-10-21 Abstract: Abstract: This document specifies a Kerberos Authorization Data container that supersedes AD-KDC-ISSUED. It allows for multiple Message Authentication Codes (MACs) or signatures to authenticate the contained Authorization Data elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-krb-wg-cammac There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-krb-wg-cammac-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-krb-wg-cammac-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From shawn.emery@oracle.com Thu Oct 24 00:47: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 B811911E82F3 for ; Thu, 24 Oct 2013 00:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 KjQhnjoT7HTL for ; Thu, 24 Oct 2013 00:47:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0188411E815C for ; Thu, 24 Oct 2013 00:47:50 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9O7lnk7025643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 24 Oct 2013 07:47:50 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9O7lmrU008152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 24 Oct 2013 07:47:49 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9O7lmYV021615 for ; Thu, 24 Oct 2013 07:47:48 GMT Received: from [10.159.84.125] (/10.159.84.125) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Oct 2013 00:47:48 -0700 Message-ID: <5268D0DC.8090008@oracle.com> Date: Thu, 24 Oct 2013 01:48:44 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20130718 Thunderbird/17.0.6 MIME-Version: 1.0 To: "kitten@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet22.oracle.com [141.146.126.238] Subject: [kitten] IETF 88 - Draft 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: Thu, 24 Oct 2013 07:47:57 -0000 Please provide any additions or updates to the draft agenda posted here: http://www.ietf.org/proceedings/88/agenda/agenda-88-kitten by Monday UTC 24:00. Thanks, Shawn. -- kitten co-chair From ghudson@mit.edu Mon Oct 28 10:03: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 A2FF311E8287 for ; Mon, 28 Oct 2013 10:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovXbs+oU+cVb for ; Mon, 28 Oct 2013 10:03:41 -0700 (PDT) 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 ECCC611E8170 for ; Mon, 28 Oct 2013 10:03:40 -0700 (PDT) X-AuditID: 12074423-b7fc98e0000009a2-20-526e98ec8c1a Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 32.9F.02466.CE89E625; Mon, 28 Oct 2013 13:03:40 -0400 (EDT) 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 r9SH3XuP010636; Mon, 28 Oct 2013 13:03:34 -0400 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r9SH3WoD018062; Mon, 28 Oct 2013 13:03:33 -0400 From: Greg Hudson To: kaduk@mit.edu References: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> Date: Mon, 28 Oct 2013 13:03:13 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUixCmqrPtmRl6QwfEmHoujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY+OdftaCL9wVzxp3szYw3uLsYuTkkBAwkbi35Q4jhC0mceHe erYuRi4OIYF9jBInjx5lhXA2MkosPbefHcL5xCix4OZvZpAWNgFliYNnv7GA2CICghKv9j9k A7GZBYQllq85C2YLC/hL3DzfCGYLCThKPL/RxQ5iswioSuzte84EYvMKGEpsPnqAGcIWlDg5 8wkLxBwtiRv/XjJNYOSbhSQ1C0lqASPTKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0zvdzMEr3U lNJNjKBwYndR3sH456DSIUYBDkYlHt4Na3ODhFgTy4orcw8xSnIwKYnyak7KCxLiS8pPqcxI LM6ILyrNSS0+xCjBwawkwhsLkuNNSaysSi3Kh0lJc7AoifPe4rAPEhJITyxJzU5NLUgtgsnK cHAoSfAumA7UKFiUmp5akZaZU4KQZuLgBBnOAzS8DaSGt7ggMbc4Mx0if4pRUUqcdz1IQgAk kVGaB9cLi/dXjOJArwjzLgOp4gGmCrjuV0CDmYAG72EBG1ySiJCSamDsP3H3QsS/pKkiWxac UHrYLrh6RX24k2RTR8HVhwz+8zf92v5IyG6pqcLN+NxOnTUlLt3McYJbJk6+11ASs0su7/v9 valCErlPU5xvGVf5Fi6axOB4QuPnCv5XFQdS55pPMdV5vlMj8ZRVj32h34zJf8pC+lJltjDw KhcWJL7dxqnpblChH63EUpyRaKjFXFScCAAfEk+e0gIAAA== Cc: kitten@ietf.org Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2013 17:03:47 -0000 Here are a couple of issues Ben and I discussed before the draft was submitted, which Ben thought we could use list input on: 1. Overlap with 2743 It wasn't immediately clear to me whether this draft is a distillation of RFC 2743 or whether it imposes new requirements. I think there might be some new requirements (like "The initiator MUST NOT change any of the input parameters to GSS_Init_sec_context() between calls", while 2743 only mentions the claimant_cred_handle parameter), but they aren't differentiated from repeated requirements. 2. Handling of impossible situations Sections 2.2 and 2.5 describe what the application "SHOULD" do if GSSAPI returns GSS_S_CONTINUE_NEEDED from init/accept_sec_context with an empty output token. This is a nonsense answer from the GSS implementation, indicative of a serious bug, and I don't think a spec like this needs to describe what applications should do in the face of bugs. I think most applications I have seen will just send an empty token to the other side, which will reject it, and that's not a problem. 3. Example code The draft is written completely at the RFC 2743 level, independent of language bindings. I was sort of expecting a draft like this to have example code using the C bindings. There is already example code for gss_init_sec_context and gss_accept_sec_context in RFC 2744, but it could perhaps be improved to cover some of the statements in the draft, like checking ret_flags after the context is established. From simo@redhat.com Mon Oct 28 10:38: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 537F821F9D05 for ; Mon, 28 Oct 2013 10:37:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Vp58eQ5Epln for ; Mon, 28 Oct 2013 10:37:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 85E7121F9CC2 for ; Mon, 28 Oct 2013 10:37:06 -0700 (PDT) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9SHb5D3024298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Oct 2013 13:37:05 -0400 Received: from [10.3.113.17] ([10.3.113.17]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r9SHb4g8023441; Mon, 28 Oct 2013 13:37:04 -0400 From: Simo Sorce To: Greg Hudson In-Reply-To: References: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Mon, 28 Oct 2013 13:37:03 -0400 Message-ID: <1382981823.899.196.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: kitten@ietf.org Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2013 17:38:03 -0000 On Mon, 2013-10-28 at 13:03 -0400, Greg Hudson wrote: > Here are a couple of issues Ben and I discussed before the draft was > submitted, which Ben thought we could use list input on: > > 1. Overlap with 2743 > > It wasn't immediately clear to me whether this draft is a distillation > of RFC 2743 or whether it imposes new requirements. I think there might > be some new requirements (like "The initiator MUST NOT change any of the > input parameters to GSS_Init_sec_context() between calls", while 2743 > only mentions the claimant_cred_handle parameter), but they aren't > differentiated from repeated requirements. > > 2. Handling of impossible situations > > Sections 2.2 and 2.5 describe what the application "SHOULD" do if GSSAPI > returns GSS_S_CONTINUE_NEEDED from init/accept_sec_context with an empty > output token. This is a nonsense answer from the GSS implementation, > indicative of a serious bug, and I don't think a spec like this needs to > describe what applications should do in the face of bugs. I think most > applications I have seen will just send an empty token to the other > side, which will reject it, and that's not a problem. Just FYI: The NTLM mechanism can do this (empty token) in "connectionless mode", and it is not a bug, the server will not reject it, but create an appropriate reply token. Simo. -- Simo Sorce * Red Hat, Inc * New York From nico@cryptonector.com Mon Oct 28 10:40: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 8ED6C21F9D05 for ; Mon, 28 Oct 2013 10:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 3JNHT3kLEhom for ; Mon, 28 Oct 2013 10:40:38 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 44B4221F9CAE for ; Mon, 28 Oct 2013 10:40:32 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id 327D126C078; Mon, 28 Oct 2013 10:40:31 -0700 (PDT) Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 8CFA326C06F; Mon, 28 Oct 2013 10:40:30 -0700 (PDT) Date: Mon, 28 Oct 2013 12:40:26 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20131028174023.GB15988@gmail.com> References: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kitten@ietf.org Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2013 17:40:43 -0000 On Mon, Oct 21, 2013 at 02:52:24PM -0400, Benjamin Kaduk wrote: > I asked Nico for review of a draft which included (among other > things) a description of the structure of the GSS negotiation loop. > Part of the comments I received were that it would be nice to have a > separate document that anyone writing a protocol spec using the > GSS-API could refer to (instead of having to document the loop for > each application protocol). So, here's the -00 version of such a > document. Comments welcome! Thanks for doing this! > >URL: http://www.ietf.org/internet-drafts/draft-kaduk-kitten-gss-loop-00.txt > >Status: http://datatracker.ietf.org/doc/draft-kaduk-kitten-gss-loop > >Htmlized: http://tools.ietf.org/html/draft-kaduk-kitten-gss-loop-00 I'll review later today in detail. I think pseudo-code would be nice to have. I don't mind if it's synchronous-looking pesudo-code: between threadlets (the JavaScript literature is filled to the brim, and long ago spilled, with libraries along these lines) and such, and programmers who know how to turn synchronous code into async code, I don't think that's a problem. I realize that normative text is also desirable, but we already have it: in RFC2743. So for an informative I-D I think pseudo-code would be very good to have, and since we have C code in RFC2744, it shouldn't be difficult to adapt. Also, given that we have consensus for the channel-bound flag extension that introduces a stepper model, I think we'll need to do this again... Nico -- From ghudson@mit.edu Mon Oct 28 10:56: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 04BD011E8290 for ; Mon, 28 Oct 2013 10:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 wPE90diChCnf for ; Mon, 28 Oct 2013 10:56:19 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) by ietfa.amsl.com (Postfix) with ESMTP id CC16B11E819B for ; Mon, 28 Oct 2013 10:56:17 -0700 (PDT) X-AuditID: 12074424-b7f528e0000009aa-fd-526ea541a3d5 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 5E.FC.02474.145AE625; Mon, 28 Oct 2013 13:56:17 -0400 (EDT) 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 r9SHuG2t003760; Mon, 28 Oct 2013 13:56:16 -0400 Received: from [18.101.8.138] (vpn-18-101-8-138.mit.edu [18.101.8.138]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r9SHuDNR008987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Oct 2013 13:56:15 -0400 Message-ID: <526EA53D.7040707@mit.edu> Date: Mon, 28 Oct 2013 13:56:13 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: Simo Sorce References: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> <1382981823.899.196.camel@willson.li.ssimo.org> In-Reply-To: <1382981823.899.196.camel@willson.li.ssimo.org> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1nVcmhdk0H6Jx+Lo5lUsFj/mLmJ1 YPJYsuQnk8f7fVfZApiiuGxSUnMyy1KL9O0SuDIWzNjJWjCVp2Jvu3oD43POLkZODgkBE4n/ nV3sELaYxIV769m6GLk4hAT2MUr0LWphhnA2Mkr0/t7NDuEcYZI4ee8CWAuvgJrExYWvmEBs FgFViYcf3rCB2GwCyhIHz35jAbFFBYIkjm+dwARRLyhxcuYTsLiIgILEgv47YDazgLDEhe17 WUFsYYFAibubPjFBLJvBKHF4/Q+woZwCNhKHpnQxQ9wqKbFt0TGgIziAmtUl1s8TgpgjL7H9 7RzmCYxCs5Csm4VQNQtJ1QJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW65nq5mSV6qSmlmxhB Yc3uorKDsfmQ0iFGAQ5GJR7eiNW5QUKsiWXFlbmHGCU5mJREeZ8vzAsS4kvKT6nMSCzOiC8q zUktPsQowcGsJMIbOwkox5uSWFmVWpQPk5LmYFES573FYR8kJJCeWJKanZpakFoEk5Xh4FCS 4OVbAtQoWJSanlqRlplTgpBm4uAEGc4DNPzgYpDhxQWJucWZ6RD5U4yKUuK8WiDNAiCJjNI8 uF5Y2nnFKA70ijCvOEgVDzBlwXW/AhrMBDR4DwvY4JJEhJRUA+PSTWt3f5i3JvzPCh3pSC6N 9CtTX8aJ+nUYpgu0yIZdfGp35UnR7PfJOjt/rDZonrVtsvmBpqNnArqy+a18Fz4uP8Mx6zOz kMLLtddn6q5fFt92ybK+PLEz6s2cm9uTC3mvz0sSzjcV9dDlbYxbbMGeu/n9sbwVGRadT57/ 8dp0d/aTIC2NS75KLMUZiYZazEXFiQC3JFErFgMAAA== Cc: kitten@ietf.org Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2013 17:56:27 -0000 On 10/28/2013 01:37 PM, Simo Sorce wrote: >> Sections 2.2 and 2.5 describe what the application "SHOULD" do if GSSAPI >> returns GSS_S_CONTINUE_NEEDED from init/accept_sec_context with an empty >> output token. This is a nonsense answer from the GSS implementation, >> indicative of a serious bug, and I don't think a spec like this needs to >> describe what applications should do in the face of bugs. I think most >> applications I have seen will just send an empty token to the other >> side, which will reject it, and that's not a problem. > > Just FYI: > The NTLM mechanism can do this (empty token) in "connectionless mode", > and it is not a bug, the server will not reject it, but create an > appropriate reply token. That violates RFC 2744, although 2743 doesn't say anything about it that I can find. See the description of output_token in RFC 2744 section 5.1 (in the free-form text, the example code, and the parameter list) and section 5.19. Note that for a GSS_S_COMPLETE result, the emptiness or non-emptiness of output_token indicates whether there is a token to be sent, and there is no other way for an application to know. For a GSS_S_CONTINUE_NEEDED result, an application could assume that the token must always be sent(*), but RFC 2744 doesn't tell applications to do so and doesn't do so in its own example code. (*) Actually, while I have always made the assumption that mech tokens must alternate between initiator and acceptor, I'm not sure whether that requirement is written down anywhere. From simo@redhat.com Mon Oct 28 11:08: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 3FA7A21E80BF for ; Mon, 28 Oct 2013 11:08:21 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQkxce+Cc-mD for ; Mon, 28 Oct 2013 11:08:15 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9E38321E80B1 for ; Mon, 28 Oct 2013 11:07:50 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9SI7VQf003467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Oct 2013 14:07:32 -0400 Received: from [10.3.113.17] ([10.3.113.17]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r9SI7V6s002474; Mon, 28 Oct 2013 14:07:31 -0400 From: Simo Sorce To: Greg Hudson In-Reply-To: <526EA53D.7040707@mit.edu> References: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> <1382981823.899.196.camel@willson.li.ssimo.org> <526EA53D.7040707@mit.edu> Content-Type: text/plain; charset="UTF-8" Organization: Red Hat, Inc. Date: Mon, 28 Oct 2013 14:07:30 -0400 Message-ID: <1382983650.899.205.camel@willson.li.ssimo.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 Cc: kitten@ietf.org Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2013 18:08:22 -0000 On Mon, 2013-10-28 at 13:56 -0400, Greg Hudson wrote: > On 10/28/2013 01:37 PM, Simo Sorce wrote: > >> Sections 2.2 and 2.5 describe what the application "SHOULD" do if GSSAPI > >> returns GSS_S_CONTINUE_NEEDED from init/accept_sec_context with an empty > >> output token. This is a nonsense answer from the GSS implementation, > >> indicative of a serious bug, and I don't think a spec like this needs to > >> describe what applications should do in the face of bugs. I think most > >> applications I have seen will just send an empty token to the other > >> side, which will reject it, and that's not a problem. > > > > Just FYI: > > The NTLM mechanism can do this (empty token) in "connectionless mode", > > and it is not a bug, the server will not reject it, but create an > > appropriate reply token. > > That violates RFC 2744, although 2743 doesn't say anything about it that > I can find. See the description of output_token in RFC 2744 section 5.1 > (in the free-form text, the example code, and the parameter list) and > section 5.19. > > Note that for a GSS_S_COMPLETE result, the emptiness or non-emptiness of > output_token indicates whether there is a token to be sent, and there is > no other way for an application to know. For a GSS_S_CONTINUE_NEEDED > result, an application could assume that the token must always be > sent(*), but RFC 2744 doesn't tell applications to do so and doesn't do > so in its own example code. > > (*) Actually, while I have always made the assumption that mech tokens > must alternate between initiator and acceptor, I'm not sure whether that > requirement is written down anywhere. In NTLMSSP this happens only in the first initiate in the client, and GSS_S_CONTINUE_NEEDED is returned. It is never the case if GSS_S_COMPLETE is returned of course. Simo. -- Simo Sorce * Red Hat, Inc * New York From jhutz@cmu.edu Mon Oct 28 11:09: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 3ECF121E80A8 for ; Mon, 28 Oct 2013 11:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 QCLTt9-DAJEF for ; Mon, 28 Oct 2013 11:09:39 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 893D821E80AB for ; Mon, 28 Oct 2013 11:09:31 -0700 (PDT) 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 r9SI9NAq025032 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 28 Oct 2013 14:09:24 -0400 (EDT) Message-ID: <1382983763.4490.33.camel@minbar.fac.cs.cmu.edu> From: Jeffrey Hutzelman To: Greg Hudson Date: Mon, 28 Oct 2013 14:09:23 -0400 In-Reply-To: <28192_1382982990_r9SHuTuu003419_526EA53D.7040707@mit.edu> References: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> <1382981823.899.196.camel@willson.li.ssimo.org> <28192_1382982990_r9SHuTuu003419_526EA53D.7040707@mit.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.198 Cc: kitten@ietf.org, Simo Sorce , jhutz@cmu.edu Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2013 18:09:45 -0000 On Mon, 2013-10-28 at 13:56 -0400, Greg Hudson wrote: > On 10/28/2013 01:37 PM, Simo Sorce wrote: > >> Sections 2.2 and 2.5 describe what the application "SHOULD" do if GSSAPI > >> returns GSS_S_CONTINUE_NEEDED from init/accept_sec_context with an empty > >> output token. This is a nonsense answer from the GSS implementation, > >> indicative of a serious bug, and I don't think a spec like this needs to > >> describe what applications should do in the face of bugs. I think most > >> applications I have seen will just send an empty token to the other > >> side, which will reject it, and that's not a problem. > > > > Just FYI: > > The NTLM mechanism can do this (empty token) in "connectionless mode", > > and it is not a bug, the server will not reject it, but create an > > appropriate reply token. > > That violates RFC 2744, although 2743 doesn't say anything about it that > I can find. See the description of output_token in RFC 2744 section 5.1 > (in the free-form text, the example code, and the parameter list) and > section 5.19. > > Note that for a GSS_S_COMPLETE result, the emptiness or non-emptiness of > output_token indicates whether there is a token to be sent, and there is > no other way for an application to know. For a GSS_S_CONTINUE_NEEDED > result, an application could assume that the token must always be > sent(*), but RFC 2744 doesn't tell applications to do so and doesn't do > so in its own example code. > > (*) Actually, while I have always made the assumption that mech tokens > must alternate between initiator and acceptor, I'm not sure whether that > requirement is written down anywhere. It effectively is -- once you call gss_init_sec_context, in order to get the input token for the next call, someone must call gss_accept_sec_context, and vice versa. -- Jeff From nico@cryptonector.com Mon Oct 28 11:25: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 C2CD221E8090 for ; Mon, 28 Oct 2013 11:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 LWo0yoj73EcE for ; Mon, 28 Oct 2013 11:25:50 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 4F56F21E80AA for ; Mon, 28 Oct 2013 11:25:48 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id AE5042005D90C; Mon, 28 Oct 2013 11:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=eMh3RXlGSRu9d1 ezhI2wgrGhvIo=; b=cmAiEeuP3AOZUQYlHWdfhn6gs+sYK+1tSJ3KS303c0FOsx wznc0nrfVdISEKArbrvcyQNdlcBdLr8ii3txZRWj/BXH1lm3He2HNJ0ZzVn51Lsl WP8B86P72it0HnrNaGuR3rrHhCFF4Af8szH69hP1oIRaon7yFJF9EVsSYnwuI= Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id 4DB4F2005D90A; Mon, 28 Oct 2013 11:25:47 -0700 (PDT) Date: Mon, 28 Oct 2013 13:25:44 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20131028182541.GC15988@gmail.com> References: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> <1382981823.899.196.camel@willson.li.ssimo.org> <526EA53D.7040707@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <526EA53D.7040707@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kitten@ietf.org, Simo Sorce Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2013 18:25:55 -0000 On Mon, Oct 28, 2013 at 01:56:13PM -0400, Greg Hudson wrote: > (*) Actually, while I have always made the assumption that mech tokens > must alternate between initiator and acceptor, I'm not sure whether that > requirement is written down anywhere. I'm certain that either it is or it's strongly implied. There's PROT_READY as well, but that factors out in prose. That is, the exchange of security context tokens absolutely must be synchronous, first one from the initiator, then one from the acceptor, then back to the initiator, and so on until complete or failure. Per-message tokens may be produced/consumed before full security context establishment if the security context is PROT_READY before it is established, and these are not required to be exchanged synchronously. But in that case the remaining security context tokens needed to get to fully-established (or failure) state must be exchange synchronously nonetheless. And any security context token must be consumed before per-msg tokens produced *after* producing the same security context token. Zero-length tokens are not allowed and/or they are indistinguishable from absent tokens (depending on the bindings). Zero-length inputs to GSS_Wrap() and GSS_GetMIC(), and zero-length outputs from GSS_Unwrap(), *are* allowed, but these aren't tokens. Nico -- From nico@cryptonector.com Mon Oct 28 11:32: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 164DA21E80C9 for ; Mon, 28 Oct 2013 11:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[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 0fHOcyjsfGSJ for ; Mon, 28 Oct 2013 11:32:35 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6D36021E80C0 for ; Mon, 28 Oct 2013 11:32:19 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id AC8AE1DE085; Mon, 28 Oct 2013 11:32:05 -0700 (PDT) Received: from gmail.com (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id B1B811DE13C; Mon, 28 Oct 2013 11:28:43 -0700 (PDT) Date: Mon, 28 Oct 2013 13:28:35 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20131028182832.GD15988@gmail.com> References: <20131021184135.32548.11906.idtracker@ietfa.amsl.com> <1382981823.899.196.camel@willson.li.ssimo.org> <526EA53D.7040707@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <526EA53D.7040707@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kitten@ietf.org, Simo Sorce Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2013 18:32:41 -0000 On Mon, Oct 28, 2013 at 01:56:13PM -0400, Greg Hudson wrote: > On 10/28/2013 01:37 PM, Simo Sorce wrote: > > Just FYI: > > The NTLM mechanism can do this (empty token) in "connectionless mode", > > and it is not a bug, the server will not reject it, but create an > > appropriate reply token. > > That violates RFC 2744, although 2743 doesn't say anything about it that > I can find. See the description of output_token in RFC 2744 section 5.1 > (in the free-form text, the example code, and the parameter list) and > section 5.19. Note that NTLMSSP is not a standard GSS-API mechanism anyways (e.g., it lacks the ASN.1 mechanism OID header on the initial context token). But we might need to make allowance for such mechanisms. In particular we might need to allow for an empty (or constant) initial security context token in the case that the mechanism is an adaptation of -say- a SASL server-goes-first mechanism. Ben's I-D should point this out. Nico -- From nkinder@redhat.com Mon Oct 28 12: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 8242321E80DF for ; Mon, 28 Oct 2013 12:03:36 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yG0lSOjKwZSa for ; Mon, 28 Oct 2013 12:03:32 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id A8E2721E80F2 for ; Mon, 28 Oct 2013 12:03:22 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9SJ3MmS024121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 28 Oct 2013 15:03:22 -0400 Received: from localhost.localdomain ([10.14.19.158]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r9SJ3LtQ030149 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 28 Oct 2013 15:03:21 -0400 Message-ID: <526EB4F9.9000007@redhat.com> Date: Mon, 28 Oct 2013 12:03:21 -0700 From: Nathan Kinder User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: kitten@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Subject: [kitten] New draft submitted for "Authentication Indicator in Kerberos tickets" X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.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, 28 Oct 2013 19:03:36 -0000 Hi, I submitted a new draft to IETF last week that seems to fit into the charter for this working group. The draft is for adding an indicator of the authentication used into Kerberos tickets. The draft is available here: http://tools.ietf.org/html/draft-jain-kitten-krb-auth-indicator-00 Please take a look at it and let me know if you have any feedback. Thanks, -NGK From mrex@sap.com Mon Oct 28 12:10: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 6702211E819F for ; Mon, 28 Oct 2013 12:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.076 X-Spam-Level: X-Spam-Status: No, score=-10.076 tagged_above=-999 required=5 tests=[AWL=0.173, 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 5ISSB6u9V3Gk for ; Mon, 28 Oct 2013 12:10:53 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 04A1221F9ED4 for ; Mon, 28 Oct 2013 12:10:52 -0700 (PDT) Received: from mail06.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r9SJAlc9014789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 28 Oct 2013 20:10:47 +0100 (MET) In-Reply-To: <20131028182832.GD15988@gmail.com> To: Nico Williams Date: Mon, 28 Oct 2013 20:10:47 +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: <20131028191047.B65381AA39@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: kitten@ietf.org, Simo Sorce Subject: Re: [kitten] I-D documenting the structure of the GSS negotiation loop 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, 28 Oct 2013 19:10:58 -0000 Nico Williams wrote: > On Mon, Oct 28, 2013 at 01:56:13PM -0400, Greg Hudson wrote: > > On 10/28/2013 01:37 PM, Simo Sorce wrote: > > > Just FYI: > > > The NTLM mechanism can do this (empty token) in "connectionless mode", > > > and it is not a bug, the server will not reject it, but create an > > > appropriate reply token. > > > > That violates RFC 2744, although 2743 doesn't say anything about it that > > I can find. See the description of output_token in RFC 2744 section 5.1 > > (in the free-form text, the example code, and the parameter list) and > > section 5.19. > > Note that NTLMSSP is not a standard GSS-API mechanism anyways (e.g., it > lacks the ASN.1 mechanism OID header on the initial context token). Keep in mind that the generic framing is a requirement for the initial context token. So it is incompatible with GSS-API to have an empty context token emitted by the first call to gss_init_sec_context(). > > But we might need to make allowance for such mechanisms. In particular > we might need to allow for an empty (or constant) initial security > context token in the case that the mechanism is an adaptation of -say- a > SASL server-goes-first mechanism. I don't think that this makes an argument for having gss_init_sec_context emit an empty token on first call. Asking whether gss_accept_sec_context should be permitted to not fail when no token is supplied in the first iteration call looks like a different question to me. For a gssapi mechanism that starts the handshake on the initiator side, defining an initial context token intitiator->acceptor hat has the generic framing should always be possible, even if there is no substantial mechanism data inside, and the primary purpose is to pass the ball to the acceptor. SPNEGO will also likely be unable to deal with a zero-length initial token from gss_init_sec_context() (and recognizing whether there is an optimistic token present). -Martin From michikos@microsoft.com Tue Oct 29 14:20: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 99B4711E81C9 for ; Tue, 29 Oct 2013 14:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwfrc9pLbnzB for ; Tue, 29 Oct 2013 14:19:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id A72C021E8087 for ; Tue, 29 Oct 2013 14:19:53 -0700 (PDT) Received: from BLUPR03CA033.namprd03.prod.outlook.com (10.141.30.26) by BLUPR03MB066.namprd03.prod.outlook.com (10.255.209.154) with Microsoft SMTP Server (TLS) id 15.0.785.10; Tue, 29 Oct 2013 21:19:51 +0000 Received: from BY2FFO11FD006.protection.gbl (2a01:111:f400:7c0c::187) by BLUPR03CA033.outlook.office365.com (2a01:111:e400:879::26) with Microsoft SMTP Server (TLS) id 15.0.785.10 via Frontend Transport; Tue, 29 Oct 2013 21:19:52 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.0.805.12 via Frontend Transport; Tue, 29 Oct 2013 21:19:51 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.109]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0158.002; Tue, 29 Oct 2013 21:18:47 +0000 From: Michiko Short To: "kitten@ietf.org" Thread-Topic: Request for summary of issues with existing AES-CTS with new SHA2 Thread-Index: Ac7U7AyPw5IckBFDS8WKQUaiQqCs1g== Date: Tue, 29 Oct 2013 21:18:47 +0000 Message-ID: <5674376E76F88641AD3748A64F0996971AE76A8B@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_5674376E76F88641AD3748A64F0996971AE76A8BTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054003)(189002)(199002)(49866001)(47736001)(63696002)(83322001)(83072001)(66066001)(54356001)(74502001)(47446002)(80022001)(15202345003)(65816001)(47976001)(50986001)(512954002)(55846006)(15975445006)(19580395003)(81816001)(84326002)(74706001)(44976005)(87266001)(46102001)(74366001)(85306002)(51856001)(53806001)(20776003)(4396001)(71186001)(76482001)(81686001)(54316002)(77096001)(6806004)(69226001)(56776001)(74876001)(31966008)(79102001)(19300405004)(80976001)(76176001)(74662001)(81542001)(33656001)(76796001)(59766001)(76786001)(77982001)(56816003)(16236675002)(81342001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB066; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0014E2CF50 X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com Cc: Anoosh Saboori Subject: [kitten] Request for summary of issues with existing AES-CTS with new 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: Tue, 29 Oct 2013 21:20:00 -0000 --_000_5674376E76F88641AD3748A64F0996971AE76A8BTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can someone summarize what the issues blocking using the existing AES-CTS w= ith SHA2? We have had several discussions over the past months discussing v= arious aspects, but it is unclear to me what the blockers were that makes w= hat we all implemented for SHA1 not feasible for SHA2. Thanks, Michiko Short | Program Manager | Windows Security & Identity --_000_5674376E76F88641AD3748A64F0996971AE76A8BTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can someone summarize what the issues blocking using= the existing AES-CTS with SHA2? We have had several discussions over the p= ast months discussing various aspects, but it is unclear to me what the blo= ckers were that makes what we all implemented for SHA1 not feasible for SHA2.

 

 

Thanks,

Michiko Short | Program Manager | Windows Security &am= p; Identity

 

--_000_5674376E76F88641AD3748A64F0996971AE76A8BTK5EX14MBXC283r_-- From mpeck@mitre.org Wed Oct 30 07:33: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 44BD011E8171 for ; Wed, 30 Oct 2013 07:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1ruzOj2s1KM for ; Wed, 30 Oct 2013 07:33:30 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D838D11E8318 for ; Wed, 30 Oct 2013 07:33:14 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BE36F1F049F; Wed, 30 Oct 2013 10:33:06 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A5E841F02B2; Wed, 30 Oct 2013 10:33:06 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.201]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0158.001; Wed, 30 Oct 2013 10:33:06 -0400 From: "Peck, Michael A" To: Michiko Short , "kitten@ietf.org" Thread-Topic: [kitten] Request for summary of issues with existing AES-CTS with new SHA2 Thread-Index: AQHO1Xzy3XvLZLzrRk256cbeIFwZRg== Date: Wed, 30 Oct 2013 14:33:05 +0000 Message-ID: In-Reply-To: <5674376E76F88641AD3748A64F0996971AE76A8B@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [128.29.194.119] Content-Type: multipart/alternative; boundary="_000_CE968B118849mpeckmitreorg_" MIME-Version: 1.0 Cc: Anoosh Saboori Subject: Re: [kitten] Request for summary of issues with existing AES-CTS with new 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, 30 Oct 2013 14:33:35 -0000 --_000_CE968B118849mpeckmitreorg_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Michiko, First, regarding the CTS vs. CBC with PKCS#7 padding question, we the docum= ent editors are of course happy to go along with whatever consensus the wor= king group comes to. Our latest CTS-based draft is at: http://tools.ietf.org/html/draft-ietf-kit= ten-aes-cts-hmac-sha2-01 Our latest CBC with PKCS#7 padding draft is at: http://tools.ietf.org/html/= draft-ietf-kitten-aes-cbc-hmac-sha2-00 In the Introduction of both drafts we have a section describing the differe= nces between them and the existing Kerberos AES specification (RFC 3961/396= 2). Our goal was to update to SHA2 and also follow current best cryptographic p= ractices. For example, unlike RFC3961 we follow the current best practice of Encrypt-= then-MAC. For CTS, we use the definition in the NIST Special Publication 800-38A Adde= ndum, which uses an explicit IV instead of a confounder. Unfortunately the NIST definition doesn=92t deal with plaintext lengths equ= al to or less than the AES block size, so we added text in Section 5 to cov= er that situation for completeness, even if it might never happen in realit= y. The CTS draft states: * The pseudorandom function used by PBKDF2 is HMAC-SHA-256 or HMAC- SHA-384. * A key derivation function from [SP800-108] which uses the SHA-2= 56 or SHA-384 hash algorithm is used to produce keys for encryption, integrity protection, and checksum operations. * The IV used during content encryption is sent as part of the ciphertext, instead of using a confounder. This saves one encryption and decryption operation per message. * The HMAC is calculated over the AES output, instead of being calculated over the plaintext. This allows the message receiver to verify the integrity of the message before decrypting the message. * The HMAC algorithm uses the SHA-256 or SHA-384 hash algorithm for integrity protection and checksum operations. From: Michiko Short > Date: Tuesday, October 29, 2013 5:18 PM To: "kitten@ietf.org" > Cc: Anoosh Saboori > Subject: [kitten] Request for summary of issues with existing AES-CTS with = new SHA2 Can someone summarize what the issues blocking using the existing AES-CTS w= ith SHA2? We have had several discussions over the past months discussing v= arious aspects, but it is unclear to me what the blockers were that makes w= hat we all implemented for SHA1 not feasible for SHA2. Thanks, Michiko Short | Program Manager | Windows Security & Identity --_000_CE968B118849mpeckmitreorg_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Michiko,

First, regarding the CTS vs. CBC with PKCS#7 padding question, we the docum= ent editors are of course happy to go along with whatever consensus the wor= king group comes to.  
Our latest CBC with PKCS#7 padding draft is at: http://tools.ietf.o= rg/html/draft-ietf-kitten-aes-cbc-hmac-sha2-00

In the Introduction of both drafts we have a section describing the differe= nces between them and the existing Kerberos AES specification (RFC 3961/396= 2).  
Our goal was to update to SHA2 and also follow current best cryptographic p= ractices.
For example, unlike RFC3961 we follow the current best practice of Encrypt-= then-MAC.
For CTS, we use the definition in the NIST Special Publication 800-38A Adde= ndum, which uses an explicit IV instead of a confounder.
Unfortunately the NIST definition doesn=92t deal with plaintext lengths equ= al to or less than the AES block size, so we added text in Section 5 to cov= er that situation for completeness, even if it might never happen in realit= y.

The CTS draft states:

From: Michiko Short <michikos@microsoft.com>
Date: Tuesday, October 29, 2013 5:1= 8 PM
To: "kitten@ietf.org" <= kitten@ietf.org>
Cc: Anoosh Saboori <ansaboor@microsoft.com>
Subject: [kitten] Request for summa= ry of issues with existing AES-CTS with new SHA2

Can someone summarize what the issues blocking using= the existing AES-CTS with SHA2? We have had several discussions over the p= ast months discussing various aspects, but it is unclear to me what the blo= ckers were that makes what we all implemented for SHA1 not feasible for SHA2.

 

 

Thanks,

Michiko Short | Program Manager | Windows Security &am= p; Identity

 

--_000_CE968B118849mpeckmitreorg_--