From nobody Wed Apr 1 09:30:42 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A991ACEF3 for ; Wed, 1 Apr 2015 09:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnhIdrgHayHL for ; Wed, 1 Apr 2015 09:30:39 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B9011A90D2 for ; Wed, 1 Apr 2015 09:30:39 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-fc-551c1d2d9427 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 69.F0.03700.D2D1C155; Wed, 1 Apr 2015 12:30:37 -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 t31GUa8a012339; Wed, 1 Apr 2015 12:30:37 -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 t31GUZdf009942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Apr 2015 12:30:36 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t31GUYUg001934; Wed, 1 Apr 2015 12:30:34 -0400 (EDT) Date: Wed, 1 Apr 2015 12:30:34 -0400 (EDT) From: Benjamin Kaduk To: Tom Yu In-Reply-To: Message-ID: References: <962591069.3713128.1427479391512.JavaMail.yahoo@mail.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6noqsrKxNq0NhlYXF08yoWi29d15kd mDyWLPnJ5DFr1mGmAKYoLpuU1JzMstQifbsEroyHbUsZCyaJV+y9soylgbFbsIuRk0NCwERi Rct/RghbTOLCvfVsXYxcHEICi5kk1jy4C5YQEtjAKLHpujhE4iCTxM+DK5kgEvUSS272s4PY LAJaEm8+NrGB2GwCKhIz32wEs0UEJCWOPTnPDGIzC7hIrPzxFqxeWCBR4s2DbjCbU0BPoml2 M1gNr4CjxP2Vz1ghlh1llNjbfBSsSFRAR2L1/iksEEWCEidnPmGBGKolsXz6NpYJjIKzkKRm IUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGuml5tZopeaUrqJERyqLso7GP8cVDrEKMDB qMTD2xAlHSrEmlhWXJl7iFGSg0lJlPempEyoEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFeSRGg HG9KYmVValE+TEqag0VJnHfTD74QIYH0xJLU7NTUgtQimKwMB4eSBK+wDFCjYFFqempFWmZO CUKaiYMTZDgP0PD90iDDiwsSc4sz0yHypxgVpcR5pUCaBUASGaV5cL2wVPKKURzoFWHeIyDt PMA0BNf9CmgwE9Bgh3nSIINLEhFSUg2MwpZWGrY1xu8m/5H7/sryRK5sya2cWRPPLtP9tPHt th0M3IHffu2uOe0c/X9tbhbPqoUsE1L8TZROn112OjLdRIrnXYDw//ny+85FvvBzFoj635pn aHIj47LXHOMLDQFRJeeWnWOsV7zGO/dPeqRKwiVnOWX77Dy++Y+W7LpQtn9KhM0TjtWJSizF GYmGWsxFxYkADfftIwADAAA= Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:30:41 -0000 On Tue, 31 Mar 2015, Tom Yu wrote: > Here are the KDF OID related changes that I think should happen to the > algorithm agility draft. > > Change the Appendix A ASN.1 module IMPORTS subclause that mentions > PK-INIT-SPEC from > > PKAuthenticator, DHNonce > FROM KerberosV5-PK-INIT-SPEC { > iso(1) identified-organization(3) dod(6) internet(1) > security(5) kerberosV5(2) modules(4) pkinit(5) }; > -- as defined in RFC 4556. > > to > > PKAuthenticator, DHNonce, id-pkinit > FROM KerberosV5-PK-INIT-SPEC { > iso(1) identified-organization(3) dod(6) internet(1) > security(5) kerberosV5(2) modules(4) pkinit(5) }; > -- as defined in RFC 4556. > > (This adds id-pkinit to the imports). > > Change the OID list in Section 6 from > > id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit 6 } > -- PKINIT KDFs > id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER ::= { id-pkinit-kdf 1 } > -- SP800 56A ASN.1 structured hash based KDF using SHA-1 > id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 } > -- SP800 56A ASN.1 structured hash based KDF using SHA-256 > id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 } > -- SP800 56A ASN.1 structured hash based KDF using SHA-512 > id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER ::= { id-pkinit-kdf 4 } > -- SP800 56A ASN.1 structured hash based KDF using SHA-384 > > to > > id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit kdf(6) } > -- PKINIT KDFs > > id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER > ::= { id-pkinit-kdf sha1(1) } > -- SP800-56A ASN.1 structured hash based KDF using SHA-1 > > id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER > ::= { id-pkinit-kdf sha256(2) } > -- SP800-56A ASN.1 structured hash based KDF using SHA-256 > > id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER > ::= { id-pkinit-kdf sha512(3) } > -- SP800-56A ASN.1 structured hash based KDF using SHA-512 > > id-pkinit-kdf-ah-sha384 OBJECT IDENTIFIER > ::= { id-pkinit-kdf sha384(4) } > -- SP800-56A ASN.1 structured hash based KDF using SHA-384 > > and also duplicate that in the Appendix A ASN.1 module. Inserting it > right after the IMPORTS clause might be a good place. > > We can debate whether the component identifiers for the KDF OIDs should > be just or ah-. > > We might also want to duplicate the id-pkinit definition from RFC 4556 > in Section 6 (but not the Appendix A ASN.1 module), to make the full OID > easier for a casual reader to derive. > > Any comments? These look generally good. I don't presently have an opinion on vs. ah-, and would support the duplication of id-pkinit in section 6 (but not Appendix A). Thanks for putting this together. -Ben From nobody Wed Apr 1 09:43:49 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DC71AD0BA for ; Wed, 1 Apr 2015 09:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP3sos8x102N for ; Wed, 1 Apr 2015 09:43:47 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 93FD91AD289 for ; Wed, 1 Apr 2015 09:43:05 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 12CDE1DE094 for ; Wed, 1 Apr 2015 09:43:04 -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=HUGS1uWQKb+bfZ52AKdL viUbHzg=; b=Q3Xz0K3THwwI0zsFWyVS3HsFKOIf5tVydLcpoo4fjyGaoCjPxe/Z Zxkj+FZjIEdHvdybNYLTKSRU7LoamfXuLLr66d6As7ZXPXjmTypL4fui7xvbKxkt 7E1RnozilULEvj5Vom8OzZYMB7uiplvRqR6LPn8/hQEhUYCkDX+y1J8= Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id C596E1DE058 for ; Wed, 1 Apr 2015 09:43:02 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so53877145ied.1 for ; Wed, 01 Apr 2015 09:43:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.164.69 with SMTP id n66mr65031638ioe.82.1427906580816; Wed, 01 Apr 2015 09:43:00 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Wed, 1 Apr 2015 09:43:00 -0700 (PDT) In-Reply-To: References: <962591069.3713128.1427479391512.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 1 Apr 2015 11:43:00 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 16:43:48 -0000 On Tue, Mar 31, 2015 at 5:07 PM, Tom Yu wrote: > Nico Williams writes: >> On Tue, Mar 31, 2015 at 4:36 PM, Tom Yu wrote: >>> We can debate whether the component identifiers for the KDF OIDs should >>> be just or ah-. >> >> I don't think that would be a breaking change, though in general OID >> naming changes could be. The safe way to do this would be to leave >> compatibility values behind: >> >> id-pkinit-kdf-sha384 OBJECT IDENTIFIER ::= id-pkinit-kdf-ah-sha384 >> >> But I don't care. > > I was intending to indicate, e.g., { id-pkinit-kdf sha384(4) } vs > { id-pkinit-kdf ah-sha384(4) } , not the reference identifiers for the > entire OIDs (id-pkinit-kdf-ah-sha384 vs id-pkinit-kdf-sha384). What's the difference? But I don't care anyways. It's just a non-breaking symbol change. From nobody Wed Apr 1 13:05:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778971A9063 for ; Wed, 1 Apr 2015 13:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajHd9jJA1mWm for ; Wed, 1 Apr 2015 13:05:05 -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 454D71A9041 for ; Wed, 1 Apr 2015 13:05:02 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-43-551c4f6d941c Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id EB.C3.03451.D6F4C155; Wed, 1 Apr 2015 16:05:01 -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 t31K514h022308; Wed, 1 Apr 2015 16:05:01 -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 t31K4wTU016977 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Apr 2015 16:05:00 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t31K4wHL028958; Wed, 1 Apr 2015 16:04:58 -0400 (EDT) Date: Wed, 1 Apr 2015 16:04:58 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrZvrLxNqsLDR2OLo5lUsFqeuHWFz YPJ4eeoco8eSJT+ZApiiuGxSUnMyy1KL9O0SuDL2vLAtaGKt6Lzwi7mBsZmli5GTQ0LAROLC yh3MELaYxIV769m6GLk4hAQWM0ncmrKbGcLZwCjRuWcJI4RzkEni+qkNYO1CAvUSn87dAbNZ BLQkWo5cABvFJqAiMfPNRjYQW0RAU+L6vKVgNrOAusS3M28YQWxhIHvOr2lgvZwCgRKnFkxi ArF5BRwl5hxZxg4xP0BiT+8hsLiogI7E6v1TWCBqBCVOznzCAjFTS2L59G0sExgFZyFJzUKS WsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXVC83s0QvNaV0EyMoUNldlHYw/jyodIhRgINR iYe3IUo6VIg1say4MvcQoyQHk5Ior6ivTKgQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV5JEaAc b0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEr7cfUKNgUWp6akVaZk4J QpqJgxNkOA/QcCOQGt7igsTc4sx0iPwpRl2OO1P+L2ISYsnLz0uVEud9AXKdAEhRRmke3BxY gnnFKA70ljDvI5AqHmBygpv0CmgJE9ASh3nSIEtKEhFSUg2M4rvv/eV8OoXRxFJPgdXipUr0 nZdVD//IfNZ+0P/06t8NGf3lKldzJz/mTDBb9L/UqGTrpPKle7QiLXYo3RU5aua/UPLv1Jnz nr3WE9514Os5XY/dTJEl8z0dm6+YVIgk1MreqX7HwvCAJ7Tt9POdlybN52aIrdF0qxW2f1a8 YL6gYoa7l1WhEktxRqKhFnNRcSIAr9mgZwsDAAA= Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS-only enctypes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 20:05:07 -0000 On Tue, 31 Mar 2015, Nico Williams wrote: > I think the consensus at the meeting was that we could indeed reuse > the Kerberos enctype number space for GSS-only enctypes, since there > is some precedent for this. It would be significantly easier, from an > implementation perspective, to do just that. I'm not sure that we got enough active input at the meeting on this question to be able to declare consensus. Regardless, we should ask the list if there are objections to (or support for) using the Kerberos enctype number space for enctypes with restricted usability (i.e., only for subsession keys, or GSS, etc.). -Ben From nobody Wed Apr 1 14:00:27 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A04E1A92E2 for ; Wed, 1 Apr 2015 14:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XClvaVGpk315 for ; Wed, 1 Apr 2015 14:00:23 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD6E1ABD39 for ; Wed, 1 Apr 2015 14:00:12 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-0a-551c5c5af688 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 52.25.03488.B5C5C155; Wed, 1 Apr 2015 17:00:11 -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 t31L04Vt015576; Wed, 1 Apr 2015 17:00:05 -0400 Received: from [18.101.8.179] (vpn-18-101-8-179.mit.edu [18.101.8.179]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t31L03IG013550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 1 Apr 2015 17:00:04 -0400 Message-ID: <551C5C53.10901@mit.edu> Date: Wed, 01 Apr 2015 17:00:03 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Kaduk , Nico Williams References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT142OkQk1mNjNYnF08yoWi1PXjrA5 MHm8PHWO0WPJkp9MAUxRXDYpqTmZZalF+nYJXBkrbu9kLfjNUrFvRyt7A2MDSxcjJ4eEgIlE +74njBC2mMSFe+vZuhi5OIQEFjNJrNv/CMrZwCjxcOI+VgjnMJPExzuXwVp4BVQkzj/dyQRi swioSvyec5kdxGYTUJZYv38r2ApRgTCJ2esuQtULSpyc+QQozsEhIuAp8WG6EYjJLKAusXM3 M0iFMJA559c0sE4hgTZGifkHwUo4BZwkfrwWBwkzC+hJ7Lj+ixXClpdo3jqbeQKj4Cwk82ch KZuFpGwBI/MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXSO93MwSvdSU0k2MoODllOTdwfjuoNIh RgEORiUe3oYo6VAh1sSy4srcQ4ySHExKorx2QTKhQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4 JUWAcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIyHBxKErzTooEaBYtS01Mr 0jJzShDSTBycIMN5gIbPBanhLS5IzC3OTIfIn2LU5bgz5f8iJiGWvPy8VClx3miQIgGQoozS PLg5sKTzilEc6C1h3pdRQFU8wIQFN+kV0BImoCUO86RBlpQkIqSkGhjX3zzhud8nMF7yj9mp 8JSpH7OmPZb3P71Qf692r+J2ZVtXx98t9tMzsp8u02UyFjAReiaXsGmeTy8b5wHDpYraUTYH Kxcluv2rdr51Z++MHva2vaLyfm5MDSaxDp0XRNlCN9ebsB1nURfzePxw1aclG3jV12hOmSzo uius61XC1N96X4pXdSqxFGckGmoxFxUnAgDo6vAAFQMAAA== Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS-only enctypes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:00:25 -0000 On 04/01/2015 04:04 PM, Benjamin Kaduk wrote: > I'm not sure that we got enough active input at the meeting on this > question to be able to declare consensus. Regardless, we should ask the > list if there are objections to (or support for) using the Kerberos > enctype number space for enctypes with restricted usability (i.e., only > for subsession keys, or GSS, etc.). I didn't totally understand all of Nico's reasoning about this when he spoke at the meeting. In general I think it's fine; it lets us negotiate AEAD enctypes using RFC 4537 enctype negotation and the existing subkey fields when mutual auth is used. From nobody Wed Apr 1 14:05:58 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4201AC3A7 for ; Wed, 1 Apr 2015 14:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwlrLQBemara for ; Wed, 1 Apr 2015 14:05:55 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 071871AC3A1 for ; Wed, 1 Apr 2015 14:05:55 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id BB91E2F4071 for ; Wed, 1 Apr 2015 14:05:54 -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=2uC/1uxV3Uw1bIdIjWYk GLWeTl0=; b=kmpEDd9iwDmNUx0RMStqiqrfxN2NGidzREOr9yBCDdkGb3p06OMr nj8QMsb7jlG0sCgY1yrZonXu9IRNS7dJ9HBhj5nNIQXWjwZTyJdXuns2zg4cmPD6 /XfmbuSNkbgEup6InpHHICFd4Kx1HPsbQEh1Jz998dyxubNaUMbKEpY= Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPSA id 964AC2F406A for ; Wed, 1 Apr 2015 14:05:54 -0700 (PDT) Received: by iedm5 with SMTP id m5so54276747ied.3 for ; Wed, 01 Apr 2015 14:05:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.171.170 with SMTP id av10mr15102735igc.28.1427922353983; Wed, 01 Apr 2015 14:05:53 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Wed, 1 Apr 2015 14:05:53 -0700 (PDT) In-Reply-To: <551C5C53.10901@mit.edu> References: <551C5C53.10901@mit.edu> Date: Wed, 1 Apr 2015 16:05:53 -0500 Message-ID: From: Nico Williams To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS-only enctypes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:05:56 -0000 On Wed, Apr 1, 2015 at 4:00 PM, Greg Hudson wrote: > On 04/01/2015 04:04 PM, Benjamin Kaduk wrote: >> I'm not sure that we got enough active input at the meeting on this >> question to be able to declare consensus. Regardless, we should ask the >> list if there are objections to (or support for) using the Kerberos >> enctype number space for enctypes with restricted usability (i.e., only >> for subsession keys, or GSS, etc.). > > I didn't totally understand all of Nico's reasoning about this when he > spoke at the meeting. In general I think it's fine; it lets us > negotiate AEAD enctypes using RFC 4537 enctype negotation and the > existing subkey fields when mutual auth is used. Conversely, not reusing the RFC3961 enctype namespace means a) adding a new extension like RFC4537 to carry the client's/initiator's AEAD enctype list and sub-keys, b) extending AP-REP to carry the server's/acceptor's sub-key and choice of AEAD enctype. That seems like lots of unnecessary complexity. That's my reasoning. Nico -- From nobody Wed Apr 1 14:16:46 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BEC1A19F4 for ; Wed, 1 Apr 2015 14:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTPjIrKKgb9T for ; Wed, 1 Apr 2015 14:16:43 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646BB1A03A6 for ; Wed, 1 Apr 2015 14:16:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=864; q=dns/txt; s=iport; t=1427923003; x=1429132603; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Pxal8HkSnUjFtmY2L64dW/xmEqbF7R+eKT5ohqBjU54=; b=jsJ4k75XOwHWWmTspps8X4cjb/8RsLqcOj61qr4KBuk5yBOihXpgEDIW 9zX+xuH17Zpenxkg3/DYIKpuut3IQX4HQsQoE5jY7GmZrw+FzBgS3a8/h sX1RBPPX+Z8i/ATPd3gqOpZSB1cRAx7oOVe9cDB3zqh9FW/J5HSejTqra E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A8BQA5XxxV/5RdJa1cgwZSXAWDEMJNhXMCgURMAQEBAQEBfYQVAQEEIw8BRRElAgUWCwICCQMCAQIBRQYNBgIBAYgrDbVWmQgBAQEBAQEBAwEBAQEBAQEBFgSBIY8IFoJSgUUFix6JN4YEgR2DMoI7hjuGeyKCAR2Bb1CBRH8BAQE X-IronPort-AV: E=Sophos;i="5.11,506,1422921600"; d="scan'208";a="137474382" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-4.cisco.com with ESMTP; 01 Apr 2015 21:16:43 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t31LGglC026155 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 1 Apr 2015 21:16:42 GMT Received: from [10.129.24.55] (10.129.24.55) by xhc-aln-x08.cisco.com (173.36.12.82) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 1 Apr 2015 16:16:42 -0500 Message-ID: <551C6039.6090408@cisco.com> Date: Wed, 1 Apr 2015 15:16:41 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: References: <5519964B.6010008@cisco.com> In-Reply-To: <5519964B.6010008@cisco.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.55] Archived-At: Subject: [kitten] IETF 92 Meeting Minutes (DRAFT POSTED) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:16:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Meeting minutes have been posted to the datatracker: https://www.ietf.org/proceedings/92/minutes/minutes-92-kitten Please do send any corrections to the chairs and we will update. - -- - - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVHGA5AAoJEDWi+S0W7cO1z1wIALEoQ/A41/lnw2S8Qz9GHEBj E5qgAaBNPG1pSF393BryZmthyh0pjmkH+bfQuSqJiUFqViiOpesWt8To/xFv7InJ TcZL/mBkyBs5AaHRlGSqhIy9qumjLYLDkYwf2aFfvFgbEq0e7+4NDOeRWZW+w3DS DzYKN6NyU2slPEh9nqhvMYbkVdc7bn929G+3D4f+AlObfQbYjIpPUJfJUogVHxre xKR6rfDSISQZLgqB7BLeDD+pa7PGOfT6g1hWfrn2g/bsd19IL4AAaA3pqaVPQ9rM RpNuiQcbI3VknKUGDrzveupWUnSZ5tTt7ZZXBH//5Zo/VgSYCtUqVkuQN8v4Kxc= =0wf6 -----END PGP SIGNATURE----- From nobody Wed Apr 1 14:58:46 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005861A8863 for ; Wed, 1 Apr 2015 14:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SDuBEHYofvVR for ; Wed, 1 Apr 2015 14:58:43 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637F61A896F for ; Wed, 1 Apr 2015 14:58:43 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-28-551c6a12adb8 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 7F.22.03493.21A6C155; Wed, 1 Apr 2015 17:58:42 -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 t31LwfoN006579; Wed, 1 Apr 2015 17:58:41 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t31LweC5002773; Wed, 1 Apr 2015 17:58:40 -0400 From: Tom Yu To: Nico Williams References: <551C5C53.10901@mit.edu> Date: Wed, 01 Apr 2015 17:58:37 -0400 In-Reply-To: (Nico Williams's message of "Wed, 1 Apr 2015 16:05:53 -0500") Message-ID: Lines: 28 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAIsWRmVeSWpSXmKPExsUixCmqrSuUJRNqMGWLiMXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGU8W/KKpaCLp+Lm4rVMDYyfOLsYOTkkBEwk Nv16xwphi0lcuLeeDcQWEljMJDHxhBqEvYFR4lCHcxcjF5D9mlFiUutGsCI2AWmJ45d3MYHY IgKaEtfnLQWLMwu4S6y4dAssLiygLjHn1zQWiEGvGCXmb0kHsVkEVCW+3JvODDKUU2Aio8T2 5zOZQRK8AroSx5e9AhvEI8AJZE9jh4gLSpyc+YQFYoGWxI1/L5kmMArMQpKahSS1gJFpFaNs Sm6Vbm5iZk5xarJucXJiXl5qka65Xm5miV5qSukmRlBAsruo7GBsPqR0iFGAg1GJh7chSjpU iDWxrLgy9xCjJAeTkiivXZBMqBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXkkRoBxvSmJlVWpR PkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgTvuwygRsGi1PTUirTMnBKENBMHJ8hw HqDhbiA1vMUFibnFmekQ+VOMilLivLtAEgIgiYzSPLheWMJ4xSgO9Iow73eQKh5gsoHrBoY/ 0EcivA7zpEEGlyQipKQaGEW8Uy7cdhFT0rTMMs+SiFo6teB2xWnjyni+cy2KpjujpVMlV+1L viGvy/9La8qBg7bZ36fa9e7cYWERKcGftOcGw7OpulK8CxbkBq6Y9Zfh98pwMy1G0f5fT39v +HKm0MHit1tV0nfpSHtFHr17TncUX27wkZ6z/iVbsLva/OcbcqdfczX9rMRSnJFoqMVcVJwI ANxwQEDzAgAA Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS-only enctypes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 21:58:45 -0000 Nico Williams writes: > On Wed, Apr 1, 2015 at 4:00 PM, Greg Hudson wrote: >> On 04/01/2015 04:04 PM, Benjamin Kaduk wrote: >>> I'm not sure that we got enough active input at the meeting on this >>> question to be able to declare consensus. Regardless, we should ask the >>> list if there are objections to (or support for) using the Kerberos >>> enctype number space for enctypes with restricted usability (i.e., only >>> for subsession keys, or GSS, etc.). >> >> I didn't totally understand all of Nico's reasoning about this when he >> spoke at the meeting. In general I think it's fine; it lets us >> negotiate AEAD enctypes using RFC 4537 enctype negotation and the >> existing subkey fields when mutual auth is used. > > Conversely, not reusing the RFC3961 enctype namespace means a) adding > a new extension like RFC4537 to carry the client's/initiator's AEAD > enctype list and sub-keys, b) extending AP-REP to carry the > server's/acceptor's sub-key and choice of AEAD enctype. That seems > like lots of unnecessary complexity. I generally agree with that reasoning. I think we should clearly document the security considerations of the "restricted usage enctype" approach. We should also require that future specifications of restricted usage enctypes clearly document the security considerations of using the restricted enctype outside of the intended scope, e.g., compromise of all future authentication if there is nonce reuse of a long-term AES-GCM key. From nobody Wed Apr 1 15:06:07 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D7C1A0151 for ; Wed, 1 Apr 2015 15:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASA6tsfxt9yT for ; Wed, 1 Apr 2015 15:06:04 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8782B1A0070 for ; Wed, 1 Apr 2015 15:06:04 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 4440E160B for ; Wed, 1 Apr 2015 15:06:04 -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=fE4yD8Fs1DAvM4ZgAS+O jLlSJFg=; b=nhp1Xyh6FAh/gkUP74qHH/a9VicouA7iW6lrGEPGl/Xjvv0LEm6a SZsgboX0qKdrK6Pcqf0MDlBN0Yjg4t0y2IJSQHEeToGqqFa4v2mxD1HVOD6wrP8e Hw/MMDdq0n2C3ERO0kFAtcWFSLEISMN3HS7ViMWWyV1WwyEkx8ct2xI= Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPSA id 3006B160A for ; Wed, 1 Apr 2015 15:06:04 -0700 (PDT) Received: by ierf6 with SMTP id f6so55093959ier.2 for ; Wed, 01 Apr 2015 15:06:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.226.69 with SMTP id iv5mr68713278icb.58.1427925963845; Wed, 01 Apr 2015 15:06:03 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Wed, 1 Apr 2015 15:06:03 -0700 (PDT) In-Reply-To: References: <551C5C53.10901@mit.edu> Date: Wed, 1 Apr 2015 17:06:03 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS-only enctypes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 22:06:05 -0000 On Wed, Apr 1, 2015 at 4:58 PM, Tom Yu wrote: > Nico Williams writes: > >> On Wed, Apr 1, 2015 at 4:00 PM, Greg Hudson wrote: >>> On 04/01/2015 04:04 PM, Benjamin Kaduk wrote: >>>> I'm not sure that we got enough active input at the meeting on this >>>> question to be able to declare consensus. Regardless, we should ask the >>>> list if there are objections to (or support for) using the Kerberos >>>> enctype number space for enctypes with restricted usability (i.e., only >>>> for subsession keys, or GSS, etc.). >>> >>> I didn't totally understand all of Nico's reasoning about this when he >>> spoke at the meeting. In general I think it's fine; it lets us >>> negotiate AEAD enctypes using RFC 4537 enctype negotation and the >>> existing subkey fields when mutual auth is used. >> >> Conversely, not reusing the RFC3961 enctype namespace means a) adding >> a new extension like RFC4537 to carry the client's/initiator's AEAD >> enctype list and sub-keys, b) extending AP-REP to carry the >> server's/acceptor's sub-key and choice of AEAD enctype. That seems >> like lots of unnecessary complexity. > > I generally agree with that reasoning. I think we should clearly > document the security considerations of the "restricted usage enctype" > approach. We should also require that future specifications of > restricted usage enctypes clearly document the security considerations > of using the restricted enctype outside of the intended scope, e.g., > compromise of all future authentication if there is nonce reuse of a > long-term AES-GCM key. Yes. I'd rather say that AEAD enctypes are just NOT RFC3961 enctypes, and they cannot be used in any RFC3961 interfaces. But that approach does increase the friction between a Kerberos GSS mechanism implementation and the libkrb5 underneath (e.g., a krb5_authcontext wouldn't be able to have GSS-only sub-keys, and extracting them from the Authenticator and AP-REP might require new internal interfaces). We might have to settle for simply not permitting use of AEAD in non-GSS contexts. Nico -- From nobody Wed Apr 1 15:19:09 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7BB1A87BF for ; Wed, 1 Apr 2015 15:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmviWDijxnvO for ; Wed, 1 Apr 2015 15:19:06 -0700 (PDT) Received: from nm28.bullet.mail.bf1.yahoo.com (nm28.bullet.mail.bf1.yahoo.com [98.139.212.187]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8180C1A87A5 for ; Wed, 1 Apr 2015 15:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427926745; bh=eNKnWWn/S2CLyjS1A2t09XjQBQKwyYjC2oUS3ivH1sg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=geh1HeEYu+5k19IBDpqXxZ3hJWdNcdHtg1BTXdHk+ffBn8MaHO/T2qJ3y3s98LXNOFW6iWND6Bo/z0gfEBx7VAcf30rvd0cZgCBOjz0TfdwrGktVgmBBLQl+waODYkkzKaCXExiDjy/ZhjK5kdg9NJ8y95T+9xNtqTiCeXyBrCZypVzYbMxAozsGp8QI722lXIt7XhgEeAhcmrWXwO/1xKOhXZGURIannXQd6fHvlG/4CIJxxCdqlSosNLi7AFTcjP/kISeI+E4AGyvWh+hqWwzmEkMm01y+/fkwN3AOuXaBENZMfEks2BhRuu/GzyXU6I1R9zozW1zr2Gx4e4Zi9w== Received: from [98.139.215.140] by nm28.bullet.mail.bf1.yahoo.com with NNFMP; 01 Apr 2015 22:19:05 -0000 Received: from [98.139.212.197] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 01 Apr 2015 22:19:05 -0000 Received: from [127.0.0.1] by omp1006.mail.bf1.yahoo.com with NNFMP; 01 Apr 2015 22:19:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 735793.94850.bm@omp1006.mail.bf1.yahoo.com X-YMail-OSG: uJShqSsVM1moWwTYEIqN7dlbXihTxqvfUdkaTSrJEPcDpG26u56y0Jj5gV4pRYL 6MQ2Q78utNS07KnWPwCPCDOxNd1oN5L9eEcnaCd7dWXb15gdiO_cSAtnytDBrGBkovUoB1ze.mFT kbdTs72w0L0nVmAT0Fcig.5Xpi8WvLV2Jzo0tNulJEqJ9ru2dYVboyGFa1oZyHbs5ez1z6YFyoOm Neb74dN.kYpNcubHx5mZ9p5EnqW2PoOAIEHHyQvRhD6YyKrnvwieTG6CUN2IiqgsobX6ri00Olbl _4JZk76W48pEv3bjoOwtEoMQ5wpS2o_pxUQyYJInjDdDtt8_zLMiA5jMZuLQU2JBgSa_7QSghcv. pGsMoTRyb57yYEFDpk0L.lnDnrLrONbbTiDjtTXnFylU4Rj1ueURyYD0Y7KKEsMBM_r.84jp024r ux47a6V5qRsyhxXYPps9Sy0tsqU.vh4qLaeAPU2L_6RRMBiCkv0zUV9Uf3ZdZVQj6qBCjBBb..Er rtBRsmFF2E0NE9ZiTzjgNRZ6MedBYa4z1dri8QTGTMXD9JjWcPp2sRj6Z8mljjOysogCJ8jN9V8u Yj2Pq5fcAjgi1 Received: by 66.196.80.117; Wed, 01 Apr 2015 22:19:05 +0000 Date: Wed, 1 Apr 2015 22:19:04 +0000 (UTC) From: Bill Mills To: Nico Williams , Tom Yu Message-ID: <202609050.3973897.1427926744182.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3973896_1399659502.1427926744177" Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 22:19:08 -0000 ------=_Part_3973896_1399659502.1427926744177 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Suggested changes updated to=C2=A0https://github.com/sweetums/idrafts Still one open question on "I don't presently have an opinion on = vs. ah-..."=C2=A0 On Wednesday, April 1, 2015 9:43 AM, Nico Williams wrote: =20 On Tue, Mar 31, 2015 at 5:07 PM, Tom Yu wrote: > Nico Williams writes: >> On Tue, Mar 31, 2015 at 4:36 PM, Tom Yu wrote: >>> We can debate whether the component identifiers for the KDF OIDs should >>> be just or ah-. >> >> I don't think that would be a breaking change, though in general OID >> naming changes could be.=C2=A0 The safe way to do this would be to leave >> compatibility values behind: >> >> id-pkinit-kdf-sha384 OBJECT IDENTIFIER ::=3D id-pkinit-kdf-ah-sha384 >> >> But I don't care. > > I was intending to indicate, e.g., { id-pkinit-kdf sha384(4) } vs > { id-pkinit-kdf ah-sha384(4) } , not the reference identifiers for the > entire OIDs (id-pkinit-kdf-ah-sha384 vs id-pkinit-kdf-sha384). What's the difference?=C2=A0 But I don't care anyways.=C2=A0 It's just a non-breaking symbol change. ------=_Part_3973896_1399659502.1427926744177 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Suggested changes updated to = ;https://github.com/sweetums/idrafts

Still one open question on "I don't presently have an opinion on <hashname> vs.= ah-<hashname>..."
 



On Wednesday, April 1, 2015 9:43 AM, Nico Williams <nic= o@cryptonector.com> wrote:


On Tue, Mar 31, 2015 at 5:07 PM, Tom Yu <tlyu@mit.edu= > wrote:

> Nico Williams <nico@cryptonector.com> writes:
>> On Tue, Mar 31, 2015 at 4:36 PM, T= om Yu <tlyu@mit.edu> wrote:
>>> We= can debate whether the component identifiers for the KDF OIDs should
>>> be just <hashname> or ah-<hashname>.<= br clear=3D"none">>>
>> I don't think that wo= uld be a breaking change, though in general OID
>> = naming changes could be.  The safe way to do this would be to leave>> compatibility values behind:
>= ;>
>> id-pkinit-kdf-sha384 OBJECT IDENTIFIER ::= =3D id-pkinit-kdf-ah-sha384
>>
&g= t;> But I don't care.
>
> I wa= s intending to indicate, e.g., { id-pkinit-kdf sha384(4) } vs
> { id-pkinit-kdf ah-sha384(4) } , not the reference identifiers fo= r the
> entire OIDs (id-pkinit-kdf-ah-sha384 vs id-pki= nit-kdf-sha384).


What's the diff= erence?  But I don't care anyways.  It's just a
non-breaking symbol change.
=


= ------=_Part_3973896_1399659502.1427926744177-- From nobody Wed Apr 1 15:47:48 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C291A017F for ; Wed, 1 Apr 2015 15:47:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oelHY1JTN4Re for ; Wed, 1 Apr 2015 15:47:46 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0B82A1A0145 for ; Wed, 1 Apr 2015 15:47:46 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 5B76D2004F4DF for ; Wed, 1 Apr 2015 15:47:45 -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=cOldAQ3gvk3aK0h2+xyN zlK9noA=; b=O30J+jWfJ6PMDR8HEHvu6uuzwqhdgHXq60GxhK+6TyJ/IGIyaP0f HHGq+g0KJyvKdh1OZAUF4wDxDSx12yvP0oi1/a7eUToaMYpYOIUVkiH7u35QYGWk X1aFOEVLuUBmFOb1rPp0dMR/svqZkkMCUY3ZaCZS04snweXKJRHrUTM= Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id 47DEE2004F4DD for ; Wed, 1 Apr 2015 15:47:45 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so62566849ied.1 for ; Wed, 01 Apr 2015 15:47:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.25.17 with SMTP id y17mr35029280icb.68.1427928464923; Wed, 01 Apr 2015 15:47:44 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Wed, 1 Apr 2015 15:47:44 -0700 (PDT) In-Reply-To: <202609050.3973897.1427926744182.JavaMail.yahoo@mail.yahoo.com> References: <202609050.3973897.1427926744182.JavaMail.yahoo@mail.yahoo.com> Date: Wed, 1 Apr 2015 17:47:44 -0500 Message-ID: From: Nico Williams To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 22:47:47 -0000 On Wed, Apr 1, 2015 at 5:19 PM, Bill Mills wrote: > Suggested changes updated to https://github.com/sweetums/idrafts > > Still one open question on "I don't presently have an opinion on > vs. ah-..." You may flip a coin as to that one. It doesn't matter. If in doubt, leave it as in the original. Nico -- From nobody Wed Apr 1 16:04:38 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8828B1AC43B for ; Wed, 1 Apr 2015 16:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6WV83lEJZtN for ; Wed, 1 Apr 2015 16:04:35 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0161AC43A for ; Wed, 1 Apr 2015 16:04:34 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-57-551c7981e16b Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 30.7A.03389.1897C155; Wed, 1 Apr 2015 19:04:33 -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 t31N4WrE029130; Wed, 1 Apr 2015 19:04:33 -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 t31N4VkL024117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Apr 2015 19:04:32 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t31N4Ulm021513; Wed, 1 Apr 2015 19:04:30 -0400 (EDT) Date: Wed, 1 Apr 2015 19:04:30 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: Message-ID: References: <551C5C53.10901@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixG6nrttYKRNq0PFd0+Lo5lUsFqeuHWFz YPJ4eeoco8eSJT+ZApiiuGxSUnMyy1KL9O0SuDLOLZ/OUvCateLG5TWsDYz3WLoYOTkkBEwk tm4/xw5hi0lcuLeerYuRi0NIYDGTxPIdq5khnA2MEn9ftbBDOAeZJHqn/2cEaRESqJfomHeJ FcRmEdCSuHbjApjNJqAiMfPNRjYQW0RAU+L6vKVgNrOAusS3M2/AeoWB7Dm/poGdwSkQKPG+ dxETiM0r4CixpKUdavNZJonZ936CJUQFdCRW75/CAlEkKHFy5hMWiKFaEsunb2OZwCg4C0lq FpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbomermZJXqpKaWbGEHByinJv4Px20GlQ4wC HIxKPLwNUdKhQqyJZcWVuYcYJTmYlER5RSpkQoX4kvJTKjMSizPii0pzUosPMUpwMCuJ8GoW AeV4UxIrq1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4i0CGChalpqdWpGXm lCCkmTg4QYbzAA3fClLDW1yQmFucmQ6RP8Woy3Fnyv9FTEIsefl5qVLivCUgRQIgRRmleXBz YEnmFaM40FvCvNtAqniACQpu0iugJUxASxzmSYMsKUlESEk1MLKs/xa79NOp+btvagvOZK1j WZnFZ5SpdyHIvyhEqtJ/5sMs70dC876JnH89U2fel8DfCVopfU4PC6ZEL10gUqJzZx7rSZej vVN6Pf6waiemHGwIbFz76J4Lx5ZdzicPSSYmePy/HrJincefikWR9yO77P4fclUO625PvrX6 u1YHc/Cj4zuub1ViKc5INNRiLipOBADxGJBPDQMAAA== Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS-only enctypes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 23:04:36 -0000 On Wed, 1 Apr 2015, Nico Williams wrote: > I'd rather say that AEAD enctypes are just NOT RFC3961 enctypes, and > they cannot be used in any RFC3961 interfaces. But that approach does > increase the friction between a Kerberos GSS mechanism implementation > and the libkrb5 underneath (e.g., a krb5_authcontext wouldn't be able > to have GSS-only sub-keys, and extracting them from the Authenticator > and AP-REP might require new internal interfaces). > > We might have to settle for simply not permitting use of AEAD in > non-GSS contexts. It's always nice to have these decisions guided by implementation experience, if someone (TM) tries out the different approaches and can attest to their strengths and weaknesses. -Ben From nobody Wed Apr 1 17:17:11 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB271A7022 for ; Wed, 1 Apr 2015 17:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBj-GMeoyGDa for ; Wed, 1 Apr 2015 17:17:09 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5111A7020 for ; Wed, 1 Apr 2015 17:17:09 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id E20E1674058 for ; Wed, 1 Apr 2015 17:17:08 -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=Ng3i7b60W69mZAWlbwst WUYfBQg=; b=dHQTjuHFSui5v3ENdboTzLfBhMXeCW+DSg0dRmmdf5exJmTojMPi yZK8FZFJl1pxsNYOxD6+9cNI7hVrg1EFyvwTdQb5agcHAVBXc7WcQiW/JOzRUDC6 e41OBaOGFbEGP9RVwa213y6CWY7c3IvFqD1Cgi0p2Pce55sTwuUtdO4= Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id CE973674057 for ; Wed, 1 Apr 2015 17:17:08 -0700 (PDT) Received: by iedm5 with SMTP id m5so57246241ied.3 for ; Wed, 01 Apr 2015 17:17:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.42.86.12 with SMTP id s12mr77792498icl.47.1427933828509; Wed, 01 Apr 2015 17:17:08 -0700 (PDT) Received: by 10.64.130.66 with HTTP; Wed, 1 Apr 2015 17:17:08 -0700 (PDT) In-Reply-To: References: <551C5C53.10901@mit.edu> Date: Wed, 1 Apr 2015 19:17:08 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] GSS-only enctypes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 00:17:10 -0000 On Wed, Apr 1, 2015 at 6:04 PM, Benjamin Kaduk wrote: > It's always nice to have these decisions guided by implementation > experience, if someone (TM) tries out the different approaches and can > attest to their strengths and weaknesses. Indeed. I'll try out this approach and see how it goes. I'll report my findings when I get there. From nobody Wed Apr 1 17:31:11 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990781ACF60 for ; Wed, 1 Apr 2015 17:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDbLLeVQ7UBx for ; Wed, 1 Apr 2015 17:31:09 -0700 (PDT) Received: from nm1-vm1.bullet.mail.bf1.yahoo.com (nm1-vm1.bullet.mail.bf1.yahoo.com [98.139.213.163]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA361ACF6C for ; Wed, 1 Apr 2015 17:31:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427934668; bh=t6eInvW8l4u0nvBLW606OwlqhoL8zBaW0jJ/iYAx0Lc=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ILgoD8FQI3ot7wDcFbKirUTAU6ca1nRx2MHcEsX8DPcKPTj0QWf4W+bkJT8God+RHMPW1s+HAvec1hPpPfhnQZIMWE00JX2+2YZjFNnqwLCZLoACliZIhme2gn8Brb5DmcIVqQSmFN9UVYJ0ysZZgORnXkQx0fJWhnxS10sR1vgM01py6y7Etl+JpHs+emRDebbd81TtUoD4fNvAQVikZsfdtNfIG6DltQ4cndC7g8xZty9XBVNZgoWfib+h0oA4NK9QQL20qe6Xy3ExOuO73hti6CtGqKGVbtkEjHpc+Ii75pGEJtrCmTKb5wt4tuC6O6gqlezdk00WKagmIpHFEA== Received: from [98.139.214.32] by nm1.bullet.mail.bf1.yahoo.com with NNFMP; 02 Apr 2015 00:31:08 -0000 Received: from [98.139.212.251] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 02 Apr 2015 00:31:08 -0000 Received: from [127.0.0.1] by omp1060.mail.bf1.yahoo.com with NNFMP; 02 Apr 2015 00:31:08 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 388120.56426.bm@omp1060.mail.bf1.yahoo.com X-YMail-OSG: qXMLYMoVM1lAdQVYgwOqMXn1Zpv2hB4QiCNG3Pzq3ffu5tyJ8UEe0CSu5l7XUgF 5NozxEF7YNNZlElTH0g2qIwTf4Vk.kl1uSGLbBLV6xMiGbnIQ28_01SUlp9PlCD8jR7zRYHh.Vwr XG_2vM_L34wQnHfMh5xpyyce.hOGVenLHNDjzk.ZLmGO8hfrsf_4vJzvukSLYB0rmmOuPaR5uRig 1uiyLl_PMVsw.ts0KRRtHa_Wtji5S9jYxoRH.EAHHIH7QaylTX4Oco.1SD.Gmpchb9b.Ttlcme4y 7il.wYb1c3b5baqfl9eewVMAvIkjhGdhqOktOTPFyDF8o_S5DA8Um3fYkNKl_aXwpDfd2A02xkTW NrVr0LTSB3bVMO0nnJPBbAcoKcUEXaey0TUiWQmet_505offQgNzFKf_xlGdhscTp4Xi84NDJzf6 gi7JuCJUj17XRdMj.7hTDx_sXxei1nv424mFfAA24n_9_EdNekgrrM.._0h2fMWvOqy2TtRLuy4H Jl2AeKW3Px2GOVkkQbDoHhjd_.l4gM.oGRv5p6JM73MrRKLFD5ug445emDlc.MyZOTYNPBmRA3GS E32HYw7S3Dw-- Received: by 66.196.80.148; Thu, 02 Apr 2015 00:31:07 +0000 Date: Thu, 2 Apr 2015 00:31:07 +0000 (UTC) From: Bill Mills To: Nico Williams Message-ID: <1851917523.4028484.1427934667577.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4028483_933287413.1427934667574" Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 00:31:10 -0000 ------=_Part_4028483_933287413.1427934667574 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable inertia wins....=20 On Wednesday, April 1, 2015 3:47 PM, Nico Williams wrote: =20 On Wed, Apr 1, 2015 at 5:19 PM, Bill Mills wrote: > Suggested changes updated to https://github.com/sweetums/idrafts > > Still one open question on "I don't presently have an opinion on > vs. ah-..." You may flip a coin as to that one.=C2=A0 It doesn't matter.=C2=A0 If in do= ubt, leave it as in the original. Nico -- ------=_Part_4028483_933287413.1427934667574 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
inertia wins....



On Wednesday, April 1, 2015 3:47 PM, Nico Williams <nic= o@cryptonector.com> wrote:


On Wed, Apr 1, 2015 at 5:19 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
> Sug= gested changes updated to https://github.com/sweetums/idrafts
>
> Still one open question on "I do= n't presently have an opinion on <hashname>
> vs= . ah-<hashname>..."

You may flip= a coin as to that one.  It doesn't matter.  If in doubt,
leave it as in the original.


Nico
--<= br clear=3D"none">


<= /html> ------=_Part_4028483_933287413.1427934667574-- From nobody Wed Apr 1 21:28:03 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3071D1B2A96 for ; Wed, 1 Apr 2015 21:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3noUYkiU739D for ; Wed, 1 Apr 2015 21:28:01 -0700 (PDT) Received: from nm17-vm1.bullet.mail.bf1.yahoo.com (nm17-vm1.bullet.mail.bf1.yahoo.com [98.139.213.55]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013901B2A8F for ; Wed, 1 Apr 2015 21:28:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427948880; bh=RT+MQF2s7J2x8s+Txb6BGo8za+OrcUrA6PIsjKE4b9Q=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=UVn/ML8g8T+Dr2z+JJZMw7zM5maRtpcBxFUYSAYYhPLo1Kqan3OS4Tn57AoSe5TTHVLXS1g6NrjHMC1BafpSvjeIc3BH8rVi9B4RPXiJBPd849rw2stkLvwkcg+8afhfKtaH2RsbPqd+mP3pd/WhifHSr1pyAb55uj55W+9T8tl7Z5S6lJp9P18bnd68pwtMXKv/12zmB7bkyVZvk4hI4s9jkJ7n1jwyS3wJElLBVF2RckiCHk9AzG1MC6lBx3BQbfjzAEk/lS4XlbiwLhhHHupKoXLgCzTmCf0FN1b4RIBlCdgTtK01qaDCVJ5saWcTGOaHoSABnUwmF9jzHgiFCw== Received: from [98.139.170.179] by nm17.bullet.mail.bf1.yahoo.com with NNFMP; 02 Apr 2015 04:28:00 -0000 Received: from [98.139.212.217] by tm22.bullet.mail.bf1.yahoo.com with NNFMP; 02 Apr 2015 04:28:00 -0000 Received: from [127.0.0.1] by omp1026.mail.bf1.yahoo.com with NNFMP; 02 Apr 2015 04:28:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 266665.68872.bm@omp1026.mail.bf1.yahoo.com X-YMail-OSG: iGlpkwsVM1lKZ1MeEHkmdtCNKIXHUAAmNw03r6N_x9aVyrqTT.7NzLCkekn2B_9 TnD3YMuaLZLrTZLNGqmfkSdKZUSMN3OHnY5YzvqRNK06TEO_bTjHZlJin9QkWI.Ut8eC4HKp5wc6 MVeb2up2Xf.jNSgfk3HV5L1j9p8iWiZwiRgi3GLMD2Uyt_tmVbbqR0J.KGJDiBfhHAMtycfLYJ0c A6vxmNN0tfH7yYVIQVg.KKVH6AKrg46_NBcIq7Sa2euUuwYzLAQZiG8DFkYU1__gkQJBlYDsFqp9 ZaVFK8NIiiCRzbFHmsjeYOi2hJc3ohnXPpLy1pdNz8Wdj79Db5RTEUGFwjkIdE3ZqL0KLw7DNFCm KtNtDM58MhKXUGVdc_VUgHcKMb3DUiUWdn_19gNL9skbAdFtKEioaN.j39sadA6CEPr83eU.0Jbs MowIt3_26CNdql3sIdWNXF3Kd9.JeLk0Oxx.Jwgs3BQSS98EzYY7kcnI9CChsWG.YLsicCVEkq13 48ici9zJEI223ZQdNoIEn5WKmK5HbNhoqjmt02jpMWXYfXyn0fjCUHIpJ9NWRqRSU9UDyQHNK7YD C7BqXbQeZ6Oy8l9KVFLga5n1oprGOvblHD2JgF8078sPS Received: by 76.13.26.136; Thu, 02 Apr 2015 04:27:59 +0000 Date: Thu, 2 Apr 2015 04:27:58 +0000 (UTC) From: Bill Mills To: Bill Mills , Nico Williams Message-ID: <435509972.4181009.1427948878220.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1851917523.4028484.1427934667577.JavaMail.yahoo@mail.yahoo.com> References: <1851917523.4028484.1427934667577.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4181008_209641291.1427948878216" Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 04:28:02 -0000 ------=_Part_4181008_209641291.1427948878216 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Any reason not to publish -08 on this?=20 On Wednesday, April 1, 2015 5:31 PM, Bill Mills wrote: =20 inertia wins....=20 On Wednesday, April 1, 2015 3:47 PM, Nico Williams wrote: =20 On Wed, Apr 1, 2015 at 5:19 PM, Bill Mills wrote: > Suggested changes updated to https://github.com/sweetums/idrafts > > Still one open question on "I don't presently have an opinion on > vs. ah-..." You may flip a coin as to that one.=C2=A0 It doesn't matter.=C2=A0 If in do= ubt, leave it as in the original. Nico -- =20 _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_4181008_209641291.1427948878216 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Any = reason not to publish -08 on this?

=

On Wednesda= y, April 1, 2015 5:31 PM, Bill Mills <wmills_92105@yahoo.com> wrote:<= br>


inertia wins....



On Wednesday, April 1, 2015 3:47 PM, Nico Williams <nico@cryptonecto= r.com> wrote:


On Wed, Apr 1, = 2015 at 5:19 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
&g= t; Suggested changes updated to https://github.com= /sweetums/idrafts
>
> Still o= ne open question on "I don't presently have an opinion on <hashname><= br clear=3D"none">> vs. ah-<hashname>..."

You may flip a coin as to that one.  It doesn't matter.&n= bsp; If in doubt,
leave it as in the original.


Nico
--


<= /div>

_________= ______________________________________
Kitten mailing lis= t
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
=


------=_Part_4181008_209641291.1427948878216-- From nobody Thu Apr 2 08:25:26 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6A41ACCD9 for ; Thu, 2 Apr 2015 08:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nX4Ze6vHG2pT for ; Thu, 2 Apr 2015 08:25:23 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C681E1ACCDE for ; Thu, 2 Apr 2015 08:25:20 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-08-551d5f5f6c15 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E8.E1.03355.F5F5D155; Thu, 2 Apr 2015 11:25:19 -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 t32FPJ3g012135; Thu, 2 Apr 2015 11:25:19 -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 t32FPHtH018998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Apr 2015 11:25:18 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t32FPHSe023799; Thu, 2 Apr 2015 11:25:17 -0400 (EDT) Date: Thu, 2 Apr 2015 11:25:17 -0400 (EDT) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <202609050.3973897.1427926744182.JavaMail.yahoo@mail.yahoo.com> Message-ID: References: <202609050.3973897.1427926744182.JavaMail.yahoo@mail.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-701480727-1427988317=:22210" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAKsWRmVeSWpSXmKPExsUixCmqrBsfLxtqMPGwlcXRzatYLL51XWd2 YPJYsuQnk8esWYeZApiiuGxSUnMyy1KL9O0SuDLOzp3LVPCFteLmud8sDYx/WboYOTkkBEwk Vu87DGWLSVy4t56ti5GLQ0hgMZPEmtWroJwNjBKPb3eyQDgHmSTuvprN1MXIAeTUS0z/kQTS zSKgJbGv+SAjiM0moCIx881GNpASEQF1iebv3iBhZgF5iWdrutlAbGGBRIk3D7rZQWxOAR+J wzOegNm8Ao4SV26dZ4dYNYFR4kbnebAGUQEdidX7p7BAFAlKnJz5hAViaIDEx47XzBMYBWch Sc1CkoKw1SUOfLrICGFrS9y/2ca2gJFlFaNsSm6Vbm5iZk5xarJucXJiXl5qka6xXm5miV5q SukmRnBgS/LtYPx6UOkQowAHoxIPb8YemVAh1sSy4srcQ4ySHExKory3I2VDhfiS8lMqMxKL M+KLSnNSiw8xSnAwK4nwioQA5XhTEiurUovyYVLSHCxK4rybfvCFCAmkJ5akZqemFqQWwWRl ODiUJHi94oAaBYtS01Mr0jJzShDSTBycIMN5gIbPBanhLS5IzC3OTIfIn2LU5bgz5f8iJiGW vPy8VClx3nKQIgGQoozSPLg5sIT0ilEc6C1h3vuxQFU8wGQGN+kV0BImoCUO86RBlpQkIqSk GhjrlOrvZAtYFr39oOgy6cHEg9kbk+qC+6MyXL8m57436ZyU4ntQpGrbA0Hzb587rM1faGsd rFudPPuyA4/iomhdiVMOYhOkzr3VY4m7fGxN1PM3c6QYMlc1Pmc2vXhiypF1dv0T1EwO83Zu DM52KHoTsujRh20nZ6zsbDrxKO2302th5muOgb+VWIozEg21mIuKEwEFNRpcIwMAAA== Archived-At: Cc: Kitten WG Subject: Re: [kitten] draft-ietf-krb-wg-pkinit-alg-agility-07 Re: now that I've volunteered.... X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 15:25:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-701480727-1427988317=:22210 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 1 Apr 2015, Bill Mills wrote: > Suggested changes updated to=C2=A0https://github.com/sweetums/idrafts > Still one open question on "I don't presently have an opinion on vs. ah-..."=C2=A0 Please go ahead and submit, as draft-ietf-kitten-pkinit-alg-agility-00 -- we have been requested to move documents into the kitten namespace which we are pulling in from the krb-wg. Thanks, Ben ---559023410-701480727-1427988317=:22210-- From nobody Thu Apr 2 09:07:55 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9671B2CD8; Thu, 2 Apr 2015 09:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dpUlEYgxdXOO; Thu, 2 Apr 2015 09:07:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C821ACD98; Thu, 2 Apr 2015 09:07:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150402160752.3534.5973.idtracker@ietfa.amsl.com> Date: Thu, 02 Apr 2015 09:07:52 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-alg-agility-00.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:07:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : PKINIT Algorithm Agility Authors : Love Hornquist Astrand Larry Zhu Margaret Wasserman William J. Mills Filename : draft-ietf-kitten-pkinit-alg-agility-00.txt Pages : 18 Date : 2015-04-02 Abstract: This document updates PKINIT, as defined in RFC 4556, to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-kitten-pkinit-alg-agility-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 nobody Thu Apr 2 09:20:28 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AAD1B2D45 for ; Thu, 2 Apr 2015 09:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hUNYW5i1Zf5 for ; Thu, 2 Apr 2015 09:20:13 -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 92AED1B2D30 for ; Thu, 2 Apr 2015 09:20:13 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-08-551d6c3cb1d6 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id A6.70.03451.D3C6D155; Thu, 2 Apr 2015 12:20:13 -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 t32GK762026256; Thu, 2 Apr 2015 12:20:07 -0400 Received: from [18.101.8.229] (vpn-18-101-8-229.mit.edu [18.101.8.229]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t32GK5Im007881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 2 Apr 2015 12:20:06 -0400 Message-ID: <551D6C35.4080108@mit.edu> Date: Thu, 02 Apr 2015 12:20:05 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Kaduk , kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6nomubIxtqcHAOm8XRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfxDVcF1sYrfX7qYGxj7hboYOTkkBEwkbi2bxQRhi0lcuLee rYuRi0NIYDGTxNbJ51kgnA2MErfX7mGHcA4zSbzofcsO0sIroCYx78FUsHYWAVWJBe33mUFs NgFlifX7t7KA2KICYRKz111khKgXlDg58wlYXETAWOLuzxtgtrCAi8SsLSvAZgoJOEq8XHgF aCYHB6eAk8TtxyEgYWYBPYkd13+xQtjyEs1bZzNPYBSYhWTqLCRls5CULWBkXsUom5JbpZub mJlTnJqsW5ycmJeXWqRrqpebWaKXmlK6iREcki5KOxh/HlQ6xCjAwajEw5uxRyZUiDWxrLgy 9xCjJAeTkijvzEzZUCG+pPyUyozE4oz4otKc1OJDjBIczEoivFppQDnelMTKqtSifJiUNAeL kjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQlexmygRsGi1PTUirTMnBKENBMHJ8hwHqDhQiA1 vMUFibnFmekQ+VOMilLivNEgCQGQREZpHlwvLGW8YhQHekWY1x2kigeYbuC6XwENZgIa7DBP GmRwSSJCSqqB0VjS8sfCdU9SawwVBPM5/y91lZ1kICGdt3fH7vSrQaXNE/Qic1fz6tz6oj8h fa0DZ8jdd1MmVyctE/yiav7t6JITJybUXOZKs//7pPr9AckDNrbVnbu4zFkCtQ7MMC7KFTg6 we+xl9LbG3MOXuENerPV8RB3Sf+NHWeFvBgdJ/9f0dO+cYd1lBJLcUaioRZzUXEiAFi9Dtj0 AgAA Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 16:20:27 -0000 On 03/30/2015 12:40 PM, Benjamin Kaduk wrote: > This message begins the Working Group Last Call (WGLC) of "AES Encryption > with HMAC-SHA2 for Kerberos 5" . > The WGLC will last two weeks, ending on Monday, April 13th. I put together a simple implementation of this draft in Python, and verified some of the test vectors (but not all; see below). There are several aspects of the enctype design whose motivations are unclear to me. They affect performance but not security. They are: * For the 192-bit security level, why use SHA-384 and truncate to 192 bits? Why not use SHA-256 and truncate to 192 bits? * Why use a 192-bit HMAC key for Ki and Kc but not for Kp? * Why use 128/256-bit PRF output lengths? Why not just output the full hash? It can't be for consistency with RFC 3962, as aes256-cts-hmac-sha1-96 has a 128-bit PRF output length. It can't be out of some desire to consistently truncate SHA-2 results in half, or we would have 128/192-bit output lengths. I have one concern about formal correctness: * Following the lead of the simplified profile, the formulation of the key derivation function in section 3 ends by calling random-to-key() as if the result had the same abstract type as a protocol key. But for the AES256 variant, Ki and Kc have a 192-bit length, so it cannot be of the same abstract type as a 256-bit protocol key. The formalism is also sloppy because it depends on context; instead of taking a length parameter, it uses an implicit length based on what operation the invoker is performing. In a similar vein, section 3 talks about what the input constant is for each derivation use; this is not the case for RFC 3961 or RFC 6803 and seems out of place. I have several concerns about the presentation of the test vectors: * The PRF test vectors do not list a base key; instead it lists a Kp value. This requires tests to exercise only a component of the PRF implementation, which may be inconvenient. The base keys are present in the key derivation test vectors, but this is not immediately clear. * The encryption test vectors do not list base keys and key usages; instead they only list "AES key" and "HMAC key" values which are presumably Kc and Ki. For the first 128-bit test vector, the base key and usage is recoverable from the key derivation test vectors, but that does not appear to be the case for any of the other encryption test vectors. Because of this, I only verified the first encryption test vector. * The checksum test vectors do not list a base key or key usage. The base keys and usages are present in the key derivation test vectors, but this is not immediately clear. (It looks like RFC 6803 is missing key usages for encryption test vectors, which may have contributed to some of the above issues. I will submit an erratum.) From nobody Thu Apr 2 10:21:39 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A44B1AD364 for ; Thu, 2 Apr 2015 10:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADKnnHkL3-Cc for ; Thu, 2 Apr 2015 10:21:35 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6BAF1AD2C0 for ; Thu, 2 Apr 2015 10:21:35 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t32HLYfh018202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 2 Apr 2015 13:21:34 -0400 Received: from pspacek.brq.redhat.com ([10.34.250.188]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t32HLWxM013035 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 2 Apr 2015 13:21:33 -0400 Message-ID: <551D7A9C.4030309@redhat.com> Date: Thu, 02 Apr 2015 19:21:32 +0200 From: Petr Spacek Organization: Red Hat User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Greg Hudson , Nathaniel McCallum References: <1425578271.2715.5.camel@redhat.com> <551121EE.1070300@redhat.com> <1427200587.29553.0.camel@redhat.com> <55117291.2040002@mit.edu> In-Reply-To: <55117291.2040002@mit.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Kerberos Service Discovery using DNS X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Apr 2015 17:21:37 -0000 On 24.3.2015 15:20, Greg Hudson wrote: > On 03/24/2015 08:36 AM, Nathaniel McCallum wrote: >> On Tue, 2015-03-24 at 09:35 +0100, Petr Spacek wrote: >>> It seems like a good idea to standardize _kerberos-master URI record >>> too (with >>> semantics equal to the one described on >>> http://web.mit.edu/Kerberos/krb5-1.12/doc/admin/realm_config.html). > >> I *think* this might be MIT specific. Maybe Greg can answer that? > > It does look like only MIT krb5 implements it. > > The semantics of _kerberos-master are "these addresses represent KDCs > (usually just one) which are more up to date than the other KDCs in the > realm, so retry with one of these if your first try fails for most > reasons." In some realms the master KDC isn't one of the regular KDCs, > in order to shed the majority of the load from the KDC which is also > running kadmind. > > These semantics are not generally needed for a realm with fast > replication (iprop with low polling delay, LDAP, etc.), but there are > enough realms with slow replication that we're not about to discard > those semantics. > > It might be good if master KDC entries could be obtained in the same DNS > lookup as regular KDC entries, but none of the ways I can think of to do > it are particularly elegant. We would need to be able to annotate each > URI with "this is also a master KDC" or "this is only a master KDC". > Shoving that tri-state into each URI scheme wouldn't be very elegant; > designating magic priority values for the URI record would be a layering > violation. It's not really a big deal if a second DNS lookup is needed > for the fallback. > > I have no strong opinion on whether the discovery standard needs to talk > about this. MIT krb5 can always continue to implement it as a > non-standardized feature, using the same lookup behavior as the > _kerberos URI record but with the label changed to _kerberos-master. IMHO: I would not optimize for fallback when it means obfuscating the original idea. I.e. a separate DNS name like _kerberos_master with URIs of masters sounds fine to me. Also, I do not see a reason not to standardize it because it is deadly simple/cheap and allows Heimdal and others to be interoperable if they decide to support this feature in future. -- Petr^2 Spacek From nobody Fri Apr 3 09:04:17 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115D51AC3D7 for ; Fri, 3 Apr 2015 09:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0X4NztahW95 for ; Fri, 3 Apr 2015 09:04:14 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63BA81AC3E0 for ; Fri, 3 Apr 2015 09:04:14 -0700 (PDT) Received: from [192.168.131.146] ([80.92.114.249]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0Ln8gj-1Z5g3T2Yft-00hKAr; Fri, 03 Apr 2015 18:04:10 +0200 Message-ID: <551EB9F9.6050909@gmx.net> Date: Fri, 03 Apr 2015 18:04:09 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Stephen Farrell , "kitten@ietf.org" References: <5515A313.4010707@cs.tcd.ie> In-Reply-To: <5515A313.4010707@cs.tcd.ie> OpenPGP: id=4D776BC9 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nMCkpKdKrCcmi7GLGsSGVEJbGMJQe1iAU" X-Provags-ID: V03:K0:xGfWRoeGttv+ZKrgiI4VLN8AgOF0NCevWdGoVnKo2FGSRTHLglk IrhCO4Lk0MHL488Ua5GESNSlK8FWG6+TV08brgGumf4RAieyZ+qyZzxR7CBVMD3p+Aiu9uh oKjB4h2vptcJ6elxYvU+JPLXHqEhJfp+aDvHTCC0CzOeQHYes/PClEQw9dG8aW3eIVPJ+u0 9693OFwlsvghr30YpEb0A== X-UI-Out-Filterresults: notjunk:1; Archived-At: Subject: Re: [kitten] thanks to Shawn X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2015 16:04:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nMCkpKdKrCcmi7GLGsSGVEJbGMJQe1iAU Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thank you Shawn for all your work and for helping moving our documents smoothly through the IETF process. On 03/27/2015 07:36 PM, Stephen Farrell wrote: >=20 > At the end of the meeting today, we had Shawn fire himself as > WG chair (he hit the datatracker button himself:-). >=20 > So many thanks Shawn for 8 years good work, and thanks also to > Ben and Matt for running with this in future. >=20 > Cheers, > S. >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 --nMCkpKdKrCcmi7GLGsSGVEJbGMJQe1iAU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJVHrn5AAoJEGhJURNOOiAtYjIH/ivQJxx0URcWu8RclacO8+MX BoshCVN/FpiqFxyeAmcuMx6/ldjL7HsaX6yFIUdK2mx/Fs4MNV43gCmLWGojcNhf Xix/SvLCNjR8NVyup0GqwLRlShIs8blHM08Qlqg90mEYcCnN4INJzsEtbX5FlD8Z q/9ao9viI25TeMpDuMRpcn2lN2MqXsuEYwyKkwA9zBVgocKSzJCQ4TZqN4re+vZZ tFCKAQGyTkV7kYB9WlVgN96YtWWdxZJ5LspjEvQCihuI4Z4f8cPI8J87wEkqVAV/ 1elNDUNJlcVz/oKnOOZm7vLChALsvHs0tqtLOpO6CLBThOeYg+ldsgbeCxP7axA= =GNY0 -----END PGP SIGNATURE----- --nMCkpKdKrCcmi7GLGsSGVEJbGMJQe1iAU-- From nobody Wed Apr 8 13:03:47 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D69111B35C6 for ; Wed, 8 Apr 2015 13:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guhpxGfmLjnx for ; Wed, 8 Apr 2015 13:03:44 -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 355231B35C0 for ; Wed, 8 Apr 2015 13:03:44 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-1c-5525899f6851 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id C0.15.03451.F9985255; Wed, 8 Apr 2015 16:03:43 -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 t38K3hQO002109 for ; Wed, 8 Apr 2015 16:03:43 -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 t38K3f4J015553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 8 Apr 2015 16:03:42 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t38K3edU006503; Wed, 8 Apr 2015 16:03:40 -0400 (EDT) Date: Wed, 8 Apr 2015 16:03:40 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixG6nrju/UzXU4NxpLYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY157B0vBNq6Kx3eXszQwHuXoYuTkkBAwkXj4bxMjhC0mceHe erYuRi4OIYHFTBIH5v5mh3COMUoc3/yKFcK5ziTRsPQiE0iLkEC9xMEXO5hBbBYBLYn7C86A xdkEVCRmvtnIBmKLCAhL7N76DqxGWMBFYtaWFUBTOTg4BZwkbj8OAQnzCjhKLNv0iB1ipKPE y4VXwMaICuhIrN4/hQWiRlDi5MwnYDYz0Krl07exTGAUmIUkNQtJagEj0ypG2ZTcKt3cxMyc 4tRk3eLkxLy81CJdU73czBK91JTSTYzg4HNR2sH486DSIUYBDkYlHl6BxSqhQqyJZcWVuYcY JTmYlER5I5NVQ4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8GaB5HhTEiurUovyYVLSHCxK4ryb fvCFCAmkJ5akZqemFqQWwWRlODiUJHgftQM1ChalpqdWpGXmlCCkmTg4QYbzAA0P7AAZXlyQ mFucmQ6RP8WoKCXO6wqSEABJZJTmwfXCksMrRnGgV4R5p4JU8QATC1z3K6DBTECD+Z8pgQwu SURISTUwTvI4vz3/qu6D+9UaTziuSzKpc/Fs/K5qW3Ev5d8bZ3lx5t6UCP3400tSFpoeXs39 3XRjqPlNXd7/blEce1xMlu878ltjSfcN5nXxffPLODcbLti2KyxgrWezyY8uPjsmFu22qFsT T+vyZ6z1cNZLPL84qTe5W/lV/VYnfqEdR7MkPHf8zLJWYinOSDTUYi4qTgQAvwwp9OkCAAA= Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 20:03:46 -0000 Sorry for the slighty-late reminder; there is less than a week remaining in this WGLC period. -Ben On Mon, 30 Mar 2015, Benjamin Kaduk wrote: > This message begins the Working Group Last Call (WGLC) of "AES Encryption > with HMAC-SHA2 for Kerberos 5" . > The WGLC will last two weeks, ending on Monday, April 13th. The draft is > available at: > > https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-06 > > Please review the document and send comments to the Working Group mailing > list or the co-chairs > before the end of the WGLC. Any and all comments on the document are > sought in order to access the strength of consensus. Even if you have > read and commented on this or earlier versions of the draft, please feel > free to comment again. This is particularly important if you found issues > with the previous version. > > As a reminder, comments can be anything from "this looks fine" to "this is > a horrible idea"; they can include suggestions for minor editorial > corrections to significant editorial changes. > > > - Your Kitten Chairs > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Wed Apr 8 14:26:52 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66F51B36A2 for ; Wed, 8 Apr 2015 14:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDDqkbRrx7Av for ; Wed, 8 Apr 2015 14:26:48 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E01541B36C1 for ; Wed, 8 Apr 2015 14:26:47 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-11-55259d168136 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F4.38.03389.61D95255; Wed, 8 Apr 2015 17:26:46 -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 t38LQjsm028653; Wed, 8 Apr 2015 17:26:46 -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 t38LQi6x014900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 8 Apr 2015 17:26:45 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t38LQfxB023329; Wed, 8 Apr 2015 17:26:41 -0400 (EDT) Date: Wed, 8 Apr 2015 17:26:41 -0400 (EDT) From: Benjamin Kaduk To: Greg Hudson In-Reply-To: <551D6C35.4080108@mit.edu> Message-ID: References: <551D6C35.4080108@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixCmqrSs2VzXUYNYubYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY+Xcf6wFa/UrDm3rZG5gfKzaxcjJISFgIjH5zSR2CFtM4sK9 9WxdjFwcQgKLmSSmHL4F5WxglFjROZcVwjnIJPHh5zuwFiGBeolbsycwg9gsAloSe95OZQGx 2QRUJGa+2cgGYosIKEr8XvmWEcRmFhCWWH9uBli9sICLxKwtK4DmcHBwCqhLvJ/PBBLmFXCU +HtsGwvE+BiJ5sbJYOWiAjoSq/dPYYGoEZQ4OfMJC8RILYnl07exTGAUnIUkNQtJagEj0ypG 2ZTcKt3cxMyc4tRk3eLkxLy81CJdE73czBK91JTSTYzgoJTk38H47aDSIUYBDkYlHl6BxSqh QqyJZcWVuYcYJTmYlER5d81WDRXiS8pPqcxILM6ILyrNSS0+xCjBwawkwnt7JlCONyWxsiq1 KB8mJc3BoiTOu+kHX4iQQHpiSWp2ampBahFMVoaDQ0mCl3cOUKNgUWp6akVaZk4JQpqJgxNk OA/QcA+QGt7igsTc4sx0iPwpRkUpcd4zIBcJgCQySvPgemFJ4xWjONArwrwWIO08wIQD1/0K aDAT0GD+Z0ogg0sSEVJSDYwynjEyKva3dMJn76/gzp29s3Vyr12V5PqbMt8/vTnBeF73mXVl RNPFCvtHR29KuYXU+eUpcCsKFJqYOyvF7l7fupinz8RZv/TVi6KY5Cs5ZkrctrtV3xxm4F4Z m8kWsEExcVXWiweaGxWfzD7c+2Dex+7zZiq2Tz83qFmzpzyqXxGXqWPhpsRSnJFoqMVcVJwI AK632Yr1AgAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 21:26:51 -0000 On Thu, 2 Apr 2015, Greg Hudson wrote: > On 03/30/2015 12:40 PM, Benjamin Kaduk wrote: > > This message begins the Working Group Last Call (WGLC) of "AES Encryption > > with HMAC-SHA2 for Kerberos 5" . > > The WGLC will last two weeks, ending on Monday, April 13th. > > I put together a simple implementation of this draft in Python, and > verified some of the test vectors (but not all; see below). Thank you! > There are several aspects of the enctype design whose motivations are > unclear to me. They affect performance but not security. They are: > > * For the 192-bit security level, why use SHA-384 and truncate to 192 > bits? Why not use SHA-256 and truncate to 192 bits? I did not go on a full trawl through the archives, but http://www.ietf.org/mail-archive/web/kitten/current/msg05307.html implies that NIST is generating a document covering "what you get from what you used" indicating that SHA-256 only gives you 128 bits, under some set of assumptions. > * Why use a 192-bit HMAC key for Ki and Kc but not for Kp? I don't think there is logic supporting this choice in the list archives; if I remember correctly, Kp was added rather late in the document's history, and the decision to have an explicit intermediate Kp instead of just making the PRF use the base key direction (in some form) was made pretty arbitrarily ("it feels better to keep the behavior parallel across enctypes" or thereabouts). Leaving k as 256 allows the PRF = k-truncate(HMAC-SHA2(Kp, octet-string)) to produce a pseudo-random function output which is a multiple of the random-to-key input size (and the underlying cipher block size), which is a nice feature to retain. I don't know of a reason why we could not retain 256-truncate using a 192-bit Kp, though. > * Why use 128/256-bit PRF output lengths? Why not just output the full > hash? It can't be for consistency with RFC 3962, as > aes256-cts-hmac-sha1-96 has a 128-bit PRF output length. It can't be > out of some desire to consistently truncate SHA-2 results in half, or we > would have 128/192-bit output lengths. I think there is some desire to always truncate SHA-2 results in half, though, for the reasons mentioned above. But a 192-bit output would not be a multiple of the blocksize or random-to-key input size, so in that sense (random-to-key input), 256 bits makes more sense. This is probably "okay" in the sense of wanting to always cut SHA-2 outputs in half, because the aes256-...-192 enctype only claims to provide 192 bits of security. > I have one concern about formal correctness: > > * Following the lead of the simplified profile, the formulation of the > key derivation function in section 3 ends by calling random-to-key() as > if the result had the same abstract type as a protocol key. But for the > AES256 variant, Ki and Kc have a 192-bit length, so it cannot be of the > same abstract type as a 256-bit protocol key. The formalism is also So random-to-key() only applies for generating base keys, and the derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)? Or is the argument rather that since we are not using the simplified profile, we just don't need random-to-key() at all because we are defining things manually and can make use of the fact that it is the identity function for these enctypes? > sloppy because it depends on context; instead of taking a length > parameter, it uses an implicit length based on what operation the > invoker is performing. In a similar vein, section 3 talks about what > the input constant is for each derivation use; this is not the case for > RFC 3961 or RFC 6803 and seems out of place. So you want to rely just on the (type of the) key being derived and not mention the last octet of the constant? I think that would be a valid way to specify things, but want to confirm the nature of your comment. > I have several concerns about the presentation of the test vectors: > > * The PRF test vectors do not list a base key; instead it lists a Kp > value. This requires tests to exercise only a component of the PRF > implementation, which may be inconvenient. The base keys are present in > the key derivation test vectors, but this is not immediately clear. We could add text so the PRF test vectors say "Kp value (repeated from above):"; would that help? > * The encryption test vectors do not list base keys and key usages; > instead they only list "AES key" and "HMAC key" values which are > presumably Kc and Ki. For the first 128-bit test vector, the base key > and usage is recoverable from the key derivation test vectors, but that > does not appear to be the case for any of the other encryption test > vectors. Because of this, I only verified the first encryption test vector. Hmm. I don't really want to propose removing test vectors to replace them with new ones, but could we add some additional test vectors which do possess the desired properties? (I.e., that the Kc and Ki are listed in a previous test vector from base key and usage, or that they are test vectors starting from base key.) > * The checksum test vectors do not list a base key or key usage. The > base keys and usages are present in the key derivation test vectors, but > this is not immediately clear. Similarly to the PRF, does "HMAC key (repeated from above):" help enough? > (It looks like RFC 6803 is missing key usages for encryption test > vectors, which may have contributed to some of the above issues. I will > submit an erratum.) Thanks. My own review notes that section 8.2 contains an extra space in "The encryption". It additionally claims that this document is proposing "the use of [...] AES-256 with a 192-bit key", but this is confusing since AES-256 definitionally requires a 256-bit encryption key, and the base key is also a 256-bit key. Perhaps "AES-256 with some derived keys of length 192 bits" is better, albeit clunky. -Ben From nobody Wed Apr 8 15:48:49 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ADE81A90E8 for ; Wed, 8 Apr 2015 15:48:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0DfA_88nkV7 for ; Wed, 8 Apr 2015 15:48:45 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1907B1A90E6 for ; Wed, 8 Apr 2015 15:48:45 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-00-5525b04be1e7 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id D5.A9.03493.B40B5255; Wed, 8 Apr 2015 18:48:44 -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 t38Mmc9j013622; Wed, 8 Apr 2015 18:48:38 -0400 Received: from [18.101.8.156] (vpn-18-101-8-156.mit.edu [18.101.8.156]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t38Mma6I008143 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 8 Apr 2015 18:48:37 -0400 Message-ID: <5525B044.8070509@mit.edu> Date: Wed, 08 Apr 2015 18:48:36 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <551D6C35.4080108@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrOuzQTXUYMV5Joujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro/PzK+aCKRoVC579YGpg7FLoYuTkkBAwkZi1fiU7hC0mceHe erYuRi4OIYHFTBJLGj+zQjgbGCWuTX7IDOEcZpL4+GYlUBkHB6+AmsT6HwkgJouAqsSBackg g9gElCXW79/KAmKLCoRJzF53kRHE5hUQlDg58wlYXERASWLx2RY2EJtZQFjiwva9rCC2sICL xKwtK9ghVk1ilJgzbxczSIJTwEli79L17BANehI7rv9ihbDlJZq3zmaewCg4C8mOWUjKZiEp W8DIvIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXXC83s0QvNaV0EyMoWNldVHYwNh9SOsQowMGo xMMrsFglVIg1say4MvcQoyQHk5Io77mVqqFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgdVgPl eFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeFesA2oULEpNT61Iy8wp QUgzcXCCDOcBGn4dpIa3uCAxtzgzHSJ/ilFRSpz3NEhCACSRUZoH1wtLJq8YxYFeEeZlXA9U xQNMRHDdr4AGMwEN5n+mBDK4JBEhJdXAyMuY8MB/R/CUM3c+LlResSayLPqzdMadhfsb1sWl mWnq9L04P+fumWz18Hkv2xufntfuF05zZu2+acLc1bNBP+HGl0dS95qXXpJce7Gt2/78/Hnn NylU3/Zjmnbiana1/TrmY82Jf4NPum02i0rQfryl+usKIyY/kfnbpm7bWt+qwaEo4FlWp8RS nJFoqMVcVJwIAIggvfwBAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Apr 2015 22:48:47 -0000 On 04/08/2015 05:26 PM, Benjamin Kaduk wrote: > I did not go on a full trawl through the archives, but > http://www.ietf.org/mail-archive/web/kitten/current/msg05307.html implies > that NIST is generating a document covering "what you get from what you > used" indicating that SHA-256 only gives you 128 bits, under some set of > assumptions. I do not understand what assumptions would yield a security level of 128 bits from SHA-256 truncated to 192 bits, and a security level of 192 bits from SHA-384 truncated to 192 bits. If there is a concern about birthday attacks on the integrity tag, then we can't get away with truncating at all; we would need to send a 256-bit tag for the 128-bit security level, and a 384-bit tag for the 192-bit security level. I wonder if NIST finished its document in the interim. >> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp? This was probably a dumb question, and really devolves into "why use a 256-bit PRF output length?" For the 192-bit security level, Ki and Kc are used to generate a 192-bit tag, but Kp is used to generate a 256-bit PRF. [Regarding truncation of the PRF output:] > I think there is some desire to always truncate SHA-2 results in half, > though, for the reasons mentioned above. I would like to better understand these reasons. > So random-to-key() only applies for generating base keys, and the > derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)? Yes. RFC 3961 defines random-to-key() as producing a protocol key. It is probably a conceptual error that RFC 3961 section 5.1 uses random-to-key() as the last step of its key derivation function. That error would be especially confusing in the new context, where derived HMAC keys can have different lengths than protocol keys. > Or is the argument rather that since we are not using the simplified > profile, we just don't need random-to-key() at all because we are defining > things manually and can make use of the fact that it is the identity > function for these enctypes? No, we need a random-to-key(); it is part the RFC 3961 definition of an encryption algorithm profile. By contrast, key derivation is not part of this definition; it's just an internal feature of every non-single-DES encryption type so far. >> sloppy because it depends on context; instead of taking a length >> parameter, it uses an implicit length based on what operation the >> invoker is performing. In a similar vein, section 3 talks about what >> the input constant is for each derivation use; this is not the case for >> RFC 3961 or RFC 6803 and seems out of place. > So you want to rely just on the (type of the) key being derived and not > mention the last octet of the constant? I think that would be a valid way > to specify things, but want to confirm the nature of your comment. My suggestion is to: * Give the key derivation function KDF-HMAC-SHA2() an explicit length parameter, and remove the discussion of what its value is for each use. Provide a length argument in each use of KDF-HMAC-SHA2() elsewhere in the document. This argument will probably need to be given symbolically, as it varies between the 128-bit and 192-bit security levels. * Remove the discussion of what the constant values are from section 3. >> I have several concerns about the presentation of the test vectors: >> >> * The PRF test vectors do not list a base key; instead it lists a Kp >> value. This requires tests to exercise only a component of the PRF >> implementation, which may be inconvenient. The base keys are present in >> the key derivation test vectors, but this is not immediately clear. > We could add text so the PRF test vectors say "Kp value (repeated from > above):"; would that help? I think it would be better to explicitly list the base key. If it happens to be the same as the base key from a previous test vector, that's not really important. >> * The encryption test vectors do not list base keys and key usages; >> instead they only list "AES key" and "HMAC key" values which are >> presumably Kc and Ki. For the first 128-bit test vector, the base key >> and usage is recoverable from the key derivation test vectors, but that >> does not appear to be the case for any of the other encryption test >> vectors. Because of this, I only verified the first encryption test vector. > Hmm. I don't really want to propose removing test vectors to replace them > with new ones, but could we add some additional test vectors which do > possess the desired properties? (I.e., that the Kc and Ki are listed in a > previous test vector from base key and usage, or that they are test > vectors starting from base key.) I don't think there's anything precious about the currently listed test vectors. If the draft authors possess the base keys they used for the encryption test vectors, they can provide them; otherwise they can generate new test vectors and we can discard the old ones. Including encryption test vectors with missing base keys just seems frustrating to an implementor. From nobody Thu Apr 9 12:07:05 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2AF81A8A66 for ; Thu, 9 Apr 2015 12:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ-Tv6w0QJsB for ; Thu, 9 Apr 2015 12:07:03 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4081A8A0D for ; Thu, 9 Apr 2015 12:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1428606400; x=1429211200; q=dns/txt; h=VBR-Info:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: OpenPGP:Content-Type; bh=EvgD2PdNv+aINoOQ0suZ1Yz/kpxpHxmDJMnu07W 7Eis=; b=HSL8fhL62YeE3ZVfmg2TtPGtUo35c8ZvkmFZ/nIkPtiBU5W8ctobyo2 YrLrxHOgQbguGvCXg823bhWFnyZ81U7vnG1a2pIzbqFx5p3p084kAkUGsn6s9HGM 0u0DpVF3ZsEUD25DNtr1BXoDz7NehxWrtYggMkKfwOOOQq0RnDgQ= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Thu, 09 Apr 2015 15:06:40 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Thu, 09 Apr 2015 15:06:40 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v15.0.0) with ESMTPSA id md50000853589.msg for ; Thu, 09 Apr 2015 15:06:39 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Thu, 09 Apr 2015 15:06:39 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1541f6abd6=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <5526CDBA.3030102@secure-endpoints.com> Date: Thu, 09 Apr 2015 15:06:34 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Greg Hudson , Benjamin Kaduk References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> In-Reply-To: <5525B044.8070509@mit.edu> OpenPGP: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020104020409030700090600" Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 19:07:04 -0000 This is a cryptographically signed message in MIME format. --------------ms020104020409030700090600 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greg, Thank you for performing this important review. The questions you have raised are significant. Do we have independent review from trusted cryptographers? I'm not one so will not try to review the math. On 4/8/2015 6:48 PM, Greg Hudson wrote: > On 04/08/2015 05:26 PM, Benjamin Kaduk wrote: >=20 >> Hmm. I don't really want to propose removing test vectors to replace = them >> with new ones, but could we add some additional test vectors which do >> possess the desired properties? (I.e., that the Kc and Ki are listed = in a >> previous test vector from base key and usage, or that they are test >> vectors starting from base key.) >=20 > I don't think there's anything precious about the currently listed test= > vectors. If the draft authors possess the base keys they used for the > encryption test vectors, they can provide them; otherwise they can > generate new test vectors and we can discard the old ones. Including > encryption test vectors with missing base keys just seems frustrating t= o > an implementor. >=20 My personal opinion is that the last call should not complete successfully if it is not possible to verify all of the test vectors. It would also be my preference that there be two interoperable implementations before the working group approves the document. Sincerely Jeffrey Altman --------------ms020104020409030700090600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhBA DYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMTAxMDIwMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGcbqJKktdkAl+5/3n tX55BjmX/xriz7C8WyWnI3IeaKHdj4Ya/VhSGfxBi58Uo4V7wV+VXAObK+EkLgO/t2OdtUOw z04SX8ZRpyZxvw5YlL50ieRRtk7SKxGfLVbxJV1pfGnRB6aM1zOxuETvdsiYclTcoRJXKoMH lUmrC+f4jF2bxu6DQPVod5Ho2kJc5ViO1mbnTz7L2fuRWmH9afQra8Q6UaJWnJHr1ZSqkWpj a0a2Gx47C85CYffAoTX1+ujuYwg0LA8C3RL0FnGvalH4dalsfTgpskhEGXKRpMMAli8Oq7bO Ob1oxziM9+yR5+v30vZ37adC2vx8L1m4F7WXAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFM2J7jAkKtP8wun+3s5rv727EDkeMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBALZrEhzBTZdbzJznEexkWvYmIu1A2s8B 95qMfk08aTvg+3D6F6wUGeZVJ/7x8vrTxIQ9vvYvfbXjDBdpWLnVoUaeEM2i//16x21NHqfA Fw5qtSxy4YQATuQIqevk96K2vIIjjL/vrIwZevwPBPpk/XhAI4Mfuzo89buT+pJB9pEVE8IC NUPVduydcZAJ0R0m8qQVIsKEYqAkULD1U6P8OKl8alblGFkFuqXISPbeMlg4OA8M5BV5IxHI GfUnXhOHH/AL1xE9GVt4DmGd8y96y+ljJHV/mD93NvJaH04W6ounDb8RBVt8DRvq0MLHtWap UHlG3zH8i/IJ8p9jQ5XdyRExggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEANiB9XZa6NrpcWXM/u DDIwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwNDA5MTkwNjM0WjAjBgkqhkiG9w0BCQQxFgQUOpAOIsfZd9AQ9lDbrNWAN143 to0wbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQA2IH1dlro2ulxZcz+4MMjCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBADYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEB AQUABIIBAHTQRdP282JcZZ/O+9qxdI/i1HDHp1GiWYyAKj1xBbx8dWRN8D1w6kYD85KUWCt0 pXZCx2HVPRce9QXtFhdtcl5qnP3gR+Udq8I98S9j/4T4gxB/dJNHPPmyxjYpLRc5/qrllOdo VctYG299X91ERG6+3/BM82rPdQxyHB1zifCt0UD988597mtApsUKHSmEk4UenrpFLO6qBHFu bWYVV4O4yHE584nCg1eGeJCxGMg1xq7PJSAjmflWR5bVV5cdi11icreppaaCfwaDIN3OTQYa 97b/yhv6x/TUJAwF5gjuR45trTb4UYEGGit5AnmQ4ZKg36e97JD7mTvoVMfs/6sAAAAAAAA= --------------ms020104020409030700090600-- From nobody Thu Apr 9 15:22:05 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8511B346F for ; Thu, 9 Apr 2015 15:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZJFv3l90w2o for ; Thu, 9 Apr 2015 15:21:56 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754D91B3470 for ; Thu, 9 Apr 2015 15:21:56 -0700 (PDT) Received: by qkx62 with SMTP id 62so1982180qkx.0 for ; Thu, 09 Apr 2015 15:21:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=I5T6cOHNLPkSEXVgpeOtnSHTszMitWV06wI+vbK+Xdo=; b=qIa8WlJzy+JlCGXBKVCYH+zH16j+O+OtzfyrvbkfCbdJ/Ce5zdpFq0d+OnUSvYGcuX 9JL9JazPzAajvJQf52mujiYSkilBWgF7HHAX+okcrNanwi2OYq+7IRqWfN+ywla5wREr gphVOQmt0wpZ+a+5Y7GIr0SfPcMdao6naDNhcVWRhhTFqv+0LdrntzhlXzedZyB7KbTe NnbGDshuHPhA4CepkBMkqxK3kK0Ar0UDFt1cXuY1tGK1YYjKdBYStcwIlMyqzQqghkeE prxoCDXcC0KBemm2AvevWywb8tc3vVsL4tCltmCQPootpyXVK0pSxRAVo//PK22l+cyp xUzg== MIME-Version: 1.0 X-Received: by 10.229.214.199 with SMTP id hb7mr40598182qcb.12.1428618115727; Thu, 09 Apr 2015 15:21:55 -0700 (PDT) Received: by 10.229.231.71 with HTTP; Thu, 9 Apr 2015 15:21:55 -0700 (PDT) In-Reply-To: <5525B044.8070509@mit.edu> References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> Date: Thu, 9 Apr 2015 18:21:55 -0400 Message-ID: From: Michael Jenkins To: Greg Hudson Content-Type: multipart/alternative; boundary=001a1132f7ea4ec82f0513521388 Archived-At: Cc: kitten@ietf.org, "mjjenki@tycho.ncsc.mil" Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 22:22:00 -0000 --001a1132f7ea4ec82f0513521388 Content-Type: text/plain; charset=UTF-8 Hi, sorry for the silence. I've been on travel and I wanted to make sure I got one of the original authors to help respond. So, we should be able to address all of Greg's concerns shortly. In the meantime, I can comment generally if simplistically on two things: Bit string lengths and bits-o'-security: When this draft was originally introduced to kitten, it was stated that it was to support draft-burgin-kerberos-suiteb < http://www.ietf.org/mail-archive/web/kitten/current/msg03802.html>. So there's an implicit presumption that one is working in one of two modes, 192-bit or 128-bit security, and consequently using either SHA-384 or SHA-256, respectively. In general, though, it's designed to make sense - you can't use SHA-256 to get a 192 bit key because a SHA-256 output has at most 128 bits of security no matter how you slice it. I am not an expert in attacks on hashes nor on hash-function construction (boy howdy!), so I'm not going to argue about whether this particular application is susceptible to this-or-that attack - ultimately the answer is "because Suite B". I'm not saying that as a hammer; I'm saying that's how the thing was pitched and accepted as a work-item back at version -02. Test vectors: I can nearly guarantee (see inheritance disclaimer above) that the Ke for the encryption test vector sets beyond the first 128-bit one came straight out of /dev/random, no doubt based on the fact that it was easier to do so than to figure out how to get access to Kelley's abandoned workfiles after he left for greener pastures (go him!). I can regenerate them taking a more soup-to-nuts approach. Mike J On Wed, Apr 8, 2015 at 6:48 PM, Greg Hudson wrote: > On 04/08/2015 05:26 PM, Benjamin Kaduk wrote: > > I did not go on a full trawl through the archives, but > > http://www.ietf.org/mail-archive/web/kitten/current/msg05307.html > implies > > that NIST is generating a document covering "what you get from what you > > used" indicating that SHA-256 only gives you 128 bits, under some set of > > assumptions. > > I do not understand what assumptions would yield a security level of 128 > bits from SHA-256 truncated to 192 bits, and a security level of 192 > bits from SHA-384 truncated to 192 bits. If there is a concern about > birthday attacks on the integrity tag, then we can't get away with > truncating at all; we would need to send a 256-bit tag for the 128-bit > security level, and a 384-bit tag for the 192-bit security level. > > I wonder if NIST finished its document in the interim. > > >> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp? > > This was probably a dumb question, and really devolves into "why use a > 256-bit PRF output length?" For the 192-bit security level, Ki and Kc > are used to generate a 192-bit tag, but Kp is used to generate a 256-bit > PRF. > > [Regarding truncation of the PRF output:] > > I think there is some desire to always truncate SHA-2 results in half, > > though, for the reasons mentioned above. > > I would like to better understand these reasons. > > > So random-to-key() only applies for generating base keys, and the > > derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)? > > Yes. RFC 3961 defines random-to-key() as producing a protocol key. It > is probably a conceptual error that RFC 3961 section 5.1 uses > random-to-key() as the last step of its key derivation function. That > error would be especially confusing in the new context, where derived > HMAC keys can have different lengths than protocol keys. > > > Or is the argument rather that since we are not using the simplified > > profile, we just don't need random-to-key() at all because we are > defining > > things manually and can make use of the fact that it is the identity > > function for these enctypes? > > No, we need a random-to-key(); it is part the RFC 3961 definition of an > encryption algorithm profile. By contrast, key derivation is not part > of this definition; it's just an internal feature of every > non-single-DES encryption type so far. > > >> sloppy because it depends on context; instead of taking a length > >> parameter, it uses an implicit length based on what operation the > >> invoker is performing. In a similar vein, section 3 talks about what > >> the input constant is for each derivation use; this is not the case for > >> RFC 3961 or RFC 6803 and seems out of place. > > > So you want to rely just on the (type of the) key being derived and not > > mention the last octet of the constant? I think that would be a valid > way > > to specify things, but want to confirm the nature of your comment. > > My suggestion is to: > > * Give the key derivation function KDF-HMAC-SHA2() an explicit length > parameter, and remove the discussion of what its value is for each use. > Provide a length argument in each use of KDF-HMAC-SHA2() elsewhere in > the document. This argument will probably need to be given > symbolically, as it varies between the 128-bit and 192-bit security levels. > > * Remove the discussion of what the constant values are from section 3. > > >> I have several concerns about the presentation of the test vectors: > >> > >> * The PRF test vectors do not list a base key; instead it lists a Kp > >> value. This requires tests to exercise only a component of the PRF > >> implementation, which may be inconvenient. The base keys are present in > >> the key derivation test vectors, but this is not immediately clear. > > > We could add text so the PRF test vectors say "Kp value (repeated from > > above):"; would that help? > > I think it would be better to explicitly list the base key. If it > happens to be the same as the base key from a previous test vector, > that's not really important. > > >> * The encryption test vectors do not list base keys and key usages; > >> instead they only list "AES key" and "HMAC key" values which are > >> presumably Kc and Ki. For the first 128-bit test vector, the base key > >> and usage is recoverable from the key derivation test vectors, but that > >> does not appear to be the case for any of the other encryption test > >> vectors. Because of this, I only verified the first encryption test > vector. > > > Hmm. I don't really want to propose removing test vectors to replace > them > > with new ones, but could we add some additional test vectors which do > > possess the desired properties? (I.e., that the Kc and Ki are listed in > a > > previous test vector from base key and usage, or that they are test > > vectors starting from base key.) > > I don't think there's anything precious about the currently listed test > vectors. If the draft authors possess the base keys they used for the > encryption test vectors, they can provide them; otherwise they can > generate new test vectors and we can discard the old ones. Including > encryption test vectors with missing base keys just seems frustrating to > an implementor. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > -- Mike Jenkins mjjenki@tycho.ncsc.mil - if you want me to read it only at my desk m.jenkins.364706@gmail.com - to read everywhere else 443-634-3951 --001a1132f7ea4ec82f0513521388 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, sorry for the silence. I've been on travel and I w= anted to make sure I got one of the original authors to help respond. So, w= e should be able to address all of Greg's concerns shortly. In the mean= time, I can comment generally if simplistically on two things:

Bit string lengths and bits-o'-security: When this draft was ori= ginally introduced to kitten, it was stated that it was to support draft-bu= rgin-kerberos-suiteb <http://www.ietf.org/mail-archive/web/kitten/cur= rent/msg03802.html>. So there's an implicit presumption that one= is working in one of two modes, 192-bit or 128-bit security, and consequen= tly using either SHA-384 or SHA-256, respectively.=C2=A0

In general, though, it's designed to make sense - you can't = use SHA-256 to get a 192 bit key because a SHA-256 output has at most 128 b= its of security no matter how you slice it. I am not an expert in attacks o= n hashes nor on hash-function construction (boy howdy!), so I'm not goi= ng to argue about whether this particular application is susceptible to thi= s-or-that attack - ultimately the answer is "because Suite B". I&= #39;m not saying that as a hammer; I'm saying that's how the thing = was pitched and accepted as a work-item back at version -02.

Test vectors: I can nearly guarantee (see inheritance discl= aimer above) that the Ke for the encryption test vector sets beyond the fir= st 128-bit one came straight out of /dev/random, no doubt based on the fact= that it was easier to do so than to figure out how to get access to Kelley= 's abandoned workfiles after he left for greener pastures (go him!). I = can regenerate them taking a more soup-to-nuts approach.
Mike J

On Wed, Apr 8, 2015 at 6:48 PM, Greg Hudson <ghudson@mit.edu> wrote:
On = 04/08/2015 05:26 PM, Benjamin Kaduk wrote:
> I did not go on a full trawl through the archives, but
> http://www.ietf.org/mail-archive/web/kitten/curre= nt/msg05307.html implies
> that NIST is generating a document covering "what you get from wh= at you
> used" indicating that SHA-256 only gives you 128 bits, under some= set of
> assumptions.

I do not understand what assumptions would yield a security level of= 128
bits from SHA-256 truncated to 192 bits, and a security level of 192
bits from SHA-384 truncated to 192 bits.=C2=A0 If there is a concern about<= br> birthday attacks on the integrity tag, then we can't get away with
truncating at all; we would need to send a 256-bit tag for the 128-bit
security level, and a 384-bit tag for the 192-bit security level.

I wonder if NIST finished its document in the interim.

>> * Why use a 192-bit HMAC key for Ki and Kc but not for Kp?

This was probably a dumb question, and really devolves into "wh= y use a
256-bit PRF output length?"=C2=A0 For the 192-bit security level, Ki a= nd Kc
are used to generate a 192-bit tag, but Kp is used to generate a 256-bit PRF.

[Regarding truncation of the PRF output:]
> I think there is some desire to always truncate SHA-2= results in half,
> though, for the reasons mentioned above.

I would like to better understand these reasons.

> So random-to-key() only applies for generating base keys, and the
> derivation of Kc/Ki/Ke/Kp should just be k-truncate(...)?

Yes.=C2=A0 RFC 3961 defines random-to-key() as producing a protocol = key.=C2=A0 It
is probably a conceptual error that RFC 3961 section 5.1 uses
random-to-key() as the last step of its key derivation function.=C2=A0 That=
error would be especially confusing in the new context, where derived
HMAC keys can have different lengths than protocol keys.

> Or is the argument rather that since we are not using the simplified > profile, we just don't need random-to-key() at all because we are = defining
> things manually and can make use of the fact that it is the identity > function for these enctypes?

No, we need a random-to-key(); it is part the RFC 3961 definition of= an
encryption algorithm profile.=C2=A0 By contrast, key derivation is not part=
of this definition; it's just an internal feature of every
non-single-DES encryption type so far.

>> sloppy because it depends on context; instead of taking a length >> parameter, it uses an implicit length based on what operation the<= br> >> invoker is performing.=C2=A0 In a similar vein, section 3 talks ab= out what
>> the input constant is for each derivation use; this is not the cas= e for
>> RFC 3961 or RFC 6803 and seems out of place.

> So you want to rely just on the (type of the) key being derived and no= t
> mention the last octet of the constant?=C2=A0 I think that would be a = valid way
> to specify things, but want to confirm the nature of your comment.

My suggestion is to:

* Give the key derivation function KDF-HMAC-SHA2() an explicit length
parameter, and remove the discussion of what its value is for each use.
=C2=A0Provide a length argument in each use of KDF-HMAC-SHA2() elsewhere in=
the document.=C2=A0 This argument will probably need to be given
symbolically, as it varies between the 128-bit and 192-bit security levels.=

* Remove the discussion of what the constant values are from section 3.

>> I have several concerns about the presentation of the test vectors= :
>>
>> * The PRF test vectors do not list a base key; instead it lists a = Kp
>> value.=C2=A0 This requires tests to exercise only a component of t= he PRF
>> implementation, which may be inconvenient.=C2=A0 The base keys are= present in
>> the key derivation test vectors, but this is not immediately clear= .

> We could add text so the PRF test vectors say "Kp value (repeated= from
> above):"; would that help?

I think it would be better to explicitly list the base key.=C2=A0 If= it
happens to be the same as the base key from a previous test vector,
that's not really important.

>> * The encryption test vectors do not list base keys and key usages= ;
>> instead they only list "AES key" and "HMAC key"= ; values which are
>> presumably Kc and Ki.=C2=A0 For the first 128-bit test vector, the= base key
>> and usage is recoverable from the key derivation test vectors, but= that
>> does not appear to be the case for any of the other encryption tes= t
>> vectors.=C2=A0 Because of this, I only verified the first encrypti= on test vector.

> Hmm.=C2=A0 I don't really want to propose removing test vectors to= replace them
> with new ones, but could we add some additional test vectors which do<= br> > possess the desired properties?=C2=A0 (I.e., that the Kc and Ki are li= sted in a
> previous test vector from base key and usage, or that they are test > vectors starting from base key.)

I don't think there's anything precious about the currently = listed test
vectors.=C2=A0 If the draft authors possess the base keys they used for the=
encryption test vectors, they can provide them; otherwise they can
generate new test vectors and we can discard the old ones.=C2=A0 Including<= br> encryption test vectors with missing base keys just seems frustrating to an implementor.

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



--
=
--001a1132f7ea4ec82f0513521388-- From nobody Thu Apr 9 15:26:47 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFAA1B3481 for ; Thu, 9 Apr 2015 15:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dl5rSAB6cDcu for ; Thu, 9 Apr 2015 15:26:44 -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 6D20A1B3477 for ; Thu, 9 Apr 2015 15:26:44 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-8b-5526fca357bd Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 60.16.03451.3ACF6255; Thu, 9 Apr 2015 18:26:43 -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 t39MQgvq026714; Thu, 9 Apr 2015 18:26:43 -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 t39MQe0r009535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Apr 2015 18:26:42 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t39MQeTG005191; Thu, 9 Apr 2015 18:26:40 -0400 (EDT) Date: Thu, 9 Apr 2015 18:26:40 -0400 (EDT) From: Benjamin Kaduk To: Jeffrey Altman In-Reply-To: <5526CDBA.3030102@secure-endpoints.com> Message-ID: References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <5526CDBA.3030102@secure-endpoints.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrLv4j1qoQdMeY4s/KyexWRzdvIrF gcljyZKfTB4n+86zBjBFcdmkpOZklqUW6dslcGV8bzYsOMJW8WFpF1MD4xLWLkZODgkBE4kp M7exQdhiEhfurQeyuTiEBBYzSZzcdgzK2cAosbD1IRNIlZDAQSaJ6SeEIex6iTtdy8AmsQho SSzv6mUEsdkEVCRmvtkINlVEwFCi7f9NoBoODmYBI4kLvzJAwsICLhKztqxgB7E5gY54dekp WCuvgKPExlPHWSD2XmWUeHX0FdgcUQEdidX7p7BAFAlKnJz5BMxmBtk7fRvLBEbBWUhSs5Ck FjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11cvNLNFLTSndxAgKU3YXpR2MPw8qHWIU4GBU 4uGd8EU1VIg1say4MvcQoyQHk5Iob/hntVAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrwfFwLl eFMSK6tSi/JhUtIcLErivJt+8IUICaQnlqRmp6YWpBbBZGU4OJQkeC/8AmoULEpNT61Iy8wp QUgzcXCCDOcBGv4LpIa3uCAxtzgzHSJ/ilGX486U/4uYhFjy8vNSpcR534IUCYAUZZTmwc2B pZdXjOJAbwnzvgKp4gGmJrhJr4CWMAEteW4ItqQkESEl1cC4UIQ/cuabR075Ec9PnGmZwOWo 90170809AScW23bdfq/6NWKui6jvSZdjMczB6QUPRD9tfHFFZV1GuuivO39WTH28NbjNV73o hZP1yTLh9Be/Euctd5z2+s/exEW/eFwWXH7j/k39xXohlarPwZp3b64xEToupOy82fz053U3 ov703fB92na0QomlOCPRUIu5qDgRAJho4jAKAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 22:26:46 -0000 Hi Jeffrey, On Thu, 9 Apr 2015, Jeffrey Altman wrote: > My personal opinion is that the last call should not complete > successfully if it is not possible to verify all of the test vectors. > > It would also be my preference that there be two interoperable > implementations before the working group approves the document. The authors have used two independent implementations to verify the test vectors; I have done some additional verification and Greg has done some different verification as well. The last I checked, two interoperable implementations was a requirement for full Internet Standard, and not required even for Proposed Standard documents, let alone the Information status this document claims to be targetting. Could you say a bit more about why you feel the situation is different here? -Ben From nobody Thu Apr 9 17:12:05 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150331B37BE for ; Thu, 9 Apr 2015 17:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZh_pAC3v2hS for ; Thu, 9 Apr 2015 17:12:01 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F38631B37BC for ; Thu, 9 Apr 2015 17:12:00 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-5e-5527154ff75a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id F3.E0.03359.F4517255; Thu, 9 Apr 2015 20:11:59 -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 t3A0BrYP026351; Thu, 9 Apr 2015 20:11:54 -0400 Received: from [18.101.8.186] (vpn-18-101-8-186.mit.edu [18.101.8.186]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3A0BoGg006936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 9 Apr 2015 20:11:52 -0400 Message-ID: <55271546.6020505@mit.edu> Date: Thu, 09 Apr 2015 20:11:50 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Jenkins References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1vUXVQ81eDLV3OLo5lUsFsu+XWWz 2Pj+FKMDs8fOWXfZPZYs+cnksbX5H2MAcxSXTUpqTmZZapG+XQJXxsU7cgVfRCvmT33C1sD4 TrCLkZNDQsBEYsr2JkYIW0ziwr31bF2MXBxCAouZJG6duMcK4WxglLh8YBdU5jCTxP75M9hA WngF1CQOT/jACmKzCKhKHJq3CsxmE1CWWL9/KwuILSoQJjHt93NWiHpBiZMzn4DFRQQMJBZN Wgc2h1kgX2LDlC1gZwgLuEjM2rKCHWLZJ0aJBVO+M4MkOAUCJbZ+OMYM0aAu8WfeJShbXqJ5 62zmCYyCs5DsmIWkbBaSsgWMzKsYZVNyq3RzEzNzilOTdYuTE/PyUot0DfVyM0v0UlNKNzGC w1qSZwfjm4NKhxgFOBiVeHhffFMNFWJNLCuuzD3EKMnBpCTKe41LPVSILyk/pTIjsTgjvqg0 J7X4EKMEB7OSCO8ZDqAcb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IE r7UIUKNgUWp6akVaZk4JQpqJgxNkOA/QcAWQGt7igsTc4sx0iPwpRkUpcd6nwkAJAZBERmke XC8s7bxiFAd6RZhXCqSdB5iy4LpfAQ1mAhr83FANZHBJIkJKqoExYnrjls0356xRu6RpXfFZ 6UOb5dzcZy72LtM/buW0iN4VyhQjnCWvVSC+tprhguafRblXy45tfi2noOaa/6vb+k9/RpP+ AZ6VPQXGnm/MjhxijljuatR5pXv9m133SgObloUeKzs+8cheBrcF/N8+3pxx9PkzeaYXW4yX zM9fWf9x2k9rBa8eJZbijERDLeai4kQAzwDonBYDAAA= Archived-At: Cc: kitten@ietf.org, "mjjenki@tycho.ncsc.mil" Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 00:12:03 -0000 On 04/09/2015 06:21 PM, Michael Jenkins wrote: > Bit string lengths and bits-o'-security: When this draft was originally > introduced to kitten, it was stated that it was to support > draft-burgin-kerberos-suiteb > . So > there's an implicit presumption that one is working in one of two modes, > 192-bit or 128-bit security, and consequently using either SHA-384 or > SHA-256, respectively. I am not familiar with what Suite B requires in detail. Looking at https://www.nsa.gov/ia/programs/suiteb_cryptography/ I do see that Suite B indicates the use of SHA-384 for TOP SECRET. I assume that it requires this because the weakest inherent aspect of a hash is its collision resistance, and SHA-384 has (we hope) a collision resistance strength of 192 bits. Some uses of a hash may not require collision resistance, but using SHA-384 means you're covered regardless. However, SHA-384 truncated to 192 bits does not have a collision resistance strength of 192 bits; it has a collision resistance strength of 96 bits. This is described in detail in SP 800-107 section 5.1, which is referenced by FIPS 180-4 section 7. I don't think any meaningful review would deem 192-truncate(HMAC-SHA-384(k, m)) to be stronger than 192-truncate(HMAC-SHA-256(k, m)) by any metric. > In general, though, it's designed to make sense - you can't use SHA-256 > to get a 192 bit key because a SHA-256 output has at most 128 bits of > security no matter how you slice it. I think it very much does matter how you slice it. For key derivation using an HMAC, collision resistance is not required, so it is entirely reasonable to use SHA-256 to generate a 192-bit key. In fact, the key derivation function used in this draft (from SP 800-108 section 5.1) can work securely even if more keying material is required than the HMAC output size. For the encryption integrity tag and checksum, collision resistance may be required for Suite B compliance (but I don't really know). But as mentioned above, if we're going to truncate the HMAC result down to 192 bits, we cannot achieve collision resistance strength greater than 96 bits no matter what hash function we use in the HMAC. In conclusion, to the best of my knowledge: * If the goal is to meet a checklist of Suite B requirements, using SHA-384 over SHA-256 internally might be necessary, but it really is just a meaningless checklist tick. Moreover, the small integrity tag and checksum lengths could mean that the draft doesn't actually satisfy Suite B--I can't speak confidently either way on that point. * If the goal is to achieve some real security strength, using truncated SHA-384 is not an improvement over using truncated SHA-256. From nobody Thu Apr 9 18:55:00 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5701A8F3D for ; Thu, 9 Apr 2015 18:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtOiyctEFy8s for ; Thu, 9 Apr 2015 18:54:57 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FF9D1A8F45 for ; Thu, 9 Apr 2015 18:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1428630875; x=1429235675; q=dns/txt; h=VBR-Info:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: OpenPGP:Content-Type; bh=SPbugMnzSDCK/kQQVnYpJGs9E1NFQ6DbEC5apgQ 1baE=; b=n/ufPRb+/mYojKmgzm8p6ANgmkotOPO80efZPnII69qrbNfLKKpgSRr MMj3fSKsZRFDsQZDEamj72NETIbF3WV6wcpdpLFNDA5lMqmefzSXKUK1/KdLxDj5 l8TSltUUGUsyEJRo6qIyJm+6FuoNr8A4KZwHbLEfOgucTFTu8KWA= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Thu, 09 Apr 2015 21:54:35 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Thu, 09 Apr 2015 21:54:35 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v15.0.0) with ESMTPSA id md50000853745.msg for ; Thu, 09 Apr 2015 21:54:34 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Thu, 09 Apr 2015 21:54:34 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1542ff95f5=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <55272D53.9020503@secure-endpoints.com> Date: Thu, 09 Apr 2015 21:54:27 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <5526CDBA.3030102@secure-endpoints.com> In-Reply-To: OpenPGP: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010303070405080007030900" Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 01:54:59 -0000 This is a cryptographically signed message in MIME format. --------------ms010303070405080007030900 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/9/2015 6:26 PM, Benjamin Kaduk wrote: > Hi Jeffrey, >=20 > On Thu, 9 Apr 2015, Jeffrey Altman wrote: >=20 >> My personal opinion is that the last call should not complete >> successfully if it is not possible to verify all of the test vectors. >> >> It would also be my preference that there be two interoperable >> implementations before the working group approves the document. >=20 > The authors have used two independent implementations to verify the tes= t > vectors; I have done some additional verification and Greg has done som= e > different verification as well. I am glad to hear this. Are there 3961 implementations available for public review? > The last I checked, two interoperable implementations was a requirement= > for full Internet Standard, and not required even for Proposed Standard= > documents, let alone the Information status this document claims to be > targetting. Could you say a bit more about why you feel the situation i= s > different here? The requirements that you mention are lower bounds that apply to all RFCs regardless of the IETF Area. Kitten is not any working group. It is a security working group whose RFCs are implemented and deployed as the basis for securing computer systems around the globe. The last "informational" Kerberos encryption type RC4-HMAC (RFC 4757) became one of the most widely deployed enc-types used for Kerberos authentication. Due to BCP 179 / RFC 6649 and draft-kaduk-kitten-des-des-des-die-die-die the Kerberos protocol is left with two related AES*-CTS-SHA1 encryption types for RFC 3961 based protocols. Regardless of what track this document is placed on it is going to be widely and rapidly deployed. As a result it is important that the working group ensure that the encryption type is correct and that independent implementations for the most widely used Kerberos implementations are available and are demonstrated to be interoperable. Without interoperable implementations there is very little justification in my opinion for publishing a security framework building block as an RFC. Its not as if the working group is going to come back and revise the RFC once it is deployed. Sincerely, Jeffrey Altman --------------ms010303070405080007030900 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhBA DYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMTAxMDIwMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGcbqJKktdkAl+5/3n tX55BjmX/xriz7C8WyWnI3IeaKHdj4Ya/VhSGfxBi58Uo4V7wV+VXAObK+EkLgO/t2OdtUOw z04SX8ZRpyZxvw5YlL50ieRRtk7SKxGfLVbxJV1pfGnRB6aM1zOxuETvdsiYclTcoRJXKoMH lUmrC+f4jF2bxu6DQPVod5Ho2kJc5ViO1mbnTz7L2fuRWmH9afQra8Q6UaJWnJHr1ZSqkWpj a0a2Gx47C85CYffAoTX1+ujuYwg0LA8C3RL0FnGvalH4dalsfTgpskhEGXKRpMMAli8Oq7bO Ob1oxziM9+yR5+v30vZ37adC2vx8L1m4F7WXAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFM2J7jAkKtP8wun+3s5rv727EDkeMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBALZrEhzBTZdbzJznEexkWvYmIu1A2s8B 95qMfk08aTvg+3D6F6wUGeZVJ/7x8vrTxIQ9vvYvfbXjDBdpWLnVoUaeEM2i//16x21NHqfA Fw5qtSxy4YQATuQIqevk96K2vIIjjL/vrIwZevwPBPpk/XhAI4Mfuzo89buT+pJB9pEVE8IC NUPVduydcZAJ0R0m8qQVIsKEYqAkULD1U6P8OKl8alblGFkFuqXISPbeMlg4OA8M5BV5IxHI GfUnXhOHH/AL1xE9GVt4DmGd8y96y+ljJHV/mD93NvJaH04W6ounDb8RBVt8DRvq0MLHtWap UHlG3zH8i/IJ8p9jQ5XdyRExggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEANiB9XZa6NrpcWXM/u DDIwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwNDEwMDE1NDI3WjAjBgkqhkiG9w0BCQQxFgQUnT3b5NWS8fT+jUB/v2Go5QeC AxIwbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQA2IH1dlro2ulxZcz+4MMjCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBADYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEB AQUABIIBAAK+o1nIs55O2T9u8a8PEnwfxtRS72kMrNS+34Bm4gAnHIOhuXeQMdcT7A/Z5HwX yJgoJfVCFRNri/cuRNvaYi7WSDcgprBDPZ7jvGjF7TDswwUNEVj5coMGM+twt72a9OGWMTjF 2irH8Cb/LbpPBh8VxLkznoz5g/x6jrKXbZ5/pQMPmv2r7JOTmUYFSLUQDHOscjkFiRVe4Z66 LYo6nMewldl/iU9ekpiTXh4hWRLlXqlTc7xleStbgo6R3N+zsqRrZDNOMXbhC5kGhtsRP4+C ipiN4sdySwjENiIi8vU+leEprDEeiho1OPvcHOr+ycli1xepM56AXqk9XdQeTSoAAAAAAAA= --------------ms010303070405080007030900-- From nobody Thu Apr 9 21:24:56 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EE31ACE88 for ; Thu, 9 Apr 2015 21:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG-6ahuIsiGD for ; Thu, 9 Apr 2015 21:24:54 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74C001ACE21 for ; Thu, 9 Apr 2015 21:24:54 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-b6-55275095ae08 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id CD.7A.03359.59057255; Fri, 10 Apr 2015 00:24:53 -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 t3A4Ol57031441; Fri, 10 Apr 2015 00:24:47 -0400 Received: from [18.101.8.186] (vpn-18-101-8-186.mit.edu [18.101.8.186]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3A4OjXt011838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 10 Apr 2015 00:24:46 -0400 Message-ID: <5527508D.6070808@mit.edu> Date: Fri, 10 Apr 2015 00:24:45 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jeffrey Altman , Benjamin Kaduk References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <5526CDBA.3030102@secure-endpoints.com> <55272D53.9020503@secure-endpoints.com> In-Reply-To: <55272D53.9020503@secure-endpoints.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT150aoB5q0NwgafFn5SQ2i6ObV7E4 MHksWfKTyeNk33nWAKYoLpuU1JzMstQifbsErowPL7cwF9xjrpj38ilLA2MjcxcjJ4eEgInE x8n/WSFsMYkL99azdTFycQgJLGaS2PC6jQUkISSwkVFi+dVSiMQRJonDj16wgyR4BdQk7l+e zwZiswioSryZvoIRxGYTUJZYv38rWLOoQJjEtN/PWSHqBSVOznwCFhcRiJI4OPUAWD2zgLDE he17wWqEBVwkZm1ZwQ6xbDOTRPPCQ0ALODg4gU59vUEJol5PYsf1X6wQtrzE9rdzmCcwCs5C smIWkrJZSMoWMDKvYpRNya3SzU3MzClOTdYtTk7My0st0jXUy80s0UtNKd3ECApgTkmeHYxv DiodYhTgYFTi4X3xTTVUiDWxrLgy9xCjJAeTkihvjbN6qBBfUn5KZUZicUZ8UWlOavEhRgkO ZiURXk8ToBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgSviT9Qo2BR anpqRVpmTglCmomDE2Q4D9DwAJAa3uKCxNzizHSI/ClGXY47U/4vYhJiycvPS5US540BKRIA KcoozYObA0s8rxjFgd4S5l0DUsUDTFpwk14BLWECWvLcUA1kSUkiQkqqgXHxvssP7J2UFA59 Ub/yvOyLKnfseYvvq7JV7lzpWS/uHrqI4dkUmR/9LJP3Loo4JBh6XUEynsWq0G7T9NzkHSWf b3uLmveuXaxVd8P5meeBWd80Y5LntH24dv7U64zNU5KVjI77xm5pzGvJ7gudubxP50XraUnh Sx4vLnDe+P3SvbX664Sqp1xKLMUZiYZazEXFiQDM/U9pFwMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 04:24:56 -0000 On 04/09/2015 09:54 PM, Jeffrey Altman wrote: > I am glad to hear this. Are there 3961 implementations available for > public review? My Python implementation is at: https://github.com/greghudson/pyk5 in crypto.py. No stability guarantees for that repository, though. I should note that my implementation assumes the default cipher state, as do all of the test vectors in the draft. (That's true of test vectors for all past enctypes, I'm pretty certain.) From nobody Fri Apr 10 00:11:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C091A0054 for ; Fri, 10 Apr 2015 00:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzOGWMMNcC6Y for ; Fri, 10 Apr 2015 00:10:58 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC0B41A0067 for ; Fri, 10 Apr 2015 00:10:53 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t3A7AqkB002691 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Apr 2015 07:10:53 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t3A7ApeF015493 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Apr 2015 07:10:52 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t3A7Ap9Z014267; Fri, 10 Apr 2015 07:10:51 GMT Received: from [192.168.10.107] (/123.119.33.16) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 10 Apr 2015 00:10:51 -0700 Message-ID: <55277772.3080408@oracle.com> Date: Fri, 10 Apr 2015 15:10:42 +0800 From: Weijun Wang User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Benjamin Kaduk , Jeffrey Altman References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <5526CDBA.3030102@secure-endpoints.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 07:11:02 -0000 I also verified the test vectors with Java: https://gist.github.com/wangweij/49d98745a461f12c1f54 Thanks Weijun On 4/10/2015 6:26 AM, Benjamin Kaduk wrote: > Hi Jeffrey, > > On Thu, 9 Apr 2015, Jeffrey Altman wrote: > >> >> It would also be my preference that there be two interoperable >> implementations before the working group approves the document. > From nobody Mon Apr 13 01:25:13 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4851B2EC5 for ; Mon, 13 Apr 2015 01:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZD7-iOlPjjZ for ; Mon, 13 Apr 2015 01:25:09 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id DFA2D1B2ECB for ; Mon, 13 Apr 2015 01:25:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id 6E9F448222 for ; Mon, 13 Apr 2015 10:25:04 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mW65ygpmGuXI for ; Mon, 13 Apr 2015 10:25:04 +0200 (CEST) Received: from [155.54.204.2] (alex.inf.um.es [155.54.204.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id 55DD33FA96 for ; Mon, 13 Apr 2015 10:25:03 +0200 (CEST) Message-ID: <552B7D5F.3000006@um.es> Date: Mon, 13 Apr 2015 10:25:03 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: kitten@ietf.org Content-Type: multipart/alternative; boundary="------------050504090102000709040600" Archived-At: Subject: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 08:25:12 -0000 This is a multi-part message in MIME format. --------------050504090102000709040600 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have a question regarding the GSS-API Naming Extensions (RFC 6680). As the document is written, it seems to assume that the attributes of a name are locally stored and available in the GSS Acceptor at the very moment the GSS context is established. In this way, when the GSS Acceptor calls the GSS_Inquire_name(), it obtains the complete set of attributes of the name, and it must stick to them. However, in relation with the work we are doing in http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10, what I'd like is to allow the GSS Acceptor to request name attributes that might not be available at the moment the GSS context is established (i.e. not listed in the results of GSS_Inquire_name()), but that can be obtained by interacting with another entity afterwards (e.g. SAML IdP, LDAP server, SQL database...). I see two approaches to achieve this: 1) Use the GSS_Get_name_attribute() call to request the desired attribute. By modifying the implementation of this call in the mechanism, instead of returning an error when the requested attribute is not available yet, the mechanism can get it from the source and return it. The main advantage of this approach is that it transparent from the point of view of the GSS Acceptor, that just uses the same call as it always does. Besides, it does not require an standardization effort, as it is solved in the implementation of each mechanism. 2) The second approach consists on defining a new GSS-API call: e.g. GSS_Request_name_attribute(). This call would allow the GSS acceptor to explicitly request an attribute that is not listed in the results of GSS_Inquire_name(). The advantage of this approach is that is does not modify the semantics or the code associated to the GSS_Get_name_attribute() call. However, it would require standardization effort to define such a new call. In my opinion, approach 1) seems to offer a better solution. I don't see a reason by which a GSS Acceptor cannot call the GSS_Get_name_attribute() to obtain the value of a name attribute that does not appear in the results of GSS_Inquire_name(). This is something that can be handled by the mechanism (or the specific implementation of the mechanism). However, before moving forward with any of these approaches, I wanted to receive some feedback from the GSS-API experts. Regards, Alejandro --------------050504090102000709040600 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi,

I have a question regarding the GSS-API Naming Extensions (RFC 6680). As the document is written, it seems to assume that the attributes of a name are locally stored and available in the GSS Acceptor at the very moment the GSS context is established. In this way, when the GSS Acceptor calls the GSS_Inquire_name(), it obtains the complete set of attributes of the name, and it must stick to them.

However, in relation with the work we are doing in http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10, what I'd like is to allow the GSS Acceptor to request name attributes that might not be available at the moment the GSS context is established (i.e. not listed in the results of GSS_Inquire_name()), but that can be obtained by interacting with another entity afterwards (e.g. SAML IdP, LDAP server, SQL database...).

I see two approaches to achieve this:

1) Use the GSS_Get_name_attribute() call to request the desired attribute. By modifying the implementation of this call in the mechanism, instead of returning an error when the requested attribute is not available yet, the mechanism can get it from the source and return it. The main advantage of this approach is that it transparent from the point of view of the GSS Acceptor, that just uses the same call as it always does. Besides, it does not require an  standardization effort, as it is solved in the implementation of each mechanism.

2) The second approach consists on defining a new GSS-API call: e.g. GSS_Request_name_attribute(). This call would allow the GSS acceptor to explicitly request an attribute that is not listed in the results of GSS_Inquire_name(). The advantage of this approach is that is does not modify the semantics or the code associated to the GSS_Get_name_attribute() call. However, it would require standardization effort to define such a new call.

In my opinion, approach 1) seems to offer a better solution. I don't see a reason by which a GSS Acceptor cannot call the GSS_Get_name_attribute() to obtain the value of a name attribute that does not appear in the results of GSS_Inquire_name(). This is something that can be handled by the mechanism (or the specific implementation of the mechanism).

However, before moving forward with any of these approaches, I wanted to receive some feedback from the GSS-API experts.

Regards,
Alejandro










--------------050504090102000709040600-- From nobody Mon Apr 13 02:00:17 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C181B2FED for ; Mon, 13 Apr 2015 02:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0dvN8H1ShJ7 for ; Mon, 13 Apr 2015 02:00:14 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68381B2FEC for ; Mon, 13 Apr 2015 02:00:13 -0700 (PDT) Received: by us.padl.com with ESMTP id t3D902ox016245; Mon, 13 Apr 2015 05:00:05 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_ED964CFE-AD6C-4F2E-8AC3-6C6B390BE7B1" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Luke Howard In-Reply-To: <552B7D5F.3000006@um.es> Date: Mon, 13 Apr 2015 19:00:02 +1000 Message-Id: <5FD4FAEB-E62A-4822-B1FA-FFCAA38B231F@padl.com> References: <552B7D5F.3000006@um.es> To: Alejandro Perez Mendez X-Mailer: Apple Mail (2.2098) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 09:00:16 -0000 --Apple-Mail=_ED964CFE-AD6C-4F2E-8AC3-6C6B390BE7B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think 1) is fine. > On 13 Apr 2015, at 6:25 pm, Alejandro Perez Mendez wrote: >=20 > In my opinion, approach 1) seems to offer a better solution. I don't = see a reason by which a GSS Acceptor cannot call the = GSS_Get_name_attribute() to obtain the value of a name attribute that = does not appear in the results of GSS_Inquire_name(). This is something = that can be handled by the mechanism (or the specific implementation of = the mechanism).=20 -- www.lukehoward.com soundcloud.com/lukehoward --Apple-Mail=_ED964CFE-AD6C-4F2E-8AC3-6C6B390BE7B1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think 1) is fine.

On = 13 Apr 2015, at 6:25 pm, Alejandro Perez Mendez <alex@um.es> wrote:

In my = opinion, approach 1) seems to offer a better solution. I don't see a = reason by which a GSS Acceptor cannot call the GSS_Get_name_attribute() = to obtain the value of a name attribute that does not appear in the = results of GSS_Inquire_name(). This is something that can be handled by = the mechanism (or the specific implementation of the mechanism). 

--
www.lukehoward.com
soundcloud.com/lukehoward

= --Apple-Mail=_ED964CFE-AD6C-4F2E-8AC3-6C6B390BE7B1-- From nobody Mon Apr 13 07:02:20 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB6C1A7008 for ; Mon, 13 Apr 2015 07:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.912 X-Spam-Level: X-Spam-Status: No, score=-6.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6FJx3CxO_zY for ; Mon, 13 Apr 2015 07:02:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D211A6F2D for ; Mon, 13 Apr 2015 07:02:06 -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 t3DE233A005239 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 13 Apr 2015 10:02:04 -0400 Received: from [10.3.113.20] (ovpn-113-20.phx2.redhat.com [10.3.113.20]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3DE22bN027209; Mon, 13 Apr 2015 10:02:03 -0400 Message-ID: <1428933722.810.52.camel@willson.usersys.redhat.com> From: Simo Sorce To: Alejandro Perez Mendez Date: Mon, 13 Apr 2015 10:02:02 -0400 In-Reply-To: <552B7D5F.3000006@um.es> References: <552B7D5F.3000006@um.es> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 14:02:17 -0000 On Mon, 2015-04-13 at 10:25 +0200, Alejandro Perez Mendez wrote: > Hi, > > I have a question regarding the GSS-API Naming Extensions (RFC 6680). As > the document is written, it seems to assume that the attributes of a > name are locally stored and available in the GSS Acceptor at the very > moment the GSS context is established. In this way, when the GSS > Acceptor calls the GSS_Inquire_name(), it obtains the complete set of > attributes of the name, and it must stick to them. > > However, in relation with the work we are doing in > http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10, what I'd like > is to allow the GSS Acceptor to request name attributes that might not > be available at the moment the GSS context is established (i.e. not > listed in the results of GSS_Inquire_name()), but that can be obtained > by interacting with another entity afterwards (e.g. SAML IdP, LDAP > server, SQL database...). > > I see two approaches to achieve this: > > 1) Use the GSS_Get_name_attribute() call to request the desired > attribute. By modifying the implementation of this call in the > mechanism, instead of returning an error when the requested attribute is > not available yet, the mechanism can get it from the source and return > it. The main advantage of this approach is that it transparent from the > point of view of the GSS Acceptor, that just uses the same call as it > always does. Besides, it does not require an standardization effort, as > it is solved in the implementation of each mechanism. > > 2) The second approach consists on defining a new GSS-API call: e.g. > GSS_Request_name_attribute(). This call would allow the GSS acceptor to > explicitly request an attribute that is not listed in the results of > GSS_Inquire_name(). The advantage of this approach is that is does not > modify the semantics or the code associated to the > GSS_Get_name_attribute() call. However, it would require standardization > effort to define such a new call. > > In my opinion, approach 1) seems to offer a better solution. I don't see > a reason by which a GSS Acceptor cannot call the > GSS_Get_name_attribute() to obtain the value of a name attribute that > does not appear in the results of GSS_Inquire_name(). This is something > that can be handled by the mechanism (or the specific implementation of > the mechanism). > > However, before moving forward with any of these approaches, I wanted to > receive some feedback from the GSS-API experts. The advantage of a new API is that applications can use GSS_Get_name_attribute() with the implicit knowledge that the call will not block or generate traffic, however I guess that apps can list all known names ahead and then call the function only if the name is listed. So perhaps 1) is fine. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Mon Apr 13 08:55:56 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 011CC1ACDF1 for ; Mon, 13 Apr 2015 08:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.245 X-Spam-Level: X-Spam-Status: No, score=-1.245 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoqAbQhpKi5o for ; Mon, 13 Apr 2015 08:55:50 -0700 (PDT) Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 014F61ACD29 for ; Mon, 13 Apr 2015 08:55:49 -0700 (PDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3DFhxmv021165; Mon, 13 Apr 2015 11:43:59 -0400 (EDT) Date: Mon, 13 Apr 2015 11:43:59 -0400 (EDT) From: Benjamin Kaduk To: Simo Sorce In-Reply-To: <1428933722.810.52.camel@willson.usersys.redhat.com> Message-ID: References: <552B7D5F.3000006@um.es> <1428933722.810.52.camel@willson.usersys.redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 15:55:55 -0000 On Mon, 13 Apr 2015, Simo Sorce wrote: > On Mon, 2015-04-13 at 10:25 +0200, Alejandro Perez Mendez wrote: > > The advantage of a new API is that applications can use > GSS_Get_name_attribute() with the implicit knowledge that the call will > not block or generate traffic, however I guess that apps can list all > known names ahead and then call the function only if the name is listed. > So perhaps 1) is fine. Let's see what sort of context we can put things in. RFC 2743 explicitly calls out that the context-establishment and -deletion calls may block pending network interactions, and the credential management calls are also permitted to block on the network. In contrast, per-message calls are explicitly declared to not block pending network interactions. The word "block" does not appear anywhere in RFC 6680. It would be nice to hear from some of the original authors of 6680 about whether this was a question they had considered. I do not think I am opposed to (1) (i.e., letting GSS_Get_name_attribute() block on network interaction), but if we proceed down that route, I think we should file an erratum against 6880 to that effect. -Ben From nobody Mon Apr 13 09:42:35 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB431ACED4 for ; Mon, 13 Apr 2015 09:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AcKZnRVHSOw for ; Mon, 13 Apr 2015 09:42:33 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:737]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A13E31ACED2 for ; Mon, 13 Apr 2015 09:42:31 -0700 (PDT) Received: from BY2FFO11FD045.protection.gbl (10.1.14.30) by BY2FFO11HUB037.protection.gbl (10.1.14.120) with Microsoft SMTP Server (TLS) id 15.1.142.12; Mon, 13 Apr 2015 16:42:11 +0000 Authentication-Results: spf=pass (sender IP is 164.107.81.220) smtp.mailfrom=osu.edu; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of osu.edu designates 164.107.81.220 as permitted sender) receiver=protection.outlook.com; client-ip=164.107.81.220; helo=cio-tnc-pf06.osuad.osu.edu; Received: from cio-tnc-pf06.osuad.osu.edu (164.107.81.220) by BY2FFO11FD045.mail.protection.outlook.com (10.1.15.177) with Microsoft SMTP Server (TLS) id 15.1.142.12 via Frontend Transport; Mon, 13 Apr 2015 16:42:10 +0000 Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by cio-tnc-pf06.osuad.osu.edu (Postfix) with ESMTPS id 790393C0074; Mon, 13 Apr 2015 12:41:04 -0400 (EDT) Received: from CIO-TNC-D2MBX02.osuad.osu.edu ([fe80::3960:dd86:ba2:ad26]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.03.0224.002; Mon, 13 Apr 2015 12:42:08 -0400 From: "Cantor, Scott" To: Benjamin Kaduk Thread-Topic: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes Thread-Index: AQHQdfJqhmgXMmqwmkyZdCDtTMZX4J1LWHmA///NM4A= Date: Mon, 13 Apr 2015 16:42:07 +0000 Message-ID: References: <552B7D5F.3000006@um.es> <1428933722.810.52.camel@willson.usersys.redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.94.140] Content-Type: text/plain; charset="utf-8" Content-ID: <0BBDF483A74FFE47BEA5574B4AA34EE4@osu.edu> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:164.107.81.220; CTRY:US; IPV:NLI; EFV:NLI; BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(438002)(377454003)(479174004)(51704005)(24454002)(199003)(189002)(77156002)(62966003)(75432002)(50986999)(54356999)(76176999)(106466001)(2171001)(50466002)(5250100002)(47776003)(106116001)(88552001)(83716003)(87936001)(89122001)(82746002)(2656002)(110136001)(19580405001)(19580395003)(86362001)(2900100001)(23676002)(2950100001)(90282001)(6806004)(36756003)(109096001)(102836002)(92566002)(93346002)(46102003)(33656002)(558084003)(66066001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2FFO11HUB037; H:cio-tnc-pf06.osuad.osu.edu; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2FFO11HUB037; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BY2FFO11HUB037; BCL:0; PCL:0; RULEID:; SRVR:BY2FFO11HUB037; X-Forefront-PRVS: 0545EFAC9A X-OriginatorOrg: osu.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Apr 2015 16:42:10.8776 (UTC) X-MS-Exchange-CrossTenant-Id: b4d138ca-1815-4a9b-a3a7-130a33b1e692 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=b4d138ca-1815-4a9b-a3a7-130a33b1e692; Ip=[164.107.81.220]; Helo=[cio-tnc-pf06.osuad.osu.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2FFO11HUB037 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 16:42:34 -0000 T24gNC8xMy8xNSwgMTE6NDMgQU0sICJCZW5qYW1pbiBLYWR1ayIgPGthZHVrQG1pdC5lZHU+IHdy b3RlOg0KPg0KPkkgZG8gbm90IHRoaW5rIEkgYW0gb3Bwb3NlZCB0byAoMSkgKGkuZS4sIGxldHRp bmcgR1NTX0dldF9uYW1lX2F0dHJpYnV0ZSgpDQo+YmxvY2sgb24gbmV0d29yayBpbnRlcmFjdGlv biksIGJ1dCBpZiB3ZSBwcm9jZWVkIGRvd24gdGhhdCByb3V0ZSwgSSB0aGluaw0KPndlIHNob3Vs ZCBmaWxlIGFuIGVycmF0dW0gYWdhaW5zdCA2ODgwIHRvIHRoYXQgZWZmZWN0Lg0KDQorMQ0KDQot LSBTY290dA0KDQo= From nobody Mon Apr 13 12:17:28 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD921B31DF for ; Mon, 13 Apr 2015 12:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHCo3FKfvfEy for ; Mon, 13 Apr 2015 12:17:24 -0700 (PDT) Received: from amersmtp2.software.dell.com (amersmtp2.software.dell.com [12.106.87.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6891AD358 for ; Mon, 13 Apr 2015 12:17:21 -0700 (PDT) Received: from amersmtp2.software.dell.com (127.0.0.1) id h5gb440171sk for ; Mon, 13 Apr 2015 12:17:21 -0700 (envelope-from ) Received: from ALVHTXW03.prod.quest.corp ([10.1.135.19]) by amersmtp2.software.dell.com (SonicWALL 8.0.7.2831) with ESMTPS (version=TLSv1 cipher=AES128-SHA bits=128/128) id 201504131917200297265; Mon, 13 Apr 2015 12:17:20 -0700 Received: from ALVMBXW01.prod.quest.corp ([fe80::48dd:e065:86b3:9cee]) by ALVHTXW03.prod.quest.corp ([::1]) with mapi id 14.03.0224.002; Mon, 13 Apr 2015 12:17:20 -0700 From: Thomas Maslen To: "Cantor, Scott" , Benjamin Kaduk Thread-Topic: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes Thread-Index: AQHQdhwRn7fH05GMqkqrjhyKNnPC6J1LTuxv Date: Mon, 13 Apr 2015 19:17:18 +0000 Message-ID: References: <552B7D5F.3000006@um.es> <1428933722.810.52.camel@willson.usersys.redhat.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.104.155] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mlf-Version: 8.0.7.2831 X-Mlf-UniqueId: o201504131917200297265 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 19:17:26 -0000 Minor nit: for "6880" read "6680".=0A= =0A= (Ben's message said "6680" the first couple of times but then typo'ed it on= ce to 6880, and per Murphy's Law the latter is the part that got quoted in = Scott's message).=0A= From nobody Tue Apr 14 21:59:28 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4421B2C51 for ; Tue, 14 Apr 2015 21:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxPoZjrBJY97 for ; Tue, 14 Apr 2015 21:59:26 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBFD01B2C50 for ; Tue, 14 Apr 2015 21:59:25 -0700 (PDT) Received: by us.padl.com with ESMTP id t3F4x3QE028259; Wed, 15 Apr 2015 00:59:05 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Luke Howard In-Reply-To: <55271546.6020505@mit.edu> Date: Wed, 15 Apr 2015 14:59:02 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <597E759F-7941-4619-BCE0-DF604221EBB5@padl.com> References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <55271546.6020505@mit.edu> To: Greg Hudson X-Mailer: Apple Mail (2.2098) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Archived-At: Cc: "kitten@ietf.org" , "mjjenki@tycho.ncsc.mil" Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 04:59:27 -0000 > On 10 Apr 2015, at 10:11 am, Greg Hudson wrote: >=20 > * If the goal is to meet a checklist of Suite B requirements, using > SHA-384 over SHA-256 internally might be necessary, but it really is > just a meaningless checklist tick. Moreover, the small integrity tag > and checksum lengths could mean that the draft doesn't actually = satisfy > Suite B--I can't speak confidently either way on that point. >=20 > * If the goal is to achieve some real security strength, using = truncated > SHA-384 is not an improvement over using truncated SHA-256. I am not a cryptographer but Greg=E2=80=99s arguments make sense to me. = Why not always truncate the hash to 256 bits when using 256-bit AES = keys? =E2=80=94 Luke= From nobody Tue Apr 14 22:57:42 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A421B3031 for ; Tue, 14 Apr 2015 22:57:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFYOKCjeoDg2 for ; Tue, 14 Apr 2015 22:57:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D2E1B30E3 for ; Tue, 14 Apr 2015 22:57:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E5405283031; Wed, 15 Apr 2015 05:57:38 +0000 (UTC) Date: Wed, 15 Apr 2015 05:57:38 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20150415055738.GT17637@mournblade.imrryr.org> References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <55271546.6020505@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55271546.6020505@mit.edu> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 05:57:41 -0000 On Thu, Apr 09, 2015 at 08:11:50PM -0400, Greg Hudson wrote: > > In general, though, it's designed to make sense - you can't use SHA-256 > > to get a 192 bit key because a SHA-256 output has at most 128 bits of > > security no matter how you slice it. > > I think it very much does matter how you slice it. For key derivation > using an HMAC, collision resistance is not required, so it is entirely > reasonable to use SHA-256 to generate a 192-bit key. In fact, the key > derivation function used in this draft (from SP 800-108 section 5.1) can > work securely even if more keying material is required than the HMAC > output size. Yes. A n-bit HMAC used as a key-derivation PRF is sound for deriving n-bit keys. The n/2 collision resistance is not in scope. Combine your nonces with the raw DH secret and key-purpose-specific salt, and away you go. -- Viktor. From nobody Wed Apr 15 02:54:24 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D9A1A0086 for ; Wed, 15 Apr 2015 02:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs4wU1eWCDKC for ; Wed, 15 Apr 2015 02:54:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003DD1A006D for ; Wed, 15 Apr 2015 02:54:20 -0700 (PDT) Received: from [93.214.238.26] by 3capp-gmx-bs24.server.lan (via HTTP); Wed, 15 Apr 2015 11:54:17 +0200 MIME-Version: 1.0 Message-ID: From: D.Rogers@gmx.net To: "Luke Howard" Content-Type: text/html; charset=UTF-8 Date: Wed, 15 Apr 2015 11:54:17 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <597E759F-7941-4619-BCE0-DF604221EBB5@padl.com> References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <55271546.6020505@mit.edu>, <597E759F-7941-4619-BCE0-DF604221EBB5@padl.com> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:5CW/SIMb8RuboAbdpBoRDK36RyKY124NODlpbFHNc/c UsEvkqkYCBobDu8AKBXHkp2pt3kWodEySuXmfXDWBzciCAsruy RCDgk9Iy7qTsr9D/7rRQY55tXaOUpe/p9toydughg4tKG7VdoB 8JMmWMzPj0woJmt3NIHmGLRAjoSTF+0L865plNrHKcqoEHxO28 9X00vNJDCI6nlkpO7+SypzoC20cbOevOmxs7l75VALtOTl3/PN mBC5fZHClvYfWSwuN+zheraHBYTvfT+6anfEqabNjDEoXbhiNn OGonFY= X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "kitten@ietf.org" , "mjjenki@tycho.ncsc.mil" Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 09:54:23 -0000
Hi Luke,
 
as I understand it truncating introduces potential predicablities and therefore weeknesses.
Here the argument is that truncating from a 384 set to 196, is no more secure than truncating from 256 to 196.
Starting from a larger set and truncating to the same end result does improve security, it may reduce it.
As would truncating 256 to 256, could be less secure than using straight 256, but it would be interesting to know if anyone has examined that.
SHA-256 of the SHA-2 family is a significant improvement over its predecessor SHA-1. So, where the ouput size has to be limited, using anything more than 256 is not necessary.
In terms of performance though, SHA-384 computes slightly faster than SHA-256.
 
Dean
Gesendet: Mittwoch, 15. April 2015 um 06:59 Uhr
Von: "Luke Howard" <lukeh@padl.com>
An: "Greg Hudson" <ghudson@MIT.EDU>
Cc: "kitten@ietf.org" <kitten@ietf.org>, "mjjenki@tycho.ncsc.mil" <mjjenki@tycho.ncsc.mil>
Betreff: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06

> On 10 Apr 2015, at 10:11 am, Greg Hudson <ghudson@MIT.EDU> wrote:
>
> * If the goal is to meet a checklist of Suite B requirements, using
> SHA-384 over SHA-256 internally might be necessary, but it really is
> just a meaningless checklist tick. Moreover, the small integrity tag
> and checksum lengths could mean that the draft doesn't actually satisfy
> Suite B--I can't speak confidently either way on that point.
>
> * If the goal is to achieve some real security strength, using truncated
> SHA-384 is not an improvement over using truncated SHA-256.

I am not a cryptographer but Greg’s arguments make sense to me. Why not always truncate the hash to 256 bits when using 256-bit AES keys?

— Luke
_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
From nobody Wed Apr 15 08:13:56 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 716F21AC40D for ; Wed, 15 Apr 2015 08:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgSULyKVbdph for ; Wed, 15 Apr 2015 08:13:53 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A0D91AC405 for ; Wed, 15 Apr 2015 08:13:53 -0700 (PDT) Received: by us.padl.com with ESMTP id t3FFDRof022169; Wed, 15 Apr 2015 11:13:29 -0400 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_B105D76B-7EBE-4DE1-999F-F8FFA96950A8" From: Luke Howard X-Priority: 3 In-Reply-To: Date: Thu, 16 Apr 2015 01:13:26 +1000 Message-Id: <46448841-4ABE-4176-88B1-94C2B26583C4@padl.com> References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <55271546.6020505@mit.edu> <597E759F-7941-4619-BCE0-DF604221EBB5@padl.com> To: D.Rogers@gmx.net X-Mailer: Apple Mail (2.2098) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,HTML_MESSAGE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Archived-At: Cc: "kitten@ietf.org" , "mjjenki@tycho.ncsc.mil" Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 15:13:54 -0000 --Apple-Mail=_B105D76B-7EBE-4DE1-999F-F8FFA96950A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 15 Apr 2015, at 7:54 pm, D.Rogers@gmx.net wrote: >=20 > Starting from a larger set and truncating to the same end result does = improve security, it may reduce it. My understanding is that as long as the hash function has strong = diffusion this is not a problem. The different SHA-2 variants are all = truncated versions of SHA-512 (with different initial values). Also, not = relevant here (because HMAC is used) but truncating hashes can actually = improve security by avoiding length extension attacks. Feel free to correct me as I=E2=80=99m not a cryptographer, I don=E2=80=99= t even play one on TV=E2=80=A6 :) =E2=80=94 Luke= --Apple-Mail=_B105D76B-7EBE-4DE1-999F-F8FFA96950A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 15 Apr 2015, at 7:54 pm, D.Rogers@gmx.net wrote:

Starting from a larger = set and truncating to the same end result does improve security, it may = reduce it.

My understanding is that as long as the = hash function has strong diffusion this is not a problem. The different = SHA-2 variants are all truncated versions of SHA-512 (with different = initial values). Also, not relevant here (because HMAC is used) but = truncating hashes can actually improve security by avoiding length = extension attacks.

Feel free to correct me as I=E2=80=99m not a cryptographer, I = don=E2=80=99t even play one on TV=E2=80=A6 :)

=E2=80=94 = Luke
= --Apple-Mail=_B105D76B-7EBE-4DE1-999F-F8FFA96950A8-- From nobody Wed Apr 15 08:50:49 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF591A912D for ; Wed, 15 Apr 2015 08:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ld_jx4LuZDQa for ; Wed, 15 Apr 2015 08:50:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9061B2BFD for ; Wed, 15 Apr 2015 08:50:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 30374283031; Wed, 15 Apr 2015 15:50:42 +0000 (UTC) Date: Wed, 15 Apr 2015 15:50:42 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20150415155041.GU17637@mournblade.imrryr.org> References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <55271546.6020505@mit.edu> <597E759F-7941-4619-BCE0-DF604221EBB5@padl.com> <46448841-4ABE-4176-88B1-94C2B26583C4@padl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46448841-4ABE-4176-88B1-94C2B26583C4@padl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 15:50:48 -0000 On Thu, Apr 16, 2015 at 01:13:26AM +1000, Luke Howard wrote: > My understanding is that as long as the hash function has strong > diffusion this is not a problem. The different SHA-2 variants are > all truncated versions of SHA-512 (with different initial values). This is not the case. There are algorithms SHA2-512 and SHA2-256 (either smaller internal state, fewer rounds or both). SHA2-384 is a truncated SHA2-512 (with different initialization). SHA2-224 is a truncated SHA2-256 (with different initialization). -- Viktor. From nobody Wed Apr 15 09:03:27 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFEDB1B2CF9 for ; Wed, 15 Apr 2015 09:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVNtIBZsAqVe for ; Wed, 15 Apr 2015 09:03:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57DD91ACD44 for ; Wed, 15 Apr 2015 09:03:24 -0700 (PDT) Received: from [93.214.238.26] by 3capp-gmx-bs26.server.lan (via HTTP); Wed, 15 Apr 2015 18:03:07 +0200 MIME-Version: 1.0 Message-ID: From: D.Rogers@gmx.net To: "Luke Howard" Content-Type: text/html; charset=UTF-8 Date: Wed, 15 Apr 2015 18:03:07 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <46448841-4ABE-4176-88B1-94C2B26583C4@padl.com> References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <55271546.6020505@mit.edu> <597E759F-7941-4619-BCE0-DF604221EBB5@padl.com> , <46448841-4ABE-4176-88B1-94C2B26583C4@padl.com> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:jy3mQJAIjvKRqgSd3TsapZkLvMofIrz9GxTAvNgwcyQ 7WlL0RYFDZmIVjbGtEdoZBS/18jz+6bFlqb+jlO9F9m45kMnrU SX4s0Tvtd3f5o9NwDtzw6jmXm3obtrZz37eTrEW2vN28c1CFiR KCSG9+KR58/vPzFhAMA8RdFNi/3T7VG8xpi/5XNtOLQaaohieW QCxrIgczZhJStsclhYsb6DStdtu5CBWO7IvMQ3iLStt6rPzGnx xaMGDPlJ6G5WfAZNxyuYdnOZkfoT7y5hw3B4GPW+VlBy2C63Tw 1WSr/Y= X-UI-Out-Filterresults: notjunk:1; Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 16:03:26 -0000
Hi Luke,
 
quite right, i should have sensed a trap when you wrote you are "not a crytographer" :-)
 
I would not presume to correct anyone, just that this a big topic, and attempting to generalise always leaves room for further comment.
The SHA-2 family has six members, falling into two architectural groups, meaning that SHA 512 truncated to 256 can be thought of as a version of SHA-512, this cannot be said for SHA-256.
But as you say, this may be going off at a tangent as HMAC is not suseptible to length extension attacks anway.
 
Dean
Gesendet: Mittwoch, 15. April 2015 um 17:13 Uhr
Von: "Luke Howard" <lukeh@padl.com>
An: D.Rogers@gmx.net
Cc: "Greg Hudson" <ghudson@MIT.EDU>, "kitten@ietf.org" <kitten@ietf.org>, "mjjenki@tycho.ncsc.mil" <mjjenki@tycho.ncsc.mil>
Betreff: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06
 
On 15 Apr 2015, at 7:54 pm, D.Rogers@gmx.net wrote:
 
Starting from a larger set and truncating to the same end result does improve security, it may reduce it.
 
My understanding is that as long as the hash function has strong diffusion this is not a problem. The different SHA-2 variants are all truncated versions of SHA-512 (with different initial values). Also, not relevant here (because HMAC is used) but truncating hashes can actually improve security by avoiding length extension attacks.
 
Feel free to correct me as I’m not a cryptographer, I don’t even play one on TV… :)
 
— Luke
From nobody Wed Apr 15 12:09:05 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4871A8850 for ; Wed, 15 Apr 2015 12:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2azLdvH14XH for ; Wed, 15 Apr 2015 12:09:03 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2851A882E for ; Wed, 15 Apr 2015 12:09:03 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id 5307B21DE6A; Wed, 15 Apr 2015 12:09:03 -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=b3JBveYZ4q19lv fh3X3DVg+Se20=; b=sv7Byu6zP66Xd1NbQE4xRxVPeu12kfuzgURVe2oKNNtAmu /QvEUlBxJ80GJBXJqBXCUyY5ZBT5uib2OkDQdtnKOm47NTEFvdVrZ0SKOeQ4ge4/ PoPn+OTpn2DGPDOFIEBTS5+WwKYcO9Iyx48bDZnjjt7nSQGv+2Hqk/ydZAD3U= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPA id 28F4B21DE77; Wed, 15 Apr 2015 12:09:01 -0700 (PDT) Date: Wed, 15 Apr 2015 14:09:00 -0500 From: Nico Williams To: Alejandro Perez Mendez Message-ID: <20150415190859.GA29890@localhost> References: <552B7D5F.3000006@um.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <552B7D5F.3000006@um.es> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 19:09:05 -0000 On Mon, Apr 13, 2015 at 10:25:03AM +0200, Alejandro Perez Mendez wrote: > I have a question regarding the GSS-API Naming Extensions (RFC > 6680). As the document is written, it seems to assume that the > attributes of a name are locally stored and available in the GSS > Acceptor at the very moment the GSS context is established. In this > way, when the GSS Acceptor calls the GSS_Inquire_name(), it obtains > the complete set of attributes of the name, and it must stick to > them. They need neither be "locally stored", nor be available only on the acceptor side for that matter. Name attributes can be set ahead of calling GSS_Init_sec_context() or GSS_Acquire_cred(). Name attributes of any MN can be queried. > However, in relation with the work we are doing in > http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10, what I'd > like is to allow the GSS Acceptor to request name attributes that > might not be available at the moment the GSS context is established > (i.e. not listed in the results of GSS_Inquire_name()), but that can > be obtained by interacting with another entity afterwards (e.g. SAML > IdP, LDAP server, SQL database...). The API permits this for GSS_Get_name_attribute(), but such attributes should probably not be listed by GSS_Inquire_name() because: a) the set of such attributes might not be possible to list, b) some such attributes might not be appropriate to get unless needed because of additional latency that might be involved. See also draft-williams-kitten-generic-naming-attributes-02, which covers the high-latency/low-latency aspect. > 1) Use the GSS_Get_name_attribute() call to request the desired > attribute. By modifying the implementation of this call in the > mechanism, instead of returning an error when the requested > attribute is not available yet, the mechanism can get it from the > source and return it. The main advantage of this approach is that it > transparent from the point of view of the GSS Acceptor, that just > uses the same call as it always does. Besides, it does not require > an standardization effort, as it is solved in the implementation of > each mechanism. Right. > 2) The second approach consists on defining a new GSS-API call: e.g. > GSS_Request_name_attribute(). This call would allow the GSS acceptor > to explicitly request an attribute that is not listed in the results > of GSS_Inquire_name(). The advantage of this approach is that is > does not modify the semantics or the code associated to the > GSS_Get_name_attribute() call. However, it would require > standardization effort to define such a new call. See above. The imporant thing is that GSS_Get_name_attribute() already functions as a requestor API, but you might not want to list all possible attributes in GSS_Inquire_name(). GSS_Inquire_name() should list the name attributes that are explicitly a part of the name (e.g., authorization-data elements, in the Kerberos case). GSS_Get_name_attribute() should be able to produce many more name attributes' values, depending on composition of name attributes, name service lookups, or whatever else you can think up. Nico -- From nobody Wed Apr 15 12:30:03 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F80D1A8905 for ; Wed, 15 Apr 2015 12:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.334 X-Spam-Level: X-Spam-Status: No, score=0.334 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VqUDFzmzWri3 for ; Wed, 15 Apr 2015 12:30:00 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1D1A88FE for ; Wed, 15 Apr 2015 12:30:00 -0700 (PDT) Received: from homiemail-a16.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTP id 2B10E50808C; Wed, 15 Apr 2015 12:30:00 -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=RTz1cdKwG4pCxU LW1taM4K2mvo4=; b=n0iqaCANEjKkk0h9LmVe1cZ+ro0tYzyFzLSeauzvRvAq1B F8fhyXKe59rK8T+BQINJemZWs/EAGM2Oro9SJ66fVmUQDNHT8C1pyjV+tFuUSVn/ Z8irUBNh519gVmAsgQeL9dOBmBzwpwNte9dbGW94pghfY5jDsShuYU/wm39lc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a16.g.dreamhost.com (Postfix) with ESMTPA id 2BFA8508084; Wed, 15 Apr 2015 12:29:58 -0700 (PDT) Date: Wed, 15 Apr 2015 14:29:57 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20150415192957.GB29890@localhost> References: <551D6C35.4080108@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551D6C35.4080108@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 19:30:01 -0000 On Thu, Apr 02, 2015 at 12:20:05PM -0400, Greg Hudson wrote: > * For the 192-bit security level, why use SHA-384 and truncate to 192 > bits? Why not use SHA-256 and truncate to 192 bits? I've no objection to the construction MAC(k, x) = trunc(HMAC(k,H), output_size(H)/2. It's simple and obvious. > * Why use a 192-bit HMAC key for Ki and Kc but not for Kp? This I dont' understand. The HMAC key should be the same size as the cipher key. I suspect this is an editing error. There should be two or three enctypes: - aes128-cts-hmac-sha256-128 AES with 128-bit keys, and MAC = trunc-128(HMAC-SHA256) with 128-bit HMAC keys - aes192-cts-hmac-sha384-192 AES with 192-bit keys, and MAC = trunc-192(HMAC-SHA384) with 192-bit HMAC keys - aes256-cts-hmac-sha512-256 AES with 256-bit keys, and MAC = trunc-256(HMAC-SHA512) with 256-bit HMAC keys Generally, the security level of the components should match the overall security level of the enctype. I suppose an aes256-cts-hmac-sha384-192 would be OK, but only if we reject AES-192 and such an enctype is noticeably faster than aes256-cts-hmac-sha512-256. > * Why use 128/256-bit PRF output lengths? Why not just output the full > hash? It can't be for consistency with RFC 3962, as > aes256-cts-hmac-sha1-96 has a 128-bit PRF output length. It can't be > out of some desire to consistently truncate SHA-2 results in half, or we > would have 128/192-bit output lengths. Eh? The KDF is a truncation of the PRF. The PRF is not truncated. >From the draft: When the encryption type is aes128-cts-hmac-sha256-128, the output key length k is 128 bits for all applications of KDF-HMAC-SHA2(key, constant) which is computed as follows: K1 = HMAC-SHA-256(key, 00 00 00 01 | constant | 00 | 00 00 00 80) KDF-HMAC-SHA2(key, constant) = random-to-key(k-truncate(K1)) ^^^^ The "SHA2" there must be a cut-n-paste error, otherwise it looks right to me. (RFC3962 does not define a PRF, just a KDF.) Nico -- From nobody Wed Apr 15 12:54:53 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8511A89B8 for ; Wed, 15 Apr 2015 12:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRFuinTvt-LN for ; Wed, 15 Apr 2015 12:54:51 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 982631A89AF for ; Wed, 15 Apr 2015 12:54:51 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 61156360094; Wed, 15 Apr 2015 12:54:51 -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=AjoF6rFTbutBTN jU7R7Wd5t45h8=; b=EoBFeamoetpBBOVnBnTSdTVcYCxVcQVIvnNzceeF8KcIbO ZXOSNJFDSjA+/pdVeEbgljDCgnNiVopAADxa/dtQwj+0SS4s8kzE0OaF6RiG/WQ8 Q/DeAvzAGReJ8IdpNI7m95SCOfpIgL0AWlc6qwMBane/5/jLo9KSuTfd8v+FM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 2512F360093; Wed, 15 Apr 2015 12:54:49 -0700 (PDT) Date: Wed, 15 Apr 2015 14:54:48 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20150415195448.GC29890@localhost> References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5525B044.8070509@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 19:54:52 -0000 On Wed, Apr 08, 2015 at 06:48:36PM -0400, Greg Hudson wrote: > I do not understand what assumptions would yield a security level of 128 > bits from SHA-256 truncated to 192 bits, and a security level of 192 > bits from SHA-384 truncated to 192 bits. If there is a concern about > birthday attacks on the integrity tag, then we can't get away with > truncating at all; we would need to send a 256-bit tag for the 128-bit > security level, and a 384-bit tag for the 192-bit security level. I expect HMAC-SHA-256 with 128-bit HMAC keys provides 128-bit security against forgeries (which is all we're after if we encrypt-then-MAC) no matter length the result is truncated to as long as that length is 128 or more bits. The reason is: the attacker has a 128-bit key search space, and any forgery attack that requires more work than a key brute-force attack is not worth it, so using a MAC length of more than 128 bits is not likely to be useful (it will cause defenders to waste bandwidth) unless there are forgery attacks at least a few bits better than the MAC length, for HMAC with any given MAC length. The critical thing here is the size of the HMAC key. Perhaps HMAC-SHA256-192 with 192-bit keys could also provide 192-bit security against distinguishing attacks and forgeries. But if there are such attacks depending only attacking the hash against collisions then HMAC-SHA256-192 can't provide 192-bit security against forgeries -- it seems prudent to assume such attacks. ISTM prudent to use HMAC with keys of size matching the advertised collision resistance of the base hash function and then truncate the result to that same size. So, HMAC-SHA256-128 w/ 128-bit keys is OK, but HMAC-SHA256-192 is not (even if the keys are 192-bit). Nico -- From nobody Wed Apr 15 12:59:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C3A1A89E1 for ; Wed, 15 Apr 2015 12:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjc7G4sLxnMG for ; Wed, 15 Apr 2015 12:59:31 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B1B3E1A89D3 for ; Wed, 15 Apr 2015 12:59:31 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 940AB2004F31D; Wed, 15 Apr 2015 12:59:31 -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=uepPJWtW+pjxHj 5rnlyVwltFR3o=; b=pWF6D3GblmwwFfLwmiI9yDig6v0+o3WaS8N7DBC3PAV28H EW/pR4XlJkZoPZFC8YfBVcBbH5jp1VL/rxVUaqMzlj2Q56vxAC7GXvHlfLtrM/S3 vK/LGu7Q2FX6BFyMxkXQXHqZCrpFXaZx4G6vL4XsNNlqk1VwaFXuL2cX42etY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id CCA492004F322; Wed, 15 Apr 2015 12:59:30 -0700 (PDT) Date: Wed, 15 Apr 2015 14:59:29 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150415195928.GD29890@localhost> References: <552B7D5F.3000006@um.es> <1428933722.810.52.camel@willson.usersys.redhat.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) Archived-At: Cc: kitten@ietf.org, Simo Sorce Subject: Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 19:59:32 -0000 On Mon, Apr 13, 2015 at 11:43:59AM -0400, Benjamin Kaduk wrote: > I do not think I am opposed to (1) (i.e., letting GSS_Get_name_attribute() > block on network interaction), but if we proceed down that route, I think > we should file an erratum against 6880 to that effect. I do not think that RFC6680 says or implies that only those attributes listed by GSS_Inquire_name() may be gotten with GSS_Get_name_attribute(), so to start with, we don't need to change anything about RFC6680 w.r.t. that. As for what blocking/non-blocking behavior can be expected, I'd say: a) GSS_Inquire_name() can never "block", b) GSS_Get_name_attribute() can, and whether it can should depend on the attribute being gotten, and preferably this is described by the attribute's documentation. For the latter, see draft-williams-kitten-generic-naming-attributes-02, which describes a generic attribute prefix by which the application can request non-blocking behavior (which can fail if whatever data is not available). Nico -- From nobody Wed Apr 15 13:27:32 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A658A1A8A45 for ; Wed, 15 Apr 2015 13:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3AThwNeuFZ4 for ; Wed, 15 Apr 2015 13:27:29 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C4E7B1A8A1D for ; Wed, 15 Apr 2015 13:27:29 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 88AA720058DAB; Wed, 15 Apr 2015 13:27:29 -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=jIsDjIB9fDF6K/ TAFNbhpYDl07M=; b=WcAwjOKQbhXij3K21wgGIXnbro5//qLUatU6T8YXOm8S3F KQ+8LskFZYpGIwft9oDJZf7250bByxp58FJMybL6gw2TX/qxSTPbcF1HmGQpoVaH 4vGzB95FjpML4g+EB/QLXkKgTSynCH/QzYZKA1669TkoktPY3umz10jhZcvtY= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id D8C202005CF2D; Wed, 15 Apr 2015 13:27:27 -0700 (PDT) Date: Wed, 15 Apr 2015 15:27:26 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20150415202725.GE29890@localhost> References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <55271546.6020505@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55271546.6020505@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org, "mjjenki@tycho.ncsc.mil" Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 20:27:30 -0000 On Thu, Apr 09, 2015 at 08:11:50PM -0400, Greg Hudson wrote: > On 04/09/2015 06:21 PM, Michael Jenkins wrote: > > Bit string lengths and bits-o'-security: When this draft was originally > > introduced to kitten, it was stated that it was to support > > draft-burgin-kerberos-suiteb > > . So > > there's an implicit presumption that one is working in one of two modes, > > 192-bit or 128-bit security, and consequently using either SHA-384 or > > SHA-256, respectively. > > However, SHA-384 truncated to 192 bits does not have a collision > resistance strength of 192 bits; it has a collision resistance strength > of 96 bits. This is described in detail in SP 800-107 section 5.1, > which is referenced by FIPS 180-4 section 7. (We're talking about the HMAC being truncated. And we're after forgery and valid MAC distinction attacks, not collision resistance.) > I don't think any meaningful review would deem > 192-truncate(HMAC-SHA-384(k, m)) to be stronger than > 192-truncate(HMAC-SHA-256(k, m)) by any metric. (provided that k is 192-bit) I suggested that prudence would. But I was wrong. Recall that Bellare and Mihir proved HMAC is secure if the hash function is a PRF, and this does not depend on collision resistance. AES256-HMAC-SHA256-192 works. Nico -- From nobody Wed Apr 15 13:52:04 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192AE1A8AD9 for ; Wed, 15 Apr 2015 13:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PBvw_qHYDrl0 for ; Wed, 15 Apr 2015 13:52:02 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 136011A8ACF for ; Wed, 15 Apr 2015 13:52:02 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id E678267408D; Wed, 15 Apr 2015 13:52:01 -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=aqydrvVJ9vPyP3 HKEr6l+wK32g4=; b=mvgnRWEmV7OzFBwZsrPafPX6aF9YfhxCnllxkyXE74Ba4R Cyya1KZyBcMDfX9a6cpf1GYbfYAZZ9hxYcc5L8LH/atYvCXFnjHyEsSDvxJskXdw yS/RxpAJk/VfrByvKw2dHYHLPHp7iHvRcE4Eq0DKMqoVT3lvDtV7kWNHjAres= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id 53B28674070; Wed, 15 Apr 2015 13:52:01 -0700 (PDT) Date: Wed, 15 Apr 2015 15:52:00 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150415205159.GF29890@localhost> References: 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) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 20:52:03 -0000 On Mon, Mar 30, 2015 at 12:40:40PM -0400, Benjamin Kaduk wrote: > This message begins the Working Group Last Call (WGLC) of "AES Encryption > with HMAC-SHA2 for Kerberos 5" . > The WGLC will last two weeks, ending on Monday, April 13th. The draft is > available at: > > https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-06 To summarize the changes from RFC3962: - CTS remains the same but is now given by a different reference (SP800-38A+). The motivation is clear (to have a NIST reference for the cipher mode). This should be the same as in RFC3962. (Confounding is still used.) - Use encrypt-then-MAC instead of MAC-then-encrypt. +1 to that. - SHA-256 is used at the 128-bit security level, instead of SHA-1, and the HMAC output is truncated to 128 bits. The keys for the HMAC are 128 bits at the 128-bit security level. - SHA-256 is used at the 192-bit security level, and the HMAC is truncated to 192 bits. The keys for the HMAC are 192 bits at the 192-bit security level. AES-256 is used at the 192-bit security level because AES-192 implementations are not as universally available as AES-256, or something. In any case, I've no objection. I also do not object to the use of HMAC-SHA256-192 with 192-bit keys at the 192 bit security level. Pending a re-review of SP800-38A+ (I think I did it last time around), I'm OK with the contents of this I-D. Nico -- From nobody Wed Apr 15 13:58:16 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E28A51A8AFE for ; Wed, 15 Apr 2015 13:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLx-dUe0OCmj for ; Wed, 15 Apr 2015 13:58:13 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D3AB1A8AF9 for ; Wed, 15 Apr 2015 13:58:12 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-18-552ed0e38546 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 7E.06.03493.3E0DE255; Wed, 15 Apr 2015 16:58:11 -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 t3FKwAwQ024448; Wed, 15 Apr 2015 16:58:11 -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 t3FKw9o1003345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Apr 2015 16:58:10 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3FKw8T1005258; Wed, 15 Apr 2015 16:58:08 -0400 (EDT) Date: Wed, 15 Apr 2015 16:58:08 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20150415205159.GF29890@localhost> Message-ID: References: <20150415205159.GF29890@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrvv4gl6owf4FFhZHN69isTh17Qib A5PHy1PnGD2WLPnJFMAUxWWTkpqTWZZapG+XwJWxav5f9oK/PBUnr69kbmBs5upi5OSQEDCR eLW3hxXCFpO4cG89G4gtJLCYSeLiyqIuRi4geyOjxOQV+1khnENMEr9XXoZyGhgltny8zwLS wiKgLTHh+SKwdjYBFYmZbzaC2SICmhLX5y0Fs5kFhCXWn5vBDGILC7hIzNqygh3E5hTQl9jz 9TCYzSvgKNGwdx8LxBkpEkunXmICsUUFdCRW75/CAlEjKHFy5hMWiJlaEsunb2OZwCg4C0lq FpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbrmermZJXqpKaWbGMGh6qKyg7H5kNIhRgEO RiUeXo95uqFCrIllxZW5hxglOZiURHmbluuFCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhbd4J lONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuDddB6oUbAoNT21Ii0z pwQhzcTBCTKcB2j4DZAa3uKCxNzizHSI/ClGRSlx3k6QhABIIqM0D64XlkpeMYoDvSLMywFM LEI8wDQE1/0KaDAT0ODjgbogg0sSEVJSDYyJfeUT/k/MmWHT92WXIffqrTJNErI7z7zZzcXx VLZK9ViYhNese1r2J+d82sBa9NOf79CcMtYrtelBM6eYrT3W+8qjn1kz/Yhl/RHTuqc3Fv7a 5urBbHlo0zXpvdwzOBTyC++JP7kbd3O35qMvisJx3I0TTIK8fQW3X1dSusT7+cVLoa41c7OV WIozEg21mIuKEwEzHMf8AAMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 20:58:15 -0000 On Wed, 15 Apr 2015, Nico Williams wrote: > On Mon, Mar 30, 2015 at 12:40:40PM -0400, Benjamin Kaduk wrote: > > This message begins the Working Group Last Call (WGLC) of "AES Encryption > > with HMAC-SHA2 for Kerberos 5" . > > The WGLC will last two weeks, ending on Monday, April 13th. The draft is > > available at: > > > > https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-06 > > To summarize the changes from RFC3962: > > - CTS remains the same but is now given by a different reference > (SP800-38A+). The motivation is clear (to have a NIST reference for > the cipher mode). > > This should be the same as in RFC3962. > > (Confounding is still used.) > > - Use encrypt-then-MAC instead of MAC-then-encrypt. +1 to that. > > - SHA-256 is used at the 128-bit security level, instead of SHA-1, and > the HMAC output is truncated to 128 bits. The keys for the HMAC are > 128 bits at the 128-bit security level. > > - SHA-256 is used at the 192-bit security level, and the HMAC is > truncated to 192 bits. The keys for the HMAC are 192 bits at the > 192-bit security level. > > AES-256 is used at the 192-bit security level because AES-192 > implementations are not as universally available as AES-256, or > something. In any case, I've no objection. > > I also do not object to the use of HMAC-SHA256-192 with 192-bit keys > at the 192 bit security level. I think that some of these "256" should be "384", unless you have progressed from summarizing the document to describing what you would like to see... -Ben From nobody Wed Apr 15 14:05:51 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39521A8F51 for ; Wed, 15 Apr 2015 14:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSqfN5MneUaX for ; Wed, 15 Apr 2015 14:05:48 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5745A1A901C for ; Wed, 15 Apr 2015 14:05:42 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 0003B678083; Wed, 15 Apr 2015 14:05:41 -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=rTrvA6+PKt0qaT vFsVWK0ceEjjI=; b=vfc11vduwJJ3acr0NJK0vHULZ5Rm6OGTiUOi16thdPqf8E aHqOX3qYGaS7R49vwdN8kh1f4J2EeIk45su5m5hMjf61srnVahas4okQgmwBc54j UiYhWvsECwNWjBWRTjMy/qvK7P0lBYH6Ts/dWZV/cgR2j08y5A1HhoHjGbRTQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPA id 48766678063; Wed, 15 Apr 2015 14:05:40 -0700 (PDT) Date: Wed, 15 Apr 2015 16:05:40 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150415210538.GG29890@localhost> References: <20150415205159.GF29890@localhost> 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) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Apr 2015 21:05:49 -0000 On Wed, Apr 15, 2015 at 04:58:08PM -0400, Benjamin Kaduk wrote: > On Wed, 15 Apr 2015, Nico Williams wrote: > > - SHA-256 is used at the 192-bit security level, and the HMAC is > > truncated to 192 bits. The keys for the HMAC are 192 bits at the > > 192-bit security level. > > > > AES-256 is used at the 192-bit security level because AES-192 > > implementations are not as universally available as AES-256, or > > something. In any case, I've no objection. > > > > I also do not object to the use of HMAC-SHA256-192 with 192-bit keys > > at the 192 bit security level. > > I think that some of these "256" should be "384", unless you have > progressed from summarizing the document to describing what you would like > to see... Yes, sorry. Nico -- From nobody Wed Apr 15 19:21:01 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F13C11B2AAD for ; Wed, 15 Apr 2015 19:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVwqAKOlDdNe for ; Wed, 15 Apr 2015 19:20:58 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A5A1B2AAA for ; Wed, 15 Apr 2015 19:20:57 -0700 (PDT) Received: by wiun10 with SMTP id n10so80558350wiu.1 for ; Wed, 15 Apr 2015 19:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gX65q/BJAf9nxTetpHs7WBy3DMuExRyj/HB9seoNnT0=; b=KdpwJ+ybrAppPV0uLL8GqFNb4zD59aO0OR/C9z9gvk40AGcb0HfcPwKTQZ4D8DMhXz JBg4u7p3oOifFfJuN1uT1B/V1r8xJANPa6KNYMSEa/qWhSWigVGzdUS6/wnRLr9BtzzP CLvojkCefMO/abWyMT+khixWXvzjQRx/DcwedKRoBF75Y46u/JAH8gwCTv0cPlOo2807 n7b+SW4wp3yOZE8IhrrI5mos2Y3GW6LeciyGOB9x/yVfzqtw4uBnw01iC5AMMCTXeDj4 kgEEyIPbiuCpWA0mN5abxELNRNpbm0aPzksOKzEEcFRdHjQKQa1UZbhP9GLpjfFgR5qZ ynaQ== MIME-Version: 1.0 X-Received: by 10.194.157.39 with SMTP id wj7mr55700578wjb.57.1429150856368; Wed, 15 Apr 2015 19:20:56 -0700 (PDT) Received: by 10.194.200.8 with HTTP; Wed, 15 Apr 2015 19:20:56 -0700 (PDT) In-Reply-To: <20150415210538.GG29890@localhost> References: <20150415205159.GF29890@localhost> <20150415210538.GG29890@localhost> Date: Wed, 15 Apr 2015 22:20:56 -0400 Message-ID: From: Michael Peck To: Nico Williams Content-Type: multipart/alternative; boundary=089e013c6b5a1fd9ae0513ce1d4c Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 02:21:00 -0000 --089e013c6b5a1fd9ae0513ce1d4c Content-Type: text/plain; charset=UTF-8 Hi - To try to address the comments on the draft: 1. HMAC-SHA-384 truncated to 192 bits versus HMAC-SHA-256 truncated to 192 bits : Suite B was our motivation for proposing the two encryption types. Suite B pairs AES-128 with SHA-256, and pairs AES-256 with SHA-384. When used in the digital signature context, SHA-256 provides an expected 128 bit security level, and SHA-384 an expected 192 bit security level because of the dependence on collision resistance. In the case of our proposed Kerberos enctypes, we're using the hashes with HMAC for message authentication and for a KDF so collision resistance is not a factor - in this case, SHA-384 truncated to 192 bits appears to add no cryptographic value over SHA-256 truncated to 192 bits. However, our preference would still be to keep the hash choice as is for consistency with the Suite B pairing of AES-256 with SHA-384. This could theoretically enable someone using just that option to not even need SHA-256, and might also help avoid confusing compliance assessors. (NIST SP 800-107 has a discussion of hash strengths as used in various contexts : http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf ) 2. With aes256-cts-hmac-sha384-192, why is a 192-bit HMAC key used for Ki and Kc but not for Kp? Kp is used for the Kerberos pseudo-random function (PRF). RFC3961 states that the PRF output "should be suitable for use in key generation" - if i recall correctly, our thinking here was that we didn't know what types of keys could potentially be derived from the PRF output, so we'd output the full 256 bits (whether the strength of the PRF output is actually 256 bits would of course depend on how the base-key is generated/derived) in case the PRF might be used to generate an AES-256 key - figured no need to drop bits even if our expected strength of the enctype overall is 192 bits. 3. Greg's suggestion to change KDF-HMAC-SHA2 to include an explicit length parameter, add the length parameter everywhere KDF-HMAC-SHA2 is invoked, and remove the discussion of the constant values from section 3: I need to work through this still, but it seems reasonable. We'll need to separately list invocations of KDF-HMAC-SHA2 for each encryption type, but that might help make the draft more readable, particularly if we instead separately refer to it as KDF-HMAC-SHA-256 and KDF-HMAC-SHA-384. 4. Provide more detail in the test vectors We can do this -- and thank you to those who wrote and shared test vector code. On Wed, Apr 15, 2015 at 5:05 PM, Nico Williams wrote: > On Wed, Apr 15, 2015 at 04:58:08PM -0400, Benjamin Kaduk wrote: > > On Wed, 15 Apr 2015, Nico Williams wrote: > > > - SHA-256 is used at the 192-bit security level, and the HMAC is > > > truncated to 192 bits. The keys for the HMAC are 192 bits at the > > > 192-bit security level. > > > > > > AES-256 is used at the 192-bit security level because AES-192 > > > implementations are not as universally available as AES-256, or > > > something. In any case, I've no objection. > > > > > > I also do not object to the use of HMAC-SHA256-192 with 192-bit keys > > > at the 192 bit security level. > > > > I think that some of these "256" should be "384", unless you have > > progressed from summarizing the document to describing what you would > like > > to see... > > Yes, sorry. > > Nico > -- > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --089e013c6b5a1fd9ae0513ce1d4c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi -=C2=A0

To try to address the commen= ts on the draft:

1. HMAC-SHA-384 truncated to 192 = bits versus HMAC-SHA-256 truncated to 192 bits :

S= uite B was our motivation for proposing the two encryption types.
Suite B pairs AES-128 with SHA-256, and pairs AES-256 with SHA-384.= =C2=A0 When used in the digital signature context, SHA-256 provides an expe= cted 128 bit security level, and SHA-384 an expected 192 bit security level= because of the dependence on collision resistance.
In the = case of our proposed Kerberos enctypes, we're using the hashes with HMA= C for message authentication and for a KDF so collision resistance is not a= factor - in this case, SHA-384 truncated to 192 bits appears to add no cry= ptographic value over SHA-256 truncated to 192 bits.=C2=A0=C2=A0
= However, our preference would still be to keep the hash choice as is for co= nsistency with the Suite B pairing of AES-256 with SHA-384.=C2=A0 This coul= d theoretically enable someone using just that option to not even need SHA-= 256, and might also help avoid confusing compliance assessors.
(N= IST SP 800-107 has a discussion of hash strengths as used in various contex= ts :=C2=A0http://csrc.nist.gov/publications/n= istpubs/800-107-rev1/sp800-107-rev1.pdf=C2=A0)

2. With=C2=A0aes256-cts-hma= c-sha384-192, why is a 192-bit HMAC key used for Ki and Kc but not f= or Kp?

Kp is used for the Kerberos pseudo-random f= unction (PRF). =C2=A0
RFC3961 states that the PRF output "sh= ould be suitable for use in key generation" - if i recall correctly, o= ur thinking here was that we didn't know what types of keys could poten= tially be derived from the PRF output, so we'd output the full 256 bits= (whether the strength of the PRF output is actually 256 bits would of cour= se depend on how the base-key is generated/derived) in case the PRF might b= e used to generate an AES-256 key - figured no need to drop bits even if ou= r expected strength of the enctype overall is 192 bits.

3. Greg's suggestion to change KDF-HMAC-SHA2 to include an explic= it length parameter, add the length parameter everywhere KDF-HMAC-SHA2 is i= nvoked, and remove the discussion of the constant values from section 3:

I need to work through this still, but it seems reas= onable.=C2=A0 We'll need to separately list invocations of KDF-HMAC-SHA= 2 for each encryption type, but that might help make the draft more readabl= e, particularly if we instead separately refer to it as KDF-HMAC-SHA-256 an= d KDF-HMAC-SHA-384.

4. Provide more detail in the = test vectors
We can do this -- and thank you to those who wrote a= nd shared test vector code.



On Wed, Apr 15, 2015 at= 5:05 PM, Nico Williams <nico@cryptonector.com> wrote:
On Wed, Apr 15, 2015 at 0= 4:58:08PM -0400, Benjamin Kaduk wrote:
> On Wed, 15 Apr 2015, Nico Williams wrote:
> >=C2=A0 - SHA-256 is used at the 192-bit se= curity level, and the HMAC is
> >=C2=A0 =C2=A0 truncated to 192 bits.=C2=A0 The keys for the HMAC a= re 192 bits at the
> >=C2=A0 =C2=A0 192-bit security level.
> >
> >=C2=A0 =C2=A0 AES-256 is used at the 192-bit security level becaus= e AES-192
> >=C2=A0 =C2=A0 implementations are not as universally available as = AES-256, or
> >=C2=A0 =C2=A0 something.=C2=A0 In any case, I've no objection.=
> >
> >=C2=A0 =C2=A0 I also do not object to the use of HMAC-SHA256-192 w= ith 192-bit keys
> >=C2=A0 =C2=A0 at the 192 bit security level.
>
> I think that some of these "256" should be "384", = unless you have
> progressed from summarizing the document to describing what you would = like
> to see...

Yes, sorry.

Nico
--

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

--089e013c6b5a1fd9ae0513ce1d4c-- From nobody Wed Apr 15 23:46:19 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 567121B2A3B for ; Wed, 15 Apr 2015 23:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 935uAewvnc3I for ; Wed, 15 Apr 2015 23:46:16 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792091B2A2A for ; Wed, 15 Apr 2015 23:46:16 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 96F89283032; Thu, 16 Apr 2015 06:46:14 +0000 (UTC) Date: Thu, 16 Apr 2015 06:46:14 +0000 From: Viktor Dukhovni To: kitten@ietf.org Message-ID: <20150416064614.GB17637@mournblade.imrryr.org> References: <20150415205159.GF29890@localhost> <20150415210538.GG29890@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: kitten@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 06:46:18 -0000 On Wed, Apr 15, 2015 at 10:20:56PM -0400, Michael Peck wrote: > 1. HMAC-SHA-384 truncated to 192 bits versus HMAC-SHA-256 truncated to 192 > bits : > > Suite B was our motivation for proposing the two encryption types. > Suite B pairs AES-128 with SHA-256, and pairs AES-256 with SHA-384. When > used in the digital signature context, SHA-256 provides an expected 128 bit > security level, and SHA-384 an expected 192 bit security level because of > the dependence on collision resistance. > In the case of our proposed Kerberos enctypes, we're using the hashes with > HMAC for message authentication and for a KDF so collision resistance is > not a factor - in this case, SHA-384 truncated to 192 bits appears to add > no cryptographic value over SHA-256 truncated to 192 bits. > However, our preference would still be to keep the hash choice as is for > consistency with the Suite B pairing of AES-256 with SHA-384. This could > theoretically enable someone using just that option to not even need > SHA-256, and might also help avoid confusing compliance assessors. > (NIST SP 800-107 has a discussion of hash strengths as used in various > contexts : > http://csrc.nist.gov/publications/nistpubs/800-107-rev1/sp800-107-rev1.pdf ) In terms of throughput, interestingly enough SHA2-512 is faster or bulk data processing, because of its wider state, which means more data is processed per step. (Tested with OpenSSL 1.1 dev branch): $ openssl speed sha256 type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha256 41170.10k 90881.05k 154050.73k 187984.90k 200602.63k $ openssl speed sha512 type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes sha512 27398.45k 107324.81k 167345.58k 234789.84k 265300.65k Similar gain reported at: https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functions So I guess there's no harm in using SHA2-384 even though SHA2-256 might do. Of course the story may be different on 32-bit CPUs. -- Viktor. From nobody Thu Apr 16 02:21:34 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE351B2E04 for ; Thu, 16 Apr 2015 02:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lz2QyHlnWy9 for ; Thu, 16 Apr 2015 02:21:31 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF6751B305D for ; Thu, 16 Apr 2015 02:21:29 -0700 (PDT) X-AuditID: 12074425-f79ca6d000000e5e-48-552f7f18e8e7 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 77.5A.03678.81F7F255; Thu, 16 Apr 2015 05:21:28 -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 t3G9LR1q008900; Thu, 16 Apr 2015 05:21:28 -0400 Received: from [18.101.8.108] (vpn-18-101-8-108.mit.edu [18.101.8.108]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3G9LPsu002113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Apr 2015 05:21:27 -0400 Message-ID: <552F7F15.5020607@mit.edu> Date: Thu, 16 Apr 2015 05:21:25 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Peck References: <20150415205159.GF29890@localhost> <20150415210538.GG29890@localhost> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrStRrx9qcG23usXRzatYLH71NbM6 MHnsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBk7pj1kKtgvVHHy513WBsY3fF2MnBwSAiYS G2ZuYYOwxSQu3FsPZHNxCAksZpK4c3IlO4SzkVHi8LlXYFVCAkeYJP5fkgexeQXUJBperWIB sVkEVCXm3z4CZrMJKEus378VzBYVCJOY9vs5K0S9oMTJmU/A4iJANf8fTGcCsZkFhCUubN8L ViMs4CIxa8sKqMVNTBIN3yAGcQoEShxquMYG0aAnseP6L1YIW16ieets5gmMgrOQ7JiFpGwW krIFjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdC30cjNL9FJTSjcxgkKY3UV1B+OEQ0qHGAU4 GJV4eD0S9EOFWBPLiitzDzFKcjApifKyFAKF+JLyUyozEosz4otKc1KLDzFKcDArifAeTwfK 8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8N6uBWoULEpNT61Iy8wp QUgzcXCCDOcBGn4XpIa3uCAxtzgzHSJ/ilFRSpz3GkhCACSRUZoH1wtLMa8YxYFeEeZlrQOq 4gGmJ7juV0CDmUCuDtQFGVySiJCSamBMOVf31nfVrOSF4px5GUFMpyumnOlWbTssMXnV38Ps e2917VGavfxzoLbLzZ3nn0+JSZ79jnPbpTsmR/VVlF/0ztb0t5rz9Mz27K1svhNZNx1SfuW9 u2Hv6zlM6hfXvWZz0OJYsFJPf/Prkgap2zvS5xS58ehdu/Ph1ZwiiakGdZZHWyd2NxjPUmIp zkg01GIuKk4EAIjPkhoMAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 09:21:33 -0000 On 04/15/2015 10:20 PM, Michael Peck wrote: > In the case of our proposed Kerberos enctypes, we're using the hashes > with HMAC for message authentication and for a KDF so collision > resistance is not a factor - in this case, SHA-384 truncated to 192 bits > appears to add no cryptographic value over SHA-256 truncated to 192 bits. > However, our preference would still be to keep the hash choice as is for > consistency with the Suite B pairing of AES-256 with SHA-384. This > could theoretically enable someone using just that option to not even > need SHA-256, and might also help avoid confusing compliance assessors. I can accept the reasoning that the choice is about Suite B pairing and not cryptographic strength. As Viktor notes, the performance impact of using SHA-384 over SHA-256 is a mixed bag; it is likely to be slower for computing derived keys and PRFs, but faster for computing integrity tags and checksums for large messages. > Kp is used for the Kerberos pseudo-random function (PRF). > RFC3961 states that the PRF output "should be suitable for use in key > generation" - if i recall correctly, our thinking here was that we > didn't know what types of keys could potentially be derived from the PRF > output, so we'd output the full 256 bits (whether the strength of the > PRF output is actually 256 bits would of course depend on how the > base-key is generated/derived) in case the PRF might be used to generate > an AES-256 key - figured no need to drop bits even if our expected > strength of the enctype overall is 192 bits. Okay, but why truncate the PRF output at all? Why not make the PRF output 256 bits for aes128-cts-hmac-sha256-128 and 384 bits for aes256-cts-hmac-sha384-192? Generally speaking, the size of the PRF output is something convenient to the enctype, and a construction like the RFC 6112 PRF+ is used to construct however much keying material is necessary by iterating and truncating the PRF. There is no need for the enctype to restrict its output length to the input key length. (Of course the entropy of the output is limited to the entropy of the input key.) For comparison, RFC 4757 defines its PRF as HMAC-SHA1(K, S) and outputs 160 bits for a 128-bit input key. I agree that Kp should be 256 bits for aes256-cts-hmac-sha384-192; that was a dumb question. From nobody Thu Apr 16 10:59:04 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C691B2DC2; Thu, 16 Apr 2015 10:59:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnX07mIsyZEG; Thu, 16 Apr 2015 10:58:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E251B3413; Thu, 16 Apr 2015 10:58:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150416175835.6159.60634.idtracker@ietfa.amsl.com> Date: Thu, 16 Apr 2015 10:58:35 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-20.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 17:59:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-20.txt Pages : 23 Date : 2015-04-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-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-20 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 nobody Thu Apr 16 11:08:28 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E381B2EE1 for ; Thu, 16 Apr 2015 11:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWR_3OYLgvCh for ; Thu, 16 Apr 2015 11:08:24 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4921B2ED4 for ; Thu, 16 Apr 2015 11:08:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id CA9D7D460; Thu, 16 Apr 2015 20:08:20 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JuMahpWcmADO; Thu, 16 Apr 2015 20:08:20 +0200 (CEST) Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id 014F29554; Thu, 16 Apr 2015 20:08:18 +0200 (CEST) Message-ID: <552FFA91.8010908@um.es> Date: Thu, 16 Apr 2015 20:08:17 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nico Williams References: <552B7D5F.3000006@um.es> <20150415190859.GA29890@localhost> In-Reply-To: <20150415190859.GA29890@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:08:27 -0000 El 15/04/15 a las 21:09, Nico Williams escribió: > On Mon, Apr 13, 2015 at 10:25:03AM +0200, Alejandro Perez Mendez wrote: >> I have a question regarding the GSS-API Naming Extensions (RFC >> 6680). As the document is written, it seems to assume that the >> attributes of a name are locally stored and available in the GSS >> Acceptor at the very moment the GSS context is established. In this >> way, when the GSS Acceptor calls the GSS_Inquire_name(), it obtains >> the complete set of attributes of the name, and it must stick to >> them. > They need neither be "locally stored", nor be available only on the > acceptor side for that matter. > > Name attributes can be set ahead of calling GSS_Init_sec_context() or > GSS_Acquire_cred(). > > Name attributes of any MN can be queried. That's exactly what we wanted. >> However, in relation with the work we are doing in >> http://tools.ietf.org/html/draft-ietf-abfab-aaa-saml-10, what I'd >> like is to allow the GSS Acceptor to request name attributes that >> might not be available at the moment the GSS context is established >> (i.e. not listed in the results of GSS_Inquire_name()), but that can >> be obtained by interacting with another entity afterwards (e.g. SAML >> IdP, LDAP server, SQL database...). > The API permits this for GSS_Get_name_attribute(), but such attributes > should probably not be listed by GSS_Inquire_name() because: > > a) the set of such attributes might not be possible to list, > b) some such attributes might not be appropriate to get unless needed > because of additional latency that might be involved. That's what we thought. > > See also draft-williams-kitten-generic-naming-attributes-02, which > covers the high-latency/low-latency aspect. I will, thanks. > >> 1) Use the GSS_Get_name_attribute() call to request the desired >> attribute. By modifying the implementation of this call in the >> mechanism, instead of returning an error when the requested >> attribute is not available yet, the mechanism can get it from the >> source and return it. The main advantage of this approach is that it >> transparent from the point of view of the GSS Acceptor, that just >> uses the same call as it always does. Besides, it does not require >> an standardization effort, as it is solved in the implementation of >> each mechanism. > Right. > >> 2) The second approach consists on defining a new GSS-API call: e.g. >> GSS_Request_name_attribute(). This call would allow the GSS acceptor >> to explicitly request an attribute that is not listed in the results >> of GSS_Inquire_name(). The advantage of this approach is that is >> does not modify the semantics or the code associated to the >> GSS_Get_name_attribute() call. However, it would require >> standardization effort to define such a new call. > See above. The imporant thing is that GSS_Get_name_attribute() already > functions as a requestor API, but you might not want to list all > possible attributes in GSS_Inquire_name(). Sure. The acceptor will not know whether the IdP will provide a specific attribute until it tries to request it. > > GSS_Inquire_name() should list the name attributes that are explicitly a > part of the name (e.g., authorization-data elements, in the Kerberos > case). GSS_Get_name_attribute() should be able to produce many more > name attributes' values, depending on composition of name attributes, > name service lookups, or whatever else you can think up. Thanks > > Nico From nobody Thu Apr 16 11:52:35 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1A1B34A7 for ; Thu, 16 Apr 2015 11:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeThgJNQ791f for ; Thu, 16 Apr 2015 11:52:33 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id AA1821B34A3 for ; Thu, 16 Apr 2015 11:52:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id E9EE448C0B for ; Thu, 16 Apr 2015 20:52:25 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5xzbAXlPnyo4 for ; Thu, 16 Apr 2015 20:52:25 +0200 (CEST) Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon21.um.es (Postfix) with ESMTPSA id BEC0148C09 for ; Thu, 16 Apr 2015 20:52:25 +0200 (CEST) Message-ID: <553004E8.9030405@um.es> Date: Thu, 16 Apr 2015 20:52:24 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: kitten@ietf.org References: <552B7D5F.3000006@um.es> <1428933722.810.52.camel@willson.usersys.redhat.com> <20150415195928.GD29890@localhost> In-Reply-To: <20150415195928.GD29890@localhost> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [kitten] Use of GSS_Get_name_attribute() to obtain further attributes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2015 18:52:34 -0000 El 15/04/15 a las 21:59, Nico Williams escribió: > On Mon, Apr 13, 2015 at 11:43:59AM -0400, Benjamin Kaduk wrote: >> I do not think I am opposed to (1) (i.e., letting GSS_Get_name_attribute() >> block on network interaction), but if we proceed down that route, I think >> we should file an erratum against 6880 to that effect. > I do not think that RFC6680 says or implies that only those attributes > listed by GSS_Inquire_name() may be gotten with > GSS_Get_name_attribute(), so to start with, we don't need to change > anything about RFC6680 w.r.t. that. > > As for what blocking/non-blocking behavior can be expected, I'd say: > > a) GSS_Inquire_name() can never "block", > b) GSS_Get_name_attribute() can, and whether it can should depend on the > attribute being gotten, and preferably this is described by the > attribute's documentation. I agree with this view. Regards, Alejandro > For the latter, see draft-williams-kitten-generic-naming-attributes-02, > which describes a generic attribute prefix by which the application can > request non-blocking behavior (which can fail if whatever data is not > available). > > Nico From nobody Fri Apr 17 10:39:18 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262241A916C; Fri, 17 Apr 2015 10:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWz9Ms5QSC0l; Fri, 17 Apr 2015 10:39:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE151A9112; Fri, 17 Apr 2015 10:39:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150417173910.6493.25334.idtracker@ietfa.amsl.com> Date: Fri, 17 Apr 2015 10:39:10 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-21.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 17:39:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-21.txt Pages : 23 Date : 2015-04-17 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-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-21 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 nobody Fri Apr 17 10:57:00 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6331AD0C6 for ; Fri, 17 Apr 2015 10:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dch8Zrt750-z for ; Fri, 17 Apr 2015 10:56:57 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3861ACE1C for ; Fri, 17 Apr 2015 10:56:30 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-14-5531494db1b6 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id B4.B4.03700.D4941355; Fri, 17 Apr 2015 13:56:29 -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 t3HHuTQd008965; Fri, 17 Apr 2015 13:56:29 -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 t3HHuQpE020935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Apr 2015 13:56:28 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3HHuQVL018997; Fri, 17 Apr 2015 13:56:26 -0400 (EDT) Date: Fri, 17 Apr 2015 13:56:26 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixCmqrOvraRhqMPewrsXRzatYLE5dO8Lm wOTx8tQ5Ro8lS34yBTBFcdmkpOZklqUW6dslcGXs+biQrWARe8Xmp7+ZGhgvsHYxcnJICJhI zOvrZYOwxSQu3FsPZHNxCAksZpJYcfMoO4SzkVGifTWMc4hJ4vrJmVBlDYwSPXfWMYH0swho S7x6PglsFpuAisTMNxvBbBEBTYnr85aC2cwCwhLrz81g7mLk4BAWCJHYsCgEJMwr4ChxYFM/ C4gtKqAjsXr/FBaIuKDEyZlPWCBatSSWT9/GMoGRfxaS1CwkqQWMTKsYZVNyq3RzEzNzilOT dYuTE/PyUot0zfRyM0v0UlNKNzGCQo/dRXkH45+DSocYBTgYlXh4D8QbhAqxJpYVV+YeYpTk YFIS5f3vYhgqxJeUn1KZkVicEV9UmpNafIhRgoNZSYRXyRQox5uSWFmVWpQPk5LmYFES5930 gy9ESCA9sSQ1OzW1ILUIJivDwaEkwbvLHahRsCg1PbUiLTOnBCHNxMEJMpwHaPhOkBre4oLE 3OLMdIj8KUZdjjtT/i9iEmLJy89LlRLndfEAKhIAKcoozYObA0sZrxjFgd4S5v0GMooHmG7g Jr0CWsIEtKR0hwHIkpJEhJRUA2Owcmim2JMlxpt6tb49Tttx3eic/rGVWw//Yr7vs64jOzNu ZnLg/xdv3ogHZuenS/5XbYpaejzqhkHJJwEt1QBviTme2sFKCTs8Gwyyn7uc9j4loXV20UG+ jecanjKmzcxRT/mQ/2tTxrWAvRzd3QWKsyRMpGRcZmu9EGOQeSDXVBZSyjO/SomlOCPRUIu5 qDgRANUh+W70AgAA Archived-At: Cc: kitten@ietf.org Subject: [kitten] proposed RFC 6680 erratum for GSS_Getname_attribute() network interaction X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 17:56:58 -0000 It was unclear if there was actually support for an erratum for this, so let me throw out some text and see what response it gets. In section 7.5. GSS_Get_name_attribute() OLD: This function outputs the value(s) associated with a given GSS name object for a given name attribute. NEW: This function outputs the value(s) associated with a given GSS name object for a given name attribute. It is permitted to block pending network interactions when the attr input is not an attribute which would be included in the attrs output of a call to GSS_Inquire_name() on the same name input. COMMENT: RFC 6680 makes no mention of blocking or not blocking on network interaction, though RFC 2743 does. This seems like the most reasonable interpretation of what is currently in RFC 6680. Calls which are not explicitly permitted to block are assumed to be not permitted to block. From nobody Fri Apr 17 11:35:49 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F310B1B2F3A for ; Fri, 17 Apr 2015 11:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-E0o798WUWX for ; Fri, 17 Apr 2015 11:35:46 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EA6C1B2F38 for ; Fri, 17 Apr 2015 11:35:46 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-a8-5531528188c0 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 95.B1.03355.18251355; Fri, 17 Apr 2015 14:35:45 -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 t3HIZijg015105; Fri, 17 Apr 2015 14:35:44 -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 t3HIZg7B002702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Apr 2015 14:35:44 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3HIZg0x023940; Fri, 17 Apr 2015 14:35:42 -0400 (EDT) Date: Fri, 17 Apr 2015 14:35:42 -0400 (EDT) From: Benjamin Kaduk To: Jeffrey Altman In-Reply-To: <5526CDBA.3030102@secure-endpoints.com> Message-ID: References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <5526CDBA.3030102@secure-endpoints.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrNsYZBhqsOmpkMWflZPYLI5uXsXi wOSxZMlPJo+TfedZA5iiuGxSUnMyy1KL9O0SuDJezH/MXnCGo6Ll/BWmBsbfbF2MnBwSAiYS 56dtYoawxSQu3FsPFOfiEBJYzCSx/PZFFghnI6PE+8UrmSGcQ0wSq/bfAGsXEmhglNg2tRDE ZhHQltgzdy8TiM0moCIx881GsBoRAUOJtv83WUFsZgFhifXnZoCtExZwkZi1ZQU7iM0JdMar S08ZQWxeAUeJp6cWM0Esu8oo8eroK7BBogI6Eqv3T2GBKBKUODnzCQvEUC2J5dO3sUxgFJyF JDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQiXWO93MwSvdSU0k2M4GCV5NvB+PWg0iFG AQ5GJR7eA/EGoUKsiWXFlbmHGCU5mJREef+7GIYK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuFV MgXK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8N4NAGoULEpNT61I y8wpQUgzcXCCDOcBGi4fCDK8uCAxtzgzHSJ/ilFRSpz3BUizAEgiozQPrheWTF4xigO9Isyb BNLOA0xEcN2vgAYzAQ0u3WEAMrgkESEl1cC4gfGKdFyVULAmo1bLgi2CeR0lQh3GzdJ5i99b 8i0Wj/wT7frsx5xru7zMzsjvyHY93PRcTIOx8e5uwcMrS9X3bzd+cog7bHVxQ/th9XVNmxeb LJyycGu7Zib/4wDO70HrM+39DpmbhQjfyOBli9ZOupvRXDNl17XwRO0OlW8lpxvyTO888lJi Kc5INNRiLipOBABKUiFzAQMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 18:35:48 -0000 Hi Jeffrey, On Thu, 9 Apr 2015, Jeffrey Altman wrote: > raised are significant. Do we have independent review from trusted > cryptographers? I'm not one so will not try to review the math. I don't believe there was explicit "independent cryptographer" review at the time you wrote this. ("Does Nico count as a cryptographer?") That said, this document is basically just taking some well-understood building blocks and combining them in well-understood ways. It differs from the existing AES enctypes in using encrypt-then-mac (now the ~universal consensus of the community), in using newer hash functions truncated to a longer length, and in the key derivation algorithm. The key derivation algorithm it uses, from NIST SP800-108, is quite well understood. Oh, and the default PBKDF2 iteration count was increased. I do not think that there is any sufficiently novel cryptography going on so as to require additional review. If you still feel that more review (e.g., from CFRG) is necessary, please say so, ideally with some rebuttals to my above argument. -Ben From nobody Fri Apr 17 12:02:39 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7C161B2E7E for ; Fri, 17 Apr 2015 12:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU0oKT7JfYun for ; Fri, 17 Apr 2015 12:02:36 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AB80D1B2F8E for ; Fri, 17 Apr 2015 12:02:34 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 67F162200; Fri, 17 Apr 2015 12:02:34 -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=tt21s/06Oo8vrK kW3uOAIOy/h6o=; b=ZyCRb/3Jg1RyC8ug+jt9+lDndSDgH4r26JiAT1XILrqvt8 MgxG4ddV059yOhYXmvmjgtfo2unEJ9tOkiogDMPQyOMBlEuq7+mkAqMqOEdMYTGq Xn+y2fkpXLRyXa8AYACnixnQb71IpMFedFlHikAovvZQQerR397KF+Nqs8Khw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id D5EA11601; Fri, 17 Apr 2015 12:02:33 -0700 (PDT) Date: Fri, 17 Apr 2015 14:02:32 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150417190232.GG13041@localhost> References: 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) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] proposed RFC 6680 erratum for GSS_Getname_attribute() network interaction X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 19:02:38 -0000 On Fri, Apr 17, 2015 at 01:56:26PM -0400, Benjamin Kaduk wrote: > It was unclear if there was actually support for an erratum for this, so > let me throw out some text and see what response it gets. > > In section 7.5. GSS_Get_name_attribute() > > OLD: > This function outputs the value(s) associated with a given GSS name > object for a given name attribute. > > NEW: > This function outputs the value(s) associated with a given GSS name > object for a given name attribute. It is permitted to block pending > network interactions when the attr input is not an attribute which > would be included in the attrs output of a call to GSS_Inquire_name() > on the same name input. I'm OK with this. Perhaps we should publish draft-williams-kitten-generic-naming- attributes-02 and make it update RFC6680 (since that I-D deals with blocking already). > COMMENT: > RFC 6680 makes no mention of blocking or not blocking on network > interaction, though RFC 2743 does. This seems like the most reasonable > interpretation of what is currently in RFC 6680. Calls which are not > explicitly permitted to block are assumed to be not permitted to block. I agree with the gist of this, but GSS in general is a bit wishy-washy as to all sorts of things related to programming language run-times. What is "blocking"? A good definition is hard to come by. Is CPU bound and long-running "blocking"? What if such a task task could be handed to a task queue? Ideally we'd have async I/O extensions for functions that can block... But this is difficult to do if we cannot assume threading (so that GSS mechanisms can run their event loops in separate threads). Which reminds me: we should do that (add async interfaces that depend on threading rather than adding interfaces to applications' event loops). Nico -- From nobody Fri Apr 17 12:06:18 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F331B2F87 for ; Fri, 17 Apr 2015 12:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ML0O79OyILRK for ; Fri, 17 Apr 2015 12:06:16 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 244021B2F7F for ; Fri, 17 Apr 2015 12:06:16 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 07893360094; Fri, 17 Apr 2015 12:06:16 -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=6wy1cIEsE0buPE ToaNtAAa6iJQ0=; b=V21nKhcyTnRWy/0oz9vckxytSLKq6hm79uopIUBMwTLQAb 2KxA/9aMB1LSQaLIaeXYJHmJ/bEtBNN9vYGsnRmQ+eTnUdyoy6ASiAUkBj2v5pHG 7mHvzQwSTiobYnUFmT6XA9hr6Wwv8NdZ6QTpLpvTxA6adEHJIPXau+rDpr3Bg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 57F50360093; Fri, 17 Apr 2015 12:06:15 -0700 (PDT) Date: Fri, 17 Apr 2015 14:06:14 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150417190613.GH13041@localhost> References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <5526CDBA.3030102@secure-endpoints.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) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 19:06:17 -0000 On Fri, Apr 17, 2015 at 02:35:42PM -0400, Benjamin Kaduk wrote: > On Thu, 9 Apr 2015, Jeffrey Altman wrote: > > raised are significant. Do we have independent review from trusted > > cryptographers? I'm not one so will not try to review the math. > > I don't believe there was explicit "independent cryptographer" review at > the time you wrote this. ("Does Nico count as a cryptographer?") "Decidedly not." However, we have authorities we can quote as to: - the safety of the confounded CTS construction (which isn't new here) - the safety of the HMAC truncation (which isn't new here) - the safety of encrypt-then-MAC (which is new here for Kerberos) - the safety of HMAC with SHA-2 functions (we need only that they be a good PRF) (which is new here, of course, for Kerberos anyways) What controversies are there? Nico -- From nobody Fri Apr 17 12:44:00 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A92D1B2FDF for ; Fri, 17 Apr 2015 12:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAeuPCy9XV7K for ; Fri, 17 Apr 2015 12:43:57 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FEA1A0235 for ; Fri, 17 Apr 2015 12:43:56 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-30-5531627bb865 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id AB.B6.03355.B7261355; Fri, 17 Apr 2015 15:43:55 -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 t3HJht6o025150; Fri, 17 Apr 2015 15:43:55 -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 t3HJhrv5027723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Apr 2015 15:43:54 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3HJhqib002501; Fri, 17 Apr 2015 15:43:52 -0400 (EDT) Date: Fri, 17 Apr 2015 15:43:52 -0400 (EDT) From: Benjamin Kaduk To: Jeffrey Altman In-Reply-To: <55272D53.9020503@secure-endpoints.com> Message-ID: References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <5526CDBA.3030102@secure-endpoints.com> <55272D53.9020503@secure-endpoints.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUixCmqrFudZBhqMGWnpcWflZPYLI5uXsXi wOSxZMlPJo+TfedZA5iiuGxSUnMyy1KL9O0SuDIaFr1lLjgqVXGh8yZbA+Nm0S5GTg4JAROJ l4deskHYYhIX7q0Hsrk4hAQWM0m8fHSIBcLZyChxpqcFyjnEJHHm3Bkop4FRYl7nHSaQfhYB bYmrxx6yg9hsAioSM99sBJsrImAo0fb/JiuIzSwgLLH+3AxmEFtYwEVi1pYVQPUcHJxAd7ze oAQS5hVwlHhwcD8TxPytTBLPdkwFmyMqoCOxev8UFogiQYmTM5+wQMzUklg+fRvLBEbBWUhS s5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11svNLNFLTSndxAgOVkm+HYxfDyodYhTg YFTi4T0QbxAqxJpYVlyZe4hRkoNJSZTXLsEwVIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb0og UI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYL3M8hQwaLU9NSKtMyc EoQ0EwcnyHAeoOEiiSDDiwsSc4sz0yHypxgVpcR574E0C4AkMkrz4HphyeQVozjQK8K8qiDt PMBEBNf9CmgwE9Dg0h0GIINLEhFSUg2Mvqt0p9s6P2Tr/S4qZ1ud+d7ss82JV38mvL7Sd2tz fdpMHfdTb5Zum/6SY/rdfSoRR7hPHlT6UvllrSHPQR3Dafer3r9m2rikeuLBlijDT9LcqU9C brD8rFOb0xH/X/CEadnCfeyrhZVZ9l1TM21dcV7ni6Tfoi52g1kLjl+6fF3z1tp3VslMBUos xRmJhlrMRcWJABeZNs0BAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 19:43:59 -0000 On Thu, 9 Apr 2015, Jeffrey Altman wrote: > On 4/9/2015 6:26 PM, Benjamin Kaduk wrote: > > > > The authors have used two independent implementations to verify the test > > vectors; I have done some additional verification and Greg has done some > > different verification as well. > > I am glad to hear this. Are there 3961 implementations available for > public review? Greg linked to his, as did Weijun. My checks were not part of a 3961 implementation but rather just confirmations of the test vectors by manually performing the specified operations. I don't think that the implementations of the authors have been published. > > The last I checked, two interoperable implementations was a requirement > > for full Internet Standard, and not required even for Proposed Standard > > documents, let alone the Information status this document claims to be > > targetting. Could you say a bit more about why you feel the situation is > > different here? > > The requirements that you mention are lower bounds that apply to all > RFCs regardless of the IETF Area. Kitten is not any working group. It > is a security working group whose RFCs are implemented and deployed as > the basis for securing computer systems around the globe. The last > "informational" Kerberos encryption type RC4-HMAC (RFC 4757) became one > of the most widely deployed enc-types used for Kerberos authentication. My understanding is that RFC 4757 needed to be Informational because it was constrained by a desire to interoperate with NTLM-SSP, and if it was Proposed Standard, the design would be open to modification as an IETF work, so the interoperability would be lost. > Due to BCP 179 / RFC 6649 and draft-kaduk-kitten-des-des-des-die-die-die > the Kerberos protocol is left with two related AES*-CTS-SHA1 encryption > types for RFC 3961 based protocols. Regardless of what track this > document is placed on it is going to be widely and rapidly deployed. As > a result it is important that the working group ensure that the > encryption type is correct and that independent implementations for the > most widely used Kerberos implementations are available and are > demonstrated to be interoperable. I don't share your confidence that this particular enctype is going to be widely and rapidly deployed. I agree with the sentiment that we should have something other than enctypes 17 and 18, but it is not necessarily clear that this would be it. There might be more excitement for something other than AES; I don't know. We certainly don't have people coming to us (MIT krb5) and clamoring for this exact enctype... > Without interoperable implementations there is very little justification > in my opinion for publishing a security framework building block as an > RFC. Its not as if the working group is going to come back and revise > the RFC once it is deployed. Well, some people may not want to implement until there is a final spec to implement (i.e., an RFC). There are mechanisms to adjust things if we mess up, whether that's an erratum or a quick bis RFC, so I am comfortable moving forward with the level of testing we currently have (test vector verification without explicit interoperation). It is certainly something that the responsible AD and the IESG can consider as the document moves forward, as well. -Ben From nobody Fri Apr 17 13:03:51 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6CB51B3022 for ; Fri, 17 Apr 2015 13:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIuJs8ySwIID for ; Fri, 17 Apr 2015 13:03:42 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBA31B3023 for ; Fri, 17 Apr 2015 13:03:41 -0700 (PDT) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:1428:d7e3:e24f:8def]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t3HK3T3N013813 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 17 Apr 2015 22:03:30 +0200 X-Hashcash: 1:22:150417:kitten@ietf.org::aw58G63V62OBoJAL:nohh From: Simon Josefsson To: kitten@ietf.org References: <20150414185958.28998.26232.idtracker@ietfa.amsl.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150417:ietf-announce@ietf.org::6cw0aG8AL3LwGk3F:28h X-Hashcash: 1:22:150417:iesg-secretary@ietf.org::kt13K3F4a66Z9JpM:9g81 X-Hashcash: 1:22:150417:ietf@ietf.org::c9o9aHq9sxmWN3ph:Sji6 X-Hashcash: 1:22:150417:precis@ietf.org::+61hk/JzqzNw5zKB:qcft Date: Fri, 17 Apr 2015 22:03:29 +0200 In-Reply-To: <20150414185958.28998.26232.idtracker@ietfa.amsl.com> (The IESG's message of "Tue, 14 Apr 2015 11:59:58 -0700") Message-ID: <87wq1amsj2.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.98.6 at duva.sjd.se X-Virus-Status: Clean Archived-At: Subject: Re: [kitten] Last Call: (Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords) to Proposed Standard X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 20:03:44 -0000 This last call below may be of interest to the Kitten WG. SASLprep is being obsoleted. /Simon <#secure method=pgpmime mode=sign> The IESG writes: > The IESG has received a request from the Preparation and Comparison of > Internationalized Strings WG (precis) to consider the following document: > - 'Preparation, Enforcement, and Comparison of Internationalized Strings > Representing Usernames and Passwords' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-04-28. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes updated methods for handling Unicode strings > representing usernames and passwords. The previous approach was > known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). > The methods specified in this document provide a more sustainable > approach to the handling of internationalized usernames and > passwords. The PRECIS framework, RFC YYYY, obsoletes RFC 3454, and > this document obsoletes RFC 4013. > > [[ NOTE TO RFC EDITOR: please replace "YYYY" in the previous > paragraph with the RFC number assigned to draft-ietf-precis- > framework. ]] > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > _______________________________________________ > precis mailing list > precis@ietf.org > https://www.ietf.org/mailman/listinfo/precis From nobody Fri Apr 17 13:41:40 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E02521A870B for ; Fri, 17 Apr 2015 13:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6n5umVjErXiv for ; Fri, 17 Apr 2015 13:41:37 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E30E1A70E1 for ; Fri, 17 Apr 2015 13:41:36 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-62-55316fff8218 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id A8.30.03488.FFF61355; Fri, 17 Apr 2015 16:41:35 -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 t3HKfZv6000330; Fri, 17 Apr 2015 16:41:35 -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 t3HKfXtx015531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Apr 2015 16:41:34 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3HKfWqF009893; Fri, 17 Apr 2015 16:41:33 -0400 (EDT) Date: Fri, 17 Apr 2015 16:41:32 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20150415192957.GB29890@localhost> Message-ID: References: <551D6C35.4080108@mit.edu> <20150415192957.GB29890@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixCmqrPs/3zDU4Ms0M4ujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr43DGdpeAcW8WLf4vYGxhbWLsYOTkkBEwk 5vb9ZYawxSQu3FvP1sXIxSEksJhJ4uuNaUwQzkZGia6p31khnENMEis//YdyGhgl+jq+M4L0 swhoS/w7/JoJxGYTUJGY+WYjG4gtIqApcX3eUjCbWUBYYv25GWD7hAVcJGZtWcEOYnMK6Eus PXmUBcTmFXCUWLp3KdhMIYF6icXLt4DdKiqgI7F6/xSoGkGJkzOfsEDM1JJYPn0bywRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdLLzSzRS00p3cQIDlZJ3h2M7w4qHWIU 4GBU4uE9EG8QKsSaWFZcmXuIUZKDSUmUVzfXMFSILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO90 kBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgTv/zygRsGi1PTUirTM nBKENBMHJ8hwHqDhH0FqeIsLEnOLM9Mh8qcYdTnuTPm/iEmIJS8/L1VKnHcPSJEASFFGaR7c HFiSecUoDvSWMK8AMOUI8QATFNykV0BLmICWlO4wAFlSkoiQkmpgrPE5cen2ib27ruoKdNr7 bHxw03rH6bWzNTfPnFrXwbxB/cfDpNhlQUvbxNxVWCI/xzeqnVw1m8vvPLNDedB7V6ZSpQve UmUejL/WeidemMrz5sPC9qqjZr85V2nOPP/W9fxhy3cmISf2GT34/uGsetLJBUvflUUeuaNS oG8UukjvOJMlU+OuX0osxRmJhlrMRcWJAAvLGwUNAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 20:41:39 -0000 On Wed, 15 Apr 2015, Nico Williams wrote: > Eh? The KDF is a truncation of the PRF. The PRF is not truncated. > > From the draft: > > When the encryption type is aes128-cts-hmac-sha256-128, the output > key length k is 128 bits for all applications of KDF-HMAC-SHA2(key, > constant) which is computed as follows: > > K1 = HMAC-SHA-256(key, 00 00 00 01 | constant | 00 | 00 00 00 80) > KDF-HMAC-SHA2(key, constant) = random-to-key(k-truncate(K1)) > ^^^^ > > The "SHA2" there must be a cut-n-paste error, otherwise it looks right > to me. It is not a cut/paste error; they are defining KDF-HMAC-SHA2() one way for the 128-bit case, and below KDF-HMAC-SHA2() is defined for the 256-bit case. Greg doesn't like this implicitness and requested an explicit length parameter be used. -Ben From nobody Fri Apr 17 14:23:19 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 904631B2F0F for ; Fri, 17 Apr 2015 14:23:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKaVed31AAE7 for ; Fri, 17 Apr 2015 14:23:15 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B11C1B2F0B for ; Fri, 17 Apr 2015 14:23:15 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-cc-553179c287c9 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 20.EA.03359.2C971355; Fri, 17 Apr 2015 17:23:14 -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 t3HLND2X006236; Fri, 17 Apr 2015 17:23:13 -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 t3HLNBRQ029915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Apr 2015 17:23:12 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3HLNAbs016012; Fri, 17 Apr 2015 17:23:10 -0400 (EDT) Date: Fri, 17 Apr 2015 17:23:10 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixCmqrHuo0jDU4OUhcYs/KyexWRzdvIrF Ytm3q2wWv/qaWR1YPHbOusvusWTJTyaPk33nWQOYo7hsUlJzMstSi/TtErgyDs1fzljwS6Oi f/ZkpgbGKwpdjJwcEgImEuveNTFD2GISF+6tZ+ti5OIQEljMJLF64V5GCGcjo8TW/3fZIZxD TBJNyz9AlTUwSlyetpEJpJ9FQFvi3KsLYLPYBFQkZr7ZyAZiiwgIS+ze+o4ZpIFZYBKjxK5v vYwgCWEBF4lZW1YAjeXg4BRwkrj9OATE5BVwlFhxtxSkQgjIfLnwCth4UQEdidX7p7CA2LwC ghInZz4Bs5kFtCSWT9/GMoFRcBaS1CwkqQWMTKsYZVNyq3RzEzNzilOTdYuTE/PyUot0DfVy M0v0UlNKNzGCA1mSZwfjm4NKhxgFOBiVeHgPxBuECrEmlhVX5h5ilORgUhLl1c01DBXiS8pP qcxILM6ILyrNSS0+xCjBwawkwjsdJMebklhZlVqUD5OS5mBREufd9IMvREggPbEkNTs1tSC1 CCYrw8GhJMFrXQHUKFiUmp5akZaZU4KQZuLgBBnOAzT8DEgNb3FBYm5xZjpE/hSjopQ470qQ hABIIqM0D64XlmheMYoDvSLMuwCkigeYpOC6XwENZgIaXLrDAGRwSSJCSqqBUbp1WsAl5fI8 KaV7ssxhOi8iH0sXrOe9G+p+4HhDUY/J9vB59/Xe3H0lWpT14vLBzl2Sssoxaas3852f0Xmt yj90ltxTzr//rC8+nOS83OnYqVkliQW975lZblzxT94Y/r89zqatrEPgvMqEG47JjT8/TuU5 +ea2mYqjbIGGB2PL19tZyqXblViKMxINtZiLihMB49n1Xg8DAAA= Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 21:23:17 -0000 We got a number of comments and questions in this last call. I will try to summarize them and the response to them, below. Please let me know if I have missed something or inaccurately represented someone's statements. ======================================================= * Greg asked about using SHA-256 instead of SHA-384 for 192-bit truncated HMACs. There was a lot of discussion on this point. The conclusion seems to be that, when used with a has function that is a PRF, the HMAC construction is not dependent on collision resistance and therefore the security level is capped by the size of the input key (or the hash output length). (Note, however, that a hash which is not collision resistant to the 2^(n/2)-bit level, such as SHA-1, is as a consequence not a PRF.) So, while it would be cryptographically fine to use HMAC-SHA2-256() truncated to 192 bits as message authentication tag, we will still retain HMAC-SHA2-384() at the 192-bit security level to be consistent with the Suite B recommendations. (It may also be faster in some situations on some hardware, but this is hard to make general statements about.) * Greg asked why Ki and Kc are 192-bit but Kp is 256-bit, or alternately "why use a 256-bit PRF output length?", but later retracted that question, as there are reasons why a 256-bit Kp makes sense that do not apply to Ki and Kc. "But why truncate the PRF at all?" remains. There is not really an issue here anymore. Ki and Kc are 192-bit derived keys because they are used to derive 192-bit message authenticity tags. The base key, Ke, and Kp are 256-bits. It is convenient to make the base key 256 bits, since we use aes256, and will need 256-bit encryption keys; making the base key smaller than that seems silly in some sense. Ke has to be 256 bits since it is in the path to the aes256 encryption keys as well. Kp is 256 bits because the PRF output should be suitable for key generation, and there is no reason to reduce the number of bits of keyspace at this point. (But see the next item.) * Greg asked why the PRF output length is 128/256 bit instead of the full hash width. There does not seem to be any reason to truncate the HMAC output, here. The output length is supposed to be what is convenient for the enctype, and there is precedent for not being a multiple of the key size. It would be good to get acknowledgement from the authors that this will go in the next revision. * Greg noted that random-to-key() is used in computing Ki and Kc, but for the AES256 variant, random-to-key() formally only produces a (256-bit) base key, so this is slightly problematic. The random-to-key() function for this enctype is the identity function, and the uses in section 3 are entirely internal to the implementation; there is no need to write random-to-key() in these places. We can safely just write things like KDF-HMAC-SHA2(key,constant,k) = k-truncate(K1). * Greg wants base keys and key usages for the test vectors instead of intermediate keys. General agreement; new test vectors will be generated that include base keys and derivation constants. * I noted an instance of "the use of [...] AES-256 with a 192-bit key" which should be reworded. No objections; will the document editor please take note. * Greg suggested giving KDF-HMAC-SHA2() an output length parameter. Michael thinks this is probably reasonable, and may help the readability of the document. It sounds like we will go forward with this approach. * Greg wants to remove discussion of the constant values from section 3. Also no objections and probably reasonable. * Jeff A. asked if we have independent cryptographic review Nico and I claim that we are using well-understood building blocks in well-understood ways, and no additional review is needed. Jeff A. has not had a chance to reply to these claims yet. * Jeff A. cares strongly about interoperability and test vector verification. Greg and Weijun have published python and java code respectively, which verify the test vectors, but are not quite enough for interoperability testing (?). The authors had java and python implementations to verify the test vectors, which are not (?) published. I claim this is sufficient for now, and Jeff A. has not had a chance to reply yet. * Michael plans to update the draft in response to comments, and expand the test vectors. There is much rejoicing. ======================================================= That seems to leave us with the following action items: For the document editor: * remove truncation from the PRF output and use the natural hash output length * remove the use of random-to-key() and discussion of constant values from section 3 * add an output length argument to KDF-HMAC-SHA2() and adjust text accordingly * update test vectors to include base keys and key usage values for all test cases * reword the text discussing aes256 with 192-bit keys For Jeffrey Altman: * comment about the status of the crypto review and the interoperability testing in light of other comments that have come in on those points. -Ben From nobody Fri Apr 17 14:57:30 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FDB1B3070 for ; Fri, 17 Apr 2015 14:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUa6YKkjMemc for ; Fri, 17 Apr 2015 14:57:27 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D61171B306D for ; Fri, 17 Apr 2015 14:57:27 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 970032C807A; Fri, 17 Apr 2015 14:57:27 -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=2r+VONeVV+USU5 qemQ6XaSq0gMc=; b=MC5m3RMKIWx58yr9oUmjTVHcVX3TdTaMcig9ZnUL+A68qS YjkJQp1FAdH+iFdzKkaos5levlzoG+BeXToSaLjKcTEDYQLKiC/FPwNRrO6MWIV/ AHkZas7acna8JxFkjq3ejXdUwJculphW2H/z/BB+JkhOSR5LfHDTJpteRCTxg= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 5051D2C806C; Fri, 17 Apr 2015 14:57:27 -0700 (PDT) Date: Fri, 17 Apr 2015 16:57:26 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150417215725.GL13041@localhost> References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <5526CDBA.3030102@secure-endpoints.com> <55272D53.9020503@secure-endpoints.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) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 21:57:28 -0000 On Fri, Apr 17, 2015 at 03:43:52PM -0400, Benjamin Kaduk wrote: > On Thu, 9 Apr 2015, Jeffrey Altman wrote: > > Due to BCP 179 / RFC 6649 and draft-kaduk-kitten-des-des-des-die-die-die > > the Kerberos protocol is left with two related AES*-CTS-SHA1 encryption > > types for RFC 3961 based protocols. Regardless of what track this > > document is placed on it is going to be widely and rapidly deployed. As > > a result it is important that the working group ensure that the > > encryption type is correct and that independent implementations for the > > most widely used Kerberos implementations are available and are > > demonstrated to be interoperable. > > I don't share your confidence that this particular enctype is going to be > widely and rapidly deployed. I agree with the sentiment that we should > have something other than enctypes 17 and 18, but it is not necessarily > clear that this would be it. There might be more excitement for something > other than AES; I don't know. We certainly don't have people coming to us > (MIT krb5) and clamoring for this exact enctype... We're definitely in shape to *add* enctypes now. Interop issues from dealing with 3DES and RC4 have shaken out the sorts of bugs that would make adding new enctypes difficult. The fact that these enctypes are simple variants on the existing ones should help get implementations, should anyone need them. I think there will be sites that need to move away from SHA-1, even if HMAC-SHA-1 remains secure (which I'm not saying it does). That said, I don't think these enctypes will generate much interest beyond moving beyond SHA-1. As with TLS, ideally we should add new enctypes based on ciphers other than AES in addition to the AES ones. For Kerberos this is much harder than for TLS due to the fact that a) AEAD ciphers/cipher modes are all the rage now, b) RFC3961 is not AEAD-friendly, c) if we're to use AEAD ciphermodes then we need ones which don't require stateful nodes (i.e., which don't fall apart because of (key, IV) reuse). There's a relevant thread on CFRG about this right now. Nico -- From nobody Fri Apr 17 16:33:01 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2531B30E9 for ; Fri, 17 Apr 2015 16:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KV7Fz7lIiWys for ; Fri, 17 Apr 2015 16:32:57 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63561B30EA for ; Fri, 17 Apr 2015 16:32:57 -0700 (PDT) X-AuditID: 1209190c-f792b6d000000d1f-6d-55319827d1d5 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 95.60.03359.82891355; Fri, 17 Apr 2015 19:32:56 -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 t3HNWt67027223; Fri, 17 Apr 2015 19:32:55 -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 t3HNWpgS000353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Apr 2015 19:32:54 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3HNWo3J002915; Fri, 17 Apr 2015 19:32:50 -0400 (EDT) Date: Fri, 17 Apr 2015 19:32:50 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20150417215725.GL13041@localhost> Message-ID: References: <551D6C35.4080108@mit.edu> <5525B044.8070509@mit.edu> <5526CDBA.3030102@secure-endpoints.com> <55272D53.9020503@secure-endpoints.com> <20150417215725.GL13041@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixG6noqsxwzDUYOErToujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4/bePteAQa8XXud3sDYw7WboYOTkkBEwk lk/Ywwhhi0lcuLeeDcQWEljMJLHriVUXIxeQvZFRYsPyzewQziEmiQ/b/jJBOA2MEsuPzgAb xSKgLXH39T92EJtNQEVi5puNYKNEBDQlrs9bCmYzCwhLrD83gxnEFhZwkZi1ZQVYPaeAvsTC 6T/AangFHCWOzm1hhljQxyxx9ugqsAWiAjoSq/dPYYEoEpQ4OfMJC8RQLYnl07exTGAUnIUk NQtJagEj0ypG2ZTcKt3cxMyc4tRk3eLkxLy81CJdQ73czBK91JTSTYygYOWU5NnB+Oag0iFG AQ5GJR7eA/EGoUKsiWXFlbmHGCU5mJREeX2mGoYK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuGd nguU401JrKxKLcqHSUlzsCiJ8276wRciJJCeWJKanZpakFoEk5Xh4FCS4FWaDtQoWJSanlqR lplTgpBm4uAEGc4DNFwUpIa3uCAxtzgzHSJ/ilGX486U/4uYhFjy8vNSpcR5GUCKBECKMkrz 4ObAkswrRnGgt4R5rUCqeIAJCm7SK6AlTEBLSncYgCwpSURISTUwrlmX2jp9tdOsx6wVa0+5 3Husafj/tMLvegllt/5tq/wTfYQP9hhXffHx1ksq/6SmP33yTfv0Y+sC704tuyAwO3XVh/ku R3xvb7yz4//Tx6lXdr/72bphjphg312nvb8vPiuyrvC8o621LC3H6eLbmt3fj58x1XLfXHsr MnH1DrkVm9fKhDwv2aXEUpyRaKjFXFScCAB6ZoLVDQMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2015 23:32:59 -0000 On Fri, 17 Apr 2015, Nico Williams wrote: > We're definitely in shape to *add* enctypes now. Interop issues from > dealing with 3DES and RC4 have shaken out the sorts of bugs that would > make adding new enctypes difficult. Well, the enctype-selection logic should be in reasonable shape, but I think some implementations will have some work to do for actually generating and using these keys for service principals, since the KDC ought not generate them without explicit signal from the service that its implementation supports the new enctype. I don't think everybody is in good shape, there. For tightly controlled environments, of course, there is no concern in this space. -Ben From nobody Sat Apr 18 14:56:46 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB9F1A9175 for ; Sat, 18 Apr 2015 14:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5D6OxcAFT_Z for ; Sat, 18 Apr 2015 14:53:10 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 420451A9173 for ; Sat, 18 Apr 2015 14:53:10 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 7ABFD180206; Sat, 18 Apr 2015 14:52:22 -0700 (PDT) To: nico@cryptonector.com, leifj@sunet.se, hartmans-ietf@mit.edu, simon@josefsson.org, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, mamille2@cisco.com, kaduk@mit.edu X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150418215222.7ABFD180206@rfc-editor.org> Date: Sat, 18 Apr 2015 14:52:22 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Sat, 18 Apr 2015 14:56:44 -0700 Cc: kitten@ietf.org, rfc-editor@rfc-editor.org Subject: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 21:53:12 -0000 The following errata report has been submitted for RFC6680, "Generic Security Service Application Programming Interface (GSS-API) Naming Extensions". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6680&eid=4337 -------------------------------------- Type: Technical Reported by: Benjamin Kaduk Section: 7.5 Original Text ------------- This function outputs the value(s) associated with a given GSS name object for a given name attribute. Corrected Text -------------- This function outputs the value(s) associated with a given GSS name object for a given name attribute. It is permitted to block pending network interactions when the attr input is not an attribute which would be included in the attrs output of a call to GSS_Inquire_name() on the same name input. Notes ----- RFC 6680 makes no mention of blocking or not blocking on network interaction, though RFC 2743 does. This seems like the most reasonable interpretation of what is currently in RFC 6680. Calls which are not explicitly permitted to block are assumed to be not permitted to block. Instructions: ------------- This erratum 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. -------------------------------------- RFC6680 (draft-ietf-kitten-gssapi-naming-exts-15) -------------------------------------- Title : Generic Security Service Application Programming Interface (GSS-API) Naming Extensions Publication Date : August 2012 Author(s) : N. Williams, L. Johansson, S. Hartman, S. Josefsson Category : PROPOSED STANDARD Source : Common Authentication Technology Next Generation Area : Security Stream : IETF Verifying Party : IESG From nobody Sat Apr 18 15:54:14 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B46521A88E4 for ; Sat, 18 Apr 2015 15:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLvhqCuiYYb6 for ; Sat, 18 Apr 2015 15:49:37 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE4731A88D5 for ; Sat, 18 Apr 2015 15:49:36 -0700 (PDT) Received: by qcyk17 with SMTP id k17so41565699qcy.1 for ; Sat, 18 Apr 2015 15:49:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YORV/2o0ntKbsNxEC0QPxzyb46sx7pdzM9UmaeZHfMA=; b=FZfm255lm0SZEM5viOPTUcz2NkP9cnKUhtcUEI1CP3w23PolKw0ZzoNmUNHfMzdLxb smaIxrntqLpX5bPWG5gv5uwZ3fdJL79VRWUIbklFzGFsD08dkHieT6lQznpUE7QO+Fi3 +S2RJDsEgRrFdFb+it3M1Q7EyiEh1P1QOmY+PRAZv3A7/fZBFl5ELdB7pOmMwAiaDSMV eQlSNxaBBSBT7x9JTMXIqMdOIpoO2WHdbmlQ51MwY4EvLuxjhtCg9XVeEWqPSzxN3HLe fmU1uXHToNMqoSKqW2Tw+F49qkT5G5cwnto8IHeXJaZ3/5qodVmDPBIW1D2Hj7maLNzc lkzA== X-Received: by 10.55.20.159 with SMTP id 31mr17617304qku.64.1429397376212; Sat, 18 Apr 2015 15:49:36 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id z93sm11166227qgd.45.2015.04.18.15.49.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 18 Apr 2015 15:49:34 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <20150418215222.7ABFD180206@rfc-editor.org> Date: Sat, 18 Apr 2015 18:49:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <4268E41F-712E-425D-B514-C0023D311462@gmail.com> References: <20150418215222.7ABFD180206@rfc-editor.org> To: RFC Errata System Archived-At: X-Mailman-Approved-At: Sat, 18 Apr 2015 15:54:11 -0700 Cc: "kitten@ietf.org" , "hartmans-ietf@mit.edu" , "leifj@sunet.se" Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 22:49:38 -0000 Authors, Please let us know what you think and if you agree with the errata, is the p= roposed text good. We are trying to reduce work load a bit and have chairs/authors handling err= ata. Stephen and I will update once we have received guidance. Thanks, Kathleen=20 Sent from my iPhone > On Apr 18, 2015, at 5:52 PM, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC6680, > "Generic Security Service Application Programming Interface (GSS-API) Nami= ng Extensions". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6680&eid=3D4337 >=20 > -------------------------------------- > Type: Technical > Reported by: Benjamin Kaduk >=20 > Section: 7.5 >=20 > Original Text > ------------- > This function outputs the value(s) associated with a given GSS name > object for a given name attribute. >=20 > Corrected Text > -------------- > This function outputs the value(s) associated with a given GSS name > object for a given name attribute. It is permitted to block pending > network interactions when the attr input is not an attribute which > would be included in the attrs output of a call to GSS_Inquire_name() > on the same name input. >=20 >=20 > Notes > ----- > RFC 6680 makes no mention of blocking or not blocking on network interacti= on, though RFC 2743 does. This seems like the most reasonable interpretatio= n of what is currently in RFC 6680. Calls which are not explicitly permitte= d to block are assumed to be not permitted to block. >=20 > Instructions: > ------------- > This erratum 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.=20 >=20 > -------------------------------------- > RFC6680 (draft-ietf-kitten-gssapi-naming-exts-15) > -------------------------------------- > Title : Generic Security Service Application Programming Int= erface (GSS-API) Naming Extensions > Publication Date : August 2012 > Author(s) : N. Williams, L. Johansson, S. Hartman, S. Josefsson > Category : PROPOSED STANDARD > Source : Common Authentication Technology Next Generation > Area : Security > Stream : IETF > Verifying Party : IESG >=20 From nobody Sun Apr 19 13:19:50 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB0F71B2DD3 for ; Sun, 19 Apr 2015 13:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTJ6HyBvY82t for ; Sun, 19 Apr 2015 13:19:47 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A501D1B2DD1 for ; Sun, 19 Apr 2015 13:19:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 31AF9206E0; Sun, 19 Apr 2015 16:19:14 -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 HnQ0L3pPJsYp; Sun, 19 Apr 2015 16:19:13 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (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; Sun, 19 Apr 2015 16:19:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 656D782851; Sun, 19 Apr 2015 16:19:40 -0400 (EDT) From: Sam Hartman To: Kathleen Moriarty References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> Date: Sun, 19 Apr 2015 16:19:40 -0400 In-Reply-To: <4268E41F-712E-425D-B514-C0023D311462@gmail.com> (Kathleen Moriarty's message of "Sat, 18 Apr 2015 18:49:34 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "kitten@ietf.org" , RFC Errata System , "hartmans-ietf@mit.edu" , "leifj@sunet.se" Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 20:19:48 -0000 I really don't think we considered blocking when developing 6680. I think this is something that if we're going to discuss we need a full IETF consensus to say. I think that the proposed text would be a good starting point, for this API. My concern is that other APIs in the document might block, and that I think that a WG such as kitten should fully consider the issue rather than using the erata process for this issue. If Ben's aware of discussion in the kitten archives that show we considered blocking and intended it to be the case that calls not explicitly mentioned as blocking cannot block, then I'd support theerrata. OTherwise, I'd prefer a new document address this concern. I'll note that we cannot really say that a call never blocks. An implementation may have network swap or executable segments that are demand page over a network filesystem. An implementation may use nsswitch resources that consult network databases, etc. The best we can say is that it's reasonable to write applications assuming certain APIs do not generally block. From nobody Sun Apr 19 16:08:52 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8811A0163 for ; Sun, 19 Apr 2015 16:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aanZzgpAIt0m for ; Sun, 19 Apr 2015 16:08:50 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 211901A0104 for ; Sun, 19 Apr 2015 16:08:50 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id CED7C674058; Sun, 19 Apr 2015 16:08:49 -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=wVN9t74O+I0z2l rj4f7G5qAPr2A=; b=jZwM3iNRzIE8PCrj2w3Ax8xxVqVmsixtZ58dqpc0bpl2uT 56hkmg9aPek/RcFxOoB6XtKC7KYVc85Zw6jN6CX4Mb1qHFQ8nVgXk+olZWQ47Tff IxQbrzpuc5RG1z+YcRCIO/zNkkOVTobmh6mIGzI0AD67iBKKOI7GmS0f94oW0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id 115F8674057; Sun, 19 Apr 2015 16:08:48 -0700 (PDT) Date: Sun, 19 Apr 2015 18:08:48 -0500 From: Nico Williams To: Sam Hartman Message-ID: <20150419230843.GP13041@localhost> References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.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) Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , RFC Errata System , "leifj@sunet.se" Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Apr 2015 23:08:51 -0000 On Sun, Apr 19, 2015 at 04:19:40PM -0400, Sam Hartman wrote: > I really don't think we considered blocking when developing 6680. > I think this is something that if we're going to discuss we need a full > IETF consensus to say. I did think about it, though I don't recall specific on-the-list discussions about it, I'm certain I discussed it with someone. In particular I had wanted to consider UID/GID/SID lookups. My intention was roughly as per-Ben's proposed text. > I think that the proposed text would be a good starting point, for this > API. > My concern is that other APIs in the document might block, and that I > think that a WG such as kitten should fully consider the issue rather > than using the erata process for this issue. I object neither to the erratum, nor to an update. I think this erratum is sufficient for now, and we can work on an update to specify blocking behavior in more detail. We could update the erratum to add a list of what should be non-controversial non-blocking behaviors: - GSS_Inquire_name() (of course, otherwise Ben's text doesn't work) - GSS_Get_name_attribute() for attributes listed by GSS_Inquire_name() - GSS_Export_name_composite() (and any call to GSS_Import_name() to import an exported composite name token) We might also want to say that specific attributes not listed by GSS_Inquire_name() may yield blocking or non-blocking behavior in GSS_Get/Set_name_attribute() according to the attributes' specifications. > I'll note that we cannot really say that a call never blocks. An > implementation may have network swap or executable segments that are > demand page over a network filesystem. An implementation may use > nsswitch resources that consult network databases, etc. > The best we can say is that it's reasonable to write applications > assuming certain APIs do not generally block. Yes. Defining "non-blocking" and "blocking" is non-trivial. What kinds of I/O are slow (network) or fast (per-Unix: file I/O is fast)? Does a long-running CPU-bound computation count as blocking? Nico -- From nobody Mon Apr 20 06:37:48 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C410C1A8A4C for ; Mon, 20 Apr 2015 06:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfLx2wJD-gHy for ; Mon, 20 Apr 2015 06:37:45 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 606C31A891F for ; Mon, 20 Apr 2015 06:37:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id AFB7D206E0; Mon, 20 Apr 2015 09:37: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 69bno2NipA2y; Mon, 20 Apr 2015 09:37:10 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (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; Mon, 20 Apr 2015 09:37:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1B68B81915; Mon, 20 Apr 2015 09:37:37 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> Date: Mon, 20 Apr 2015 09:37:37 -0400 In-Reply-To: <20150419230843.GP13041@localhost> (Nico Williams's message of "Sun, 19 Apr 2015 18:08:48 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , RFC Errata System , Sam Hartman , "leifj@sunet.se" Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 13:37:46 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Sun, Apr 19, 2015 at 04:19:40PM -0400, Sam Hartman wrote: >> I really don't think we considered blocking when developing 6680. >> I think this is something that if we're going to discuss we need >> a full IETF consensus to say. Nico> I did think about it, though I don't recall specific Nico> on-the-list discussions about it, I'm certain I discussed it Nico> with someone. In particular I had wanted to consider Nico> UID/GID/SID lookups. My intention was roughly as per-Ben's Nico> proposed text. Well, I agree that we did think that things might block. I am less clear that we thought about anything specific that wouldn't block, and I'm concerned introducing this text implies there are things that don't block. From nobody Mon Apr 20 07:55:52 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58F401B2E26 for ; Mon, 20 Apr 2015 07:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ndUlTzR3LkD for ; Mon, 20 Apr 2015 07:55:48 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id D64E91B2C1E for ; Mon, 20 Apr 2015 07:55:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 472EFD1A2 for ; Mon, 20 Apr 2015 16:55:46 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2XQRM6SLR1qp for ; Mon, 20 Apr 2015 16:55:46 +0200 (CEST) Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id 1EFA8CE51 for ; Mon, 20 Apr 2015 16:55:45 +0200 (CEST) Message-ID: <55351371.70403@um.es> Date: Mon, 20 Apr 2015 16:55:45 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: kitten@ietf.org References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 14:55:50 -0000 El 20/04/15 a las 15:37, Sam Hartman escribió: >>>>>> "Nico" == Nico Williams writes: > Nico> On Sun, Apr 19, 2015 at 04:19:40PM -0400, Sam Hartman wrote: > >> I really don't think we considered blocking when developing 6680. > >> I think this is something that if we're going to discuss we need > >> a full IETF consensus to say. > > Nico> I did think about it, though I don't recall specific > Nico> on-the-list discussions about it, I'm certain I discussed it > Nico> with someone. In particular I had wanted to consider > Nico> UID/GID/SID lookups. My intention was roughly as per-Ben's > Nico> proposed text. > > Well, I agree that we did think that things might block. > I am less clear that we thought about anything specific that wouldn't > block, and I'm concerned introducing this text implies there are things > that don't block. I agree with Sam's view. How can we assure that something doesn't block on a pending network interactions? Is a DNS query a pending network interaction? Or retrieving a DTD for XML validation? Or querying a SQL database using a connection to localhost. In principle, we could assume that any call to the "open/read/write" functions are potentially blocking. From my point of view, since the GSS is an API, one might assume the caller should not be aware of how each specific call is actually implemented. What's the purpose of knowing that something does not block? If the purpose is avoiding the caller to wait too much (or even forever) for a result, probably the best option would be to allow specifying some sort of timeout after which the caller will either receive a valid result, or obtain an ERROR (e.g. GSS_C_CALL_TIMEOUT). Regards, Alejandro > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Mon Apr 20 08:15:45 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78A0A1B2ED3 for ; Mon, 20 Apr 2015 08:15:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifpm4UTAvZ5O for ; Mon, 20 Apr 2015 08:15:43 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EEAD1B2ECF for ; Mon, 20 Apr 2015 08:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1429542910; x=1430147710; q=dns/txt; h=VBR-Info:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To: OpenPGP:Content-Type; bh=ojiAC7Yt//5d6jXC2ivjBcEykmbhh7DdmB+kFwM tjsQ=; b=ivaF1NIeRnL0+Xk02sQxUucslO30PJkXhVTWkJn2UkRQgjk50Zlr0g6 KdHr16bUQhfwnj2CyKXZ3o2BEEn6YmcJSlRI0UGWHkJWGowqTWlqbFIhy5eMeSb9 1AFUSHa8EqM129N1Fl2/fcCON87QXV6LckRI/Xb5+10REQW3EDGs= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Mon, 20 Apr 2015 11:15:10 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Mon, 20 Apr 2015 11:15:10 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:128) (MDaemon PRO v15.0.0) with ESMTPSA id md50000859311.msg for ; Mon, 20 Apr 2015 11:15:09 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Mon, 20 Apr 2015 11:15:09 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1552b90a4b=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org Message-ID: <553517F8.5060108@secure-endpoints.com> Date: Mon, 20 Apr 2015 11:15:04 -0400 From: Jeffrey Altman Organization: Secure Endpoints Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Benjamin Kaduk , kitten@ietf.org References: In-Reply-To: OpenPGP: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000407040009050909060005" Archived-At: Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 15:15:44 -0000 This is a cryptographically signed message in MIME format. --------------ms000407040009050909060005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 4/17/2015 5:23 PM, Benjamin Kaduk wrote: > We got a number of comments and questions in this last call. I will tr= y > to summarize them and the response to them, below. Please let me know = if > I have missed something or inaccurately represented someone's statement= s. > * Jeff A. asked if we have independent cryptographic review >=20 > Nico and I claim that we are using well-understood building blocks in > well-understood ways, and no additional review is needed. Jeff A. has = not > had a chance to reply to these claims yet. I am happy with the current level of review activity. >=20 > * Jeff A. cares strongly about interoperability and test vector > verification. >=20 > Greg and Weijun have published python and java code respectively, which= > verify the test vectors, but are not quite enough for interoperability > testing (?). The authors had java and python implementations to verify= > the test vectors, which are not (?) published. I claim this is suffici= ent > for now, and Jeff A. has not had a chance to reply yet. I care enough about interoperability that I have agreed to fund an implementation for Heimdal. I would like to see someone commit to a second implementation. > * Michael plans to update the draft in response to comments, and expand= > the test vectors. >=20 > There is much rejoicing. Thank you. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > That seems to leave us with the following action items: >=20 > For the document editor: > * remove truncation from the PRF output and use the natural hash output= > length > * remove the use of random-to-key() and discussion of constant values f= rom > section 3 > * add an output length argument to KDF-HMAC-SHA2() and adjust text > accordingly > * update test vectors to include base keys and key usage values for all= > test cases > * reword the text discussing aes256 with 192-bit keys >=20 > For Jeffrey Altman: > * comment about the status of the crypto review and the interoperabilit= y > testing in light of other comments that have come in on those points. Done. --------------ms000407040009050909060005 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINXTCC BkIwggUqoAMCAQICEDirAC//rpa3Vv85Wvtd5xswDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0 aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJp bWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDkwMTAwMDAwMFoXDTIx MDgzMTIzNTk1OVowgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3Jh dGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwg U3Vic2NyaWJlciBDQSAtIEc0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxuwn /R1j9DsdisHTHMjIgoa2uEqGkqqBXHLKMA0vnkEiVzAhJZCao/SsKsaIF4ZhchN2LuwDyyeb jyCAN+DkitpVplAP/LlcI2mJQqG6H6/vDvmkyQrx+DeyxtmSSq5937hEH5u6P4wG/tgjT0hR I2pghKjuJy9g35byGiqMPI8AzE/L+iCOvDX24fCatgXz/B0/xhR7DtryBeTTgwKmxWlwtKnk VunbHVz0pjbia7UeKi3cvrvuOgSwMAitX2hsxr0GloiE5+apZC28ODC7iCbDZ2ZmtLR3+cCh xw5y72bi5bnK4POFdzWY3tQcsP5mceI4y258T0BV65fZqBge7QIDAQABo4ICRDCCAkAwOAYI KwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vcGtpLW9jc3AudmVyaXNpZ24uY29t MBIGA1UdEwEB/wQIMAYBAf8CAQAwbAYDVR0gBGUwYzBhBgtghkgBhvhFAQcXATBSMCYGCCsG AQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEFBQcCAjAcGhpodHRw Oi8vd3d3LnN5bWF1dGguY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZl cmlzaWduLmNvbS9wY2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwKQYDVR0RBCIwIKQeMBwx GjAYBgNVBAMTEVZlcmlTaWduTVBLSS0yLTk3MB0GA1UdDgQWBBSt+cOTci21uShh5KTXYNXE Cl4aATCB8QYDVR0jBIHpMIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+vOEjOsaQwDQYJKoZIhvcNAQEFBQADggEBANaP wdqbiPKzbE0fWC+6AVFddMFG6MO4e5/WQPHv/zK6iWvADjRDn6SZ5qTwXUgzYoWFYf4jiCKM YJsrnGVJlMSiOCRIpVylUEto6WIip5PomSJuPVu7EEIOH0x1RzRWCY/4vYw881y70pZwVHBi Te/REL6dSCxe7IZrB4LwPeElJygs4BZ2HrP95WKW0oo9Xyuu+1zCE7dlY8s0dkOf1oeZq26t lcEAP0Yngf813iMOQ9wUXzL5yinvwlIw9ZnduYH4OiUgjYJo8rkhhXRmBOGGORYy8i3WKqjJ 3tkAAk/jGCDFpYFWtpXe04Kt+HslvmR8LqC6cCz4+XXidE0HbYQwggcTMIIF+6ADAgECAhBA DYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEBBQUAMIGmMQswCQYDVQQGEwJVUzEdMBsGA1UE ChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdv cmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMg Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNDAeFw0xNDEyMTgwMDAwMDBa Fw0xNTEyMTkyMzU5NTlaMIHOMS4wLAYDVQQDDCVQZXJzb25hIE5vdCBWYWxpZGF0ZWQgLSAx NDE4ODgyMTAxMDIwMSswKQYJKoZIhvcNAQkBFhxqYWx0bWFuQHNlY3VyZS1lbmRwb2ludHMu Y29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEf MB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEdMBsGA1UECgwUU3ltYW50ZWMgQ29y cG9yYXRpb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDGcbqJKktdkAl+5/3n tX55BjmX/xriz7C8WyWnI3IeaKHdj4Ya/VhSGfxBi58Uo4V7wV+VXAObK+EkLgO/t2OdtUOw z04SX8ZRpyZxvw5YlL50ieRRtk7SKxGfLVbxJV1pfGnRB6aM1zOxuETvdsiYclTcoRJXKoMH lUmrC+f4jF2bxu6DQPVod5Ho2kJc5ViO1mbnTz7L2fuRWmH9afQra8Q6UaJWnJHr1ZSqkWpj a0a2Gx47C85CYffAoTX1+ujuYwg0LA8C3RL0FnGvalH4dalsfTgpskhEGXKRpMMAli8Oq7bO Ob1oxziM9+yR5+v30vZ37adC2vx8L1m4F7WXAgMBAAGjggMRMIIDDTAMBgNVHRMBAf8EAjAA MA4GA1UdDwEB/wQEAwIFoDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYD VR0OBBYEFM2J7jAkKtP8wun+3s5rv727EDkeMCcGA1UdEQQgMB6BHGphbHRtYW5Ac2VjdXJl LWVuZHBvaW50cy5jb20wHwYDVR0jBBgwFoAUrfnDk3IttbkoYeSk12DVxApeGgEwggErBggr BgEFBQcBAQSCAR0wggEZMIIBFQYIKwYBBQUHMAKGggEHbGRhcDovL2RpcmVjdG9yeS52ZXJp c2lnbi5jb20vQ04lMjAlM0QlMjBTeW1hbnRlYyUyMENsYXNzJTIwMSUyMEluZGl2aWR1YWwl MjBTdWJzY3JpYmVyJTIwQ0ElMjAtJTIwRzQlMkMlMjBPVSUyMCUzRCUyMFBlcnNvbmElMjBO b3QlMjBWYWxpZGF0ZWQlMkMlMjBPVSUyMCUzRCUyMFN5bWFudGVjJTIwVHJ1c3QlMjBOZXR3 b3JrJTJDJTIwTyUyMCUzRCUyMFN5bWFudGVjJTIwQ29ycG9yYXRpb24lMkMlMjBDJTIwJTNE JTIwVVM/Y0FDZXJ0aWZpY2F0ZTtiaW5hcnkwXQYDVR0fBFYwVDBSoFCgToZMaHR0cDovL3Br aS1jcmwuc3ltYXV0aC5jb20vY2FfNTYxYzEwMzY5MGM5N2E2OTI0N2EwZWYwNzFhYzgxYWYv TGF0ZXN0Q1JMLmNybDBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEW Gmh0dHA6Ly93d3cuc3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vcnBhMCsGCmCGSAGG+EUBEAMEHTAbBhJghkgBhvhFARABAgIEAYbHzm8W BTEwOTIyMDkGCmCGSAGG+EUBEAUEKzApAgEAFiRhSFIwY0hNNkx5OXdhMmt0Y21FdWMzbHRZ WFYwYUM1amIyMD0wDQYJKoZIhvcNAQEFBQADggEBALZrEhzBTZdbzJznEexkWvYmIu1A2s8B 95qMfk08aTvg+3D6F6wUGeZVJ/7x8vrTxIQ9vvYvfbXjDBdpWLnVoUaeEM2i//16x21NHqfA Fw5qtSxy4YQATuQIqevk96K2vIIjjL/vrIwZevwPBPpk/XhAI4Mfuzo89buT+pJB9pEVE8IC NUPVduydcZAJ0R0m8qQVIsKEYqAkULD1U6P8OKl8alblGFkFuqXISPbeMlg4OA8M5BV5IxHI GfUnXhOHH/AL1xE9GVt4DmGd8y96y+ljJHV/mD93NvJaH04W6ounDb8RBVt8DRvq0MLHtWap UHlG3zH8i/IJ8p9jQ5XdyRExggRSMIIETgIBATCBuzCBpjELMAkGA1UEBhMCVVMxHTAbBgNV BAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3 b3JrMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVj IENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzQCEEANiB9XZa6NrpcWXM/u DDIwCQYFKw4DAhoFAKCCAmswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTUwNDIwMTUxNTA0WjAjBgkqhkiG9w0BCQQxFgQU1TRvVBO/ghXdiY/fASAqYs6+ +S0wbAYJKoZIhvcNAQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0D AgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3lt YW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3Mg MSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNAIQQA2IH1dlro2ulxZcz+4MMjCBzgYL KoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2 aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc0AhBADYgfV2Wuja6XFlzP7gwyMA0GCSqGSIb3DQEB AQUABIIBAKTR791lCnHIna4RyiUILmsDAzAGBaUCoFtKfliR3Q9RscG0g3rObrR/aDZqT8zl Ckc+7cKHK9kFevDzrzlS8Nz2iE3vLUKtYJeJKxv8nwd2udSumkNd47bTNIMAhG5NunTZd2rD zGpQk0T/whCjG6h4HQMzuDiDGVIBGu5cvAJv1uPXc2LHwijwlblQWVy7ErtZ+gUN+lpXF5go uiA6z2qqlXTI3ICCMI07eTnRIoo6Kp2h4ZF0wV1LfiSUQTUR1PupYPrfOgPTS+THlBnqQVGy /cyh8v1EH7LlMk0to8+DQs6wtdHcJkN0q8dXNfrUXSe9qBiBrZIyNT/nNlnmW3cAAAAAAAA= --------------ms000407040009050909060005-- From nobody Mon Apr 20 08:53:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 687391B2EAD for ; Mon, 20 Apr 2015 08:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYjsfZjB0Dua for ; Mon, 20 Apr 2015 08:53:21 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 95A731B2EAC for ; Mon, 20 Apr 2015 08:53:21 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id EF44B31808D; Mon, 20 Apr 2015 08:53:20 -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=BYYfvBpXQzSC9P Y4UkT2YhzP3jI=; b=APYOqqn0oFZzZEEizxrtD1ttaJs75/v5nuoCETcBy73sGP 4zXRDEFZbzIjNVHmN6OOPyaiQ/8GOWVxXRKYJSrnzMw1SX+/PDu5PYCriVzA6OVm uhFS+deuHG0LPGeXgSmoQJpDP6H/YqlSr8wQGWDChiUEwqsX7McmWfkEHBVM8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPA id 0B5AE318093; Mon, 20 Apr 2015 08:53:16 -0700 (PDT) Date: Mon, 20 Apr 2015 10:53:15 -0500 From: Nico Williams To: Sam Hartman Message-ID: <20150420155313.GQ13041@localhost> References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> 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) Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , RFC Errata System , "leifj@sunet.se" Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 15:53:22 -0000 On Mon, Apr 20, 2015 at 09:37:37AM -0400, Sam Hartman wrote: > Well, I agree that we did think that things might block. > I am less clear that we thought about anything specific that wouldn't > block, and I'm concerned introducing this text implies there are things > that don't block. I always thought that attributes listed in GSS_Inquire_name() wouldn't block: because they are would be "raw" things in Kerberos authorization-data or similar. Also, have you seen draft-williams-kitten-generic-naming-attributes-02 ? That I-D uses your idea of attribute name prefixing to control a variety of things. It makes blocking/non-blocking attribute-specific for some attribute prefixes. In particular it adds a generic attribute prefix to indicate the application's desire to not block. I think this is the right approach, and I think it was your idea. Nico -- From nobody Mon Apr 20 08:54:14 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 617FD1B2EAC for ; Mon, 20 Apr 2015 08:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxeLQSkfULs4 for ; Mon, 20 Apr 2015 08:54:12 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C39FE1B2EA7 for ; Mon, 20 Apr 2015 08:54:12 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 9920C1DE087; Mon, 20 Apr 2015 08:54:12 -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=WsmKp0altu2pGM lKT5Ol0DMwyvU=; b=G2eMw2wpTIYdZ+VGUK1ToQPFmwErPXB45YOyAvk6iGclbq fKNPX+Y+Y7QJjr6fp9oU9cefmxgbCfhtk8FdZEqTELLFx5tN9sSGOx4NwLQ5wPJG oDtTErTqESMY6zoyMgcUcRpP6c/eZCgKzHHGMv6XHuT1g989PY+Us0xf7rsLQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id 25A531DE081; Mon, 20 Apr 2015 08:54:10 -0700 (PDT) Date: Mon, 20 Apr 2015 10:54:09 -0500 From: Nico Williams To: Alejandro Perez Mendez Message-ID: <20150420155409.GR13041@localhost> References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> <55351371.70403@um.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55351371.70403@um.es> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 15:54:13 -0000 On Mon, Apr 20, 2015 at 04:55:45PM +0200, Alejandro Perez Mendez wrote: > I agree with Sam's view. How can we assure that something doesn't > block on a pending network interactions? [...] Please see draft-williams-kitten-generic-naming-attributes-02. Nico -- From nobody Mon Apr 20 08:56:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4365A1B2A69 for ; Mon, 20 Apr 2015 08:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vy16d1scqAz1 for ; Mon, 20 Apr 2015 08:56:52 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EBD51B2F39 for ; Mon, 20 Apr 2015 08:56:46 -0700 (PDT) Received: by widdi4 with SMTP id di4so97288035wid.0 for ; Mon, 20 Apr 2015 08:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2S9elOAGDt5k2ipq9cQWdGtlsOFTp4mjZFZ3bXGZk/A=; b=uHRA/oY6ctYq+1xrXUgdE6OJSSIiFmJgUZcBkWqkOmvSuBmTr31vymcaLssmOZqyRQ rg6y/H4I1toxBN3gOtuTVWRWT0Ztosc8mKPC1F2zbBWIh2Bzq4GDIwBmykCBiywHVXd4 rwI7Rmssovmzoz3d5Cm1I0jORgluEJPVWZcNOfe2NsACsGzC1Q1ACRQWmPyHhsIVLm/n K0obuK9x9rVRp+8UKYWAp41Z6Ct+huET4LaOjVrK14Dj+QpxHqv9kOSX97UDBp19ynap TOaQyhQUosgEStFNLyvmDt4qLikVpLt47YYL/hlY0CFas8T8Rt8C0MCXgQFdMLLSza0T VwyA== MIME-Version: 1.0 X-Received: by 10.194.104.164 with SMTP id gf4mr32919937wjb.102.1429545405174; Mon, 20 Apr 2015 08:56:45 -0700 (PDT) Received: by 10.194.200.8 with HTTP; Mon, 20 Apr 2015 08:56:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 20 Apr 2015 11:56:44 -0400 Message-ID: From: Michael Peck To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=089e010d83f610d8f9051429fa04 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 15:56:55 -0000 --089e010d83f610d8f9051429fa04 Content-Type: text/plain; charset=UTF-8 Ben, Thank you for summarizing the discussion, and we'll work on making these changes. Our draft's current practice of truncating the pseudo-random function output to 128 bits (for enctype aes128-cts-hmac-sha256-128) and 256 bits (for enctype aes256-cts-hmac-sha384-192) rather than providing the full HMAC output has the benefit of discouraging misuse of the output. If the full HMAC output is returned by the PRF, I'd be afraid it may imply an output of 256 or 384 bit strength when the maximum strength is in reality limited to 128 or 256. It's not clear to me the potential ways the PRF output might be used - certainly I could see both appropriate and inappropriate ways to use the output. If the working group prefers the full output be returned, we can do that and could attempt to address it in the security considerations. We provide the PRF definition to comply with the RFC 3961 framework but would probably prefer a NIST SP 800-108 KDF be used to derive keys for other uses. I could see the PRF output potentially being used as the Ki key derivation key input to a NIST SP 800-108 KDF for those who want to use that. Mike On Fri, Apr 17, 2015 at 5:23 PM, Benjamin Kaduk wrote: > We got a number of comments and questions in this last call. I will try > to summarize them and the response to them, below. Please let me know if > I have missed something or inaccurately represented someone's statements. > > > ======================================================= > > * Greg asked about using SHA-256 instead of SHA-384 for 192-bit truncated > HMACs. > > There was a lot of discussion on this point. The conclusion seems to be > that, when used with a has function that is a PRF, the HMAC construction > is not dependent on collision resistance and therefore the security level > is capped by the size of the input key (or the hash output length). > (Note, however, that a hash which is not collision resistant to the > 2^(n/2)-bit level, such as SHA-1, is as a consequence not a PRF.) So, > while it would be cryptographically fine to use HMAC-SHA2-256() truncated > to 192 bits as message authentication tag, we will still retain > HMAC-SHA2-384() at the 192-bit security level to be consistent with the > Suite B recommendations. (It may also be faster in some situations on > some hardware, but this is hard to make general statements about.) > > > > * Greg asked why Ki and Kc are 192-bit but Kp is 256-bit, or alternately > "why use a 256-bit PRF output length?", but later retracted that question, > as there are reasons why a 256-bit Kp makes sense that do not apply to Ki > and Kc. "But why truncate the PRF at all?" remains. > > There is not really an issue here anymore. Ki and Kc are 192-bit derived > keys because they are used to derive 192-bit message authenticity tags. > The base key, Ke, and Kp are 256-bits. It is convenient to make the base > key 256 bits, since we use aes256, and will need 256-bit encryption keys; > making the base key smaller than that seems silly in some sense. Ke has > to be 256 bits since it is in the path to the aes256 encryption keys as > well. Kp is 256 bits because the PRF output should be suitable for key > generation, and there is no reason to reduce the number of bits of > keyspace at this point. (But see the next item.) > > > > * Greg asked why the PRF output length is 128/256 bit instead of the full > hash width. > > There does not seem to be any reason to truncate the HMAC output, here. > The output length is supposed to be what is convenient for the enctype, > and there is precedent for not being a multiple of the key size. It would > be good to get acknowledgement from the authors that this will go in the > next revision. > > > > * Greg noted that random-to-key() is used in computing Ki and Kc, but for > the AES256 variant, random-to-key() formally only produces a (256-bit) > base key, so this is slightly problematic. > > The random-to-key() function for this enctype is the identity function, > and the uses in section 3 are entirely internal to the implementation; > there is no need to write random-to-key() in these places. We can safely > just write things like KDF-HMAC-SHA2(key,constant,k) = k-truncate(K1). > > > > * Greg wants base keys and key usages for the test vectors instead of > intermediate keys. > > General agreement; new test vectors will be generated that include base > keys and derivation constants. > > > > * I noted an instance of "the use of [...] AES-256 with a 192-bit key" > which should be reworded. > > No objections; will the document editor please take note. > > > > * Greg suggested giving KDF-HMAC-SHA2() an output length parameter. > > Michael thinks this is probably reasonable, and may help the readability > of the document. It sounds like we will go forward with this approach. > > > > * Greg wants to remove discussion of the constant values from section 3. > > Also no objections and probably reasonable. > > > > * Jeff A. asked if we have independent cryptographic review > > Nico and I claim that we are using well-understood building blocks in > well-understood ways, and no additional review is needed. Jeff A. has not > had a chance to reply to these claims yet. > > > > * Jeff A. cares strongly about interoperability and test vector > verification. > > Greg and Weijun have published python and java code respectively, which > verify the test vectors, but are not quite enough for interoperability > testing (?). The authors had java and python implementations to verify > the test vectors, which are not (?) published. I claim this is sufficient > for now, and Jeff A. has not had a chance to reply yet. > > > > * Michael plans to update the draft in response to comments, and expand > the test vectors. > > There is much rejoicing. > > > > ======================================================= > > That seems to leave us with the following action items: > > For the document editor: > * remove truncation from the PRF output and use the natural hash output > length > * remove the use of random-to-key() and discussion of constant values from > section 3 > * add an output length argument to KDF-HMAC-SHA2() and adjust text > accordingly > * update test vectors to include base keys and key usage values for all > test cases > * reword the text discussing aes256 with 192-bit keys > > For Jeffrey Altman: > * comment about the status of the crypto review and the interoperability > testing in light of other comments that have come in on those points. > > -Ben > --089e010d83f610d8f9051429fa04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ben,

Thank you for summarizing the disc= ussion, and we'll work on making these changes.

Our draft's current practice of truncating the pseudo-random function= output to 128 bits (for enctype aes128-cts-hmac-sha256-128) and 256 bits (= for enctype aes256-cts-hmac-sha384-192) rather than providing the full HMAC= output has the benefit of discouraging misuse of the output.=C2=A0 If the = full HMAC output is returned by the PRF, I'd be afraid it may imply an = output of 256 or 384 bit strength when the maximum strength is in reality l= imited to 128 or 256.=C2=A0 It's not clear to me the potential ways the= PRF output might be used - certainly I could see both appropriate and inap= propriate ways to use the output.

If the working g= roup prefers the full output be returned, we can do that and could attempt = to address it in the security considerations.=C2=A0 We provide the PRF defi= nition to comply with the RFC 3961 framework but would probably prefer a NI= ST SP 800-108 KDF be used to derive keys for other uses.=C2=A0 I could see = the PRF output potentially being used as the Ki key derivation key input to= a NIST SP 800-108 KDF for those who want to use that.

Mike
=C2=A0

On Fri, Apr 17, 2015 at 5:23 PM, Benjamin Kaduk <kaduk@mit.= edu> wrote:
We got a number= of comments and questions in this last call.=C2=A0 I will try
to summarize them and the response to them, below.=C2=A0 Please let me know= if
I have missed something or inaccurately represented someone's statement= s.


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

* Greg asked about using SHA-256 instead of SHA-384 for 192-bit truncated HMACs.

There was a lot of discussion on this point.=C2=A0 The conclusion seems to = be
that, when used with a has function that is a PRF, the HMAC construction is not dependent on collision resistance and therefore the security level is capped by the size of the input key (or the hash output length).
(Note, however, that a hash which is not collision resistant to the
2^(n/2)-bit level, such as SHA-1, is as a consequence not a PRF.)=C2=A0 So,=
while it would be cryptographically fine to use HMAC-SHA2-256() truncated to 192 bits as message authentication tag, we will still retain
HMAC-SHA2-384() at the 192-bit security level to be consistent with the
Suite B recommendations.=C2=A0 (It may also be faster in some situations on=
some hardware, but this is hard to make general statements about.)



* Greg asked why Ki and Kc are 192-bit but Kp is 256-bit, or alternately "why use a 256-bit PRF output length?", but later retracted that = question,
as there are reasons why a 256-bit Kp makes sense that do not apply to Ki and Kc.=C2=A0 "But why truncate the PRF at all?" remains.

There is not really an issue here anymore.=C2=A0 Ki and Kc are 192-bit deri= ved
keys because they are used to derive 192-bit message authenticity tags.
The base key, Ke, and Kp are 256-bits.=C2=A0 It is convenient to make the b= ase
key 256 bits, since we use aes256, and will need 256-bit encryption keys; making the base key smaller than that seems silly in some sense.=C2=A0 Ke h= as
to be 256 bits since it is in the path to the aes256 encryption keys as
well.=C2=A0 Kp is 256 bits because the PRF output should be suitable for ke= y
generation, and there is no reason to reduce the number of bits of
keyspace at this point.=C2=A0 (But see the next item.)



* Greg asked why the PRF output length is 128/256 bit instead of the full hash width.

There does not seem to be any reason to truncate the HMAC output, here.
The output length is supposed to be what is convenient for the enctype,
and there is precedent for not being a multiple of the key size.=C2=A0 It w= ould
be good to get acknowledgement from the authors that this will go in the next revision.



* Greg noted that random-to-key() is used in computing Ki and Kc, but for the AES256 variant, random-to-key() formally only produces a (256-bit)
base key, so this is slightly problematic.

The random-to-key() function for this enctype is the identity function,
and the uses in section 3 are entirely internal to the implementation;
there is no need to write random-to-key() in these places.=C2=A0 We can saf= ely
just write things like KDF-HMAC-SHA2(key,constant,k) =3D k-truncate(K1).


* Greg wants base keys and key usages for the test vectors instead of
intermediate keys.

General agreement; new test vectors will be generated that include base
keys and derivation constants.



* I noted an instance of "the use of [...] AES-256 with a 192-bit key&= quot;
which should be reworded.

No objections; will the document editor please take note.



* Greg suggested giving KDF-HMAC-SHA2() an output length parameter.

Michael thinks this is probably reasonable, and may help the readability of the document.=C2=A0 It sounds like we will go forward with this approach= .



* Greg wants to remove discussion of the constant values from section 3.
Also no objections and probably reasonable.



* Jeff A. asked if we have independent cryptographic review

Nico and I claim that we are using well-understood building blocks in
well-understood ways, and no additional review is needed.=C2=A0 Jeff A. has= not
had a chance to reply to these claims yet.



* Jeff A. cares strongly about interoperability and test vector
verification.

Greg and Weijun have published python and java code respectively, which
verify the test vectors, but are not quite enough for interoperability
testing (?).=C2=A0 The authors had java and python implementations to verif= y
the test vectors, which are not (?) published.=C2=A0 I claim this is suffic= ient
for now, and Jeff A. has not had a chance to reply yet.



* Michael plans to update the draft in response to comments, and expand
the test vectors.

There is much rejoicing.



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D

That seems to leave us with the following action items:

For the document editor:
* remove truncation from the PRF output and use the natural hash output
length
* remove the use of random-to-key() and discussion of constant values from<= br> section 3
* add an output length argument to KDF-HMAC-SHA2() and adjust text
accordingly
* update test vectors to include base keys and key usage values for all
test cases
* reword the text discussing aes256 with 192-bit keys

For Jeffrey Altman:
* comment about the status of the crypto review and the interoperability testing in light of other comments that have come in on those points.

-Ben

--089e010d83f610d8f9051429fa04-- From nobody Mon Apr 20 09:18:58 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99DA1B2F9B for ; Mon, 20 Apr 2015 09:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2PL-mtkd5U7 for ; Mon, 20 Apr 2015 09:18:55 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 489381B2F94 for ; Mon, 20 Apr 2015 09:18:55 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 2AB8D2004F4E1; Mon, 20 Apr 2015 09:18:55 -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=Kp6vNzx2lZuS/x 4dhEjzKATxgCA=; b=xgi1Rb44QVpJvKBSmb7iKBebRPO1gL7ZAqCPLhEhkeSIOo fedCNQaNdVLpeiw9dACYSDOC4Los2TSXekqDNT8Z4S/BMyuhlzRwkJUxZyXey3Oz qEMUCeoH0/sEUq3F6fkn/tsOhiSmqeURJcNT0Pqvr0Tb364uiomKQj8lpjcPA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id 04FF32004F4DE; Mon, 20 Apr 2015 09:18:51 -0700 (PDT) Date: Mon, 20 Apr 2015 11:18:49 -0500 From: Nico Williams To: Sam Hartman Message-ID: <20150420161848.GS13041@localhost> References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> <20150420155313.GQ13041@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420155313.GQ13041@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , "leifj@sunet.se" , RFC Errata System Subject: [kitten] Non-blocking attribute prefix (Re: [Technical Errata Reported] RFC6680 (4337)) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 16:18:56 -0000 draft-williams-kitten-generic-naming-attributes-02 defines an attribute prefix, GSS_C_ATTR_GENERIC_FAST, to denote "please be fast/non-blocking". This works because if the mechanism/mechglue doesn't understand the composed attribute, then it must fail. And if it does understand it, then it must fail if it can't satisfy the constraint. This shows that we don't need to update RFC6680 so much as we need to publish an RFC defining generic attributes and attribute prefixes like this one. Nico -- From nobody Mon Apr 20 09:24:02 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936291B2FC2 for ; Mon, 20 Apr 2015 09:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnXm-ify00lV for ; Mon, 20 Apr 2015 09:24:00 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DF6F01B2FBF for ; Mon, 20 Apr 2015 09:24:00 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 633D4202044; Mon, 20 Apr 2015 09:24:00 -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=Pt7PpHr+9aUI40 IKtwytV3n/2uE=; b=xKPOOEtih4UcfbbxHozuVTi2BlPuVrVtDBI8bedEXqPJnO RFjxyhNcO1fWWsElvXkxurGGdMK2GSWPXWBdffpK/KGDv3Bgfsolg4Vxble/O+sg G8Chbys2OgUoAJ16od90ymmiW+baA7mkoHoybV3HAMgE5FTJlnJ7npbUM6c2I= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPA id 2775220203C; Mon, 20 Apr 2015 09:23:57 -0700 (PDT) Date: Mon, 20 Apr 2015 11:23:56 -0500 From: Nico Williams To: Sam Hartman Message-ID: <20150420162355.GT13041@localhost> References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> <20150420155313.GQ13041@localhost> <20150420161848.GS13041@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420161848.GS13041@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , "leifj@sunet.se" , RFC Errata System Subject: Re: [kitten] Non-blocking attribute prefix (Re: [Technical Errata Reported] RFC6680 (4337)) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 16:24:01 -0000 On Mon, Apr 20, 2015 at 11:18:49AM -0500, Nico Williams wrote: > draft-williams-kitten-generic-naming-attributes-02 defines an attribute > prefix, GSS_C_ATTR_GENERIC_FAST, to denote "please be fast/non-blocking". We could also add an attribute prefix by which to request that the mechanism implement a [POSIX thread] cancellation point around getting an attribute, thus making it easier for callers to impose timeouts. We could also have an attribute that imposes a particular timeout, though that requires baking the timeout value into the attribute name, and so that's a bit obnoxious. Nico -- From nobody Mon Apr 20 09:26:36 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046451B2FD9 for ; Mon, 20 Apr 2015 09:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJF-Ge8WlT8T for ; Mon, 20 Apr 2015 09:26:33 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A64DE1B2FDD for ; Mon, 20 Apr 2015 09:26:29 -0700 (PDT) Received: from homiemail-a98.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTP id D329E55406C; Mon, 20 Apr 2015 09:26:28 -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=OIW8N/YPdo6i7V 96kdAgqWJeMbk=; b=sGYmOm84Dld47kUzj3MzQ2U+rvuF7q3V7p70ZUTkPRUnV+ DQ1iHF5xvzRLtxt06SQyop6VsPweJwcDcaMgy71N/C0QAmQ3svO7ePS5BmAsK8BR ZYCNI4RcTEtc9XhZXzH9m+5f6XS5NH52cWRRJGUMYPXJyJLFmQ0PTqHXB2VW8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a98.g.dreamhost.com (Postfix) with ESMTPA id 53539554063; Mon, 20 Apr 2015 09:26:22 -0700 (PDT) Date: Mon, 20 Apr 2015 11:26:21 -0500 From: Nico Williams To: Sam Hartman Message-ID: <20150420162620.GU13041@localhost> References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> <20150420155313.GQ13041@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420155313.GQ13041@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , "leifj@sunet.se" , RFC Errata System Subject: [kitten] We may need GSS_Get_name_attributes() (plural) (Re: [Technical Errata Reported] RFC6680 (4337)) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 16:26:34 -0000 I think Alejandro may need a batched get attributes function. That would decidedly be an update. From nobody Mon Apr 20 09:35:04 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812E31A1A4B for ; Mon, 20 Apr 2015 09:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fguU2_GMmt0s for ; Mon, 20 Apr 2015 09:35:01 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BBEB1A039C for ; Mon, 20 Apr 2015 09:35:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 801AE206EB; Mon, 20 Apr 2015 12:34:26 -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 GqbNxVXg7o9Y; Mon, 20 Apr 2015 12:34:26 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (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; Mon, 20 Apr 2015 12:34:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 371638188A; Mon, 20 Apr 2015 12:34:53 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> <20150420155313.GQ13041@localhost> Date: Mon, 20 Apr 2015 12:34:53 -0400 In-Reply-To: <20150420155313.GQ13041@localhost> (Nico Williams's message of "Mon, 20 Apr 2015 10:53:15 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , RFC Errata System , Sam Hartman , "leifj@sunet.se" Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 16:35:02 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Mon, Apr 20, 2015 at 09:37:37AM -0400, Sam Hartman wrote: >> Well, I agree that we did think that things might block. >> I am less clear that we thought about anything specific that >> wouldn't block, and I'm concerned introducing this text implies >> there are things that don't block. Nico> I always thought that attributes listed in GSS_Inquire_name() Nico> wouldn't block: because they are would be "raw" things in Nico> Kerberos authorization-data or similar. I agree that we should write applications assuming they will be fast. That's very different from non-blocking for reasons including the ones I already explained: network swap, demand paging over the net, database lookups for things like nss etc that you'd expect to be fast but sometimes aren't. Basically, I don't think the IETF is in a position to say something is non-blocking because there are many reasonable implementations where that's simply impossible to implement. We can talk about whether an application should be prepared for an API to take a while. I think that attributes listed in the return from inquire_name are things an application can assume will be relatively fast compared to ones not in inquire_name. From nobody Mon Apr 20 09:35:34 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038CC1A03A0 for ; Mon, 20 Apr 2015 09:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB2xG-RKR3nv for ; Mon, 20 Apr 2015 09:35:32 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CFF651A026E for ; Mon, 20 Apr 2015 09:35:22 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 66BB72C8097; Mon, 20 Apr 2015 09:35:22 -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=2MqWw+IxF1znRe vh52QFRB58tKg=; b=ejG4g0ZYus+8pyqELKUvxqy4ic7PycUYFp7lx3n05QvHch Jd0PjVyb2+ANinOHOx8Qy/xmNFZHKhG+vaZnW/S7jTubpwfqwSK1YMpflxpqYViQ UW/jgAPN/Z8izYuvdRYXZrEBsEry6ueYzMswCCf3zw0FVtfSYvpTCR0G0I3yQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 6EB332C807A; Mon, 20 Apr 2015 09:35:21 -0700 (PDT) Date: Mon, 20 Apr 2015 11:35:20 -0500 From: Nico Williams To: Sam Hartman Message-ID: <20150420163519.GV13041@localhost> References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> <20150420155313.GQ13041@localhost> <20150420162620.GU13041@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150420162620.GU13041@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , "leifj@sunet.se" , RFC Errata System Subject: Re: [kitten] We may need GSS_Get_name_attributes() (plural) (Re: [Technical Errata Reported] RFC6680 (4337)) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 16:35:33 -0000 On Mon, Apr 20, 2015 at 11:26:21AM -0500, Nico Williams wrote: > I think Alejandro may need a batched get attributes function. That > would decidedly be an update. Actually, it seems that Alejandro needs to be able to request name attributes that should come in a security context token. That's a significant complication. And it may be a great use for asynchronous context tokens! Nico -- From nobody Mon Apr 20 09:42:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAD11A7113 for ; Mon, 20 Apr 2015 09:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uozwkt6VoXYw for ; Mon, 20 Apr 2015 09:42:31 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 390631A19E3 for ; Mon, 20 Apr 2015 09:42:31 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 179F159407C; Mon, 20 Apr 2015 09:42:31 -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=W3RBIrf7zZx/U8 3et64Zp/XPR+A=; b=OEPYoQfgyG7Bo5rGxdmIGd0RXayMYC7aBKiHf8XpnrtDIL 4wXmtcLEfs5HH4RpoDDmtqhX3JVxbW0UUzsfWBHv1I6hkPJJShbFRytM0IY8fBOZ fD7V9WWPMBd4uPrhWn3JujKfIRGuIcZVqii5ACNQEa+0yBaenTqaqTeN/EbQs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id A7E3D594079; Mon, 20 Apr 2015 09:42:27 -0700 (PDT) Date: Mon, 20 Apr 2015 11:42:26 -0500 From: Nico Williams To: Sam Hartman Message-ID: <20150420164225.GW13041@localhost> References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> <20150420155313.GQ13041@localhost> 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) Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , RFC Errata System , "leifj@sunet.se" Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 16:42:32 -0000 On Mon, Apr 20, 2015 at 12:34:53PM -0400, Sam Hartman wrote: > I agree that we should write applications assuming they will be fast. > That's very different from non-blocking for reasons including the ones I > already explained: network swap, demand paging over the net, database > lookups for things like nss etc that you'd expect to be fast but > sometimes aren't. My take is this: if reading [what should be] a local configuration file results in slow I/O, then all is lost when it comes to being non-blocking. The same applies to swapping. So, if I ask for "fast" behavior, I should get "fast" behavior given the constraints of the running environment. E.g., bare metal with close-by local storage all cached in memory anyways, vs. VM guests with all-remote "local" storage. Using standard, portable APIs, the implementation can't tell if reading a "local" configuration file, or a memory allocation of some non-trivial size, will be slow, but it also doesn't have to. > Basically, I don't think the IETF is in a position to say something is > non-blocking because there are many reasonable implementations where > that's simply impossible to implement. We don't have to be too exact. > We can talk about whether an application should be prepared for an API > to take a while. That's what my I-D does. > I think that attributes listed in the return from inquire_name are > things an application can assume will be relatively fast compared to > ones not in inquire_name. Yes, but consider an attribute prefix that demands "relatively fast" service. A mechanism must fail if it doesn't understand that prefix. And if it does understand it, then it must fail if it can't satisfy the requested constraint. Nico -- From nobody Mon Apr 20 10:24:34 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 590501A035F for ; Mon, 20 Apr 2015 10:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id myJtbWd_qHuG for ; Mon, 20 Apr 2015 10:24:31 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67581A8773 for ; Mon, 20 Apr 2015 10:24:31 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-a2-5535364e3657 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 2E.58.03355.E4635355; Mon, 20 Apr 2015 13:24: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 t3KHOO4J014659; Mon, 20 Apr 2015 13:24:24 -0400 Received: from [18.101.8.198] (vpn-18-101-8-198.mit.edu [18.101.8.198]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3KHOMT3011458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 20 Apr 2015 13:24:23 -0400 Message-ID: <55353646.2020009@mit.edu> Date: Mon, 20 Apr 2015 13:24:22 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Michael Peck , Benjamin Kaduk References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrOtnZhpqMOu3mMXRzatYLH71NbM6 MHnsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBl/rq1iLfglUtF7/xJ7A+NtgS5GTg4JAROJ cwsOM0PYYhIX7q1nA7GFBBYzSRzozeli5AKyNzJKHL16nB3COcIkMXfHHxaQKl4BNYktHVfY QWwWAVWJje8+s4LYbALKEuv3bwWrERUIk5j2+zkrRL2gxMmZT8DiIgLOEs9PHWMCsZkFhCUu bN8LViMs4CIxa8sKqGV7GCW+rlgLVsQpEChx8udbFogGPYkd13+xQtjyEs1bZzNPYBSchWTH LCRls5CULWBkXsUom5JbpZubmJlTnJqsW5ycmJeXWqRrrJebWaKXmlK6iREcwpJ8Oxi/HlQ6 xCjAwajEwythaBIqxJpYVlyZe4hRkoNJSZR3rrZpqBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR XkF2oBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgTvQxOgRsGi1PTU irTMnBKENBMHJ8hwHqDhV0BqeIsLEnOLM9Mh8qcYFaXEeV+DJARAEhmleXC9sBTzilEc6BVh XglToCoeYHqC634FNJgJaHDcNhOQwSWJCCmpBkahNW777dX/9zvcXval0Vh+z8I072erba/f nvnf1nuGdGmS6cbAyC7+b8eUJlg9MDL5yHpZbOnpI9tkDk4+8iU7o8T46+s3xgcPbXO4+2Pz jKYvs5hc6iqbdl/4FeQ6aaLTJ4dJZvVf/Uy3TJ0kW/gl1yNd5GJkdSNHkkVzzEIPn8bJ83XW ae9WYinOSDTUYi4qTgQAnto1qAwDAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 17:24:33 -0000 On 04/20/2015 11:56 AM, Michael Peck wrote: > Our draft's current practice of truncating the pseudo-random function > output to 128 bits (for enctype aes128-cts-hmac-sha256-128) and 256 bits > (for enctype aes256-cts-hmac-sha384-192) rather than providing the full > HMAC output has the benefit of discouraging misuse of the output. If > the full HMAC output is returned by the PRF, I'd be afraid it may imply > an output of 256 or 384 bit strength when the maximum strength is in > reality limited to 128 or 256. It's not clear to me the potential ways > the PRF output might be used - certainly I could see both appropriate > and inappropriate ways to use the output. To the best of my knowledge, all current users of the RFC 3961 PRF have a fixed amount of desired output, and iterate and truncate the PRF function to produce the number of desired bytes. See the definitions of PRF+ in RFC 4402 and RFC 6112. So, for example, if someone asks for 256 bits of PRF output (e.g. via gss_pseudo_random()) and the enctype is aes128-cts-hmac-sha256-128 with the PRF truncated to 128 bits. The user will wind up invoking PRF(K, 00 00 00 00 || string) PRF(K, 00 00 00 01 || string) and concatenating the results. The application has not in any way been discouraged from producing a 256-bit string with only 2^128 possible values; it has merely been made twice as slow. > If the working group prefers the full output be returned, we can do that > and could attempt to address it in the security considerations. I think the audience of this enctype's security considerations is mainly implementors of the enctype. Applications aren't written to specific enctypes; they are written to RFC 3961 or a higher layer. If you want to say something about the inherently limited entropy of the PRF output then I won't object, but I don't think it is necessary or useful. > We > provide the PRF definition to comply with the RFC 3961 framework but > would probably prefer a NIST SP 800-108 KDF be used to derive keys for > other uses. I could see the PRF output potentially being used as the Ki > key derivation key input to a NIST SP 800-108 KDF for those who want to > use that. The PRF+ construction is pretty similar to the KDF used in the aes-sha2 draft, except that it doesn't append a length to the end of each PRF invocation's input string. I believe the only potential problem there is that PRF+(K, 256, S) will be an extension of PRF+(K, 128, S) rather than a totally different value. That's a potential safety issue, but as long as callers use different S values for different kinds of keys, it's not a real problem. From nobody Mon Apr 20 10:44:19 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6171B2C6C for ; Mon, 20 Apr 2015 10:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDQPI0mC7unN for ; Mon, 20 Apr 2015 10:44:15 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C039D1A876D for ; Mon, 20 Apr 2015 10:44:15 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-8a-55353aeed298 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 74.C0.03389.EEA35355; Mon, 20 Apr 2015 13:44:14 -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 t3KHiDtQ024272; Mon, 20 Apr 2015 13:44:13 -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 t3KHi8Dh017261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Apr 2015 13:44:10 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3KHi7cA018743; Mon, 20 Apr 2015 13:44:07 -0400 (EDT) Date: Mon, 20 Apr 2015 13:44:07 -0400 (EDT) From: Benjamin Kaduk To: Sam Hartman In-Reply-To: Message-ID: References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsUixG6nrvvOyjTUYO1HVYuvbQ/YLBp25lsc 3byKxWJB71Zmi88Pb7NanLp2hM2iaf9XNot7Wy6xW0zfe43dgdNjyu+NrB4vT51j9FjbfZXN Y+esu+weS5b8ZPKYeeYiu0dD2zFWj5VTT7N77N3Uxx7AGcVlk5Kak1mWWqRvl8CV8XnGAZaC LSwVKw/PZGlgPMrcxcjJISFgIrHj7zYWCFtM4sK99WxdjFwcQgKLmSQ+dd2HcjYySix4OYkJ wjnEJPHxzAJGCKeBUaL13gUgh4ODRUBbYn6/BsgoNgEViZlvNrKB2CIC6hLtE76C2cwCG5gl tqyxBbGFBcwl3t99DHYGp4CaRPeGJWBjeAUcgeoFIcY3MUqsfPOCCaRGVEBHYvX+KWCn8goI Spyc+YQFYqaWxPLp21gmMArOQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6JXm5m iV5qSukmRlDUcEry72D8dlDpEKMAB6MSD6+EoUmoEGtiWXFl7iFGSQ4mJVFeDlPTUCG+pPyU yozE4oz4otKc1OJDjBIczEoivILsQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWp RTBZGQ4OJQnedEugRsGi1PTUirTMnBKENBMHJ8hwHqDhx0FqeIsLEnOLM9Mh8qcYdTnuTPm/ iEmIJS8/L1VKnHcuSJEASFFGaR7cHFiye8UoDvSWMC8HMPUJ8QATJdykV0BLmICWxG0zAVlS koiQkmpg7Gc5w3zqcfxmr70X9zZ/ndCobBd46u2aSBVhHf4Pu+9KV6z+u6VaXTH71vtbMh2S X49MLe56Kr/h9gX76ZJphWL7Il3zdt3vSffbUvdqUvxKtj9m57lOvOqS39XGEmkfwPupssxi zZTZ+11XqayaOKdQZEaZ6dTezyF3ZfIqkjgOKW77Eh1cpcRSnJFoqMVcVJwIAOEHZ1tRAwAA Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , RFC Errata System , "leifj@sunet.se" Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 17:44:17 -0000 On Sun, 19 Apr 2015, Sam Hartman wrote: > If Ben's aware of discussion in the kitten archives that show we > considered blocking and intended it to be the case that calls not > explicitly mentioned as blocking cannot block, then I'd support > theerrata. > OTherwise, I'd prefer a new document address this concern. This is somewhat overcome by events, but when submitting this erratum, I considered only the recent (past month) discussions on kitten. I did not investigate discussions back from when the document was still being developed. -Ben From nobody Mon Apr 20 11:03:26 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A27751B2CB5 for ; Mon, 20 Apr 2015 11:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtfYT9TiOiFS for ; Mon, 20 Apr 2015 11:03:23 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD1E91B2CB2 for ; Mon, 20 Apr 2015 11:03:22 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-e3-55353f696152 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 37.BA.03355.96F35355; Mon, 20 Apr 2015 14:03:21 -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 t3KI3KrW026256; Mon, 20 Apr 2015 14:03:20 -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 t3KI3HCO023379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Apr 2015 14:03:18 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3KI3GFN021226; Mon, 20 Apr 2015 14:03:16 -0400 (EDT) Date: Mon, 20 Apr 2015 14:03:16 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20150419230843.GP13041@localhost> Message-ID: References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrEKsWRmVeSWpSXmKPExsUixG6nrptpbxpqcHeyhsXXtgdsFg078y2O bl7FYrGgdyuzxeeHt1ktTl07wmbRtP8rm8W9LZfYLabvvcbuwOkx5fdGVo+Xp84xeqztvsrm sXPWXXaPJUt+MnnMPHOR3aOh7Rirx8qpp9k99m7qYw/gjOKySUnNySxLLdK3S+DKOHXyGnvB H4mK+3+fMzcwfhXuYuTkkBAwkTh45TMjhC0mceHeejYQW0hgMZPE1LWFEPZGRokJa8W6GLmA 7ENMEl2PTjNDOA2MEv/3dbCDVLEIaEu83/GIGcRmE1CRmPlmI9gkEQFNievzlrKBNDALLGGW mHAeokhYwFzi/d3HQDYHB6eAvsTUyyUgYV4BR4kXO88wQSxYyihx9tFUsEGiAjoSq/dPYYEo EpQ4OfMJmM0soCWxfPo2lgmMgrOQpGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6yX m1mil5pSuokRFDWcknw7GL8eVDrEKMDBqMTDK2FoEirEmlhWXJl7iFGSg0lJlJfD1DRUiC8p P6UyI7E4I76oNCe1+BCjBAezkgivIDtQjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6Yklqdmpq QWoRTFaGg0NJgveiLVCjYFFqempFWmZOCUKaiYMTZDgP0PCDIDW8xQWJucWZ6RD5U4yKUuK8 20ASAiCJjNI8uF5YUnvFKA70ijDvP5AqHmBChOt+BTSYCWhw3DYTkMEliQgpqQbGytalOTZp X7TWWV1IOjW5Qn7JrUPyt2XaX+ov15Lfx5Z+de+zTI4dX16duOn+W3HLh5KLG2UVU+fH/Tfe suPlk/O5/11OTJgW0jNXt3LHzJ+8u8SPdO+ZzBK62nyNeM6ee0xNsannzfgX8sqvfJ6cpvL5 xrcrZj2/mlyOtYms/FBjd+gcX8E7MyWW4oxEQy3mouJEAPinm/tFAwAA Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , RFC Errata System , Sam Hartman , "leifj@sunet.se" Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 18:03:24 -0000 On Sun, 19 Apr 2015, Nico Williams wrote: > On Sun, Apr 19, 2015 at 04:19:40PM -0400, Sam Hartman wrote: > > I really don't think we considered blocking when developing 6680. > > I think this is something that if we're going to discuss we need a full > > IETF consensus to say. > > I did think about it, though I don't recall specific on-the-list > discussions about it, I'm certain I discussed it with someone. In > particular I had wanted to consider UID/GID/SID lookups. My intention > was roughly as per-Ben's proposed text. > > > I think that the proposed text would be a good starting point, for this > > API. > > My concern is that other APIs in the document might block, and that I > > think that a WG such as kitten should fully consider the issue rather > > than using the erata process for this issue. > > I object neither to the erratum, nor to an update. I think this erratum > is sufficient for now, and we can work on an update to specify blocking > behavior in more detail. It sounds like the main objection to the current proposed erratum text is in the COMMENT, "Calls which are not explicitly permitted to block are assumed to be not permitted to block." Though the new text which explicitly calls out the attrs output of GSS_Inquire_name() does still have some implicit implications that some calls do not block, as well. I am not tied to the comment text; we could remove it and still have an erratum which stands on its own. It is a bit harder to excise the implicit implication from the new text. > We could update the erratum to add a list of what should be > non-controversial non-blocking behaviors: > > - GSS_Inquire_name() (of course, otherwise Ben's text doesn't work) > - GSS_Get_name_attribute() for attributes listed by GSS_Inquire_name() > - GSS_Export_name_composite() > (and any call to GSS_Import_name() to import an exported composite > name token) > > We might also want to say that specific attributes not listed by > GSS_Inquire_name() may yield blocking or non-blocking behavior in > GSS_Get/Set_name_attribute() according to the attributes' > specifications. > > > I'll note that we cannot really say that a call never blocks. An > > implementation may have network swap or executable segments that are > > demand page over a network filesystem. An implementation may use > > nsswitch resources that consult network databases, etc. > > The best we can say is that it's reasonable to write applications > > assuming certain APIs do not generally block. > > Yes. Defining "non-blocking" and "blocking" is non-trivial. What kinds > of I/O are slow (network) or fast (per-Unix: file I/O is fast)? Does a > long-running CPU-bound computation count as blocking? These both are getting to seem like fairly substantial changes which do not seem appropriate for an erratum, to me. It's also unclear that the WG has sufficient energy to do a full 6680bis right now. I will also note that we can choose to mark the current (small) 6680 erratum as Verified or Hold for Document Update, if we want to accept it; the latter may be more appropriate given Sam's concerns. -Ben From nobody Mon Apr 20 11:07:47 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342E51B2CD0 for ; Mon, 20 Apr 2015 11:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuMHu5h4R0NQ for ; Mon, 20 Apr 2015 11:07:45 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C2D1B2CCC for ; Mon, 20 Apr 2015 11:07:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3FF72206C0; Mon, 20 Apr 2015 14:07: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 xCqu7C1fRLIM; Mon, 20 Apr 2015 14:07:10 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (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; Mon, 20 Apr 2015 14:07:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CEA838188A; Mon, 20 Apr 2015 14:07:36 -0400 (EDT) From: Sam Hartman To: Benjamin Kaduk References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> Date: Mon, 20 Apr 2015 14:07:36 -0400 In-Reply-To: (Benjamin Kaduk's message of "Mon, 20 Apr 2015 14:03:16 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , Sam Hartman , "leifj@sunet.se" , RFC Errata System Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 18:07:47 -0000 >>>>> "Benjamin" == Benjamin Kaduk writes: Benjamin> It sounds like the main objection to the current proposed Benjamin> erratum text is in the COMMENT, "Calls which are not Benjamin> explicitly permitted to block are assumed to be not Benjamin> permitted to block." Though the new text which explicitly Benjamin> calls out the attrs output of GSS_Inquire_name() does Benjamin> still have some implicit implications that some calls do Benjamin> not block, as well. Benjamin> I am not tied to the comment text; we could remove it and Benjamin> still have an erratum which stands on its own. It is a Benjamin> bit harder to excise the implicit implication from the new Benjamin> text. Yeah, the comment is what caused me to have a concern. I think adding a note that this call can block would be helpful. From nobody Mon Apr 20 16:36:29 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD721B34E4 for ; Mon, 20 Apr 2015 16:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hOzdd6So8zT for ; Mon, 20 Apr 2015 16:36:25 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C5D1B34DD for ; Mon, 20 Apr 2015 16:36:24 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-81-55358d76981f Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B5.13.03389.67D85355; Mon, 20 Apr 2015 19:36:22 -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 t3KNaLMf005584; Mon, 20 Apr 2015 19:36:21 -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 t3KNaHnq027857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Apr 2015 19:36:18 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3KNaGn8003912; Mon, 20 Apr 2015 19:36:16 -0400 (EDT) Date: Mon, 20 Apr 2015 19:36:16 -0400 (EDT) From: Benjamin Kaduk To: Sam Hartman In-Reply-To: Message-ID: References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> <20150420155313.GQ13041@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCKsWRmVeSWpSXmKPExsUixCmqrVvWaxpqcL3bwuJr2wM2i4ad+RZH N69isVjQu5XZ4vPD26wWp64dYbNo2v+VzeLelkvsFtP3XmN34PSY8nsjq8fLU+cYPdZ2X2Xz 2DnrLrvHkiU/mTxmnrnI7tHQdozVY+XU0+weezf1sQdwRnHZpKTmZJalFunbJXBl/PmfXbCA p2Lmlv9sDYynOLsYOTkkBEwkWr7fYYWwxSQu3FvP1sXIxSEksJhJYnnDE1YIZyOjxOelS9gh nENMEtP2PGSCcBoYJX5d288M0s8ioC3R/e8tmM0moCIx881GNhBbREBdon3CV7C5zALLmCW2 XL4AlhAWMJd4f/cxWAOngJrEpKM3wA7hFXCUuN7QwgKx4Q+jxKSlP5hAEqICOhKr909hgSgS lDg58wmYzSygJbF8+jaWCYyCs5CkZiFJLWBkWsUom5JbpZubmJlTnJqsW5ycmJeXWqRropeb WaKXmlK6iREcOZL8Oxi/HVQ6xCjAwajEwythaBIqxJpYVlyZe4hRkoNJSZT3W4tpqBBfUn5K ZUZicUZ8UWlOavEhRgkOZiURXkF2oBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILU IpisDAeHkgRvQg9Qo2BRanpqRVpmTglCmomDE2Q4D9DwEpAa3uKCxNzizHSI/ClGRSlx3rkg CQGQREZpHlwvLLG9YhQHekWY1xykigeYFOG6XwENZgIaHLfNBGRwSSJCSqqBUeeF26O15XYt q6NETZg8l/s5Nu044iL1cpLHgtSc/hMeGZN94uZPkbQO2jenMaoxtIJnZsWmdlfWrxMkT367 Vtw6u1L641ZVy6xkBeNtJaZWJevPp5eomMzU3/vjhtCkG++d5nxLsfu698O1lcuNU2bNeh+d oWCZUPijMUpqacvd6DtGx01jlViKMxINtZiLihMB12gFfEcDAAA= Archived-At: Cc: "kitten@ietf.org" , Kathleen Moriarty , RFC Errata System , "leifj@sunet.se" Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2015 23:36:27 -0000 On Mon, 20 Apr 2015, Sam Hartman wrote: > >>>>> "Nico" == Nico Williams writes: > > Nico> On Mon, Apr 20, 2015 at 09:37:37AM -0400, Sam Hartman wrote: > >> Well, I agree that we did think that things might block. > > >> I am less clear that we thought about anything specific that > >> wouldn't block, and I'm concerned introducing this text implies > >> there are things that don't block. > > Nico> I always thought that attributes listed in GSS_Inquire_name() > Nico> wouldn't block: because they are would be "raw" things in > Nico> Kerberos authorization-data or similar. > > I agree that we should write applications assuming they will be fast. > That's very different from non-blocking for reasons including the ones I > already explained: network swap, demand paging over the net, database > lookups for things like nss etc that you'd expect to be fast but > sometimes aren't. I do not disagree. I used the term "block" in the erratum submission because that is the terminology used in RFC 2743, and the erratum should be consistent with the current base spec. > Basically, I don't think the IETF is in a position to say something is > non-blocking because there are many reasonable implementations where > that's simply impossible to implement. > We can talk about whether an application should be prepared for an API > to take a while. That's probably a better set of language to use, yes. We should keep it in mind when we pick up a 6680bis or 2743bis. -Ben From nobody Mon Apr 20 17:33:02 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 868081B35E1 for ; Mon, 20 Apr 2015 17:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bMRxZFQl4iI for ; Mon, 20 Apr 2015 17:33:00 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A571B35E2 for ; Mon, 20 Apr 2015 17:33:00 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-e4-55359abb9f5d Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 98.D4.03389.BBA95355; Mon, 20 Apr 2015 20:32:59 -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 t3L0Wwwq021754; Mon, 20 Apr 2015 20:32:58 -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 t3L0WuTW010218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 20 Apr 2015 20:32:58 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3L0Wu5Z010995; Mon, 20 Apr 2015 20:32:56 -0400 (EDT) Date: Mon, 20 Apr 2015 20:32:55 -0400 (EDT) From: Benjamin Kaduk To: Michael Peck In-Reply-To: <55353646.2020009@mit.edu> Message-ID: References: <55353646.2020009@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUixCmqrLt7lmmoweL1vBZHN69isfjV18zq wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGUsuHCDtWAze8WpufOZGhh/s3YxcnJICJhI XNyxlB3CFpO4cG89WxcjF4eQwGImicdf+1kgnI2MErNnb2YCqRISOMQkseg6VFUDo8TCU3MY QRIsAtoS/edugNlsAioSM99sZAOxRQSUJf4/mA7WzCwgLLH+3AxmEFtYwEVi1pYVYKs5BdQl tt56xAJi8wo4SkxfuZwVYsF1RomH3w+D3SoqoCOxev8UqCJBiZMzn7BADNWSWD59G8sERsFZ SFKzkKQWMDKtYpRNya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECA5WSf4djN8OKh1i FOBgVOLhZZhsGirEmlhWXJl7iFGSg0lJlPdbC1CILyk/pTIjsTgjvqg0J7X4EKMEB7OSCO+1 qUA53pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJXreZQI2CRanpqRVp mTklCGkmDk6Q4TxAw2+A1PAWFyTmFmemQ+RPMepy3JnyfxGTEEtefl6qlDjvb5AiAZCijNI8 uDmwJPOKURzoLWHeHJAqHmCCgpv0CmgJE9CSuG0mIEtKEhFSUg2MuSYuP7yuTN56+FZZy49S /fLut/t2zxTKZGtfn7vGwuV1xDup55Z7jBz8Tl7de8vj6ZEVx0LuT6tOvnp/e0XClglmTOGm t9Lk/+nmzTd8zregpXj9wrgrC8RXH2hN/HXwHuPSavbcvzmsbHLG/1Y8crewm9m6/qFEYcBD Od7SCLWihVeS1zFOVGIpzkg01GIuKk4EAJ7vvUMNAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-kitten-aes-cts-hmac-sha2-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 00:33:01 -0000 On Mon, 20 Apr 2015, Greg Hudson wrote: > On 04/20/2015 11:56 AM, Michael Peck wrote: > > Our draft's current practice of truncating the pseudo-random function > > output to 128 bits (for enctype aes128-cts-hmac-sha256-128) and 256 bits > > (for enctype aes256-cts-hmac-sha384-192) rather than providing the full > > HMAC output has the benefit of discouraging misuse of the output. If > > To the best of my knowledge, all current users of the RFC 3961 PRF have > a fixed amount of desired output, and iterate and truncate the PRF > function to produce the number of desired bytes. See the definitions of > PRF+ in RFC 4402 and RFC 6112. I'm trimming most of the mail, but I agree with everything Greg said. The RFC 3961 pseudo-random function is basically only useful as a building block for a PRF+ construction, given that different enctypes are permitted to (and do!) output different length pseudo-random output. -Ben From nobody Mon Apr 20 17:55:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD601B35AE for ; Mon, 20 Apr 2015 17:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7g79q2nHJxM for ; Mon, 20 Apr 2015 17:19:12 -0700 (PDT) Received: from mail-qc0-x22e.google.com (mail-qc0-x22e.google.com [IPv6:2607:f8b0:400d:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDB11B35A9 for ; Mon, 20 Apr 2015 17:19:12 -0700 (PDT) Received: by qcpm10 with SMTP id m10so68196745qcp.3 for ; Mon, 20 Apr 2015 17:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GIciiKYNUM9+ZXxwm7cmV7AJUuwovRLo3CP4pmcrLiA=; b=m9cQEBvHovHn9oOSrf75KzRvDwFKjYzKTcz1TQrqOBEG1xW6LMQepw/JuqN9Jughrt tFgrzy+GbF9bAm8mzhM5Fbs3VStoOvgZP6lTihQzbosovpkbZjBBNQisJKsXKw9WrYCA aIDTaHsMHHMY+KV192/P+khlktjBWYinTLkgdingvbXJb9msYd2chDiaXf9llAkwHBxc GjVB+d5Pb+BBAFPm6gAHVa2VoJZ107KdsOWUVMbXd0ykkzUGZ3DvOpy/c7eA87u/Wqxi hGABiye2v/dx8mIxfWteNW2RoVKx4zz4JArr4BOeDRLeFMdPi7cadVLLAdBwVcF0q/2k CulQ== X-Received: by 10.141.28.6 with SMTP id f6mr21052055qhe.97.1429575551406; Mon, 20 Apr 2015 17:19:11 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id g80sm198533qkh.18.2015.04.20.17.19.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 20 Apr 2015 17:19:10 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: Date: Mon, 20 Apr 2015 20:19:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <541B61E0-AC84-42B3-8F81-97D0D132FB91@gmail.com> References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> <20150420155313.GQ13041@localhost> To: Benjamin Kaduk Archived-At: X-Mailman-Approved-At: Mon, 20 Apr 2015 17:55:22 -0700 Cc: "kitten@ietf.org" , RFC Errata System , Sam Hartman , "leifj@sunet.se" Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 00:19:14 -0000 As Sam said, we can put a note in it and can edit the text of the proposed e= rrata. Tell us what this changes are and either Stephen or I will update an= d mark the errata. Thanks, Kathleen=20 Sent from my iPhone > On Apr 20, 2015, at 7:36 PM, Benjamin Kaduk wrote: >=20 > On Mon, 20 Apr 2015, Sam Hartman wrote: >=20 >>>>>>> "Nico" =3D=3D Nico Williams writes: >>=20 >> Nico> On Mon, Apr 20, 2015 at 09:37:37AM -0400, Sam Hartman wrote: >>>> Well, I agree that we did think that things might block. >>=20 >>>> I am less clear that we thought about anything specific that >>>> wouldn't block, and I'm concerned introducing this text implies >>>> there are things that don't block. >>=20 >> Nico> I always thought that attributes listed in GSS_Inquire_name() >> Nico> wouldn't block: because they are would be "raw" things in >> Nico> Kerberos authorization-data or similar. >>=20 >> I agree that we should write applications assuming they will be fast. >> That's very different from non-blocking for reasons including the ones I >> already explained: network swap, demand paging over the net, database >> lookups for things like nss etc that you'd expect to be fast but >> sometimes aren't. >=20 > I do not disagree. >=20 > I used the term "block" in the erratum submission because that is the > terminology used in RFC 2743, and the erratum should be consistent with > the current base spec. >=20 >> Basically, I don't think the IETF is in a position to say something is >> non-blocking because there are many reasonable implementations where >> that's simply impossible to implement. >> We can talk about whether an application should be prepared for an API >> to take a while. >=20 > That's probably a better set of language to use, yes. We should keep it > in mind when we pick up a 6680bis or 2743bis. >=20 > -Ben From nobody Wed Apr 22 10:50:43 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05EEB1A6FEA for ; Wed, 22 Apr 2015 10:50:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6PCyddweNH9 for ; Wed, 22 Apr 2015 10:50:40 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30C6A1A1A24 for ; Wed, 22 Apr 2015 10:50:38 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-b7-5537df6c334e Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 8F.06.03389.C6FD7355; Wed, 22 Apr 2015 13:50:37 -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 t3MHoZaE014988; Wed, 22 Apr 2015 13:50:36 -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 t3MHoVsk020861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Apr 2015 13:50:33 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3MHoVEH016163; Wed, 22 Apr 2015 13:50:31 -0400 (EDT) Date: Wed, 22 Apr 2015 13:50:31 -0400 (EDT) From: Benjamin Kaduk To: Sam Hartman In-Reply-To: Message-ID: References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsUixCmqrJt73zzU4MFdJouvbQ/YLI5uXsVi saB3K7PF54e3WS1OXTvCZtG0/yubxb0tl9gd2D2m/N7I6vHy1DlGjyVLfjJ5zDxzkd2joe0Y q8fKqafZPfZu6mMPYI/isklJzcksSy3St0vgyji8dCZjQTtHxct9L1gaGDewdTFyckgImEg0 7HvGBGGLSVy4tx4ozsUhJLCYSWLjz/1gCSGBjYwSj/8XQSQOMUmcXfmIEcJpYJToXH2SBaSK RUBbYsPyDewgNpuAisTMNxvBVogIqEu0T/gKNpZZYCmTxPS+78wgCWEBc4n3dx+D2ZwCahIf Zr8EW8cr4CjROvskE8SGr4wS35uWgRWJCuhIrN4/hQWiSFDi5MwnYDazgJbE8unbWCYwCs5C kpqFJLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrolebmaJXmpK6SZGcExI8u9g/HZQ6RCj AAejEg9vAKt5qBBrYllxZe4hRkkOJiVR3q9XgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeLlO AuV4UxIrq1KL8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR4Ze8BNQoWpaanVqRl 5pQgpJk4OEGG8wANf30XZHhxQWJucWY6RP4Uo6KUOC8XSLMASCKjNA+uF5ayXjGKA70izPsO pJ0HmO7gul8BDWYCGhy3zQRkcEkiQkqqgZFF6Sqbz416/tze8+aNqg9C/VzW7DRnPCWs+OAD Q4aAg5xtr6djpAWbr3vu2tdXK4ttNnFvZOZ1V+zr9dMre/ltGqdN5Jpv/KEPZTV2PRXUfLO+ 9wjbs5C3u5ekN7bP1fkXuGNt9ZTE24+cJ5iZaqRm1S5bovT5b+OGcy7rTh6/lbCDoWZ3iBJL cUaioRZzUXEiAFkQW200AwAA Archived-At: Cc: "kitten@ietf.org" , "leifj@sunet.se" , RFC Errata System Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:50:42 -0000 [Removing the ADs from the cc list until discussion is complete] On Mon, 20 Apr 2015, Sam Hartman wrote: > Yeah, the comment is what caused me to have a concern. > I think adding a note that this call can block would be helpful. Okay, I propose then that we modify the comment text in the reported erratum, and mark it as "hold for document update" (not "verified"). Does this proposal seem agreeable to everyone as a path forward? Other document updates could then proceed via the normal paths. OLD COMMENT: RFC 6680 makes no mention of blocking or not blocking on network interaction, though RFC 2743 does. This seems like the most reasonable interpretation of what is currently in RFC 6680. Calls which are not explicitly permitted to block are assumed to be not permitted to block. NEW COMMENT: RFC 6680 makes no mention of blocking or not blocking on network interaction, though RFC 2743 does. This seems like the most reasonable interpretation of what is currently in RFC 6680. -Ben From nobody Wed Apr 22 10:59:51 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10E881ACEA2 for ; Wed, 22 Apr 2015 10:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOTDu_W4GAN0 for ; Wed, 22 Apr 2015 10:59:49 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEE11ACE95 for ; Wed, 22 Apr 2015 10:59:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B994B206AE; Wed, 22 Apr 2015 13:58:51 -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 ch51Raer8E0T; Wed, 22 Apr 2015 13:58:51 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (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, 22 Apr 2015 13:58:51 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 32BEA87E88; Wed, 22 Apr 2015 13:59:28 -0400 (EDT) From: Sam Hartman To: Benjamin Kaduk References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> Date: Wed, 22 Apr 2015 13:59:28 -0400 In-Reply-To: (Benjamin Kaduk's message of "Wed, 22 Apr 2015 13:50:31 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "kitten@ietf.org" , Sam Hartman , "leifj@sunet.se" , RFC Errata System Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 17:59:50 -0000 I'm fine with the new comment, but I'd recommend marking approved. We can still do the update From nobody Wed Apr 22 11:19:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9F1AD066 for ; Wed, 22 Apr 2015 11:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.456 X-Spam-Level: X-Spam-Status: No, score=0.456 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, IXHASH_X1=1.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OtvqJqByzHT for ; Wed, 22 Apr 2015 11:19:31 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CA9771AD072 for ; Wed, 22 Apr 2015 11:19:25 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id 88234674060 for ; Wed, 22 Apr 2015 11:19:25 -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=4ekCX0h7gvrMRsLxU4FP E+LMh6A=; b=wq4Vy7p2C2n+Qacwbs6vBoYNUIDhRe274V52LZPRd2JtkU7sjMnS +nyukaL8IFkefdydjmCWe5xaZr83pjZY+kvWTxNZo0YTYJNBeRu5jCrkoollc1UM MDkDA2X/8o0J0apBpd8a32rwfFpdUlhig9Cr36+E5s1q+FrI5m+m6Rg= Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPSA id 599E1674058 for ; Wed, 22 Apr 2015 11:19:25 -0700 (PDT) Received: by iedfl3 with SMTP id fl3so49363519ied.1 for ; Wed, 22 Apr 2015 11:19:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.7.87 with SMTP id 84mr38272466ioh.76.1429726763072; Wed, 22 Apr 2015 11:19:23 -0700 (PDT) Received: by 10.64.128.133 with HTTP; Wed, 22 Apr 2015 11:19:22 -0700 (PDT) In-Reply-To: References: <20150418215222.7ABFD180206@rfc-editor.org> <4268E41F-712E-425D-B514-C0023D311462@gmail.com> <20150419230843.GP13041@localhost> Date: Wed, 22 Apr 2015 13:19:22 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" , "leifj@sunet.se" , RFC Errata System Subject: Re: [kitten] [Technical Errata Reported] RFC6680 (4337) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2015 18:19:32 -0000 On Wed, Apr 22, 2015 at 12:59 PM, Sam Hartman wrote: > I'm fine with the new comment, but I'd recommend marking approved. > We can still do the update +1 From nobody Sat Apr 25 07:06:00 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B121B2CB8 for ; Sat, 25 Apr 2015 07:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fAuhwVG14X3z for ; Sat, 25 Apr 2015 07:05:57 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A25C11B2CC3 for ; Sat, 25 Apr 2015 07:05:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DF717BE4D for ; Sat, 25 Apr 2015 15:05:55 +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 WXNi1UB-22Xf for ; Sat, 25 Apr 2015 15:05:54 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.29.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C14D0BE47 for ; Sat, 25 Apr 2015 15:05:54 +0100 (IST) Message-ID: <553B9F3D.9070104@cs.tcd.ie> Date: Sat, 25 Apr 2015 15:05:49 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "kitten@ietf.org" OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 14:05:59 -0000 Hiya, Sorry for the bit of delay here but I've done my AD evaluation of this. I have to questions I'd like to understand the answers for before starting IETF LC. I'm not sure if those will or will not cause any revisions to be needed before LC. Please consider the other nits along with any IETF LC comments that turn up. My questions: (1) 3.1 - I'm not getting why the host and port number are needed - won't the server know those anyway? (At least the port number for sure.) And if not, then I'm not clear what's going on, or it at least needs more explanation. Can you explain? (2) MUST TLS be provided or used? Section 4 said STARTTLS MUST be used, in section 5 you say provided. Either way, I think you should include a definitive statement in section 3 about that. (And I'd prefer MUST use of course:-) nitty nits: - ID nits gets a few reference things wrong, but it's ok - 3.1 (and elsewhere probably) I'm assuming the ABNF has been cross-checked, is that a safe assumption? - 3.1 kvsep with a value of 0x01 - is that commonly used? But it might be quite common for all I know:-) - 3.1, is there a real privacy benefit in omitting the authzid (where it works to omit that)? If not, this question is probably moot. But if there is, I wonder if the way you've stated the MAY there will result in people always including that if they can, which might not be what we want. In any case, the guidance here is a bit vague (and maybe it has to be) so would it be possible to be more concrete about in/ex-clusion of authzid? - Section 4, I also assume the examples have been checked. (Good set of examples though.) Cheers, Stephen. From nobody Sat Apr 25 10:25:15 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13831B2DCB for ; Sat, 25 Apr 2015 10:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ0IzC7Uje9t for ; Sat, 25 Apr 2015 10:25:11 -0700 (PDT) Received: from nm22-vm1.bullet.mail.bf1.yahoo.com (nm22-vm1.bullet.mail.bf1.yahoo.com [98.139.212.127]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CFDB1B2DCA for ; Sat, 25 Apr 2015 10:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1429982710; bh=dacOAU1V/wpG1LDQine8EfKpNam1wLl0KGQDnIRY8+8=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=AYRnIo+r0l53/P2+6quiARHuB+HmaGW0cSR3ecSZ0atUzIeIy8zM5jfsTVZeabOjZszejNJy1bZsBIv8UBBMQ1avEgXfVWZt28xDCj7ZYxLip1vnxzJRahF8j32qbV5tO2qBvN2r5/hzRkii/6TkHqbcTIbkSvrwkM3+cf0ytMijv0dtRY0k4vLu0iq+AOYKew3WLf42TXP5lzI2bDxQyTLgKRYsnQwk0c+zc1MH2fyDlcj3Htzl9nqYj3pXBgZsjsvReTw0RBgg88br6So2wzieR4lxRdBCy88O8vjxsZHb6T88PUbH3oaRngkYAB7lVmTodQedgcCoS5HmFheg3w== Received: from [98.139.214.32] by nm22.bullet.mail.bf1.yahoo.com with NNFMP; 25 Apr 2015 17:25:10 -0000 Received: from [98.139.212.195] by tm15.bullet.mail.bf1.yahoo.com with NNFMP; 25 Apr 2015 17:25:10 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 25 Apr 2015 17:25:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 894556.88044.bm@omp1004.mail.bf1.yahoo.com X-YMail-OSG: WJ7ZnjsVM1kJgFBMrDgtRaAwWBCkoeuDmWj0VNXuzyTDt3z8Sbn152mn3y6l.Xz zmsiaZKOOrAgtlcKlxQqISnJJsILQ.7GpSxfcmlUspZAQV7mvfmu5qlJm65qZQamMvTiJiuU.l.Q nIaX04McTE6dtdw7L.fMM2jO1dCPIaAeYfrX_2EO.rrF7e6ZrjvyHyxnC9jVA8_5gpH_WqUg_Hh5 pHef_a.uuzmlXvobiqgHX7pwFGxXkm3E1upjU4QeVsz796gVxz3HBJRyMvaWHoVzsuBmRUNOgGhV dEEuJMbfZai6RIr5mayRuJkfDJkj.5kXG.fqw8M5gzKisxliTdMuClKpXhcj7p2rsRsNbdn3A9CO O0SvVvMI50WzYKq9mWzE.8aGn.q54Jhp85SRTxJ60698vmMGwS5_v_XJVAdJntRTbjxSJ1upjbK_ gEDysOslox4zl7mFkZoehmM8eGZick1.iCpUvoZq3o3ciXxepMNuRKzzyIPBbgeI0_iltqnKUA7q rQf4pgPwHouPS9kCoFnUhgE0oQGViiCWAqndumZrYoIbXlZR7wclxog-- Received: by 66.196.80.193; Sat, 25 Apr 2015 17:25:10 +0000 Date: Sat, 25 Apr 2015 17:25:10 +0000 (UTC) From: Bill Mills To: Stephen Farrell , "kitten@ietf.org" Message-ID: <315224591.5091319.1429982710161.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <553B9F3D.9070104@cs.tcd.ie> References: <553B9F3D.9070104@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 17:25:13 -0000 Responses inline... On Saturday, April 25, 2015 7:06 AM, Stephen Farrell wrote: Hiya, Sorry for the bit of delay here but I've done my AD evaluation of this. I have to questions I'd like to understand the answers for before starting IETF LC. I'm not sure if those will or will not cause any revisions to be needed before LC. Please consider the other nits along with any IETF LC comments that turn up. My questions: (1) 3.1 - I'm not getting why the host and port number are needed - won't the server know those anyway? (At least the port number for sure.) And if not, then I'm not clear what's going on, or it at least needs more explanation. Can you explain? [wmills] To allow support of things like OAuth 1.0a that need the host and port to construct the signature base string. No the host may not know what name the client used to connect to it given that the same IMAP server (for example) might have N different names if it's a provider serving multiple companies each with their own domain name. (2) MUST TLS be provided or used? Section 4 said STARTTLS MUST be used, in section 5 you say provided. Either way, I think you should include a definitive statement in section 3 about that. (And I'd prefer MUST use of course:-) [wmills] The must here is because it's Bearer tokens which require TLS. "The Bearer Token examples assume encrypted transport; if the underlying connection is not already TLS then STARTTLS MUST be used as TLS is required in the Bearer Token specification." OAuth 1.0a may be used safely without TLS, but of course the underlying data should probably have TLS for privacy etc. nitty nits: - ID nits gets a few reference things wrong, but it's ok [wmills] happy to fix them if needed. Will RFC Ed. do it anyway? - 3.1 (and elsewhere probably) I'm assuming the ABNF has been cross-checked, is that a safe assumption? [wmills] I believe so. I'm aware of multiple interoperable implementations, Google and Outlook.com are major providers who have implemented. - 3.1 kvsep with a value of 0x01 - is that commonly used? But it might be quite common for all I know:-) [wmills] Control character separators are common in many systems. I chose it because we're handling things that might otherwise be in HTTP headers and 0x01 isn't valid there so we don't have to worry about escaping. - 3.1, is there a real privacy benefit in omitting the authzid (where it works to omit that)? If not, this question is probably moot. But if there is, I wonder if the way you've stated the MAY there will result in people always including that if they can, which might not be what we want. In any case, the guidance here is a bit vague (and maybe it has to be) so would it be possible to be more concrete about in/ex-clusion of authzid? [wmills] In the end whether authzid is required is based on server policy. I suspect you are right that clients will include it even when it's not needed because servers might require it and a generic client won't know. The existing implementations all have data in the protocol (IMAP, SMTP) that mirror the authzid anyway. - Section 4, I also assume the examples have been checked.(Good set of examples though.) [wmills] Ben did make me fix several as iteration happened so they have had at least one review.. Cheers, Stephen. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten From nobody Sat Apr 25 10:47:16 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5E71B2E12 for ; Sat, 25 Apr 2015 10:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSSSOLNwjw2s for ; Sat, 25 Apr 2015 10:47:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD031B2E11 for ; Sat, 25 Apr 2015 10:47:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 388EFBE50; Sat, 25 Apr 2015 18:47:10 +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 Gacus_nGsN8G; Sat, 25 Apr 2015 18:47:08 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.29.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 35DBFBE4D; Sat, 25 Apr 2015 18:47:08 +0100 (IST) Message-ID: <553BD31B.303@cs.tcd.ie> Date: Sat, 25 Apr 2015 18:47:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Bill Mills , "kitten@ietf.org" References: <553B9F3D.9070104@cs.tcd.ie> <315224591.5091319.1429982710161.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <315224591.5091319.1429982710161.JavaMail.yahoo@mail.yahoo.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 17:47:16 -0000 Hiya, On 25/04/15 18:25, Bill Mills wrote: > Responses inline... > > > On Saturday, April 25, 2015 7:06 AM, Stephen Farrell wrote: > > > Hiya, > > Sorry for the bit of delay here but I've done my AD evaluation > of this. I have to questions I'd like to understand the answers > for before starting IETF LC. I'm not sure if those will or will > not cause any revisions to be needed before LC. Please consider > the other nits along with any IETF LC comments that turn up. > > My questions: > > (1) 3.1 - I'm not getting why the host and port number are > needed - won't the server know those anyway? (At least the > port number for sure.) And if not, then I'm not clear what's > going on, or it at least needs more explanation. Can you > > explain? > > [wmills] To allow support of things like OAuth 1.0a that need > the host and port to construct the signature base string. No > the host may not know what name the client used to connect to > it given that the same IMAP server (for example) might have N > different names if it's a provider serving multiple companies > each with their own domain name. In principle the client might use a hostname that the server doesn't know about, or can't determine. However, were it the case that the SASL mechanism has to tell the server, then the application protocol would not work for multiple server identities with other SASL mechanisms, right? In which case the server has to know already or is broken. Or can you provide me with the details of a protocol that uses SASL where this is a real issue? I also don't see any case where the server does not know on which port it received data. And if the client could use authorization information for server1 at what the server thinks is server2 then that would seem to raise some significant vulnerabilities that are not discussed at all. Perhaps we're trying too hard to cover the issues faced when OAuth1.0a was used over http without tls? Nowadays, that is handled via SNI within TLS. > (2) MUST TLS be provided or used? Section 4 said STARTTLS > MUST be used, in section 5 you say provided. Either way, I > think you should include a definitive statement in section 3 > > about that. (And I'd prefer MUST use of course:-) > > [wmills] The must here is because it's Bearer tokens which require > TLS. "The Bearer Token examples assume > encrypted transport; if the underlying connection is not already TLS > then STARTTLS MUST be used as TLS is required in the Bearer Token > specification." OAuth 1.0a may be used safely without TLS, but of > course the underlying data should probably have TLS for privacy etc. All of that is fine, but does not explain why section 3 doesn't clearly say when TLS must be used, nor why sections 4 and 5 are not quite saying the same thing about that. So I think my question isn't really answered yet, sorry. S. > > nitty nits: > > > - ID nits gets a few reference things wrong, but it's ok > > [wmills] happy to fix them if needed. Will RFC Ed. do it anyway? > > - 3.1 (and elsewhere probably) I'm assuming the ABNF > has been cross-checked, is that a safe assumption? > > > [wmills] I believe so. I'm aware of multiple interoperable > implementations, Google and Outlook.com are major providers who > have implemented. > - 3.1 kvsep with a value of 0x01 - is that commonly used? > But it might be quite common for all I know:-) > > > [wmills] Control character separators are common in many systems. > I chose it because we're handling things that might otherwise be > in HTTP headers and 0x01 isn't valid there so we don't have to > worry about escaping. > > - 3.1, is there a real privacy benefit in omitting the > authzid (where it works to omit that)? If not, this > question is probably moot. But if there is, I wonder if > the way you've stated the MAY there will result in people > always including that if they can, which might not be what > we want. In any case, the guidance here is a bit vague > (and maybe it has to be) so would it be possible to be > more concrete about in/ex-clusion of authzid? > > > [wmills] In the end whether authzid is required is based on > server policy. I suspect you are right that clients will > include it even when it's not needed because servers might > require it and a generic client won't know. The existing > implementations all have data in the protocol (IMAP, SMTP) that > mirror the authzid anyway. > > > - Section 4, I also assume the examples have been checked.(Good set of examples though.) > > > [wmills] Ben did make me fix several as iteration happened > so they have had at least one review.. > > > Cheers, > Stephen. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > From nobody Sat Apr 25 11:14:56 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8402E1B2EBB for ; Sat, 25 Apr 2015 11:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCJW2DDa1waN for ; Sat, 25 Apr 2015 11:14:51 -0700 (PDT) Received: from nm12-vm0.bullet.mail.bf1.yahoo.com (nm12-vm0.bullet.mail.bf1.yahoo.com [98.139.213.140]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196E21B2EB9 for ; Sat, 25 Apr 2015 11:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1429985690; bh=Q5WzZVMmZksyGCUrcBUx1LdCcAIge0urL2H8qsFRbSY=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=JOXqzZVy97VV33UfofAXev56Xk0ovp7/Q0Jjjz6yCTMOLYfC/N36y1WYWaapPRvRIFqiZR6e297zQB1ZYgNC6DftsySzIS2HvDDvL7SwC8+RKfzfB81DKWpVe5L3smRnrUrjkcjoVOELBLFZTGjHllUb8tim7GKwnhIBmpS1rz2zsNMMuRj+s36YE1/8WpbVE+AbRXqWYYUDti4alIWz3QIj657qoKVpyR7bjtncpjBPAmBi6KD/QtKTNg1+txbTHlc6zbB+eYLJxU///pB4IoCgYLJ/RlB/4pXJ4khMP5aqVle1sEH43NoKm05Q/1CUY/SDEVM1y50KOxGGVac7SQ== Received: from [66.196.81.172] by nm12.bullet.mail.bf1.yahoo.com with NNFMP; 25 Apr 2015 18:14:50 -0000 Received: from [98.139.212.243] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 25 Apr 2015 18:14:50 -0000 Received: from [127.0.0.1] by omp1052.mail.bf1.yahoo.com with NNFMP; 25 Apr 2015 18:14:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 253856.74168.bm@omp1052.mail.bf1.yahoo.com X-YMail-OSG: pe0JsT8VM1m3IPg2LZeNOjJYHcVRBkqiw.LknIi0Nf8s90X_WJOWZu_HW03b0qn 8RQasNgfQm49.h0_eBjDO_mUHM5HrJQIIZEH.3BEKXz9S6dGDvPGCrRPaVTdipBM.NTgMkOKs6nY pHozEa3g3M2CEhj4MU5WQAfnw3.EyfoEfgsoCtfjNrQmPF7XM8C1IF5AmZUuwkj39RnHj58M.2dW cxGSDsqQzbXilDqsTYmFo1FUKICuN8aJWJAqKmnEhlez1dOYpvuTU0zeWMNba1UINAbFWVWT_Npf KbhdnpNXtzeN2HW4sCyVvsL3cAvuCQgiibaH0kw3lC8NlP81G8RUyl7gimJa0CD7INVak6sNGw0m Pn4fex5mk12edCt_bU251rAW7z.wv0WcQeODDSL71vNRQ.oB8UEhBRRDrJEC_30vMuGGi1x20EM7 A6Bnm6XR7mu5aSLGRytSYuFVXZGNmnfOB_a1NsEoY1fV6sRdsGPdbMAddsfM.vUka4QyL4MZmMuj w6b9Ee9n3eroBsKhNzEzOouIVmkd7cmhbYpniuAaoLyR2LblJYTZfbw-- Received: by 66.196.80.121; Sat, 25 Apr 2015 18:14:49 +0000 Date: Sat, 25 Apr 2015 18:14:49 +0000 (UTC) From: Bill Mills To: Stephen Farrell , "kitten@ietf.org" Message-ID: <575127954.5175870.1429985689398.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <553BD31B.303@cs.tcd.ie> References: <553BD31B.303@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5175869_1445947949.1429985689389" Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 18:14:54 -0000 ------=_Part_5175869_1445947949.1429985689389 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Inline again...=20 On Saturday, April 25, 2015 10:47 AM, Stephen Farrell wrote: =20 Hiya, On 25/04/15 18:25, Bill Mills wrote: > Responses inline... >=20 >=20 > On Saturday, April 25, 2015 7:06 AM, Stephen Farrell wrote: >=20 >=20 > Hiya, >=20 > Sorry for the bit of delay here but I've done my AD evaluation > of this. I have to questions I'd like to understand the answers > for before starting IETF LC. I'm not sure if those will or will > not cause any revisions to be needed before LC. Please consider > the other nits along with any IETF LC comments that turn up. >=20 > My questions: >=20 > (1) 3.1 - I'm not getting why the host and port number are > needed - won't the server know those anyway? (At least the > port number for sure.) And if not, then I'm not clear what's > going on, or it at least needs more explanation. Can you >=20 > explain? >=20 > [wmills] To allow support of things like OAuth 1.0a that need > the host and port to construct the signature base string.=C2=A0 No > the host may not know what name the client used to connect to > it given that the same IMAP server (for example) might have N > different names if it's a provider serving multiple companies > each with their own domain name.=20 In principle the client might use a hostname that the server doesn't know about, or can't determine. However, were it the case that the SASL mechanism has to tell the server, then the application protocol would not work for multiple server identities with other SASL mechanisms, right? In which case the server has to know already or is broken. Or can you provide me with the details of a protocol that uses SASL where this is a real issue? [wmills] =C2=A0Yes the server might validate for known hostnames, asHTTP se= rvers can but it you specify an unknown host in the hostheader it falls thr= ough to default. =C2=A0 This is specific to the case wherethe mechanism sup= porting OAuth 1.0a requires hostname, so Idon't see how this would break so= me other SASL mechanism? I also don't see any case where the server does not know on which port it received data. [wmills] at ${previousjob} there were IMAP servers that had a TLSaccellerat= or in front of them and the back end IMAP server lived=C2=A0on the same por= t whether it got a direct connect or a proxied one.Not ideal perhaps, but a= n example. And if the client could use authorization information for server1 at what the server thinks is server2 then that would seem to raise some significant vulnerabilities that are not discussed at all. [wmills] OAuth tokens might or might not be bound ot a singledomain and cer= tainly cane be used at N hostnames withing a given=C2=A0TLD. =C2=A0Where/ho= w tokens might be valid is outside this scope. Perhaps we're trying too hard to cover the issues faced when OAuth1.0a was used over http without tls? Nowadays, that is handled via SNI within TLS. [wmills] I completely disagree given that SNI is not pervasive,=C2=A0less t= han 70% of browsers/clients support it last I knew. =C2=A0SNI=C2=A0doesn't = solve for why OAuth 1.0a uses hostname either. > (2) MUST TLS be provided or used? Section 4 said STARTTLS > MUST be used, in section 5 you say provided. Either way, I > think you should include a definitive statement in section 3 >=20 > about that. (And I'd prefer MUST use of course:-) >=20 > [wmills] The must here is because it's Bearer tokens which require=20 > TLS.=C2=A0 "The Bearer Token examples assume=20 > encrypted transport; if the underlying connection is not already TLS=20 > then STARTTLS MUST be used as TLS is required in the Bearer Token=20 > specification."=C2=A0 OAuth 1.0a may be used safely without TLS, but of > course the underlying data should probably have TLS for privacy etc. All of that is fine, but does not explain why section 3 doesn't clearly say when TLS must be used, nor why sections 4 and 5 are not quite saying the same thing about that. So I think my question isn't really answered yet, sorry. [wmills] Section 3 defines this per mechanism and says: "OAUTHBEARER: OAuth 2.0 bearer tokens, as described in [RFC6750]. R= FC 6750 uses Transport Layer Security (TLS) [RFC5246] to secure the protocol interaction between the client and the resource server." This is derived from the explicit requirements in the Bearer spec, but ther= e was=C2=A0a problem there in that there was an existing Bearer implementat= ion (FB) that didn't=C2=A0use TLS and they didn't want to be declared out o= f spec so I think the language isSHOULD instead of MUST. =C2=A0We were awar= e of a possible mismatch and didn't want=C2=A0be in conflict with the langu= age from there. =C2=A0 Do we need something clearer than that? =C2=A0Do we need to add something= =C2=A0explicit about new mechanisms being required to define whether encryp= tion=C2=A0is required? =C2=A0=C2=A0[/wmills] S. >=20 > nitty nits: >=20 >=20 > - ID nits gets a few reference things wrong, but it's ok >=20 > [wmills] happy to fix them if needed.=C2=A0 Will RFC Ed. do it anyway? >=20 > - 3.1 (and elsewhere probably) I'm assuming the ABNF > has been cross-checked, is that a safe assumption? >=20 >=20 > [wmills]=C2=A0 I believe so.=C2=A0 I'm aware of multiple interoperable=20 > implementations, Google and Outlook.com are major providers who > have implemented. > - 3.1 kvsep with a value of 0x01 - is that commonly used? > But it might be quite common for all I know:-) >=20 >=20 > [wmills] Control character separators are common in many systems. > I chose it because we're handling things that might otherwise be > in HTTP headers and 0x01 isn't valid there so we don't have to=20 > worry about escaping. >=20 > - 3.1, is there a real privacy benefit in omitting the > authzid (where it works to omit that)? If not, this > question is probably moot. But if there is, I wonder if > the way you've stated the MAY there will result in people > always including that if they can, which might not be what > we want. In any case, the guidance here is a bit vague > (and maybe it has to be) so would it be possible to be > more concrete about in/ex-clusion of authzid? >=20 >=20 > [wmills] In the end whether authzid is required is based on=20 > server policy.=C2=A0 I suspect you are right that clients will=20 > include it even when it's not needed because servers might > require it and a generic client won't know.=C2=A0 The existing=20 > implementations all have data in the protocol (IMAP, SMTP) that=20 > mirror the authzid anyway. >=20 >=20 > - Section 4, I also assume the examples have been checked.(Good set of ex= amples though.) >=20 >=20 > [wmills] Ben did make me fix several as iteration happened > so they have had at least one review.. >=20 >=20 > Cheers, > Stephen. >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 >=20 ------=_Part_5175869_1445947949.1429985689389 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Inline again...



<= /div>
On Saturday, April 25, 2015 10:47 AM, S= tephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
=
Hiya,

On 25/04/15 18:25, Bill Mills = wrote:
> Responses inline...
> >
> On Saturday, April 25, 2015 7= :06 AM, Stephen Farrell <stephen.farrell@c= s.tcd.ie> wrote:
>
>
> Hiya,
>
> So= rry for the bit of delay here but I've done my AD evaluation
> of this. I have to questions I'd like to understand the answers> for before starting IETF LC. I'm not sure if those wil= l or will
> not cause any revisions to be needed befor= e LC. Please consider
> the other nits along with any = IETF LC comments that turn up.
>
&g= t; My questions:
>
> (1) 3.1 - I= 'm not getting why the host and port number are
> need= ed - won't the server know those anyway? (At least the
&g= t; port number for sure.) And if not, then I'm not clear what's
> going on, or it at least needs more explanation. Can you
>
> explain?
> > [wmills] To allow support of things like OAuth 1.0a t= hat need
> the host and port to construct the signatur= e base string.  No
> the host may not know what n= ame the client used to connect to
> it given that the = same IMAP server (for example) might have N
> differen= t names if it's a provider serving multiple companies
>= ; each with their own domain name.

In= principle the client might use a hostname that the server
doesn't know about, or can't determine. However, were it the
case that the SASL mechanism has to tell the server, then the
application protocol would not work for multiple server
identities with other SASL mechanisms, right? In which case
the server has to know already or is broken. Or can you provid= e
me with the details of a protocol that uses SASL where = this is
a real issue?

[wmills] &nbs= p;Yes the server might validate for known hostnames, as
HTTP servers can = but it you specify an unknown host in the host
header it fall= s through to default.   This is specific to the case where
the mechanism supporting OAuth 1.0a requires hostname, so I
don't see how this would break some other SASL mechanism?
<= br>
I also don't see any case where the server does not k= now on
which port it received data.
[wmills] at ${previousjob} there were IMAP servers that had a TLS
accellerator in front of them and the back end IMAP server lived = ;
on the same port whether it got a direct connect or a proxi= ed one.
Not ideal perhaps, but an example.

=

And if the client could use authorization= information for
server1 at what the server thinks is ser= ver2 then that would seem
to raise some significant vulne= rabilities that are not discussed
at all.

[wmills] OAuth tokens might or might not be bound ot a single
<= div class=3D"y_msg_container" id=3D"yui_3_16_0_1_1429898340981_235728" dir= =3D"ltr">domain and certainly cane be used at N hostnames withing a given&n= bsp;
TLD.  Where/how tokens might be valid is outside th= is scope.

Perhaps we're trying too hard to cover the = issues faced when
OAuth1.0a was used over http without tl= s? Nowadays, that is
handled via SNI within TLS.

[wmills] I completely disagree given that SNI is not pervasiv= e, 
less than 70% of browsers/clients support it last I = knew.  SNI 
doesn't solve for why OAuth 1.0a uses h= ostname either.

> (2) MUST TLS be provi= ded or used? Section 4 said STARTTLS
> MUST be used, i= n section 5 you say provided. Either way, I
> think yo= u should include a definitive statement in section 3
>=
> about that. (And I'd prefer MUST use of course:-)<= br clear=3D"none">>
> [wmills] The must here is be= cause it's Bearer tokens which require
> TLS.  "= The Bearer Token examples assume
> encrypted transpor= t; if the underlying connection is not already TLS
> = then STARTTLS MUST be used as TLS is required in the Bearer Token
> specification."  OAuth 1.0a may be used safely without = TLS, but of
> course the underlying data should probab= ly have TLS for privacy etc.

All of th= at is fine, but does not explain why section 3 doesn't
cl= early say when TLS must be used, nor why sections 4 and 5 are
not quite saying the same thing about that. So I think my question
isn't really answered yet, sorry.

[wmills] Section 3 defines this per mechanism and says:
=

"OAUTHBEARER: OAuth 2= .0 bearer tokens, as described in [RFC6750].
         RFC 6750 uses Transport =
Layer Security (TLS) [RFC5246] to
         secure the protocol interaction between the client and the
         resource server."

This is derived from the explicit requirements in the Bearer spec= , but there was 
a problem there in that there was an existing Bearer implementat= ion (FB) that didn't 
use TLS and they didn't want to be declared out of spec so = I think the language is
SHOULD instead of MUST.  We were aware of a possible mism= atch and didn't want 
be in conflict with the language from there.  

Do we need something cle= arer than that?  Do we need to add something 
explicit about new mechanisms = being required to define whether encryption 
is required?   
[/wmills]

S.

>
> nitty nits:
>
>
> - ID nits gets a few reference things wrong, but it's ok
>
> [wmills] happy to fix them if n= eeded.  Will RFC Ed. do it anyway?
>
> - 3.1 (and elsewhere probably) I'm assuming the ABNF
> has been cross-checked, is that a safe assumption?
>
>
> [wmills]&nbs= p; I believe so.  I'm aware of multiple interoperable
> implementations, Google and Outlook.com are major providers who
> have implemented.
> - 3.1 kvsep wi= th a value of 0x01 - is that commonly used?
> But it m= ight be quite common for all I know:-)
>
>
> [wmills] Control character separators ar= e common in many systems.
> I chose it because we're h= andling things that might otherwise be
> in HTTP heade= rs and 0x01 isn't valid there so we don't have to
> w= orry about escaping.
>
> - 3.1, = is there a real privacy benefit in omitting the
> auth= zid (where it works to omit that)? If not, this
> ques= tion is probably moot. But if there is, I wonder if
> = the way you've stated the MAY there will result in people
> always including that if they can, which might not be what
> we want. In any case, the guidance here is a bit vague
> (and maybe it has to be) so would it be possible to be> more concrete about in/ex-clusion of authzid?
>
>
> [wmills] In = the end whether authzid is required is based on
> ser= ver policy.  I suspect you are right that clients will
> include it even when it's not needed because servers might
> require it and a generic client won't know.  The exist= ing
> implementations all have data in the protocol (= IMAP, SMTP) that
> mirror the authzid anyway.
>
>
> - Section 4= , I also assume the examples have been checked.(Good set of examples though= .)
>
>
> [= wmills] Ben did make me fix several as iteration happened
> so they have had at least one review..
>
>
> Cheers,
> Ste= phen.
>
> ______________________= _________________________
> Kitten mailing list
> Kitten@ietf.org
> https://www.ietf.org/mailman/listinfo/kitten
>
>


<= /div>
------=_Part_5175869_1445947949.1429985689389-- From nobody Sat Apr 25 13:31:45 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F93D1B3051 for ; Sat, 25 Apr 2015 13:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwCtoNZ9mVwq for ; Sat, 25 Apr 2015 13:31:41 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A901B3050 for ; Sat, 25 Apr 2015 13:31:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9EC37BE4C; Sat, 25 Apr 2015 21:31:37 +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 U5qjjpPMVyh5; Sat, 25 Apr 2015 21:31:35 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.29.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D5984BE49; Sat, 25 Apr 2015 21:31:34 +0100 (IST) Message-ID: <553BF9A5.7080408@cs.tcd.ie> Date: Sat, 25 Apr 2015 21:31:33 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Bill Mills , "kitten@ietf.org" References: <553BD31B.303@cs.tcd.ie> <575127954.5175870.1429985689398.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <575127954.5175870.1429985689398.JavaMail.yahoo@mail.yahoo.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 20:31:44 -0000 I'm sorry but we seem to be talking past one another for both issues. Let me try another tack but it may also help if someone else chimes in. On 25/04/15 19:14, Bill Mills wrote: > Inline again... > > > On Saturday, April 25, 2015 10:47 AM, Stephen Farrell > wrote: > > Hiya, > > On 25/04/15 18:25, Bill Mills wrote: >> Responses inline... >> >> >> On Saturday, April 25, 2015 7:06 AM, Stephen Farrell >> wrote: >> >> >> Hiya, >> >> Sorry for the bit of delay here but I've done my AD evaluation of >> this. I have to questions I'd like to understand the answers for >> before starting IETF LC. I'm not sure if those will or will not >> cause any revisions to be needed before LC. Please consider the >> other nits along with any IETF LC comments that turn up. >> >> My questions: >> >> (1) 3.1 - I'm not getting why the host and port number are needed - >> won't the server know those anyway? (At least the port number for >> sure.) And if not, then I'm not clear what's going on, or it at >> least needs more explanation. Can you >> >> explain? >> >> [wmills] To allow support of things like OAuth 1.0a that need the >> host and port to construct the signature base string. No the host >> may not know what name the client used to connect to it given that >> the same IMAP server (for example) might have N different names if >> it's a provider serving multiple companies each with their own >> domain name. > > In principle the client might use a hostname that the server doesn't > know about, or can't determine. However, were it the case that the > SASL mechanism has to tell the server, then the application protocol > would not work for multiple server identities with other SASL > mechanisms, right? In which case the server has to know already or is > broken. Or can you provide me with the details of a protocol that > uses SASL where this is a real issue? > > [wmills] Yes the server might validate for known hostnames, asHTTP > servers can but it you specify an unknown host in the hostheader it > falls through to default. This is specific to the case wherethe > mechanism supporting OAuth 1.0a requires hostname, so Idon't see how > this would break some other SASL mechanism? Let's stick with just IMAP for a moment. If an IMAP server has to support many server identities then that has to work for all the SASL mechanisms it supports. That means that identifying the correct server name has to be done by IMAP, or, possibly, via TLS, since most SASL mechanisms will not specify which server identity is in question, or if they do, it is too late in the overall client-server interaction. Otherwise, something is broken already in IMAP. If IMAP is not broken in that way, then I don't see any need for additional mechanism to support IMAP mutli-tenancy (or whatever one wants to call it) that has to be provided here, as part of any of these SASL mechanisms. And if I'm wrong and there is such a need, (quite possible, I'm often wrong) then that calls for discussion of the possible mismatches that may ensue. Or, if there is some reason to want some special handling for just these mechanisms (e.g. if the authorization is really for something else but we want to re-use that for e.g. IMAP), then that clearly calls for additional security considerations. > > I also don't see any case where the server does not know on which > port it received data. > > [wmills] at ${previousjob} there were IMAP servers that had a > TLSaccellerator in front of them and the back end IMAP server lived > on the same port whether it got a direct connect or a proxied one.Not > ideal perhaps, but an example. Not convinced tbh. That's an issue for the weird middlebox isn't it. Same as passing on possible client cert information. > > And if the client could use authorization information for server1 at > what the server thinks is server2 then that would seem to raise some > significant vulnerabilities that are not discussed at all. > > [wmills] OAuth tokens might or might not be bound ot a singledomain > and certainly cane be used at N hostnames withing a given TLD. > Where/how tokens might be valid is outside this scope. > > Perhaps we're trying too hard to cover the issues faced when > OAuth1.0a was used over http without tls? Nowadays, that is handled > via SNI within TLS. > > [wmills] I completely disagree given that SNI is not pervasive, less > than 70% of browsers/clients support it last I knew. Those are surprising numbers. Do you have a reference? > SNI doesn't > solve for why OAuth 1.0a uses hostname either. My point in any case is that this either is not an issue or else if you do want potential duplication of data sent from client to server, then you have to account for the security considerations. >> (2) MUST TLS be provided or used? Section 4 said STARTTLS MUST be >> used, in section 5 you say provided. Either way, I think you should >> include a definitive statement in section 3 >> >> about that. (And I'd prefer MUST use of course:-) >> >> [wmills] The must here is because it's Bearer tokens which require >> TLS. "The Bearer Token examples assume encrypted transport; if >> the underlying connection is not already TLS then STARTTLS MUST be >> used as TLS is required in the Bearer Token specification." OAuth >> 1.0a may be used safely without TLS, but of course the underlying >> data should probably have TLS for privacy etc. > > All of that is fine, but does not explain why section 3 doesn't > clearly say when TLS must be used, nor why sections 4 and 5 are not > quite saying the same thing about that. So I think my question isn't > really answered yet, sorry. [wmills] Section 3 defines this per > mechanism and says: "OAUTHBEARER: OAuth 2.0 bearer tokens, as > described in [RFC6750]. RFC 6750 uses Transport Layer > Security (TLS) [RFC5246] to secure the protocol interaction between > the client and the resource server." This is derived from the > explicit requirements in the Bearer spec, but there was a problem > there in that there was an existing Bearer implementation (FB) that > didn't use TLS and they didn't want to be declared out of spec so I > think the language isSHOULD instead of MUST. We were aware of a > possible mismatch and didn't want be in conflict with the language > from there. Do we need something clearer than that? Do we need to > add something explicit about new mechanisms being required to define > whether encryption is required? [/wmills] S. > Sorry, I remain none the wiser. Yes, other RFCs make statements about support or use of TLS. My point is this draft makes two different statements on the topic, and says nothing at all in section 3. The inconsistency is within this single draft in this case and needs fixing I think. S. >> >> nitty nits: >> >> >> - ID nits gets a few reference things wrong, but it's ok >> >> [wmills] happy to fix them if needed. Will RFC Ed. do it anyway? >> >> - 3.1 (and elsewhere probably) I'm assuming the ABNF has been >> cross-checked, is that a safe assumption? >> >> >> [wmills] I believe so. I'm aware of multiple interoperable >> implementations, Google and Outlook.com are major providers who >> have implemented. - 3.1 kvsep with a value of 0x01 - is that >> commonly used? But it might be quite common for all I know:-) >> >> >> [wmills] Control character separators are common in many systems. I >> chose it because we're handling things that might otherwise be in >> HTTP headers and 0x01 isn't valid there so we don't have to worry >> about escaping. >> >> - 3.1, is there a real privacy benefit in omitting the authzid >> (where it works to omit that)? If not, this question is probably >> moot. But if there is, I wonder if the way you've stated the MAY >> there will result in people always including that if they can, >> which might not be what we want. In any case, the guidance here is >> a bit vague (and maybe it has to be) so would it be possible to be >> more concrete about in/ex-clusion of authzid? >> >> >> [wmills] In the end whether authzid is required is based on server >> policy. I suspect you are right that clients will include it even >> when it's not needed because servers might require it and a generic >> client won't know. The existing implementations all have data in >> the protocol (IMAP, SMTP) that mirror the authzid anyway. >> >> >> - Section 4, I also assume the examples have been checked.(Good set >> of examples though.) >> >> >> [wmills] Ben did make me fix several as iteration happened so they >> have had at least one review.. >> >> >> Cheers, Stephen. >> >> _______________________________________________ Kitten mailing >> list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten >> >> > > > > From nobody Sat Apr 25 15:31:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D37C1ACDB9 for ; Sat, 25 Apr 2015 15:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.459 X-Spam-Level: X-Spam-Status: No, score=-0.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-GX-tX-0YlY for ; Sat, 25 Apr 2015 15:31:18 -0700 (PDT) Received: from nm33-vm8.bullet.mail.gq1.yahoo.com (nm33-vm8.bullet.mail.gq1.yahoo.com [98.136.216.247]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D23D31ACDB4 for ; Sat, 25 Apr 2015 15:31:18 -0700 (PDT) Received: from [127.0.0.1] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2015 22:31:18 -0000 Received: from [98.137.12.63] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2015 22:28:18 -0000 Received: from [98.139.215.141] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 25 Apr 2015 22:28:17 -0000 Received: from [98.139.212.220] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 25 Apr 2015 22:28:17 -0000 Received: from [127.0.0.1] by omp1029.mail.bf1.yahoo.com with NNFMP; 25 Apr 2015 22:28:17 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 610053.84428.bm@omp1029.mail.bf1.yahoo.com Received: (qmail 90614 invoked by uid 60001); 25 Apr 2015 22:28:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1430000897; bh=Kn+WIl8SGY6WxxgMP7wWvVNChcYj7TPTFH+4pReMh6M=; h=Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=2wiopACXUWlfHwOq7JiQW9uRS+hgrqXkHDl8wIj0r4yfvIyjMZc+Oh/LFGegkNMQum/vJ3zmnAJ/WCldOZPcrQ26vOth3ouktpHrlH4Wl3nWXEYcmI7pmO/VN5KXzw6XzTWfJErdeKIU0RDfV150V4+qylAh6G6+W/CGv6H/qVs= X-YMail-OSG: c7rvfu0VM1m.INPaSPY36uYvTrSV0s0L9rHmuwYpVZqAUwG opcXAlG03Nd6e7xHFabS6HGxMl0XME_VTpZeQ1th708cFgtmpH3ZPKGZTSfL Ezu.hV1_7I2D_V0M9OxWfyv9pPbFTrJYFrz.ovlKICRSLnZhWofU7p7tUg8H EHjkkTAFoAozl673MtnTFjQan7WCrvnoG2_sL4cPUY7AR5ILVFGZsHQr7wNP f1L7_orz9jIsKdxiANRPi6DtEnEm6PouwjqXbcIgzZj6XSW3CPUlS6.gfFlA Aon4JEYqTsBKAxGo9H2HQnfX20qWlOhx_GdxMc7e59HSfpfC62i1.UnSllFe dco.LkHuvrEfL4_IialyqXO6u0NEDXKqqv_U.0A63HzZrWNNpmdWvlEcP_vQ Qs4oH.TfEdwyX.yiKZpmDazD9ulxtOo1cpP85MBd0pykaycJH318qRxu60fN pHVD5L9xIpKmCkzmLj6KYxPUZEPB7GTPrv0f4kIr3DaePEKB9E_xkOMzDjQ_ .XPIgucmQJ.VXaWSyq1ZPpOR6jXMlrvm9u9gVlc2u5NUMaYC65VCV_bSmzSc .Id1jRkL1qnq9OHCGw7AmZ_MQ0ihIQI.XZp7qONQ- Received: from [238.203.205.176] by web142802.mail.bf1.yahoo.com via HTTP; Sat, 25 Apr 2015 15:28:17 PDT X-Rocket-MIMEInfo: 002.001, CgpTZW50IGZyb20gWWFob28gTWFpbCBvbiBBbmRyb2lkCgpGcm9tOiJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPgpEYXRlOlNhdCwgQXByIDI1LCAyMDE1IGF0IDEzOjMxClN1YmplY3Q6UmU6IFtraXR0ZW5dIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWtpdHRlbi1zYXNsLW9hdXRoLTIxCgoKSSdtIHNvcnJ5IGJ1dCB3ZSBzZWVtIHRvIGJlIHRhbGtpbmcgcGFzdCBvbmUgYW5vdGhlciBmb3IgYm90aAppc3N1ZXMuIExldCBtZSB0cnkgYW5vdGhlciB0YWNrIGJ1dCBpdCBtYXkBMAEBAQE- X-Mailer: YahooMailAndroidMobile/4.8.5 YahooMailWebService/0.8.203.740 Message-ID: <1430000897.69831.YahooMailAndroidMobile@web142802.mail.bf1.yahoo.com> Date: Sat, 25 Apr 2015 15:28:17 -0700 From: Bill Mills To: Stephen Farrell , "kitten@ietf.org" In-Reply-To: <553BF9A5.7080408@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-1550685100-1430000897=:69831" Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Apr 2015 22:31:22 -0000 --1397251415-1550685100-1430000897=:69831 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A=0ASent from Yahoo Mail on Android=0A=0AFrom:"Stephen Farrell" =0ADate:Sat, Apr 25, 2015 at 13:31=0ASubject:Re: [kitten]= AD review of draft-ietf-kitten-sasl-oauth-21=0A=0A=0AI'm sorry but we seem= to be talking past one another for both=0Aissues. Let me try another tack = but it may also help if someone=0Aelse chimes in.=0A=0A=0AOn 25/04/15 19:14= , Bill Mills wrote:=0A> Inline again...=0A> =0A> =0A> On Saturday, April 25= , 2015 10:47 AM, Stephen Farrell=0A> wrote:=0A>= =0A> Hiya,=0A> =0A> On 25/04/15 18:25, Bill Mills wrote:=0A>> Responses in= line...=0A>> =0A>> =0A>> On Saturday, April 25, 2015 7:06 AM, Stephen Farre= ll=0A>> wrote:=0A>> =0A>> =0A>> Hiya,=0A>> =0A>= > Sorry for the bit of delay here but I've done my AD evaluation of=0A>> th= is. I have to questions I'd like to understand the answers for=0A>> before = starting IETF LC. I'm not sure if those will or will not=0A>> cause any rev= isions to be needed before LC. Please consider the=0A>> other nits along wi= th any IETF LC comments that turn up.=0A>> =0A>> My questions:=0A>> =0A>> (= 1) 3.1 - I'm not getting why the host and port number are needed -=0A>> won= 't the server know those anyway? (At least the port number for=0A>> sure.) = And if not, then I'm not clear what's going on, or it at=0A>> least needs m= ore explanation. Can you=0A>> =0A>> explain?=0A>> =0A>> [wmills] To allow s= upport of things like OAuth 1.0a that need the=0A>> host and port to constr= uct the signature base string.=A0 No the host=0A>> may not know what name t= he client used to connect to it given that=0A>> the same IMAP server (for e= xample) might have N different names if=0A>> it's a provider serving multip= le companies each with their own=0A>> domain name.=0A> =0A> In principle th= e client might use a hostname that the server doesn't=0A> know about, or ca= n't determine. However, were it the case that the=0A> SASL mechanism has to= tell the server, then the application protocol=0A> would not work for mult= iple server identities with other SASL=0A> mechanisms, right? In which case= the server has to know already or is=0A> broken. Or can you provide me wit= h the details of a protocol that=0A> uses SASL where this is a real issue?= =0A> =0A> [wmills]=A0 Yes the server might validate for known hostnames, as= HTTP=0A> servers can but it you specify an unknown host in the hostheader i= t=0A> falls through to default.=A0 This is specific to the case wherethe=0A= > mechanism supporting OAuth 1.0a requires hostname, so Idon't see how=0A> = this would break some other SASL mechanism?=0A=0ALet's stick with just IMAP= for a moment.=0A=0AIf an IMAP server has to support many server identities= then that=0Ahas to work for all the SASL mechanisms it supports. That mean= s=0Athat identifying the correct server name has to be done by IMAP,=0Aor, = possibly, via TLS, since most SASL mechanisms will not specify=0Awhich serv= er identity is in question, or if they do, it is too=0Alate in the overall = client-server interaction. Otherwise, something=0Ais broken already in IMAP= .=0A=0AIf IMAP is not broken in that way, then I don't see any need for=0Aa= dditional mechanism to support IMAP mutli-tenancy (or whatever=0Aone wants = to call it) that has to be provided here, as part of=0Aany of these SASL me= chanisms.=0A=0AAnd if I'm wrong and there is such a need, (quite possible, = I'm=0Aoften wrong) then that calls for discussion of the possible=0Amismatc= hes that may ensue.=0A=0AOr, if there is some reason to want some special h= andling for=0Ajust these mechanisms (e.g. if the authorization is really fo= r=0Asomething else but we want to re-use that for e.g. IMAP), then=0Athat c= learly calls for additional security considerations.=0A=0A> =0A> I also don= 't see any case where the server does not know on which=0A> port it receive= d data.=0A> =0A> [wmills] at ${previousjob} there were IMAP servers that ha= d a=0A> TLSaccellerator in front of them and the back end IMAP server lived= =0A> on the same port whether it got a direct connect or a proxied one.Not= =0A> ideal perhaps, but an example.=0A=0ANot convinced tbh. That's an issue= for the weird middlebox isn't=0Ait. Same as passing on possible client cer= t information.=0A=0A(Wmills) why is this a problem worth arguing? This was = done to allow support of Oauth 1 so that all the required info is in the me= chanism payload and both sides know exactly what was used to construct the = signature. =A0 The server certainly should be making sure that it is valid/= correct.=0A=0A> =0A> And if the client could use authorization information = for server1 at=0A> what the server thinks is server2 then that would seem t= o raise some=0A> significant vulnerabilities that are not discussed at all.= =0A> =0A> [wmills] OAuth tokens might or might not be bound ot a singledoma= in=0A> and certainly cane be used at N hostnames withing a given TLD.=0A> W= here/how tokens might be valid is outside this scope.=0A> =0A> Perhaps we'r= e trying too hard to cover the issues faced when =0A> OAuth1.0a was used ov= er http without tls? Nowadays, that is handled=0A> via SNI within TLS.=0A> = =0A> [wmills] I completely disagree given that SNI is not pervasive, less= =0A> than 70% of browsers/clients support it last I knew. =0A=0AThose are s= urprising numbers. Do you have a reference?=0A=0A(WMills) this was internal= operational data. =A0Not published anywhere.=A0=0A=0A=0A> SNI doesn't=0A> = solve for why OAuth 1.0a uses hostname either.=0A=0AMy point in any case is= that this either is not an issue or else=0Aif you do want potential duplic= ation of data sent from client to=0Aserver, then you have to account for th= e security considerations.=0A=0A>> (2) MUST TLS be provided or used? Sectio= n 4 said STARTTLS MUST be=0A>> used, in section 5 you say provided. Either = way, I think you should=0A>> include a definitive statement in section 3=0A= >> =0A>> about that. (And I'd prefer MUST use of course:-)=0A>> =0A>> [wmil= ls] The must here is because it's Bearer tokens which require=0A>>=A0 TLS.= =A0 "The Bearer Token examples assume encrypted transport; if=0A>> the unde= rlying connection is not already TLS then STARTTLS MUST be=0A>> used as TLS= is required in the Bearer Token specification."=A0 OAuth=0A>> 1.0a may be = used safely without TLS, but of course the underlying=0A>> data should prob= ably have TLS for privacy etc.=0A> =0A> All of that is fine, but does not e= xplain why section 3 doesn't =0A> clearly say when TLS must be used, nor wh= y sections 4 and 5 are not=0A> quite saying the same thing about that. So I= think my question isn't=0A> really answered yet, sorry. [wmills] Section 3= defines this per=0A> mechanism and says: "OAUTHBEARER: OAuth 2.0 bearer to= kens, as=0A> described in [RFC6750].=A0 =A0 =A0 =A0 RFC 6750 uses Transport= Layer=0A> Security (TLS) [RFC5246] to secure the protocol interaction betw= een=0A> the client and the resource server." This is derived from the=0A> e= xplicit requirements in the Bearer spec, but there was a problem=0A> there = in that there was an existing Bearer implementation (FB) that=0A> didn't us= e TLS and they didn't want to be declared out of spec so I=0A> think the la= nguage isSHOULD instead of MUST.=A0 We were aware of a=0A> possible mismatc= h and didn't want be in conflict with the language=0A> from there. Do we ne= ed something clearer than that?=A0 Do we need to=0A> add something explicit= about new mechanisms being required to define=0A> whether encryption is re= quired?=A0 [/wmills] S.=0A> =0A=0ASorry, I remain none the wiser. Yes, othe= r RFCs make statements=0Aabout support or use of TLS. My point is this draf= t makes two=0Adifferent statements on the topic, and says nothing at all in= =0Asection 3. The inconsistency is within this single draft in this=0Acase = and needs fixing I think.=0A=0A=0A(wmills) my quote above is from section 3= so I don't get why you say it's silent on this? =A0TLS is mandatory for Be= arer token. =A0Other mechanisms using this same model have to specify the T= LS requirement just like the token definition spec.=0A=0A=0AS.=0A=0A=0A=0A>= > =0A>> nitty nits:=0A>> =0A>> =0A>> - ID nits gets a few reference things = wrong, but it's ok=0A>> =0A>> [wmills] happy to fix them if needed.=A0 Will= RFC Ed. do it anyway?=0A>> =0A>> - 3.1 (and elsewhere probably) I'm assumi= ng the ABNF has been=0A>> cross-checked, is that a safe assumption?=0A>> = =0A>> =0A>> [wmills]=A0 I believe so.=A0 I'm aware of multiple interoperabl= e =0A>> implementations, Google and Outlook.com are major providers who =0A= >> have implemented. - 3.1 kvsep with a value of 0x01 - is that=0A>> common= ly used? But it might be quite common for all I know:-)=0A>> =0A>> =0A>> [w= mills] Control character separators are common in many systems. I=0A>> chos= e it because we're handling things that might otherwise be in=0A>> HTTP hea= ders and 0x01 isn't valid there so we don't have to worry=0A>> about escapi= ng.=0A>> =0A>> - 3.1, is there a real privacy benefit in omitting the authz= id=0A>> (where it works to omit that)? If not, this question is probably=0A= >> moot. But if there is, I wonder if the way you've stated the MAY=0A>> th= ere will result in people always including that if they can,=0A>> which mig= ht not be what we want. In any case, the guidance here is=0A>> a bit vague = (and maybe it has to be) so would it be possible to be =0A>> more concrete = about in/ex-clusion of authzid?=0A>> =0A>> =0A>> [wmills] In the end whethe= r authzid is required is based on server=0A>> policy.=A0 I suspect you are = right that clients will include it even=0A>> when it's not needed because s= ervers might require it and a generic=0A>> client won't know.=A0 The existi= ng implementations all have data in=0A>> the protocol (IMAP, SMTP) that mir= ror the authzid anyway.=0A>> =0A>> =0A>> - Section 4, I also assume the exa= mples have been checked.(Good set=0A>> of examples though.)=0A>> =0A>> =0A>= > [wmills] Ben did make me fix several as iteration happened so they=0A>> h= ave had at least one review..=0A>> =0A>> =0A>> Cheers, Stephen.=0A>> =0A>> = _______________________________________________ Kitten mailing=0A>> list Ki= tten@ietf.org https://www.ietf.org/mailman/listinfo/kitten=0A>> =0A>> =0A> = =0A> =0A> =0A> =0A=0A --1397251415-1550685100-1430000897=:69831 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable


Sent from Yahoo Mail on Android

From:"Stephen Fa= rrell" <stephen.farrell@cs.tcd.ie>
Date:Sat, Apr 25, 2015 a= t 13:31
Subject:Re: [kitten] AD review of draft-ietf-kitten-sasl-= oauth-21


I'm sorry but we seem to be talking past on= e another for both
issues. Let me try another tack but it= may also help if someone
else chimes in.


On 25/04/15 19:14, Bill Mills wrot= e:
> Inline again...
>
>
> On Saturday, April 25, 2015 10:47 AM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie> wrote:
>
> Hiya,
>
> On 25/04/15 18:25, Bill Mills wrote:
&g= t;> Responses inline...
>>
&g= t;>
>> On Saturday, April 25, 2015 7:06 AM, Ste= phen Farrell
>> <stephen.farrell@= cs.tcd.ie> wrote:
>>
>= >
>> Hiya,
>>
>> Sorry for the bit of delay here but I've done my AD eval= uation of
>> this. I have to questions I'd like to understand the answers for
>> before starting IETF LC. I'm not sure if those will or will not=
>> cause any revisions to be needed before LC. Ple= ase consider the
>> other nits along with any IETF = LC comments that turn up.
>>
>= ;> My questions:
>>
>> = (1) 3.1 - I'm not getting why the host and port number are needed -
>> won't the server know those anyway? (At least the port = number for
>> sure.) And if not, then I'm not clear= what's going on, or it at
>> least needs more expl= anation. Can you
>>
>> exp= lain?
>>
>> [wmills] To al= low support of things like OAuth 1.0a that need the
>&= gt; host and port to construct the signature base string.  No the host
&= gt;> may not know what name the client used to connect to it given that<= br clear=3D"none">>> the same IMAP server (for example) might have N = different names if
>> it's a provider serving multi= ple companies each with their own
>> domain name.>
> In principle the client might= use a hostname that the server doesn't
> know about, = or can't determine. However, were it the case that the
&g= t; SASL mechanism has to tell the server, then the application protocol
> would not work for multiple server identities with othe= r SASL
> mechanisms, right? In which case the server h= as to know already or is
> broken. Or can you provide = me with the details of a protocol that
> uses SASL whe= re this is a real issue?
>
> [wmills]  Yes t= he server might validate for known hostnames, asHTTP
>= servers can but it you specify an unknown host in the hostheader it
> falls through to default.  This is specific to the c= ase wherethe
> mechanism supporting OAuth 1.0a require= s hostname, so Idon't see how
> this would break some = other SASL mechanism?

Let's stick with= just IMAP for a moment.

If an IMAP se= rver has to support many server identities then that
has = to work for all the SASL mechanisms it supports. That means
that identifying the correct server name has to be done by IMAP,
or, possibly, via TLS, since most SASL mechanisms will not speci= fy
which server identity is in question, or if they do, i= t is too
late in the overall client-server interaction. Otherwise, s= omething
is broken already in IMAP.
If IMAP is not broken in that way, then I don't see any nee= d for
additional mechanism to support IMAP mutli-tenancy = (or whatever
one wants to call it) that has to be provide= d here, as part of
any of these SASL mechanisms.

And if I'm wrong and there is such a need, (qu= ite possible, I'm
often wrong) then that calls for discus= sion of the possible
mismatches that may ensue.

Or, if there is some reason to want some speci= al handling for
just these mechanisms (e.g. if the author= ization is really for
something else but we want to re-us= e that for e.g. IMAP), then
that clearly calls for additi= onal security considerations.

>
> I also don't see any case where the server does not know on which> port it received data.
>
> [wmills] at ${previousjob} there were IMAP servers that ha= d a
> TLSaccellerator in front of them and the back en= d IMAP server lived
> on the same port whether it got = a direct connect or a proxied one.Not
> ideal perhaps,= but an example.

Not convinced tbh. Th= at's an issue for the weird middlebox isn't
it. Same as p= assing on possible client cert information.
(Wmills) why is this a problem worth= arguing? This was done to allow support of Oauth 1 so that all the require= d info is in the mechanism payload and both sides know exactly what was used to construct t= he signature.   The server certainly should be making sure that it is = valid/correct.

>
> And if the client could use authorization information for server1 at<= br clear=3D"none">> what the server thinks is server2 then that would se= em to raise some
> significant vulnerabilities that ar= e not discussed at all.
>
> [wmi= lls] OAuth tokens might or might not be bound ot a singledomain
> and certainly cane be used at N hostnames withing a given TLD.<= br clear=3D"none">> Where/how tokens might be valid is outside this scop= e.
>
> Perhaps we're trying too = hard to cover the issues faced when
> OAuth1.0a was u= sed over http without tls? Nowadays, that is handled
>= via SNI within TLS.
>
> [wmills] I completely = disagree given that SNI is not pervasive, less
> than = 70% of browsers/clients support it last I knew.

Those are surprising numbers. Do you have a reference?
(WMills) this= was internal operational data.  Not published anywhere. 
> SNI doe= sn't
> solve for why OAuth 1.0a uses hostname either.<= br clear=3D"none">
My point in any case is that this eith= er is not an issue or else
if you do want potential duplication of data sent f= rom client to
server, then you have to account for the se= curity considerations.

>> (2) MU= ST TLS be provided or used? Section 4 said STARTTLS MUST be
>> used, in section 5 you say provided. Either way, I think you sh= ould
>> include a definitive statement in section 3=
>>
>> about that. (And I'= d prefer MUST use of course:-)
>>
>> [wmills] The must here is because it's Bearer tokens which requi= re
>>  TLS.  "The Bearer Token examples a= ssume encrypted transport; if
>> the underlying con= nection is not already TLS then STARTTLS MUST be
>>= used as TLS is required in the Bearer Token specification."  OAuth
>> 1.0a may be used safely without TLS, but of course= the underlying
>> data should probably have TLS fo= r privacy etc.
>
> All of that i= s fine, but does not explain why section 3 doesn't
> = clearly say when TLS must be used, nor why sections 4 and 5 are not
> quite saying the same thing about that. So I think my quest= ion isn't
> really answered yet, sorry. [wmills] Secti= on 3 defines this per
> mechanism and says: "OAUTHBEAR= ER: OAuth 2.0 bearer tokens, as
> described in [RFC675= 0].        RFC 6750 uses Transport Layer
> Security (TLS) [RFC5246] to secure the protocol interaction betwe= en
> the client and the resource server." This is deri= ved from the
> explicit requirements in the Bearer spe= c, but there was a problem
> there in that there was an existing Beare= r implementation (FB) that
> didn't use TLS and they d= idn't want to be declared out of spec so I
> think the= language isSHOULD instead of MUST.  We were aware of a
> possible mismatch and didn't want be in conflict with the language=
> from there. Do we need something clearer than that?=   Do we need to
> add something explicit about ne= w mechanisms being required to define
> whether encryp= tion is required?  [/wmills] S.
>

Sorry, I remain none the wiser. Yes, other RFCs mak= e statements
about support or use of TLS. My point is thi= s draft makes two
different statements on the topic, and = says nothing at all in
section 3. The inconsistency is wi= thin this single draft in this
case and needs fixing I think.

(wmills) my quote above is from sectio= n 3 so I don't get why you say it's silent on this?  TLS is mandatory = for Bearer token.  Other mechanisms using this same model have to spec= ify the TLS requirement just like the token definition spec.

S.



>&g= t;
>> nitty nits:
>>
>>
>> - ID nits gets a few ref= erence things wrong, but it's ok
>>
>> [wmills] happy to fix them if needed.  Will RFC Ed. do it= anyway?
>>
>> - 3.1 (and = elsewhere probably) I'm assuming the ABNF has been
>> cross-checked, is that a safe= assumption?
>>
>>
>> [wmills]  I believe so.  I'm aware of multip= le interoperable
>> implementations, Google and Ou= tlook.com are major providers who
>> have implemen= ted. - 3.1 kvsep with a value of 0x01 - is that
>> = commonly used? But it might be quite common for all I know:-)
>>
>>
>> [wmil= ls] Control character separators are common in many systems. I
>> chose it because we're handling things that might otherwise = be in
>> HTTP headers and 0x01 isn't valid there so= we don't have to worry
>> about escaping.
>>
>> - 3.1, is there a real priva= cy benefit in omitting the authzid
>> (where it works to omit that)? If n= ot, this question is probably
>> moot. But if there= is, I wonder if the way you've stated the MAY
>> t= here will result in people always including that if they can,
>> which might not be what we want. In any case, the guidance he= re is
>> a bit vague (and maybe it has to be) so wo= uld it be possible to be
>> more concrete about in= /ex-clusion of authzid?
>>
>&= gt;
>> [wmills] In the end whether authzid is requ= ired is based on server
>> policy.  I suspect = you are right that clients will include it even
>> = when it's not needed because servers might require it and a generic
>> client won't know.  The existing implementations a= ll have data in
>> the protocol (IMAP, SMTP) that mirror the au= thzid anyway.
>>
>>
>> - Section 4, I also assume the examples have been che= cked.(Good set
>> of examples though.)
>>
>>
>> [wmi= lls] Ben did make me fix several as iteration happened so they
>> have had at least one review..
>> >>
>> Cheers, Stephen.
>>
>> ________________________= _______________________ Kitten mailing
>> list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/k= itten
>>
>>
>
>= ;
>
>
=
--1397251415-1550685100-1430000897=:69831-- From nobody Sun Apr 26 20:37:40 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363231B29AE for ; Sun, 26 Apr 2015 20:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.191 X-Spam-Level: * X-Spam-Status: No, score=1.191 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP9-_6UkR6-I for ; Sun, 26 Apr 2015 20:37:35 -0700 (PDT) Received: from nm4.bullet.mail.bf1.yahoo.com (nm4.bullet.mail.bf1.yahoo.com [98.139.212.163]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD63B1AD35F for ; Sun, 26 Apr 2015 20:37:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430105854; bh=e4z0DkyhFg2pcyeI508jY4qKYjGVrGWSSEs3Oww8BMs=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=GFAzmxQSXL8CeyMNXGetaFFIuI9RLY/JtqBN/LzE/WEq69jZ9YLkoHKPHoFdB3GOEpWzNGjq7KpCsH42zK3NayscKpiwuW6IMWu1BTfDPMVu6RvgQ3mh1pUmFquoKmwZ3GaAFT1mztJovPHYQpYFgLS1fN7hsWaeMVsSoTuzoSiYvUGsHkiiJdLR37yGusSxp2Tn9FEY85gXImbJy2ydI30zalyZLJh8JEpoUNLCsDO3yYtP5ec/EG3Of8z49WUf1HjlQwlgaSnXsgnG5pcoIjYdJE112ay3oteVHhZ6964E7bPr9dKpOXZrQjKXKknpzt/iaCOwSmDyMwve4KLmBw== Received: from [98.139.215.140] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 27 Apr 2015 03:37:34 -0000 Received: from [98.139.215.230] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 27 Apr 2015 03:37:33 -0000 Received: from [127.0.0.1] by omp1070.mail.bf1.yahoo.com with NNFMP; 27 Apr 2015 03:37:33 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 905288.36287.bm@omp1070.mail.bf1.yahoo.com X-YMail-OSG: 3sbNWGEVM1lnQjNVTq4kkrUp1dwkwHl.f399UVSD6.AQJUBpUsYQYa5Aq9Bocu6 S1WTmgYTvWLS8FobxT.0A8BNqazFHZqpgxpJQISH_bUqY4C2KGdpIJ9DuyC2V48n3XJ.x9iBszMy Mxe997aonXQ7LNAGvS4ag0bkKYCa7mIvdVBUlUDsZ3g4xNA0Aw2iIO2Ik97JtUtKPfpd9HxEOcN0 gQXX0Eh79OZbNfrhCW3UhWVKGBXGvre5upxFPYBd1OWYFM24vF6Qryn_Je5XQBLD3ayDTX.MvUNC Z7EDdyfXgzUNSaufTr1Jx1Q8TskGIYdieDt0.WwqoQrfeH4G3OBZVxoslRh0aB_J2RqP2QkmQiA1 4UxM_n9TCn.5JNP3Bn9rZ7eQh0NJzPx59kv29ZBpymqCjPXKvhkS9q_EPbra3uC4B2iPQZvi5gpO 5XJz4cl8leBHaIDWnv0MMKTunLxTQ9BkRCKJfu.GqDnzOZoY7l5ISNfviLMrL02OpyfCI75zRU5q 2FvO8MgoA0mud51LXXUCNUAqNND2XKssZDTl8K_MyXu_8qC9ZvvxB5Q-- Received: by 66.196.80.123; Mon, 27 Apr 2015 03:37:33 +0000 Date: Mon, 27 Apr 2015 03:37:32 +0000 (UTC) From: Bill Mills To: Bill Mills , Stephen Farrell , "kitten@ietf.org" Message-ID: <822739189.5849217.1430105853002.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <1430000897.69831.YahooMailAndroidMobile@web142802.mail.bf1.yahoo.com> References: <1430000897.69831.YahooMailAndroidMobile@web142802.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5849216_1689255520.1430105852992" Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 03:37:39 -0000 ------=_Part_5849216_1689255520.1430105852992 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry, that was from my phone and it's impossible to read. The port and hostname a there in the mechanism primarily to make sure that = the client and server can both easily agree on what data was used in the si= gnature. =C2=A0If we need more language there to specify that the server sh= ould validate these things then that can happen but I'd really rather not t= ake it out because it will mean writing code to get that passed through the= stack by the server app. =C2=A0Trying to get that info into the mechanism = so that can be used by the server is custom code you have to stuff into the= SASL stack.=20 Section 3 explicitly requires TLS on one mechanism as I quoted, so I don't = see why you're saying it's silent on TLS. =C2=A0This matches the reuirement= s for the token specs themselves. =C2=A0Bearer speakes to TLS and OAuth 1.0= has no requirement for TLS. =C2=A0The mechanisms need to match the require= ments for the token specs for this to make sense, and this is what the open= ing paragraph of Security Considerations is intended to address. If you still think changes are needed perhaps proposed language would help = us get on common ground? Regards, -bill On Saturday, April 25, 2015 3:31 PM, Bill Mills wrote: =20 =20 |=20 Sent from Yahoo Mail on Android=20 | From:"Stephen Farrell" Date:Sat, Apr 25, 2015 at 13:31 Subject:Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 =20 I'm sorry but we seem to be talking past one another for both issues. Let me try another tack but it may also help if someone else chimes in. On 25/04/15 19:14, Bill Mills wrote: > Inline again... >=20 >=20 > On Saturday, April 25, 2015 10:47 AM, Stephen Farrell > wrote: >=20 > Hiya, >=20 > On 25/04/15 18:25, Bill Mills wrote: >> Responses inline... >>=20 >>=20 >> On Saturday, April 25, 2015 7:06 AM, Stephen Farrell >> wrote: >>=20 >>=20 >> Hiya, >>=20 >> Sorry for the bit of delay here but I've done my AD evaluation of >> this. I have to questions I'd like to understand the answers for >> before starting IETF LC. I'm not sure if those will or will not >> cause any revisions to be needed before LC. Please consider the >> other nits along with any IETF LC comments that turn up. >>=20 >> My questions: >>=20 >> (1) 3.1 - I'm not getting why the host and port number are needed - >> won't the server know those anyway? (At least the port number for >> sure.) And if not, then I'm not clear what's going on, or it at >> least needs more explanation. Can you >>=20 >> explain? >>=20 >> [wmills] To allow support of things like OAuth 1.0a that need the >> host and port to construct the signature base string.=C2=A0 No the host >> may not know what name the client used to connect to it given that >> the same IMAP server (for example) might have N different names if >> it's a provider serving multiple companies each with their own >> domain name. >=20 > In principle the client might use a hostname that the server doesn't > know about, or can't determine. However, were it the case that the > SASL mechanism has to tell the server, then the application protocol > would not work for multiple server identities with other SASL > mechanisms, right? In which case the server has to know already or is > broken. Or can you provide me with the details of a protocol that > uses SASL where this is a real issue? >=20 > [wmills]=C2=A0 Yes the server might validate for known hostnames, asHTTP > servers can but it you specify an unknown host in the hostheader it > falls through to default.=C2=A0 This is specific to the case wherethe > mechanism supporting OAuth 1.0a requires hostname, so Idon't see how > this would break some other SASL mechanism? Let's stick with just IMAP for a moment. If an IMAP server has to support many server identities then that has to work for all the SASL mechanisms it supports. That means that identifying the correct server name has to be done by IMAP, or, possibly, via TLS, since most SASL mechanisms will not specify which server identity is in question, or if they do, it is too late in the overall client-server interaction. Otherwise, something is broken already in IMAP. If IMAP is not broken in that way, then I don't see any need for additional mechanism to support IMAP mutli-tenancy (or whatever one wants to call it) that has to be provided here, as part of any of these SASL mechanisms. And if I'm wrong and there is such a need, (quite possible, I'm often wrong) then that calls for discussion of the possible mismatches that may ensue. Or, if there is some reason to want some special handling for just these mechanisms (e.g. if the authorization is really for something else but we want to re-use that for e.g. IMAP), then that clearly calls for additional security considerations. >=20 > I also don't see any case where the server does not know on which > port it received data. >=20 > [wmills] at ${previousjob} there were IMAP servers that had a > TLSaccellerator in front of them and the back end IMAP server lived > on the same port whether it got a direct connect or a proxied one.Not > ideal perhaps, but an example. Not convinced tbh. That's an issue for the weird middlebox isn't it. Same as passing on possible client cert information.(Wmills) why is thi= s a problem worth arguing? This was done to allow support of Oauth 1 so tha= t all the required info is in the mechanism payload and both sides know exa= ctly what was used to construct the signature. =C2=A0 The server certainly = should be making sure that it is valid/correct. >=20 > And if the client could use authorization information for server1 at > what the server thinks is server2 then that would seem to raise some > significant vulnerabilities that are not discussed at all. >=20 > [wmills] OAuth tokens might or might not be bound ot a singledomain > and certainly cane be used at N hostnames withing a given TLD. > Where/how tokens might be valid is outside this scope. >=20 > Perhaps we're trying too hard to cover the issues faced when=20 > OAuth1.0a was used over http without tls? Nowadays, that is handled > via SNI within TLS. >=20 > [wmills] I completely disagree given that SNI is not pervasive, less > than 70% of browsers/clients support it last I knew.=20 Those are surprising numbers. Do you have a reference?(WMills) this was int= ernal operational data. =C2=A0Not published anywhere.=C2=A0 > SNI doesn't > solve for why OAuth 1.0a uses hostname either. My point in any case is that this either is not an issue or else if you do want potential duplication of data sent from client to server, then you have to account for the security considerations. >> (2) MUST TLS be provided or used? Section 4 said STARTTLS MUST be >> used, in section 5 you say provided. Either way, I think you should >> include a definitive statement in section 3 >>=20 >> about that. (And I'd prefer MUST use of course:-) >>=20 >> [wmills] The must here is because it's Bearer tokens which require >>=C2=A0 TLS.=C2=A0 "The Bearer Token examples assume encrypted transport; = if >> the underlying connection is not already TLS then STARTTLS MUST be >> used as TLS is required in the Bearer Token specification."=C2=A0 OAuth >> 1.0a may be used safely without TLS, but of course the underlying >> data should probably have TLS for privacy etc. >=20 > All of that is fine, but does not explain why section 3 doesn't=20 > clearly say when TLS must be used, nor why sections 4 and 5 are not > quite saying the same thing about that. So I think my question isn't > really answered yet, sorry. [wmills] Section 3 defines this per > mechanism and says: "OAUTHBEARER: OAuth 2.0 bearer tokens, as > described in [RFC6750].=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC 6750 uses Transpor= t Layer > Security (TLS) [RFC5246] to secure the protocol interaction between > the client and the resource server." This is derived from the > explicit requirements in the Bearer spec, but there was a problem > there in that there was an existing Bearer implementation (FB) that > didn't use TLS and they didn't want to be declared out of spec so I > think the language isSHOULD instead of MUST.=C2=A0 We were aware of a > possible mismatch and didn't want be in conflict with the language > from there. Do we need something clearer than that?=C2=A0 Do we need to > add something explicit about new mechanisms being required to define > whether encryption is required?=C2=A0 [/wmills] S. >=20 Sorry, I remain none the wiser. Yes, other RFCs make statements about support or use of TLS. My point is this draft makes two different statements on the topic, and says nothing at all in section 3. The inconsistency is within this single draft in this case and needs fixing I think. (wmills) my quote above is from section 3 so I don't get why you say it's s= ilent on this? =C2=A0TLS is mandatory for Bearer token. =C2=A0Other mechani= sms using this same model have to specify the TLS requirement just like the= token definition spec. S. >>=20 >> nitty nits: >>=20 >>=20 >> - ID nits gets a few reference things wrong, but it's ok >>=20 >> [wmills] happy to fix them if needed.=C2=A0 Will RFC Ed. do it anyway? >>=20 >> - 3.1 (and elsewhere probably) I'm assuming the ABNF has been >> cross-checked, is that a safe assumption? >>=20 >>=20 >> [wmills]=C2=A0 I believe so.=C2=A0 I'm aware of multiple interoperable= =20 >> implementations, Google and Outlook.com are major providers who=20 >> have implemented. - 3.1 kvsep with a value of 0x01 - is that >> commonly used? But it might be quite common for all I know:-) >>=20 >>=20 >> [wmills] Control character separators are common in many systems. I >> chose it because we're handling things that might otherwise be in >> HTTP headers and 0x01 isn't valid there so we don't have to worry >> about escaping. >>=20 >> - 3.1, is there a real privacy benefit in omitting the authzid >> (where it works to omit that)? If not, this question is probably >> moot. But if there is, I wonder if the way you've stated the MAY >> there will result in people always including that if they can, >> which might not be what we want. In any case, the guidance here is >> a bit vague (and maybe it has to be) so would it be possible to be=20 >> more concrete about in/ex-clusion of authzid? >>=20 >>=20 >> [wmills] In the end whether authzid is required is based on server >> policy.=C2=A0 I suspect you are right that clients will include it even >> when it's not needed because servers might require it and a generic >> client won't know.=C2=A0 The existing implementations all have data in >> the protocol (IMAP, SMTP) that mirror the authzid anyway. >>=20 >>=20 >> - Section 4, I also assume the examples have been checked.(Good set >> of examples though.) >>=20 >>=20 >> [wmills] Ben did make me fix several as iteration happened so they >> have had at least one review.. >>=20 >>=20 >> Cheers, Stephen. >>=20 >> _______________________________________________ Kitten mailing >> list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten >>=20 >>=20 >=20 >=20 >=20 >=20 | | _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_5849216_1689255520.1430105852992 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, that was from my phone a= nd it's impossible to read.

The port and hostname a there in the mechanism primarily to make sure that= the client and server can both easily agree on what data was used in the s= ignature.  If we need more language there to specify that the server s= hould validate these things then that can happen but I'd really rather not = take it out because it will mean writing code to get that passed through th= e stack by the server app.  Trying to get that info into the mechanism= so that can be used by the server is custom code you have to stuff into th= e SASL stack.
<= br>
Section = 3 explicitly requires TLS on one mechanism as I quoted, so I don't see why = you're saying it's silent on TLS.  This matches the reuirements for th= e token specs themselves.  Bearer speakes to TLS and OAuth 1.0 has no = requirement for TLS.  The mechanisms need to match the requirements fo= r the token specs for this to make sense, and this is what the opening para= graph of Security Considerations is intended to address.

If you still think changes are neede= d perhaps proposed language would help us get on common ground?

Regards,

-bill


=
On Saturday, April 25, 2015 3:31 PM, Bill Mills <wmills_92105@yahoo.c= om> wrote:


From:"Stephen Farrell" &l= t;stephen.farrell@cs.tcd.ie>
Date:Sat, Apr 25, = 2015 at 13:31
Subject:Re: [kitten] AD review of dr= aft-ietf-kitten-sasl-oauth-21

<= div class=3D"yiv8588530992msgSandbox" id=3D"yiv8588530992msgSandbox_AGpL2kI= AAI2FFVTv5sgB9AGjXXd4" style=3D"padding:1.5em 0.5em 0.5em 1.2em;word-wrap:b= reak-word;">
I'm sorry but we seem to be talking past one= another for both
issues. Let me try another tack but it = may also help if someone
else chimes in.


On 25/04/15 19:14, Bill Mills wrote= :
> Inline again...
>
>
> On Saturday, April 25, 2015 10:47 AM, Stephen Farrell
> <stephen.farrell@cs= .tcd.ie> wrote:
>
> Hiya,=
>
> On 25/04/15 18:25, Bill Mil= ls wrote:
>> Responses inline...
= >>
>>
>> On Saturda= y, April 25, 2015 7:06 AM, Stephen Farrell
>> <<= a rel=3D"nofollow" shape=3D"rect" href=3D"">stephen.farrell@cs.tcd.ie&g= t; wrote:
>>
>>
>> Hiya,
>>
>= > Sorry for the bit of delay here but I've done my AD evaluation of
>> this. I have to questions I'd like to understand the answers for
>> before starting IETF LC. I'm not sure if those will or will not=
>> cause any revisions to be needed before LC. Ple= ase consider the
>> other nits along with any IETF = LC comments that turn up.
>>
>= ;> My questions:
>>
>> = (1) 3.1 - I'm not getting why the host and port number are needed -
>> won't the server know those anyway? (At least the port = number for
>> sure.) And if not, then I'm not clear= what's going on, or it at
>> least needs more expl= anation. Can you
>>
>> exp= lain?
>>
>> [wmills] To al= low support of things like OAuth 1.0a that need the
>&= gt; host and port to construct the signature base string.  No the host
&= gt;> may not know what name the client used to connect to it given that<= br clear=3D"none">>> the same IMAP server (for example) might have N = different names if
>> it's a provider serving multi= ple companies each with their own
>> domain name.>
> In principle the client might= use a hostname that the server doesn't
> know about, = or can't determine. However, were it the case that the
&g= t; SASL mechanism has to tell the server, then the application protocol
> would not work for multiple server identities with othe= r SASL
> mechanisms, right? In which case the server h= as to know already or is
> broken. Or can you provide = me with the details of a protocol that
> uses SASL whe= re this is a real issue?
>
> [wmills]  Yes t= he server might validate for known hostnames, asHTTP
>= servers can but it you specify an unknown host in the hostheader it
> falls through to default.  This is specific to the c= ase wherethe
> mechanism supporting OAuth 1.0a require= s hostname, so Idon't see how
> this would break some = other SASL mechanism?

Let's stick with= just IMAP for a moment.

If an IMAP se= rver has to support many server identities then that
has = to work for all the SASL mechanisms it supports. That means
that identifying the correct server name has to be done by IMAP,
or, possibly, via TLS, since most SASL mechanisms will not speci= fy
which server identity is in question, or if they do, i= t is too
late in the overall client-server interaction. O= therwise, something
is broken already in IMAP.

If IMAP is not broken in that way, then I don'= t see any need for
additional mechanism to support IMAP m= utli-tenancy (or whatever
one wants to call it) that has = to be provided here, as part of
any of these SASL mechani= sms.

And if I'm wrong and there is suc= h a need, (quite possible, I'm
often wrong) then that cal= ls for discussion of the possible
mismatches that may ens= ue.

Or, if there is some reason to wan= t some special handling for
just these mechanisms (e.g. i= f the authorization is really for
something else but we w= ant to re-use that for e.g. IMAP), then
that clearly call= s for additional security considerations.

>
> I also don't see any case where the server does not know on which> port it received data.
>
> [wmills] at ${previousjob} there were IMAP servers that ha= d a
> TLSaccellerator in front of them and the back en= d IMAP server lived
> on the same port whether it got = a direct connect or a proxied one.Not
> ideal perhaps,= but an example.

Not convinced tbh. Th= at's an issue for the weird middlebox isn't
it. Same as p= assing on possible client cert information.
(Wmills) why = is this a problem worth arguing? This was done to allow support of Oauth 1 = so that all the required info is in the mechanism payload and both sides know exactly what was used to construct t= he signature.   The server certainly should be making sure that it is = valid/correct.

>
> And if the client could use authorization information for server1 at<= br clear=3D"none">> what the server thinks is server2 then that would se= em to raise some
> significant vulnerabilities that ar= e not discussed at all.
>
> [wmi= lls] OAuth tokens might or might not be bound ot a singledomain
> and certainly cane be used at N hostnames withing a given TLD.<= br clear=3D"none">> Where/how tokens might be valid is outside this scop= e.
>
> Perhaps we're trying too = hard to cover the issues faced when
> OAuth1.0a was u= sed over http without tls? Nowadays, that is handled
>= via SNI within TLS.
>
> [wmills] I completely = disagree given that SNI is not pervasive, less
> than = 70% of browsers/clients support it last I knew.

Those are surprising numbers. Do you have a reference?
(WMills) this was internal operational data.  Not published a= nywhere. 

>= SNI doesn't
> solve for why OAuth 1.0a uses hostname = either.

My point in any case is that t= his either is not an issue or else
if you do want potential duplication of data sent f= rom client to
server, then you have to account for the se= curity considerations.

>> (2) MU= ST TLS be provided or used? Section 4 said STARTTLS MUST be
>> used, in section 5 you say provided. Either way, I think you sh= ould
>> include a definitive statement in section 3=
>>
>> about that. (And I'= d prefer MUST use of course:-)
>>
>> [wmills] The must here is because it's Bearer tokens which requi= re
>>  TLS.  "The Bearer Token examples a= ssume encrypted transport; if
>> the underlying con= nection is not already TLS then STARTTLS MUST be
>>= used as TLS is required in the Bearer Token specification."  OAuth>> 1.0a may be used safely without TLS, but of course= the underlying
>> data should probably have TLS fo= r privacy etc.
>
> All of that i= s fine, but does not explain why section 3 doesn't
> = clearly say when TLS must be used, nor why sections 4 and 5 are not
> quite saying the same thing about that. So I think my quest= ion isn't
> really answered yet, sorry. [wmills] Secti= on 3 defines this per
> mechanism and says: "OAUTHBEAR= ER: OAuth 2.0 bearer tokens, as
> described in [RFC675= 0].        RFC 6750 uses Transport Layer
> Security (TLS) [RFC5246] to secure the protocol interaction betwe= en
> the client and the resource server." This is deri= ved from the
> explicit requirements in the Bearer spe= c, but there was a problem
> there in that there was an existing Beare= r implementation (FB) that
> didn't use TLS and they d= idn't want to be declared out of spec so I
> think the= language isSHOULD instead of MUST.  We were aware of a
> possible mismatch and didn't want be in conflict with the language=
> from there. Do we need something clearer than that?=   Do we need to
> add something explicit about ne= w mechanisms being required to define
> whether encryp= tion is required?  [/wmills] S.
>

Sorry, I remain none the wiser. Yes, other RFCs mak= e statements
about support or use of TLS. My point is thi= s draft makes two
different statements on the topic, and = says nothing at all in
section 3. The inconsistency is wi= thin this single draft in this
case and needs fixing I think.

(wmills) my quote ab= ove is from section 3 so I don't get why you say it's silent on this?  = ;TLS is mandatory for Bearer token.  Other mechanisms using this same = model have to specify the TLS requirement just like the token definition sp= ec.

S.



>>
>> nitty nits:
>>
>= >
>> - ID nits gets a few reference things wron= g, but it's ok
>>
>> [wmil= ls] happy to fix them if needed.  Will RFC Ed. do it anyway?
>>
>> - 3.1 (and elsewhere probabl= y) I'm assuming the ABNF has been
>> cross-checked, is that a safe= assumption?
>>
>>
>> [wmills]  I believe so.  I'm aware of multip= le interoperable
>> implementations, Google and Ou= tlook.com are major providers who
>> have implemen= ted. - 3.1 kvsep with a value of 0x01 - is that
>> = commonly used? But it might be quite common for all I know:-)
>>
>>
>> [wmil= ls] Control character separators are common in many systems. I
>> chose it because we're handling things that might otherwise = be in
>> HTTP headers and 0x01 isn't valid there so= we don't have to worry
>> about escaping.
>>
>> - 3.1, is there a real priva= cy benefit in omitting the authzid
>> (where it works to omit that)? If n= ot, this question is probably
>> moot. But if there= is, I wonder if the way you've stated the MAY
>> t= here will result in people always including that if they can,
>> which might not be what we want. In any case, the guidance he= re is
>> a bit vague (and maybe it has to be) so wo= uld it be possible to be
>> more concrete about in= /ex-clusion of authzid?
>>
>&= gt;
>> [wmills] In the end whether authzid is requ= ired is based on server
>> policy.  I suspect = you are right that clients will include it even
>> = when it's not needed because servers might require it and a generic
>> client won't know.  The existing implementations a= ll have data in
>> the protocol (IMAP, SMTP) that mirror the au= thzid anyway.
>>
>>
>> - Section 4, I also assume the examples have been che= cked.(Good set
>> of examples though.)
>>
>>
>> [wmi= lls] Ben did make me fix several as iteration happened so they
>> have had at least one review..
>> >>
>> Cheers, Stephen.
>>
>> ________________________= _______________________ 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


=
------=_Part_5849216_1689255520.1430105852992-- From nobody Mon Apr 27 05:45:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F5C1ACF5E for ; Mon, 27 Apr 2015 05:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa_-oK3hRF9F for ; Mon, 27 Apr 2015 05:45:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AA6C1ACF57 for ; Mon, 27 Apr 2015 05:45:56 -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 (Postfix) with ESMTPS id E95768E780 for ; Mon, 27 Apr 2015 12:45:55 +0000 (UTC) Received: from vpn-55-128.rdu2.redhat.com (vpn-55-128.rdu2.redhat.com [10.10.55.128]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3RCjskC013704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 27 Apr 2015 08:45:55 -0400 Message-ID: <1430138754.2682.10.camel@redhat.com> From: Nathaniel McCallum To: "kitten@ietf.org" Date: Mon, 27 Apr 2015 08:45:54 -0400 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Subject: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 12:45:57 -0000 I have finally finished the first edition of SPAKE Preauth. You can read it at this link: http://www.ietf.org/id/draft-mccallum-kitten-krb-spake-preauth-00.txt Comments welcome! Nathaniel From nobody Mon Apr 27 15:23:15 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6745F1A9136 for ; Mon, 27 Apr 2015 15:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6iwiPxO6Zh1 for ; Mon, 27 Apr 2015 15:23:12 -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 D2A411A8F50 for ; Mon, 27 Apr 2015 15:23:10 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-1f-553eb6ce3e5b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id B5.9C.03451.EC6BE355; Mon, 27 Apr 2015 18:23:10 -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 t3RMN9SW011109; Mon, 27 Apr 2015 18:23:09 -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 t3RMN6U3019566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Apr 2015 18:23:08 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3RMN6sL010021; Mon, 27 Apr 2015 18:23:06 -0400 (EDT) Date: Mon, 27 Apr 2015 18:23:06 -0400 (EDT) From: Benjamin Kaduk To: Stephen Farrell In-Reply-To: <553BF9A5.7080408@cs.tcd.ie> Message-ID: References: <553BD31B.303@cs.tcd.ie> <575127954.5175870.1429985689398.JavaMail.yahoo@mail.yahoo.com> <553BF9A5.7080408@cs.tcd.ie> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrHtum12oQesTToujm1exWEzfe43d 4lvXdWYHZo+13VfZPJYs+cnkMWvWYaYA5igum5TUnMyy1CJ9uwSujLanDawFG3Urrq1+x9zA eFOli5GTQ0LAROLBpKNMELaYxIV769m6GLk4hAQWM0lsbexghHA2Mkpcu/CVFcI5xCRx7/tZ qEwDo8TqBXMZQfpZBLQl/v88zg5iswmoSMx8s5ENxBYR0JfYu/kcWJxZwEfi2cWXLCC2sICT xPU518B2cwpoSjy/dg7M5hVwlPh27DwzxIJGRomnp56BLRAV0JFYvX8KC0SRoMTJmU9YIIZq SSyfvo1lAqPgLCSpWUhSCxiZVjHKpuRW6eYmZuYUpybrFicn5uWlFuma6uVmluilppRuYgSF MLuL0g7GnweVDjEKcDAq8fAWTLYNFWJNLCuuzD3EKMnBpCTK29ZjFyrEl5SfUpmRWJwRX1Sa k1p8iFGCg1lJhPfUFqAcb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IE b8RWoEbBotT01Iq0zJwShDQTByfIcB6g4fEgNbzFBYm5xZnpEPlTjIpS4ry8IAkBkERGaR5c LyzFvGIUB3pFmHc7SBUPMD3Bdb8CGswENLhypg3I4JJEhJRUA6PzNZ4HeaVX/0uzu1k/y0z/ MoXheXjVxZCSbpaXL4X4Jff9t2OKv7reclsd7yGrvTcy14okuammq/4/Z9nFpyP7Kctgi9Tm Qh17J7m3U9r0L7/VPjk568v+lQ4fajL/zTywoMra63TL4s0nw348nPqmwN//8Z+Axt+mH1yf zt2d4fUz+KizXaoSS3FGoqEWc1FxIgBsn4GJDAMAAA== Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 22:23:14 -0000 On Sat, 25 Apr 2015, Stephen Farrell wrote: > > I'm sorry but we seem to be talking past one another for both > issues. Let me try another tack but it may also help if someone > else chimes in. [puts on shepherd hat] Sorry for the long silence; I was sick last week and didn't get much of anything done. Question (1) is about the host and port kvpairs of the initial client response; Stephen claims that any server software using this SASL mechanism will know what hostname and port the client is trying to access. It seems like this is in fact true, but Bill says there is no API for a SASL mechanism implementation to query this from up the stack (and would require patching the core SASL implementation, not just a mechanism implementation). The natural question to ask, then, is if other SASL mechanisms are verifying a client-supplied hostname, and if so, how. In Kerberos the desired service principal name includes a hostname, and can be determined by examining the sname field of the presented Ticket. In practice, kerberized application servers are generally configured to either use one specific service principal name, or any for which keys can be found [optionally, of the given service type]. So, the hostname used by the client can be determined just from the authentication blob, without a need to consult the SASL stack. If other mechanisms are similar to kerberos, than I guess it makes sense to explicitly include the target hostname in the initial client response, as is currently done. This seems to be the only relevant part of the discussion; I don't think that OAuth tokens valid for multiple servers are particularly interesting for answering this question. Additionally, the SASL application server certainly knows what port it is receiving traffic on. But, as Bill notes, if there is a load-balancer or TLS terminator in between, the port the server is listening on can differ from the port that the client sent to. My understanding is that it is not terribly common for authentication/authorization schemes to be port-restricted, so it is plausible that the SASL mechanisms currently in use in such scenarios do not use a port number and thus can succeed unchanged, whereas OAuth 1.0a does bind to the port number and needs an explicit hint. In both cases (hostname and port), my tentative conclusion is that no change to the draft is needed. Question (2) relates to the use of TLS. This document is in a somewhat awkward position of specifying both a specific (pair of) mechanisms and a (hopefully) general framework for converting HTTP OAuth mechanisms into SASL mechanisms. For all currently specified OAuth (2.0) mechanisms, TLS is required to protect the bearer token, but we hope that future OAuth mechanisms can be specified which do not use bearer tokens and thus have a weaker dependency on TLS. In particular, we hope that such future OAuth HTTP mechanisms can be converted to SASL mechanisms using the framework specified in this document. So, while TLS MUST be used for the concrete mechanisms this document specifies [1], there is not a very strong case to say that TLS MUST be used for all mechanisms compliant to this framework. This framework for SASL mechanisms does not provide any security layer for data security, so if confidentiality of data is required, TLS ought to be used. But I'm not sure that's even a SHOULD, let alone a MUST. I concede Stephen's point that section 3 should say *something* about TLS, and propose moving (or copying?) text from the security considerations relating to the two specific mechanisms (MUST for OAUTHBEARER; RECOMMENDED for OAUTH10A), along with some text giving guidance for future mechanisms using this framework. It's not clear to me that sections 4 and 5 are internally inconsistent, though -- unless the difference between "TLS MUST be used" and "TLS must be provided" is the concern? To suggest some concrete text, insert into section 3, after the paragraph "New extensions may be defined [...] citing this specification for the further definition.": %%%%%%%%%%%%%%%%%%%%%%%% SASL mechanisms using this document as their definition do not provide a data security layer; that is, they cannot provide integrity or confidentiality protection for application messages after the initial authentication. If such protection is needed, TLS or some similar solution should be used. Additionally, for the two mechanisms specified in this document, TLS MUST be used for OAUTHBEARER to protect the bearer token; for OAUTH10A the use of TLS is RECOMMENDED. %%%%%%%%%%%%%%%%%%%%%%%% The start of the next paragraph could probably also benefit from new transition text, such as "Mechanisms using this document as a definition are client initiated [...]". With respect to the nits: I only see one valid entry in the idnits output about the references; draft-ietf-oauth-dyn-reg has had a new version come out in the interim. It also claims that RFC 5849 (OAuth 1) is obsolete, but we do need to reference it for the OAUTH10A mechanism. (I thought I said that in the shepherd report....) Alexey looked at an old version of the ABNF and we had to make a couple tweaks, but I think it's okay, now. Bill talked about the kvsep of 0x01, so I will say no more. I think Bill also covered the privacy aspects of (not) including the authzid as well. I did some checking of the examples, but they should ideally be checked again at some point. (I will probably do it during IETF last call.) There were several points in time where the examples were internally inconsistent, so it would be good to make sure that we've stamped those out. -Ben [1] I'm ignoring OAuth 1.0a for this point. From nobody Mon Apr 27 15:34:58 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321621ABD35 for ; Mon, 27 Apr 2015 15:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtnoChm0jEEt for ; Mon, 27 Apr 2015 15:34:55 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:743]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA18A1ABD37 for ; Mon, 27 Apr 2015 15:34:54 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB210.namprd03.prod.outlook.com (10.255.230.144) with Microsoft SMTP Server (TLS) id 15.1.148.15; Mon, 27 Apr 2015 22:34:35 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.246]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.246]) with mapi id 15.01.0148.017; Mon, 27 Apr 2015 22:34:35 +0000 From: Michiko Short To: Greg Hudson , Sam Hartman Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt Thread-Index: AQHQXZiJ07vPZrskK0qMbSTckV74FZ0an2mggAAi1zCAAAm3AIAH5dPggD8GlGA= Date: Mon, 27 Apr 2015 22:34:35 +0000 Message-ID: References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> <550339DA.6000109@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ed31::4] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB210; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(479174004)(51704005)(13464003)(377454003)(24454002)(99286002)(33656002)(74316001)(106116001)(76576001)(2656002)(86612001)(76176999)(50986999)(86362001)(54356999)(5001920100001)(2900100001)(19580405001)(19580395003)(92566002)(77156002)(93886004)(62966003)(102836002)(122556002)(230783001)(40100003)(551544002)(46102003)(5001770100001)(87936001)(2171001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB210; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006)(3002001); SRVR:BL2PR03MB210; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB210; x-forefront-prvs: 0559FB9674 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2015 22:34:35.4064 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB210 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2015 22:34:57 -0000 Time for me to publish a new draft since this one is expiring.=20 We found a use case in our implementation of PKInit where the client must r= equest a freshness token or else they will get a principal not found error,= so we need to keep the client behavior. I would prefer to not make that MS= -PKCA Microsoft extension. It there any problem with keeping the client lan= guage as is? Also we would prefer to keep token generation limited to the p= ublic key case. Yes, we are hoping to expand the number of customers who us= e PKInit, but there will still be customers for a while who do not, have ol= d servers, etc. -----Original Message----- From: Michiko Short=20 Sent: Wednesday, March 18, 2015 1:07 PM To: 'Greg Hudson'; Sam Hartman Cc: Benjamin Kaduk; kitten@ietf.org Subject: RE: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt I think a KDC implementation can always choose to send a Freshness token, b= ut that should be an implementation option not a requirement. Having a KDC = only send the Freshness Token on client gives the option to limit generatin= g Freshness tokens to just PKInit clients.=20 -----Original Message----- From: Greg Hudson [mailto:ghudson@mit.edu]=20 Sent: Friday, March 13, 2015 12:26 PM To: Michiko Short; Sam Hartman Cc: Benjamin Kaduk; kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt On 03/13/2015 02:55 PM, Michiko Short wrote: > Once the tool reopens then I will submit the version without the client r= equest behavior.=20 >=20 > [Michiko Short] Creating a freshness token will be a crypto hit on the KD= C, so sending freshness tokens to clients who will never use them will nega= tively impact KDC performance with no gains. If the PKInit client does not = explicitly ask for the token, then clients using password authentication wi= ll also have freshness tokens generated and sent to them.=20 That's worth considering. Here are my thoughts: * A freshness token doesn't have to be unique to a request or client; it ju= st has to be unknown to an attacker far in advance of an AS exchange. A KDC could compute a new global freshness token every five minutes or so = (by encrypting the current time in a TGS key, for instance) and use it for = many requests. * A KDC only needs to send a freshness token if it is offering PKINIT (or a= future mechanism which also uses freshness tokens). I guess it's unusual = for that to be a per-client decision by the KDC; typically either the KDC i= s configured with PKINIT support or it isn't, and it offers PKINIT to all c= lients if it is. * Is AES encryption a significant load factor on modern KDCs? I don't have= numbers for our KDC at the moment. It probably depends a lot on whether A= ES-NI can be used. * If a client wants to save the KDC the effort of computing a freshness tok= en, it has to decide ahead of time whether it might be able to use PKINIT (= or a future mechanism which also uses freshness tokens). This is generally= possible, but maybe a bit complex. From nobody Tue Apr 28 07:49:16 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB62C1A1B03 for ; Tue, 28 Apr 2015 07:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9w6IgYhTKJw for ; Tue, 28 Apr 2015 07:49:07 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AE261A1A83 for ; Tue, 28 Apr 2015 07:49:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 38B50BE38; Tue, 28 Apr 2015 15:49:01 +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 EJetV2Xr7_8Q; Tue, 28 Apr 2015 15:48:59 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.29.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5CBFFBE35; Tue, 28 Apr 2015 15:48:59 +0100 (IST) Message-ID: <553F9DDB.4050401@cs.tcd.ie> Date: Tue, 28 Apr 2015 15:48:59 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <553BD31B.303@cs.tcd.ie> <575127954.5175870.1429985689398.JavaMail.yahoo@mail.yahoo.com> <553BF9A5.7080408@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 14:49:15 -0000 Hi Ben, Bill, (Sorry for the slow response, got distracted yesterday;-) On 27/04/15 23:23, Benjamin Kaduk wrote: > On Sat, 25 Apr 2015, Stephen Farrell wrote: > >> >> I'm sorry but we seem to be talking past one another for both >> issues. Let me try another tack but it may also help if someone >> else chimes in. > > [puts on shepherd hat] > Sorry for the long silence; I was sick last week and didn't get much > of anything done. > > Question (1) is about the host and port kvpairs of the initial client > response; Stephen claims that any server software using this SASL > mechanism will know what hostname and port the client is trying to access. > It seems like this is in fact true, Right. And that means we're duplicating that information. And such duplication, when the value are not the same, is a time-honoured way of getting around authorization systems that forget that there are two copies and who only check one. If you want to keep the duplication then I think you have to note that. > but Bill says there is no API for a > SASL mechanism implementation to query this from up the stack (and would > require patching the core SASL implementation, not just a mechanism > implementation). The natural question to ask, then, is if other SASL > mechanisms are verifying a client-supplied hostname, and if so, how. In > Kerberos the desired service principal name includes a hostname, and can > be determined by examining the sname field of the presented Ticket. In > practice, kerberized application servers are generally configured to > either use one specific service principal name, or any for which keys can > be found [optionally, of the given service type]. That could be a valid choice, but ought be clear to whoever is issuing the tickets, (or tokens here) right? > So, the hostname used > by the client can be determined just from the authentication blob, without > a need to consult the SASL stack. If other mechanisms are similar to > kerberos, than I guess it makes sense to explicitly include the target > hostname in the initial client response, as is currently done. This seems > to be the only relevant part of the discussion; I don't think that OAuth > tokens valid for multiple servers are particularly interesting for > answering this question. > > Additionally, the SASL application server certainly knows what port it is > receiving traffic on. But, as Bill notes, if there is a load-balancer or > TLS terminator in between, the port the server is listening on can differ > from the port that the client sent to. My understanding is that it is not > terribly common for authentication/authorization schemes to be > port-restricted, so it is plausible that the SASL mechanisms currently in > use in such scenarios do not use a port number and thus can succeed > unchanged, whereas OAuth 1.0a does bind to the port number and needs an > explicit hint. > > In both cases (hostname and port), my tentative conclusion is that no > change to the draft is needed. If keeping it, I think you need the warning about duplication. I'm guessing that that warning won't ever be in other RFCs, as applications presumably don't need to say which SASL mechanisms are allowed. (I wonder if this is just one example of where the first sentence of 3.2 doesn't have sufficient detail?) > > > Question (2) relates to the use of TLS. This document is in a somewhat > awkward position of specifying both a specific (pair of) mechanisms and a > (hopefully) general framework for converting HTTP OAuth mechanisms into > SASL mechanisms. For all currently specified OAuth (2.0) mechanisms, TLS > is required to protect the bearer token, but we hope that future OAuth > mechanisms can be specified which do not use bearer tokens and thus have a > weaker dependency on TLS. In particular, we hope that such future OAuth > HTTP mechanisms can be converted to SASL mechanisms using the framework > specified in this document. > > So, while TLS MUST be used for the concrete mechanisms this document > specifies [1], there is not a very strong case to say that TLS MUST be > used for all mechanisms compliant to this framework. This framework for > SASL mechanisms does not provide any security layer for data security, so > if confidentiality of data is required, TLS ought to be used. But I'm not > sure that's even a SHOULD, let alone a MUST. > > I concede Stephen's point that section 3 should say *something* about TLS, > and propose moving (or copying?) text from the security considerations > relating to the two specific mechanisms (MUST for OAUTHBEARER; RECOMMENDED > for OAUTH10A), along with some text giving guidance for future mechanisms > using this framework. It's not clear to me that sections 4 and 5 are > internally inconsistent, though -- unless the difference between "TLS MUST > be used" and "TLS must be provided" is the concern? > > To suggest some concrete text, insert into section 3, after the paragraph > "New extensions may be defined [...] citing this specification for the > further definition.": > > %%%%%%%%%%%%%%%%%%%%%%%% > > SASL mechanisms using this document as their definition do not provide > a data security layer; that is, they cannot provide integrity or > confidentiality protection for application messages after the initial > authentication. If such protection is needed, TLS or some similar > solution should be used. Additionally, for the two mechanisms specified > in this document, TLS MUST be used for OAUTHBEARER to protect the bearer > token; for OAUTH10A the use of TLS is RECOMMENDED. I'd be fine with that change. S. > > %%%%%%%%%%%%%%%%%%%%%%%% > > The start of the next paragraph could probably also benefit from new > transition text, such as "Mechanisms using this document as a definition > are client initiated [...]". > > > > With respect to the nits: > > I only see one valid entry in the idnits output about the references; > draft-ietf-oauth-dyn-reg has had a new version come out in the interim. > It also claims that RFC 5849 (OAuth 1) is obsolete, but we do need to > reference it for the OAUTH10A mechanism. (I thought I said that in the > shepherd report....) > > Alexey looked at an old version of the ABNF and we had to make a couple > tweaks, but I think it's okay, now. > > Bill talked about the kvsep of 0x01, so I will say no more. > > I think Bill also covered the privacy aspects of (not) including the > authzid as well. > > I did some checking of the examples, but they should ideally be checked > again at some point. (I will probably do it during IETF last call.) > There were several points in time where the examples were internally > inconsistent, so it would be good to make sure that we've stamped those > out. > > -Ben > > [1] I'm ignoring OAuth 1.0a for this point. > From nobody Tue Apr 28 08:09:56 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BC51A876D for ; Tue, 28 Apr 2015 08:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivpqz48igJHc for ; Tue, 28 Apr 2015 08:09:53 -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 7F31A1A878E for ; Tue, 28 Apr 2015 08:09:43 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-23-553fa2b60d65 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 4F.98.03451.6B2AF355; Tue, 28 Apr 2015 11:09:42 -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 t3SF9gPS032675; Tue, 28 Apr 2015 11:09:42 -0400 Received: from [18.101.8.246] (vpn-18-101-8-246.mit.edu [18.101.8.246]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3SF9eRE025529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2015 11:09:41 -0400 Message-ID: <553FA2B3.8030301@mit.edu> Date: Tue, 28 Apr 2015 11:09:39 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nathaniel McCallum , "kitten@ietf.org" References: <1430138754.2682.10.camel@redhat.com> In-Reply-To: <1430138754.2682.10.camel@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrLttkX2owefL1hZHN69isZj7dRar A5PHkiU/mTze77vKFsAUxWWTkpqTWZZapG+XwJXx44RiwVKRiks/fRsYDwp0MXJySAiYSEz7 cI0RwhaTuHBvPVsXIxeHkMBiJonjC8+yQDgbGSW+T5jECOEcYZJ48PgJE0gLr4CaxN97M8Ha WQRUJQ70HWYHsdkElCXW79/KAmKLCoRJTPv9nBWiXlDi5MwnYHERgRiJ28u3g8WFgerPvjoF 1iskYChxYO8SsDingJHEwgNzmEFsZgE9iR3Xf7FC2PISzVtnM09gFJiFZOwsJGWzkJQtYGRe xSibklulm5uYmVOcmqxbnJyYl5dapGuql5tZopeaUrqJERSm7C5KOxh/HlQ6xCjAwajEw2tx 0y5UiDWxrLgy9xCjJAeTkihvX699qBBfUn5KZUZicUZ8UWlOavEhRgkOZiURXqMJQDnelMTK qtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQne1wuAGgWLUtNTK9Iyc0oQ0kwc nCDDeYCG9y8EGV5ckJhbnJkOkT/FqCglzisGkhAASWSU5sH1wtLIK0ZxoFeEeR1BqniAKQiu +xXQYCagwZUzbUAGlyQipKQaGKOmLKySVHzAxzldNrBpmf63uUlCi1pkSx84PndsfFi0bP3n 4k1X4pys/5mwKiaEzeHQnXpmYUfl1kBt8wcnBBY89Tg5w2ix47N+t2NrlILe3Nz6+PPPj/bz P5YarFLIdP9+XW5eV/BxmZLrspZiB4JmB5j4LtnCzKNbX5V1a812qZoC99Kv8UosxRmJhlrM RcWJAJLNkEL+AgAA Archived-At: Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 15:09:55 -0000 On 04/27/2015 08:45 AM, Nathaniel McCallum wrote: > I have finally finished the first edition of SPAKE Preauth. You can > read it at this link: > http://www.ietf.org/id/draft-mccallum-kitten-krb-spake-preauth-00.txt I think this mechanism has a lot of potential, and I hope the kitten working group will adopt this document. There is a lot of work to be done at the detail level, but I think the general shape of the mechanism is about right. I think this mechanism addresses three under-served scenarios: 1. A realm administrators are concerned (or ought to be concerned) about the potential for offline dictionary attacks conducted by an adversary using passive network surveillance. The realm is using only passwords for user authentication and does not have the resources to deploy a second factor. Encrypted timestamps are in use but do not protect against a network listener. There are several other ways to address this use case, including FAST. But SPAKE preauth can be deployed more easily than FAST--perhaps even turned on by default--and does not require as many changes to other layers to make deployment easier. 2. A realm is using passwords for user authentication, and the administrators want to add a traditional OTP second factor (like Yubikey or RSA tokens) for some or all principals. FAST-OTP is designed to replace, rather than augment, the use of Kerberos long-term keys, and is therefore not easy to apply to this situation. In this use case, SPAKE preauth is used with a second-factor challenge in the second pass, and the token value is transmitted inside the key confirmation. The KDC issues a ticket if key agreement succeeded and the token value is valid, and responds with an error if either is wrong. If there are no side channels, an attacker can't tell which factor was guessed incorrectly. 3. Same as (2), but the realm administrators want to add a Duo-style second factor. In this style, the password needs to be validated first, and then the user is presented with a choice of options for the second factor. Depending on the choice, there may or may not be an OTP value presented to the KDC for validation. In this use case, SPAKE preauth is used without a second-factor challenge in the second pass, but additional challenge/responses occur after key agreement. An attacker does get to make on-line guesses at the password separately from the second factor, but is unable to cause nuisance second-factor challenges (such as pushes to the user's mobile device) without knowledge of the password. From nobody Tue Apr 28 08:48:52 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882E41A87A8 for ; Tue, 28 Apr 2015 08:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.291 X-Spam-Level: X-Spam-Status: No, score=0.291 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_82=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEOVIAWZ4GMs for ; Tue, 28 Apr 2015 08:48:47 -0700 (PDT) Received: from nm42-vm10.bullet.mail.bf1.yahoo.com (nm42-vm10.bullet.mail.bf1.yahoo.com [216.109.114.155]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67E1B1A8792 for ; Tue, 28 Apr 2015 08:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430236126; bh=sLkDW8dAfdmx+9fRPWOLo5OIKCm4G63ZtHBEOA6UM6I=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=ERpLEbCw/cdwsWF3qyTsPCvmUmpEhtdXmdC5wT7hDHjH7hFjewHr78zv2yfADboRLA6C2cZsRGoXWZ3Xcqo+9g4Bxsvi8HddgbHlvUlMRUe+0E5JgN1ThoEUq23Z+iz+9HASJ489xqlT0gsMtnMXI+BCT0Y3zsZAtNkJUWSr4TkpS+GX8JLOt+6/rLM0hj4hFslX9mzbEiRsPdn8Q/mMUI9G1M/LTe56qurEWRsVz9pwXdcBxkbABi0A8yV0n8o1SiBEvMPlPn6176KmroS4Hrbk0jTYdl2IVfcLtJ/EpI9/1jjcUrYYB57T+0nDhKlTi6m39Ewl7QPzyVxnXkF4Fw== Received: from [98.139.170.180] by nm42.bullet.mail.bf1.yahoo.com with NNFMP; 28 Apr 2015 15:48:46 -0000 Received: from [98.139.212.240] by tm23.bullet.mail.bf1.yahoo.com with NNFMP; 28 Apr 2015 15:48:46 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 28 Apr 2015 15:48:46 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 558245.9690.bm@omp1049.mail.bf1.yahoo.com X-YMail-OSG: yk41OLIVM1nxgZ7GZuoWphQMdh7zcQVos6rYIAqH9U5XP0weLtdmyZYQtCCovAv cwnlZu_lp_fl9I1oQH7A0VHn_PWCqWxHIfMWBxyw6P5GATbh3xYjchLzp0LOZOVXKDrFymszk0Gj KBHG0qce1hQVADO1ygbpS0LA5MrS8cmiGfyHWYu7_Z1JpnVhDMA8MkqbY_fw2YewqIyWkF5EylD7 pYTxVTTrJ0nXt.2vr5heYQOgViTCgFMkyxkkurMRZz.jHw5BsHkh.1AmlZhNEc9z3vYX8Szvp9T6 IXKzMpsd3KqrQXFjLEdkvx1lPEhhEQRH9UF.zV6gxSXK9Yl5xxqM800msGAgMLRKSva1D1gorQfV fYHtmkfNdHR6l2.aY73MMLJVWBtfBV6Y8G.omjiWaPIjTmF8AZH0CQZIZi3jPrvnww4rOsO.cZSa o9lliL0NmM1rtZXb9bp3_CH_LHBUiz9KH6vzc_pxzcrptg577FNsqRsiICjSaLT_mNxESFe1F95L xzI5RDFVbUNEu8taj77LxgwLIaNT1ajSbeB79OpXZSSge Received: by 66.196.80.122; Tue, 28 Apr 2015 15:48:46 +0000 Date: Tue, 28 Apr 2015 15:48:45 +0000 (UTC) From: Bill Mills To: Stephen Farrell , Benjamin Kaduk Message-ID: <699427215.7347807.1430236125356.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <553F9DDB.4050401@cs.tcd.ie> References: <553F9DDB.4050401@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7347806_1631543971.1430236125336" Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 15:48:50 -0000 ------=_Part_7347806_1631543971.1430236125336 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable -22 up on Github with the noted changes from below. =C2=A0 https://github.com/sweetums/idrafts/commit/4f38fc40cf45784f23667c1d792122af= 572ba779 On Tuesday, April 28, 2015 7:48 AM, Stephen Farrell wrote: >Hi Ben, Bill,>>(Sorry for the slow response, got distracted yesterday;-)>>= On 27/04/15 23:23, Benjamin Kaduk wrote:>> On Sat, 25 Apr 2015, Stephen Far= rell wrote:>>=C2=A0>>>>>> I'm sorry but we seem to be talking past one anot= her for both>>> issues. Let me try another tack but it may also help if som= eone>>> else chimes in.>>=C2=A0>> [puts on shepherd hat]>> Sorry for the lo= ng silence; I was sick last week and didn't get much>> of anything done.>>= =C2=A0>> Question (1) is about the host and port kvpairs of the initial cli= ent>> response; Stephen claims that any server software using this SASL>> m= echanism will know what hostname and port the client is trying to access.>>= It seems like this is in fact true,=C2=A0>>Right. And that means we're dup= licating that information. And such>duplication, when the value are not the= same, is a time-honoured way>of getting around authorization systems that = forget that there are>two copies and who only check one. If you want to kee= p the duplication>then I think you have to note that. Again I disagree, this is *exactly* the same problem the HTTP host headerso= lves. =C2=A0IMAP does not have anything that conveys hostname. =C2=A0Port n= umber=C2=A0might be known but hostname is not guaranteed. Added "The server= SHOULD=C2=A0validate that the host and port values match the expected valu= es for the=C2=A0service." to the end of the paragraph discussing signature = base strings=C2=A0where host and port are defined in 3. >>> but Bill says there is no API for a>> SASL mechanism implementation to = query this from up the stack (and would>> require patching the core SASL im= plementation, not just a mechanism>> implementation). =C2=A0The natural que= stion to ask, then, is if other SASL>> mechanisms are verifying a client-su= pplied hostname, and if so, how. =C2=A0In>> Kerberos the desired service pr= incipal name includes a hostname, and can>> be determined by examining the = sname field of the presented Ticket. =C2=A0In>> practice, kerberized applic= ation servers are generally configured to>> either use one specific service= principal name, or any for which keys can>> be found [optionally, of the g= iven service type]. =C2=A0>>That could be a valid choice, but ought be clea= r to whoever>is issuing the tickets, (or tokens here) right? No. =C2=A0The example is Google's OAuth implementation that uses the same t= okenfor both SMTP and IMAP. =C2=A0Same ticket, different hostnames.=C2=A0 >>> So, the hostname used>> by the client can be determined just from the a= uthentication blob, without>> a need to consult the SASL stack. =C2=A0If ot= her mechanisms are similar to>> kerberos, than I guess it makes sense to ex= plicitly include the target>> hostname in the initial client response, as i= s currently done. =C2=A0This seems>> to be the only relevant part of the di= scussion; I don't think that OAuth>> tokens valid for multiple servers are = particularly interesting for>> answering this question.>>=C2=A0>> Additiona= lly, the SASL application server certainly knows what port it is>> receivin= g traffic on. =C2=A0But, as Bill notes, if there is a load-balancer or>> TL= S terminator in between, the port the server is listening on can differ>> f= rom the port that the client sent to. =C2=A0My understanding is that it is = not>> terribly common for authentication/authorization schemes to be>> port= -restricted, so it is plausible that the SASL mechanisms currently in>> use= in such scenarios do not use a port number and thus can succeed>> unchange= d, whereas OAuth 1.0a does bind to the port number and needs an>> explicit = hint.>>=C2=A0>> In both cases (hostname and port), my tentative conclusion = is that no>> change to the draft is needed.>>If keeping it, I think you nee= d the warning about duplication. I'm>guessing that that warning won't ever = be in other RFCs, as>applications presumably don't need to say which SASL m= echanisms are>allowed.>>(I wonder if this is just one example of where the = first sentence>of 3.2 doesn't have sufficient detail?)>>>=C2=A0>>=C2=A0>> Q= uestion (2) relates to the use of TLS. =C2=A0This document is in a somewhat= >> awkward position of specifying both a specific (pair of) mechanisms and = a>> (hopefully) general framework for converting HTTP OAuth mechanisms into= >> SASL mechanisms. =C2=A0For all currently specified OAuth (2.0) mechanism= s, TLS>> is required to protect the bearer token, but we hope that future O= Auth>> mechanisms can be specified which do not use bearer tokens and thus = have a>> weaker dependency on TLS. =C2=A0In particular, we hope that such f= uture OAuth>> HTTP mechanisms can be converted to SASL mechanisms using the= framework>> specified in this document.>>=C2=A0>> So, while TLS MUST be us= ed for the concrete mechanisms this document>> specifies [1], there is not = a very strong case to say that TLS MUST be>> used for all mechanisms compli= ant to this framework. =C2=A0This framework for>> SASL mechanisms does not = provide any security layer for data security, so>> if confidentiality of da= ta is required, TLS ought to be used. =C2=A0But I'm not>> sure that's even = a SHOULD, let alone a MUST.>>=C2=A0>> I concede Stephen's point that sectio= n 3 should say *something* about TLS,>> and propose moving (or copying?) te= xt from the security considerations>> relating to the two specific mechanis= ms (MUST for OAUTHBEARER; RECOMMENDED>> for OAUTH10A), along with some text= giving guidance for future mechanisms>> using this framework. =C2=A0It's n= ot clear to me that sections 4 and 5 are>> internally inconsistent, though = -- unless the difference between "TLS MUST>> be used" and "TLS must be prov= ided" is the concern?>>=C2=A0>> To suggest some concrete text, insert into = section 3, after the paragraph>> "New extensions may be defined [...] citin= g this specification for the>> further definition.":>>=C2=A0>> %%%%%%%%%%%%= %%%%%%%%%%%%>>=C2=A0>> SASL mechanisms using this document as their definit= ion do not provide>> a data security layer; that is, they cannot provide in= tegrity or>> confidentiality protection for application messages after the = initial>> authentication. =C2=A0If such protection is needed, TLS or some s= imilar>> solution should be used. =C2=A0Additionally, for the two mechanism= s specified>> in this document, TLS MUST be used for OAUTHBEARER to protect= the bearer>> token; for OAUTH10A the use of TLS is RECOMMENDED.>>I'd be fi= ne with that change.> This duplicates text from the definition of OAUTHBEARER above, but if it=C2= =A0makes you happy it's in. >S.>>>=C2=A0>> %%%%%%%%%%%%%%%%%%%%%%%%>>=C2=A0>> The start of the next par= agraph could probably also benefit from new>> transition text, such as "Mec= hanisms using this document as a definition>> are client initiated [...]".>= >=C2=A0>>=C2=A0>>=C2=A0>> With respect to the nits:>>=C2=A0>> I only see on= e valid entry in the idnits output about the references;>> draft-ietf-oauth= -dyn-reg has had a new version come out in the interim.>> It also claims th= at RFC 5849 (OAuth 1) is obsolete, but we do need to>> reference it for the= OAUTH10A mechanism. =C2=A0(I thought I said that in the>> shepherd report.= ...)>>=C2=A0>> Alexey looked at an old version of the ABNF and we had to ma= ke a couple>> tweaks, but I think it's okay, now.>>=C2=A0>> Bill talked abo= ut the kvsep of 0x01, so I will say no more.>>=C2=A0>> I think Bill also co= vered the privacy aspects of (not) including the>> authzid as well.>>=C2=A0= >> I did some checking of the examples, but they should ideally be checked>= > again at some point. =C2=A0(I will probably do it during IETF last call.)= >> There were several points in time where the examples were internally>> i= nconsistent, so it would be good to make sure that we've stamped those>> ou= t.>>=C2=A0>> -Ben>>=C2=A0>> [1] I'm ignoring OAuth 1.0a for this point.>>= =C2=A0>> ------=_Part_7347806_1631543971.1430236125336 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
-22 up on Github with the noted changes from below.  = ;

https://github.com/sweetums/idrafts/commit= /4f38fc40cf45784f23667c1d792122af572ba779

On Tuesday, April 28, 2015 7:48 AM, Stephen Farrell <= ;stephen.farrell@cs.tcd.ie> wrote:

>Hi Ben, Bill,
>
>(Sorry for the slow re= sponse, got distracted yesterday;-)
>
>On 27/04/15 = 23:23, Benjamin Kaduk wrote:
>> On Sat, 25 Apr 2015, Stephen= Farrell wrote:
>> 
>>>
>= ;>> I'm sorry but we seem to be talking past one another for both
>>> issues. Let me try another tack but it may also help if = someone
>>> else chimes in.
>> 
=
>> [puts on shepherd hat]
>> Sorry for the long = silence; I was sick last week and didn't get much
>> of anyt= hing done.
>> 
>> Question (1) is about = the host and port kvpairs of the initial client
>> response;= Stephen claims that any server software using this SASL
>> = mechanism will know what hostname and port the client is trying to access.<= /div>
>> It seems like this is in fact true, 
>
>Right. And that means we're duplicating that information. And s= uch
>duplication, when the value are not the same, is a time-ho= noured way
>of getting around authorization systems that forget= that there are
>two copies and who only check one. If you want= to keep the duplication
>then I think you have to note that.

Again I disagree, this is *exac= tly* the same problem the HTTP host header
solves.  IMAP does= not have anything that conveys hostname.  Port number 
= might be known but hostname is not guaranteed. Added "The server SHOULD&nbs= p;
validate that the host and port values match the expected value= s for the 
service." to the end of the paragraph discussing s= ignature base strings 
where host and port are defined in 3.<= /div>

>
>> but Bil= l says there is no API for a
>> SASL mechanism implementatio= n to query this from up the stack (and would
>> require patc= hing the core SASL implementation, not just a mechanism
>> i= mplementation).  The natural question to ask, then, is if other SASL
>> mechanisms are verifying a client-supplied hostname, and i= f so, how.  In
>> Kerberos the desired service principa= l name includes a hostname, and can
>> be determined by exam= ining the sname field of the presented Ticket.  In
>> p= ractice, kerberized application servers are generally configured to
>> either use one specific service principal name, or any for which= keys can
>> be found [optionally, of the given service typ= e].  
>
>That could be a valid choice, but oug= ht be clear to whoever
>is issuing the tickets, (or tokens here= ) right?

No.  The examp= le is Google's OAuth implementation that uses the same token
for= both SMTP and IMAP.  Same ticket, different hostnames. 

>
>> So, the hostnam= e used
>> by the client can be determined just from the auth= entication blob, without
>> a need to consult the SASL stack= .  If other mechanisms are similar to
>> kerberos, than= I guess it makes sense to explicitly include the target
>> = hostname in the initial client response, as is currently done.  This s= eems
>> to be the only relevant part of the discussion; I do= n't think that OAuth
>> tokens valid for multiple servers ar= e particularly interesting for
>> answering this question.
>> 
>> Additionally, the SASL application= server certainly knows what port it is
>> receiving traffic= on.  But, as Bill notes, if there is a load-balancer or
>= ;> TLS terminator in between, the port the server is listening on can di= ffer
>> from the port that the client sent to.  My unde= rstanding is that it is not
>> terribly common for authentic= ation/authorization schemes to be
>> port-restricted, so it = is plausible that the SASL mechanisms currently in
>> use in= such scenarios do not use a port number and thus can succeed
>= ;> unchanged, whereas OAuth 1.0a does bind to the port number and needs = an
>> explicit hint.
>> 
>&g= t; In both cases (hostname and port), my tentative conclusion is that no
>> change to the draft is needed.
>
>= ;If keeping it, I think you need the warning about duplication. I'm
>guessing that that warning won't ever be in other RFCs, as
&= gt;applications presumably don't need to say which SASL mechanisms are
>allowed.
>
>(I wonder if this is just on= e example of where the first sentence
>of 3.2 doesn't have suff= icient detail?)
>
>> 
>>&nbs= p;
>> Question (2) relates to the use of TLS.  This doc= ument is in a somewhat
>> awkward position of specifying bot= h a specific (pair of) mechanisms and a
>> (hopefully) gener= al framework for converting HTTP OAuth mechanisms into
>> SA= SL mechanisms.  For all currently specified OAuth (2.0) mechanisms, TL= S
>> is required to protect the bearer token, but we hope th= at future OAuth
>> mechanisms can be specified which do not = use bearer tokens and thus have a
>> weaker dependency on TL= S.  In particular, we hope that such future OAuth
>> HT= TP mechanisms can be converted to SASL mechanisms using the framework
=
>> specified in this document.
>> 
>> So, while TLS MUST be used for the concrete mechanisms this docum= ent
>> specifies [1], there is not a very strong case to say= that TLS MUST be
>> used for all mechanisms compliant to = this framework.  This framework for
>> SASL mechanisms = does not provide any security layer for data security, so
>>= if confidentiality of data is required, TLS ought to be used.  But I'= m not
>> sure that's even a SHOULD, let alone a MUST.
<= div id=3D"yui_3_16_0_1_1430202264217_81867" class=3D"" dir=3D"ltr" style=3D= "">>> 
>> I concede Stephen's point that sectio= n 3 should say *something* about TLS,
>> and propose moving = (or copying?) text from the security considerations
>> relat= ing to the two specific mechanisms (MUST for OAUTHBEARER; RECOMMENDED
=
>> for OAUTH10A), along with some text giving guidance for futu= re mechanisms
>> using this framework.  It's not clear = to me that sections 4 and 5 are
>> internally inconsistent, = though -- unless the difference between "TLS MUST
>> be used= " and "TLS must be provided" is the concern?
>> 
<= div id=3D"yui_3_16_0_1_1430202264217_81867" class=3D"" dir=3D"ltr" style=3D= "">>> To suggest some concrete text, insert into section 3, after the= paragraph
>> "New extensions may be defined [...] citing th= is specification for the
>> further definition.":
&= gt;> 
>> %%%%%%%%%%%%%%%%%%%%%%%%
>>&= nbsp;
>> SASL mechanisms using this document as their defini= tion do not provide
>> a data security layer; that is, they = cannot provide integrity or
>> confidentiality protection fo= r application messages after the initial
>> authentication. =  If such protection is needed, TLS or some similar
>> s= olution should be used.  Additionally, for the two mechanisms specifie= d
>> in this document, TLS MUST be used for OAUTHBEARER to p= rotect the bearer
>> token; for OAUTH10A the use of TLS is= RECOMMENDED.
>
>I'd be fine with that change.
>

This duplicates tex= t from the definition of OAUTHBEARER above, but if it 
makes = you happy it's in.

>S.
>
>> 
>> %%%%%%%%%%%%%%%%%%%%%%= %%
>> 
>> The start of the next paragrap= h could probably also benefit from new
>> transition text, s= uch as "Mechanisms using this document as a definition
>> ar= e client initiated [...]".
>> 
>> <= /div>
>> 
>> With respect to the nits:
>> 
>> I only see one valid entry in the idnits= output about the references;
>> draft-ietf-oauth-dyn-reg ha= s had a new version come out in the interim.
>> It also clai= ms that RFC 5849 (OAuth 1) is obsolete, but we do need to
>>= reference it for the OAUTH10A mechanism.  (I thought I said that in t= he
>> shepherd report....)
>> 
= >> Alexey looked at an old version of the ABNF and we had to make a c= ouple
>> tweaks, but I think it's okay, now.
>&g= t; 
>> Bill talked about the kvsep of 0x01, so I will= say no more.
>> 
>> I think Bill also c= overed the privacy aspects of (not) including the
>> authzid= as well.
>> 
>> I did some checking of= the examples, but they should ideally be checked
>> again a= t some point.  (I will probably do it during IETF last call.)
>> There were several points in time where the examples were interna= lly
>> inconsistent, so it would be good to make sure that w= e've stamped those
>> out.
>> 
>> -Ben
>> 
>> [1] I'm ignoring O= Auth 1.0a for this point.
>> 
>
&g= t;

------=_Part_7347806_1631543971.1430236125336-- From nobody Tue Apr 28 09:48:06 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23EC01B2A30 for ; Tue, 28 Apr 2015 09:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G24sM1NZ30xV for ; Tue, 28 Apr 2015 09:48:05 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 240181B2A35 for ; Tue, 28 Apr 2015 09:47:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E5221BDD8; Tue, 28 Apr 2015 17:47:28 +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 F2qNVgC4orzj; Tue, 28 Apr 2015 17:47:27 +0100 (IST) Received: from [10.87.48.73] (unknown [86.42.29.198]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BC6DDBDCC; Tue, 28 Apr 2015 17:47:27 +0100 (IST) Message-ID: <553FB99F.5070609@cs.tcd.ie> Date: Tue, 28 Apr 2015 17:47:27 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Bill Mills , Benjamin Kaduk References: <553F9DDB.4050401@cs.tcd.ie> <699427215.7347807.1430236125356.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <699427215.7347807.1430236125356.JavaMail.yahoo@mail.yahoo.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 16:48:06 -0000 On 28/04/15 16:48, Bill Mills wrote: > Again I disagree, this is *exactly* the same problem the HTTP host > header solves. The Host header field solves that problem for HTTP, but creates a problem for an authorization subsystem - if one piece of server side code checks an action the client wants to do vs. the Host header field and another makes that check vs. the new field that we're defining here then that opens a hole. And that error has been seen many times, so I don't believe you can just do a plug and play thing here safely, in general. > IMAP does not have anything that conveys hostname. > Port number might be known but hostname is not guaranteed. Added "The > server SHOULD validate that the host and port values match the > expected values for the service." to the end of the paragraph > discussing signature base strings where host and port are defined in > 3. I've no problem if you add the above but what I'm asking for is more like: "The server MUST validate that the host and port values defined here match any other application protocol data units or configured values that carry the same information. The details of how to do that match are application-specific and so cannot defined here, but implementers integrating these SASL mechanisms with applications need to ensure that such checks are made, where they are needed." Cheers, S. From nobody Tue Apr 28 14:53:13 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594381A8025 for ; Tue, 28 Apr 2015 14:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vcSmPTI7CktC for ; Tue, 28 Apr 2015 14:53:08 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA1C91A8A0C for ; Tue, 28 Apr 2015 14:53:05 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-99-55400140c519 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 64.97.03493.04100455; Tue, 28 Apr 2015 17:53:04 -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 t3SLr3uS025994; Tue, 28 Apr 2015 17:53:04 -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 t3SLr15j008030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Apr 2015 17:53:03 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3SLr12w006461; Tue, 28 Apr 2015 17:53:01 -0400 (EDT) Date: Tue, 28 Apr 2015 17:53:01 -0400 (EDT) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <553FA2B3.8030301@mit.edu> Message-ID: References: <1430138754.2682.10.camel@redhat.com> <553FA2B3.8030301@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqrOvA6BBq0Ltaw+Lo5lUsFnO/zmJ1 YPJYsuQnk8f7fVfZApiiuGxSUnMyy1KL9O0SuDJ2TXArmGhRcfjmebYGxlO6XYycHBICJhKb rq9mh7DFJC7cW88GYgsJLGaS+PXVo4uRC8jeyChx59BJFgjnEJPElK8rmSGcBkaJxR8ms4C0 sAhoS8yfOYEVxGYTUJGY+WYj2CgRAT2JZfsmMILYzALqEt/OvAGzhQWUJc6+OgW2mhMofnjn FDCbV8BRYtXzU8wQZ/hILFz5DmyOqICOxOr9U1ggagQlTs58wgIxU0ti+fRtLBMYBWchSc1C klrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11wvN7NELzWldBMjKFDZXVR2MDYfUjrEKMDB qMTDa3HTLlSINbGsuDL3EKMkB5OSKK8tg0OoEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRFe6+P2 oUK8KYmVValF+TApaQ4WJXHeTT/4QoQE0hNLUrNTUwtSi2CyMhwcShK8KiBDBYtS01Mr0jJz ShDSTBycIMN5gIaf+w8yvLggMbc4Mx0if4pRUUqc9zNIQgAkkVGaB9cLSySvGMWBXhHm1QZZ wQNMQnDdr4AGMwENrpxpAzK4JBEhJdXAaHqD5aj3vdzPm87+mGfUGL/GtHSiQ17816WmG2/N mdrao7BF1es6f1GqrKqbMec6z475zvt55jq8mndCWHGHSfuWcu0bK5K5vIU2TLuv0/hu25UT BU8LJll6ad4Pf1rx6v6fD+b6a4/c3TrpedND4/PHbP6se25tl5PuMPWfJFOYH4u/x/HZ25VY ijMSDbWYi4oTAcWMAPr/AgAA Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 21:53:11 -0000 On Tue, 28 Apr 2015, Greg Hudson wrote: > On 04/27/2015 08:45 AM, Nathaniel McCallum wrote: > > I have finally finished the first edition of SPAKE Preauth. You can > > read it at this link: > > http://www.ietf.org/id/draft-mccallum-kitten-krb-spake-preauth-00.txt > > I think this mechanism has a lot of potential, and I hope the kitten > working group will adopt this document. There is a lot of work to be > done at the detail level, but I think the general shape of the mechanism > is about right. I agree with this assessment, and hope that the document will move forward through the working group. > I think this mechanism addresses three under-served scenarios: > > 1. A realm administrators are concerned (or ought to be concerned) about > the potential for offline dictionary attacks conducted by an adversary > using passive network surveillance. The realm is using only passwords > for user authentication and does not have the resources to deploy a > second factor. Encrypted timestamps are in use but do not protect > against a network listener. I think this point could be emphasized in section 1 -- the current text is only "offline brute-force attack against the transferred packet", saying nothing about passwords, let alone weak passwords. > 2. A realm is using passwords for user authentication, and the > administrators want to add a traditional OTP second factor (like Yubikey > or RSA tokens) for some or all principals. FAST-OTP is designed to > replace, rather than augment, the use of Kerberos long-term keys, and is > therefore not easy to apply to this situation. > > In this use case, SPAKE preauth is used with a second-factor challenge > in the second pass, and the token value is transmitted inside the key > confirmation. The KDC issues a ticket if key agreement succeeded and > the token value is valid, and responds with an error if either is wrong. > If there are no side channels, an attacker can't tell which factor was > guessed incorrectly. "can't tell which factor was guessed incorrectly" seems like a pretty important property (I would be really excited to see a scheme with this property get deployed!), but it does not seem to be mentioned in the current section 1.2 text. (It does talk about avoiding ciphertexts^Wpackets which are vulnerable to offline brute-force attack, but I don't see anything mentioning the online attack as well.) Hmm, this is mentioned in the security considerations, at least. I think it should be more prominent earlier in the document. However, it seems like the text at the end of section 4.3 wherein "[i]f validation of the second factor requires furthe round-trips, the KDC MUST reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED [...]" loses the indistinguishability property, as the encrypted SPAKESecondFactor would not be generated if the long-term key (password) was incorrect. This seems inherent to second factors which require multiple round trips to validate, though, so maybe we have to make a choice of the tradeoff. [case 3 trimmed] Some additional comments: The current version of 4.3 only allows for one second factor to be used. Do we want to consider a design which permits multiple additional factors to be used (maybe, phone and hardware token, or something like that)? We talked about SPAKE on the MIT kerberos dev call today, and one of the things mentioned is that the M and N values are specified per group in draft-irtf-cfrg-spake2 (along with a procedure for selecting them for new groups); we should explicitly note that their selection (and encoding?) is delegated to the IRTF document. Also covered on the MIT dev call, we should go into more detail about the transcript hash (in a separate subsection?). Apparently there is also a discussion to have about the way the transcript includes the full exchange of messages, i.e., whether it is okay to chain hashes or the full history must be buffered. With respect to the recommended groups in section 7, I believe that interoperability concerns should drive us to pick at least one mandatory to implement group. The state of things elsewhere in the IETF and IRTF seem to be leaning towards non-NIST curves as well; we should probably consider if the CFRG curve recommendations to the TLS working group are relevant for this case. The IANA considerations are not considered complete by current standards; see BCP 26 (i.e., RFC 5226 at present). In particular, section 4.2 contains the list of what needs to be in a document which creates a registry. Nits: In 1.2, "attempting to encrypt this data using the long-term password" implicitly assumes "using authenticated encryption (such as RFC 3961 crypto)", as I understand it. 1.2, second paragraph, first line, comma after "FAST". Still 1.2, it's "certification authority", not "certificate authority". Last sentence of 1.2, is "leveraged into" really correct? I thought that the long-term key and the 2FA data were mixed into the DHE in the same way. In 1.3, first paragraph, penultemate sentence, "indistinguishable from random" seems like an incomplete clause; maybe "random data" or "random bits"? 1.3, second paragraph, antepenultimate sentence, in "equivalent security", as a reader I expect to see what it is equivalent to, i.e., "equivalent security using standard DH-KE". In 3.1, I think the text would read more naturally if consolidated into a single sentence, viz. "a PA-ETYPE-INFO2 element with a single ETYPE-INFO2-ENTRY containing the etype [...]". Perhaps 3.3 should cite RFC 6113 for KDC_ERR_MORE_PREAUTH_DATA_REQUIRED. There are several places where the document indicates only the fields in KDC-RE{Q,P}s which are specific to SPAKE, with no reference to the other fields which will be included indicating support for other preauth schemes, etc.. While this can be a valid style to use, I wonder if some consideration should be given to some additional text about "in the set of pre-authentication data in the KRB_ERROR message" for section 4.1, and similarly elsewhere in the document. Section 4.3 should forward-reference section 5.1 for key derivation. In section 4.3, second paragraph, us a comma instead of a semicolon to prefix "possibly using the challenge data for this second factor type", since that is a dependent clause. We should probably be a little more explicit about what key, usage, etc. are going on for the EncryptedData encrypted/checksummed with the session key derived from the SPAKE key; we covered this a little bit on the MIT dev call today as well. In 4.4, "second factor type specific" is a bit awkward; maybe "specific to each type of second factor"? In section 8, the integrity confirmation of the transcript messages occurs when the SPAKEResponse is processed and validated, not when it is transmitted, I think -- the KDC is the second party to compute the transcript/key derivation, and the verification that the two parties' transcripts agree occurs when the KDC compares its local copy to the one it got from the network. -Ben From nobody Wed Apr 29 09:17:26 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9871A6FCB for ; Wed, 29 Apr 2015 09:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4nSElmCDGv6z for ; Wed, 29 Apr 2015 09:17:23 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 34DB61A1BCF for ; Wed, 29 Apr 2015 09:17:23 -0700 (PDT) Received: from homiemail-a97.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTP id C26F8286080; Wed, 29 Apr 2015 09:17:22 -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=gs4pETf6kiGrF5 C6W0CDM7SWK1c=; b=OOkYVZIp7G9oU25jaz4qqZ2/sQwJ6Ag1et9QzFTVuHU098 UVNSxcWPn03WWJPMYHgmBD74Rd26S1IQT6C0C8WyrfF4K7zFHZmg9DrqCghuVLl8 XFaUgsTlc/EKjoD2xO6lZDYjGCyQyNYI0y2tLYXTwIKNw6vvF4B5Z6xpXJ44E= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a97.g.dreamhost.com (Postfix) with ESMTPA id B7EFF286055; Wed, 29 Apr 2015 09:17:21 -0700 (PDT) Date: Wed, 29 Apr 2015 11:17:19 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150429161716.GH6026@localhost> References: <1430138754.2682.10.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430138754.2682.10.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 16:17:24 -0000 On Mon, Apr 27, 2015 at 08:45:54AM -0400, Nathaniel McCallum wrote: > I have finally finished the first edition of SPAKE Preauth. You can > read it at this link: > http://www.ietf.org/id/draft-mccallum-kitten-krb-spake-preauth-00.txt I'm in favor of the WG adopting this as a WG work item. I have some comments: - Kerberos doesn't really depend on synchronization of client clocks for any of the KDC exchanges (AS, TGS): because they are stateless and retriable, and the client learns the KDC's time in KRB-ERROR PDUs. Pre-auth methods that don't depend on the client's clock are mostly an optimization. They are less of an optimization when failures count towards locking a principal, but still an optimization (since one can account for clock skew by adding one to N-strikes-you're- locked policies). Time synchronization across services in a realm is not something that is being fixed here either. IMO the time sync aspects of this are a bit overdone :) - Section 1.1 is a bit weak. I don't think it's even necessary to explain PAKE in terms of DH key agreement either. The properties of a PAKE are: - provides authenticated key agreement with both parties contributing entropy to the shared secret; (And each exchange yields a different shared secret.) - is resistant to off-line dictionary attacks by eavesdroppers, even for small, simple passwordsj - "servers" store password equivalents; (In an augmented PAKE the server stores a verifier, but you're not proposing the use of an augmented PAKE.) - users "store" passwords. - Section 1.2, the claim about why FAST is difficult to deploy requires more evidence, and I believe it's wrong. The problem with FAST is that it's difficult to make it a requirement for PA-ENC-TIMESTAMP because FAST is not universally available yet -- the tragedy of legacy forever. Sure, one has to deploy trust anchors, but then again, one doesn't have to (leap of faith), and one can (for machines that have "joined" a realm or hierarchy of realms). Either elaborate this claim, or leave it at "it's difficult to deploy". This claim just isn't all that important to this work: after all, the key is the ability to combine a PAKE and a second factor in a way that leaks no information about which factor was incorrect when either (or both) were. FAST doesn't help with that. Even more interesting properties can be dreamed up that FAST simply can't help with either. On the other hand, FAST is still relevant: for providing confidentiality protection of the client's principal name. There's just no need to justify this or any other pre-auth method based on FAST's real or perceived failure. Indeed, all new pre-auth methods might well (will!) suffer from some of the same barriers to adoption that I think FAST suffers from, and then what? Should we stop designing new pre-auth methods? No. Controversial claims that are not core to the document should just go. That's as far as I got reading the I-D so far. I've reviewed the design before and I approve, and I'll complete my review of the I-D at some point. Nico -- From nobody Wed Apr 29 12:43:20 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8631A00BE for ; Wed, 29 Apr 2015 12:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw8g4QDfEAGV for ; Wed, 29 Apr 2015 12:43:14 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9880A1A00C2 for ; Wed, 29 Apr 2015 12:43:05 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-aa-55413448d98a Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id A1.3D.03389.84431455; Wed, 29 Apr 2015 15:43:04 -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 t3TJh3qX022619; Wed, 29 Apr 2015 15:43:04 -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 t3TJh1S1023897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Apr 2015 15:43:02 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3TJh1K6021855; Wed, 29 Apr 2015 15:43:01 -0400 (EDT) Date: Wed, 29 Apr 2015 15:43:01 -0400 (EDT) From: Benjamin Kaduk To: Stephen Farrell In-Reply-To: <553FB99F.5070609@cs.tcd.ie> Message-ID: References: <553F9DDB.4050401@cs.tcd.ie> <699427215.7347807.1430236125356.JavaMail.yahoo@mail.yahoo.com> <553FB99F.5070609@cs.tcd.ie> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsUixCmqrOth4hhq8P6hnMXRzatYLKbvvcZu 8a3rOrMDs8fa7qtsHkuW/GTymDXrMFMAcxSXTUpqTmZZapG+XQJXRvf31ywF78Uq7r/byNTA uEWoi5GTQ0LAROL2pz9sELaYxIV768FsIYHFTBKvV4V0MXIB2RsZJf4vmMQCkTjEJLHyChNE ooFRYuKFBrAOFgFtidmHjjOD2GwCKhIz32wEi4sI6Evs3XyOHcRmFvCReHbxJdggYQEnietz rgEN4uDgFNCU2LZJCSTMK+AosXrTIqj5rYwS9zffZgRJiAroSKzeP4UFokhQ4uTMJywQM7Uk lk/fxjKBUXAWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE30cjNL9FJTSjcxgoNX kn8H47eDSocYBTgYlXh4Nyg7hAqxJpYVV+YeYpTkYFIS5X2s4RgqxJeUn1KZkVicEV9UmpNa fIhRgoNZSYT3gB5QjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgnei MVCjYFFqempFWmZOCUKaiYMTZDgP0PDTIDW8xQWJucWZ6RD5U4yKUuK8cSAJAZBERmkeXC8s ubxiFAd6RZj3ghFQFQ8wMcF1vwIazAQ0+PwtB5DBJYkIKakGRgWD25YrS9c1FPLdCZ/cZbhR 5aT7YXmbG4/jIjKnsbIxqXyXP9f8JvxkTchcY6EVIjLndha23ZpXtaxQQUVXbiuXZ8M+b8/n 8+T7fsdK+7mb1zVG3+F7FR7GztZzaGPbqQn/rC2npW32O7dRyP3rXqZdvwyf7Hc4J9a3Z6ls V//6h5y/In46K7EUZyQaajEXFScCADi5smkJAwAA Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 19:43:16 -0000 On Tue, 28 Apr 2015, Stephen Farrell wrote: > > > On 28/04/15 16:48, Bill Mills wrote: > > Again I disagree, this is *exactly* the same problem the HTTP host > > header solves. > > The Host header field solves that problem for HTTP, but creates a > problem for an authorization subsystem - if one piece of server > side code checks an action the client wants to do vs. the Host > header field and another makes that check vs. the new field that > we're defining here then that opens a hole. And that error has > been seen many times, so I don't believe you can just do a plug > and play thing here safely, in general. > > > IMAP does not have anything that conveys hostname. > > Port number might be known but hostname is not guaranteed. Added "The > > server SHOULD validate that the host and port values match the > > expected values for the service." to the end of the paragraph > > discussing signature base strings where host and port are defined in > > 3. > > I've no problem if you add the above but what I'm asking for is > more like: "The server MUST validate that the host and port values > defined here match any other application protocol data units or > configured values that carry the same information. The details of > how to do that match are application-specific and so cannot defined > here, but implementers integrating these SASL mechanisms with > applications need to ensure that such checks are made, where they > are needed." In any case, I think the text about validation should be in section 3.2, not section 3.1 where "[t]he server SHOULD validate that the host and port values match the expected values for the service" was added for the version on github. Section 3.2 is where server validation is discussed, in the first sentence that Stephen thinks is incomplete. I think we could combine expanding that sentence with discussion of validating the supplied hostname and port. My strawman text: %%%%%%%%%%%%%%%%%%%%%%%%% The server fully validates the client response before generating a server response; this will necessarily include the validation steps listed in the specification for the OAuth Access Token Type used. However, additional validation steps may be needed, depending on the particular application protocol making use of SASL. In particular, values included as kvpairs in the client response (such as host and port) which correspond to values known to the application by some other mechanism (such as an application protocol data unit or pre-configured values) MUST be validated to match between the initial client response and the the other source(s) of such information. As a concrete example, when SASL is used over TLS, the hostname can be available via the Server Name Indication TLS extension; this hostname must be validated to match the value sent in the 'host' kvpair. %%%%%%%%%%%%%%%%%%%%%%%%% -Ben From nobody Wed Apr 29 13:25:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 682591A1A78 for ; Wed, 29 Apr 2015 13:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT1GlQBW9vYy for ; Wed, 29 Apr 2015 13:25:05 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB58B1A1A7C for ; Wed, 29 Apr 2015 13:25:04 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-4c-55413e1fff41 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id C5.3A.03355.F1E31455; Wed, 29 Apr 2015 16:25:03 -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 t3TKP27I030754; Wed, 29 Apr 2015 16:25:03 -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 t3TKP0QD007920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 29 Apr 2015 16:25:02 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3TKP09K027135; Wed, 29 Apr 2015 16:25:00 -0400 (EDT) Date: Wed, 29 Apr 2015 16:25:00 -0400 (EDT) From: Benjamin Kaduk To: Michiko Short In-Reply-To: Message-ID: References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> <550339DA.6000109@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nritv5xhq8GiqhcXXtgdsFkc3r2Kx +NfN58DssWTJTyaP1h1/2T1WTj3NHsAcxWWTkpqTWZZapG+XwJWx/cELloK3XBU9uy+wNTCe 5+hi5OSQEDCR+DrnGjuELSZx4d56ti5GLg4hgcVMEosWr2aFcDYySkzt6WeHcA4xSTQePcMC 4TQwSqyZ+5cZpJ9FQFvi7r5mJhCbTUBFYuabjWwgtoiAlsSHC6dZQGxmgRKJ5edvgNnCAt4S D7fNBNvNKRAtsWrvXLA4r4CjxIwd/WC2kMAiFomTp1RBbFEBHYnV+6dA1QhKnJz5BGqmlsTy 6dtYJjAKzkKSmoUktYCRaRWjbEpulW5uYmZOcWqybnFyYl5eapGusV5uZoleakrpJkZQ+HJK 8u1g/HpQ6RCjAAejEg/vBmWHUCHWxLLiytxDjJIcTEqivGutHUOF+JLyUyozEosz4otKc1KL DzFKcDArifAe0APK8aYkVlalFuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8H63 AWoULEpNT61Iy8wpQUgzcXCCDOcBGv4FpIa3uCAxtzgzHSJ/ilFRSpz3DUhCACSRUZoH1wtL L68YxYFeEebVtQWq4gGmJrjuV0CDmYAGn7/lADK4JBEhJdXAGP8pfiHXd6uCsLeidXOmdlhe 9DyXx7DwUQWrg9FU+/k50zfzHn6yXWWjUZjfgacMD2ecYGmtXJNWV7Ipykr2pfPqw7tWXLsY 97LS852wwsJ3Al0qiTtt5MrKmDu/8xTxuB6dWfL8XPyiH93cU5LlFvMLRc6PvzCrfM+W3sT9 k1ae4e7ZPkFguRJLcUaioRZzUXEiACpUc3MKAwAA Archived-At: Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 20:25:07 -0000 On Mon, 27 Apr 2015, Michiko Short wrote: > Time for me to publish a new draft since this one is expiring. > > We found a use case in our implementation of PKInit where the client > must request a freshness token or else they will get a principal not > found error, so we need to keep the client behavior. I would prefer to > not make that MS-PKCA Microsoft extension. It there any problem with > keeping the client language as is? Also we would prefer to keep token > generation limited to the public key case. Yes, we are hoping to expand > the number of customers who use PKInit, but there will still be > customers for a while who do not, have old servers, etc. I think I've lost track of which client behavior is in question -- is this just the part where the client sends an empty PA_AS_FRESHNESS padata to indicate support of freshness tokens and prompt the KDC to send one (in contrast to having the KDC always send a freshness token on all requests or all requests being offered PKINIT)? It does not seem like a bad scheme to me in the abstract, but it seems that if we permit it, than all clients wishing to use freshness tokens must be prepared to implement it, in case they encounter a KDC which does not proactively provide freshness tokens. That's probably fine, but we should consciously take that choice instead of just falling into it. -Ben From nobody Wed Apr 29 14:05:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63651A1BE3 for ; Wed, 29 Apr 2015 14:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4wBpU-3c40w for ; Wed, 29 Apr 2015 14:05:30 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C84ED1A1BBD for ; Wed, 29 Apr 2015 14:05:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E6362BE3E; Wed, 29 Apr 2015 22:05:26 +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 U_2AXO1bunvK; Wed, 29 Apr 2015 22:05:25 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.18.22]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CA9D1BDCA; Wed, 29 Apr 2015 22:05:25 +0100 (IST) Message-ID: <55414795.3030606@cs.tcd.ie> Date: Wed, 29 Apr 2015 22:05:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Benjamin Kaduk References: <553F9DDB.4050401@cs.tcd.ie> <699427215.7347807.1430236125356.JavaMail.yahoo@mail.yahoo.com> <553FB99F.5070609@cs.tcd.ie> In-Reply-To: OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 21:05:31 -0000 On 29/04/15 20:43, Benjamin Kaduk wrote: > The server fully validates the client response before generating a server > response; this will necessarily include the validation steps listed in the > specification for the OAuth Access Token Type used. However, additional > validation steps may be needed, depending on the particular application > protocol making use of SASL. In particular, values included as kvpairs in > the client response (such as host and port) which correspond to values > known to the application by some other mechanism (such as an application > protocol data unit or pre-configured values) MUST be validated to match > between the initial client response and the the other source(s) of such > information. As a concrete example, when SASL is used over TLS, the > hostname can be available via the Server Name Indication TLS extension; > this hostname must be validated to match the value sent in the 'host' Yep, that'd work I think. S. From nobody Wed Apr 29 14:41:00 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE6861A6FED for ; Wed, 29 Apr 2015 14:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.759 X-Spam-Level: X-Spam-Status: No, score=-1.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dT1KMZbKyTUo for ; Wed, 29 Apr 2015 14:40:57 -0700 (PDT) Received: from nm37-vm8.bullet.mail.ne1.yahoo.com (nm37-vm8.bullet.mail.ne1.yahoo.com [98.138.229.136]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9406E1A8725 for ; Wed, 29 Apr 2015 14:40:57 -0700 (PDT) Received: from [127.0.0.1] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 21:40:57 -0000 Received: from [98.138.100.116] by nm37.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 21:38:12 -0000 Received: from [98.139.170.182] by tm107.bullet.mail.ne1.yahoo.com with NNFMP; 29 Apr 2015 21:38:12 -0000 Received: from [98.139.215.254] by tm25.bullet.mail.bf1.yahoo.com with NNFMP; 29 Apr 2015 21:38:12 -0000 Received: from [127.0.0.1] by omp1067.mail.bf1.yahoo.com with NNFMP; 29 Apr 2015 21:38:12 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 134750.94597.bm@omp1067.mail.bf1.yahoo.com Received: (qmail 25591 invoked by uid 60001); 29 Apr 2015 21:38:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1430343492; bh=0RkT6QtPWmx3SHl7+86iLsdBdrmWjCH8PQbx15CJ0ws=; h=Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tV5B+SJlHgGBTnWL7khuIoCFZnNnMRmlW+OPrH2Xf4OvukrB0Y0VhAZxpaNgXYX/BU9ai5cOkUw29cAAT348eqcSSLi+jP86+6TDQbPuIoRGpJYZnpNxUkXSObiX4HahUb2wh4J2kF4AXOc2Yera8CpfGE6wZbpvG7F0rHF+1Ns= X-YMail-OSG: GLe132gVM1l5NsVxjQFNP7ZStvgVzF3XykHXknX_5KI565L Mq.nle.lWxkGYiRmcUV3CXnpaKODa7RjO8BtC8nkaoNgbP9fsd1oGHEaJXV. YU5tGJHX_ewUY0RU7DZfGMumjfbMzTMRCY6CcMOgJAXRq7su2gGuektO0UBM yCexxEnGtklPK1bj0ZFocWaD0fmk49K0X6rMlylL081qk3k3kt_ygqlFtHKv wRxt3cuwhTU1hb6whUfGUZ0WVwOofaqRqRTsYTaM2fldfDOJFcNhwmqdXtzd pCSmzbxK_uwRDjn_UXRLAFykG.5AFAFs9vrRfuZZrcAjumn8jAXStOLNeKBt uP4VsaGnVcwXJVvbssN9PwCAZYKCGXipvDdwtIDCWhKAgkw6Y5aa0KvdjDVQ mNzNLia0nVN0jopEgJjqe50XrpvTVb8s8BRVkHpomldTWCZjK8oKcRNgK3Mp djcHg6aqDfxMup4jeutSm__ilfTBHHR1q3rRKYLMqn_eCoVLbaooZvHlGFBe HFg_H927dYn2p76qDvR6lRELo.L.IeUUjiUhLWRFhKdi.nQzHiyDhSFWPM4A sq1A9E4cSBIICCJWFQ6lpEg-- Received: from [167.220.25.190] by web142801.mail.bf1.yahoo.com via HTTP; Wed, 29 Apr 2015 14:38:11 PDT X-Rocket-MIMEInfo: 002.001, RXZlcnl0aGluZyB1cCB0byB0aGUgY29uY3JldGUgZXhhbXBsZSB3b3JrcyBmb3IgbWUuIMKgVGhlIGV4YW1wbGUgaXMgdmFwb3J3YXJlLCBJJ2QgcmF0aGVyIHVzZSBhIGNvbmNyZXRlIG9uZSBvciBsZWF2ZSBpdCBvdXQuCgpTZW50IGZyb20gWWFob28gTWFpbCBvbiBBbmRyb2lkCgpGcm9tOiJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPgpEYXRlOldlZCwgQXByIDI5LCAyMDE1IGF0IDE0OjA1ClN1YmplY3Q6UmU6IFtraXR0ZW5dIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWsBMAEBAQE- X-Mailer: YahooMailAndroidMobile/4.8.10 YahooMailWebService/0.8.203.740 Message-ID: <1430343491.78016.YahooMailAndroidMobile@web142801.mail.bf1.yahoo.com> Date: Wed, 29 Apr 2015 14:38:11 -0700 From: Bill Mills To: Stephen Farrell , Benjamin Kaduk In-Reply-To: <55414795.3030606@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="469468616-1937866873-1430343491=:78016" Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2015 21:40:59 -0000 --469468616-1937866873-1430343491=:78016 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Everything up to the concrete example works for me. =A0The example is vapor= ware, I'd rather use a concrete one or leave it out.=0A=0ASent from Yahoo M= ail on Android=0A=0AFrom:"Stephen Farrell" =0ADa= te:Wed, Apr 29, 2015 at 14:05=0ASubject:Re: [kitten] AD review of draft-iet= f-kitten-sasl-oauth-21=0A=0A=0A=0AOn 29/04/15 20:43, Benjamin Kaduk wrote:= =0A> The server fully validates the client response before generating a ser= ver=0A> response; this will necessarily include the validation steps listed= in the=0A> specification for the OAuth Access Token Type used.=A0 However,= additional=0A> validation steps may be needed, depending on the particular= application=0A> protocol making use of SASL.=A0 In particular, values incl= uded as kvpairs in=0A> the client response (such as host and port) which co= rrespond to values=0A> known to the application by some other mechanism (su= ch as an application=0A> protocol data unit or pre-configured values) MUST = be validated to match=0A> between the initial client response and the the o= ther source(s) of such=0A> information.=A0 As a concrete example, when SASL= is used over TLS, the=0A> hostname can be available via the Server Name In= dication TLS extension;=0A> this hostname must be validated to match the va= lue sent in the 'host'=0A=0AYep, that'd work I think.=0A=0A=0A=0AS.=0A=0A --469468616-1937866873-1430343491=:78016 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <= /tr>
Everything up to the concrete example works for me.  The example i= s vaporware, I'd rather use a concrete one or leave it out.

Sent from Yah= oo Mail on Android

From:"Stephen Farrell" <stephen.f= arrell@cs.tcd.ie>
Date:Wed, Apr 29, 2015 at 14:05
Subjec= t:Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21



On 29/04/15 20:43, Benjamin Kaduk wrote:
> The server fully validates the client response before ge= nerating a server
> response; this will necessarily include the validation= steps listed in the
> specification for the OAuth Acc= ess Token Type used.  However, additional
> valid= ation steps may be needed, depending on the particular application
> protocol making use of SASL.  In particular, values inc= luded as kvpairs in
> the client response (such as hos= t and port) which correspond to values
> known to the = application by some other mechanism (such as an application
> protocol data unit or pre-configured values) MUST be validated to m= atch
> between the initial client response and the the= other source(s) of such
> information.  As a con= crete example, when SASL is used over TLS, the
> hostn= ame can be available via the Server Name Indication TLS extension;
> this hostname must be validated to match the value sent in the 'host'

Yep, that'd work I think.


S.
--469468616-1937866873-1430343491=:78016-- From nobody Thu Apr 30 06:49:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC051B2A80 for ; Thu, 30 Apr 2015 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.011 X-Spam-Level: X-Spam-Status: No, score=-4.011 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGaH3da_Ktvi for ; Thu, 30 Apr 2015 06:49:56 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F1891B2A72 for ; Thu, 30 Apr 2015 06:49:55 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3UDnpWv021590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 30 Apr 2015 09:49:52 -0400 Received: from vpn-58-66.rdu2.redhat.com (vpn-58-66.rdu2.redhat.com [10.10.58.66]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3UDnomb008308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Apr 2015 09:49:51 -0400 Message-ID: <1430401789.5004.21.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Thu, 30 Apr 2015 09:49:49 -0400 In-Reply-To: <20150429161716.GH6026@localhost> References: <1430138754.2682.10.camel@redhat.com> <20150429161716.GH6026@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 13:49:58 -0000 Thanks for your feedback! On Wed, 2015-04-29 at 11:17 -0500, Nico Williams wrote: > On Mon, Apr 27, 2015 at 08:45:54AM -0400, Nathaniel McCallum wrote: > > I have finally finished the first edition of SPAKE Preauth. You can > > read it at this link: > > http://www.ietf.org/id/draft-mccallum-kitten-krb-spake-preauth > > -00.txt > > I'm in favor of the WG adopting this as a WG work item. > > I have some comments: > > - Kerberos doesn't really depend on synchronization of client clocks > for any of the KDC exchanges (AS, TGS): because they are stateless > and retriable, and the client learns the KDC's time in KRB-ERROR > PDUs. > > Pre-auth methods that don't depend on the client's clock are > mostly > an optimization. They are less of an optimization when failures > count towards locking a principal, but still an optimization > (since > one can account for clock skew by adding one to N-strikes-you're- > locked policies). As I stated in the draft: "where a timestamp is used, time synchronization between the client and KDC becomes a point of fragility." I think your paragraph here proves this point. Where synchronization is off, extra messages are sent. I think this qualifies as fragility. > Time synchronization across services in a realm is not something > that > is being fixed here either. Agreed. > IMO the time sync aspects of this are a bit overdone :) Maybe. I'll see if I can come up with wording you like better. I still think it is worth mentioning however. > - Section 1.1 is a bit weak. I don't think it's even necessary to > explain PAKE in terms of DH key agreement either. > > The properties of a PAKE are: > > - provides authenticated key agreement with both parties > contributing entropy to the shared secret; > > (And each exchange yields a different shared secret.) > > - is resistant to off-line dictionary attacks by eavesdroppers, > even > for small, simple passwordsj > > - "servers" store password equivalents; > > (In an augmented PAKE the server stores a verifier, but you're > not > proposing the use of an augmented PAKE.) > > - users "store" passwords. The intent of this section is to explain PAKE to those unfamiliar with it. If such is not needed in this document, I can remove it. > - Section 1.2, the claim about why FAST is difficult to deploy > requires > more evidence, and I believe it's wrong. The problem with FAST is > that it's difficult to make it a requirement for PA-ENC-TIMESTAMP > because FAST is not universally available yet -- the tragedy of > legacy forever. Sure, one has to deploy trust anchors, but then > again, one doesn't have to (leap of faith), and one can (for > machines > that have "joined" a realm or hierarchy of realms). Well, that is not Red Hat's experience. We have FAST everywhere, but we have people who don't want us to configure their client. This is most especially true in open communities like Fedora where we are working with volunteers. In these cases we have two options: 1. Use the existing system trust anchor w/ anonymous pkinit. This has all the problems that web developers are already trying to solve. For instance, if we trusted Verisign, someone could setup efdoraproject.org and configure the KDC for OTP. Anyone who did "kinit user@efdoraproject.org" by mistake would leak both the first and second factor to a completely trusted but malicious KDC. 2. Ask volunteers to trust our KDC cert explicitly. Then have them do a manual anonymous pkinit. Then have them use this ccache for enabling FAST. This is error prone and requires manual configuration. It is a no go. In contrast, PAKE allows a completely configless usage with no third -party trust and no leap of faith. Perhaps I have simply not captured this concern well in the draft. But it is most definitely more than "we don't have FAST everywhere." > Either elaborate this claim, or leave it at "it's difficult to > deploy". This claim just isn't all that important to this work: > after all, the key is the ability to combine a PAKE and a second > factor in a way that leaks no information about which factor was > incorrect when either (or both) were. FAST doesn't help with > that. > Even more interesting properties can be dreamed up that FAST > simply > can't help with either. > > On the other hand, FAST is still relevant: for providing > confidentiality protection of the client's principal name. Nowhere did I claim that PAKE obsoletes FAST. I said: "In the past, this problem (2FA) has been mitigated by FAST which uses a secondary trust relationship to create a secure encryption channel within which pre-authentication data can be sent. However, the requirement for a secondary trust relationship has proven to be cumbersome to deploy and often introduces third parties into the trust chain (such as certificate authorities)." Both of these statements are true and represent true complexities of FAST that do not exist with PAKE. > There's just no need to justify this or any other pre-auth method > based on FAST's real or perceived failure. I do think this document needs to justify why we just shouldn't use FAST like how RFC 6560 does. This draft represents a departure from the recently established precedent of second factors. The reason why this departure is necessary is because of the above reasons. > Indeed, all new pre-auth methods might well (will!) suffer from > some > of the same barriers to adoption that I think FAST suffers from, > and > then what? Should we stop designing new pre-auth methods? No. I'm not addressing all pre-auth types. I'm addressing why we should depart from recent precedent in RFC 6560. > Controversial claims that are not core to the document should just > go. I agree. I just don't think these claims are controversial. > That's as far as I got reading the I-D so far. I've reviewed the > design > before and I approve, and I'll complete my review of the I-D at some > point. Thanks! I look forward to your feedback! Nathaniel From nobody Thu Apr 30 07:39:54 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9A21B2C15 for ; Thu, 30 Apr 2015 07:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aa_-Cg-0vNKa for ; Thu, 30 Apr 2015 07:39:52 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDEDD1B2C12 for ; Thu, 30 Apr 2015 07:39:51 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-58-55423eb6f33a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id F2.88.03355.6BE32455; Thu, 30 Apr 2015 10:39:50 -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 t3UEdnxl025255; Thu, 30 Apr 2015 10:39: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 t3UEdlPD003627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Apr 2015 10:39:49 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t3UEdlRM027823; Thu, 30 Apr 2015 10:39:47 -0400 (EDT) Date: Thu, 30 Apr 2015 10:39:47 -0400 (EDT) From: Benjamin Kaduk To: Bill Mills In-Reply-To: <1430343491.78016.YahooMailAndroidMobile@web142801.mail.bf1.yahoo.com> Message-ID: References: <1430343491.78016.YahooMailAndroidMobile@web142801.mail.bf1.yahoo.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1220371129-1430404787=:22210" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IRYrdT191m5xRqsHCussXRzatYLKbvvcZu 8a3rOrMDs8fa7qtsHkuW/GTymDXrMFMAcxSXTUpqTmZZapG+XQJXxqw7LYwF13kq2l/tZW9g XMfVxcjJISFgIrHw/kx2CFtM4sK99WxdjFwcQgKLmST67+6GcjYySjReu8sM4RxikpgwYSVU poFRYvPRXWwg/SwC2hKvtn5gAbHZBFQkZr7ZCBTn4BARUJdo/u4NYjILxErseZYIUiEs4CRx fc41JhCbUyBY4vfXaawgNq+Ao8S0e3cYQWwhgSCJrY/vgsVFBXQkVu+fwgJRIyhxcuYTMJtZ IFBi6d/NbBMYBWchSc1CkoKwdSRWfrrCCGFrS9y/2ca2gJFlFaNsSm6Vbm5iZk5xarJucXJi Xl5qka6xXm5miV5qSukmRlCwc0ry7WD8elDpEKMAB6MSD++HdsdQIdbEsuLK3EOMkhxMSqK8 SrZOoUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeD8bAeV4UxIrq1KL8mFS0hwsSuK8m37whQgJ pCeWpGanphakFsFkZTg4lCR4d4AMFSxKTU+tSMvMKUFIM3FwggznARq+F6SGt7ggMbc4Mx0i f4pRUUqcdwVIQgAkkVGaB9cLS0avGMWBXhHmbQKp4gEmMrjuV0CDmYAGn7/lADK4JBEhJdXA uMk5wmUC+66TJ0r2/v/q8sb+eu1k/vQtc7ZMDT5x4fuhwt2K53rXeZml90peWqksuTG9Qs6D dW6DmaHOeckO/5b0hqJTx8q3FdcIifd9Kjyx/enc6QtT/Fo3zVIUUH27OvDK99d+fL0tNell Gv1lKToaEgek3tU6/Nm9XOFq+9WGSMV9+rHaSizFGYmGWsxFxYkAYtxc9SEDAAA= Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 14:39:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1220371129-1430404787=:22210 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 29 Apr 2015, Bill Mills wrote: > Everything up to the concrete example works for me. =A0The example is > vaporware, I'd rather use a concrete one or leave it out. I think the SNI example is a concrete example, in that it is very clear which values are to be compared. The fact that it is not a comparison which is performed by any extant software is a different issue. To continue along those lines, we frequently publish specifications that have not been (fully) implemented; I see our duty as to publish documents that say what should be done for correct and secure (inter)operation. I recognize that not all checks are always implemeted everywhere, but that does not free us of our obligation to write documents containing all the security checks that we believe are relevant. So, I believe that this text is useful and correct, and do not see merit in the objection raised thus far. However, I am not particularly tied to this particular example, and if you still wish to replace it with a different example (such as the one Stephen mentioned off-list, of an IMAP server configured only to serve example.com that should reject client response claiming to be for example.net), I can accept that for the goal of moving the document forward. -Ben ---559023410-1220371129-1430404787=:22210-- From nobody Thu Apr 30 08:50:17 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45C831B2CEA for ; Thu, 30 Apr 2015 08:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.109 X-Spam-Level: X-Spam-Status: No, score=-0.109 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XF2R-v7gJY-1 for ; Thu, 30 Apr 2015 08:50:13 -0700 (PDT) Received: from nm36-vm2.bullet.mail.bf1.yahoo.com (nm36-vm2.bullet.mail.bf1.yahoo.com [72.30.238.138]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F26A21B2CFA for ; Thu, 30 Apr 2015 08:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430409011; bh=cUoOGfpk7l2TDYyuntDwDHYJoV+ZrQLNcFqgkEHQ/qs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=Uh2vj5IZPfbS146Av+/KEbZDfVGZc643HUvfYSkHLyeWtw4RXTIvUxsO0i4WRMrpZ3Jj165qPfqsc34+3eqN79PgDho6IHxyCfi5bOVuAQqGjyPsM1hu21cEuy6//gUZmDHDyMIOwnYH4BuJq1ISCqRtIzZfjBgQu6F2LfBMOgZbRBrC6PExrMjp5PW/AxxITVR5cDE2XhzPfl8LcSzSG/xXioOJXQRatkv7PK/IBmNRuCt68mLL8VLFBqH6ET9SAKhS9sF/mQ67SpB8mNHLkrZVrOdYDM8unBJvfVYb/4UR8aAtlixzUVev6J0qCE+b6zw+ZwLC+evTpTBSs3sEew== Received: from [66.196.81.173] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 30 Apr 2015 15:50:11 -0000 Received: from [98.139.215.229] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 30 Apr 2015 15:50:11 -0000 Received: from [127.0.0.1] by omp1069.mail.bf1.yahoo.com with NNFMP; 30 Apr 2015 15:50:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 145410.5219.bm@omp1069.mail.bf1.yahoo.com X-YMail-OSG: LjMVFbwVM1m3ku92NtwYIgOVyN3yI5oASPu0x02Htys7Z42kg10NSqdiJ3gPw9d BXvdU95dCuTy5ETUfSK_x3ZbBGKC6k1B7NO2IkT0PhcoCCjkC8.tcsMB6zOrYnzPRn4z.kt2hhc4 MHqSEziCZhN1MsqcJOmrxfsbO8La65D2wbtvOC8_L5LgMwYo6kUmJpZ2GUJIsmm6S9kRWFiunRDq ttGiPB5KP.frx3fd56W5xattpKwxLxZLQ6pctGWCbqd3wassbl6BWC3TirYKnLL89WBwTY7KaHta 7yhdRDdfGHM_I26cKuQ7yGK3wnwlDG34TNtfR7YiEu4LIuPL3QVfznt8.IA0jSDIgA0K26tQiZGT w7__5aG22h7GbsiFHH9ivYrySJVgBRtoUd0o9u_6Th_ECux717Eg7ukPkC.p89MYDah9BXwLLI5D JmI2viyq7C8u5GYzn_UMpFlCi93Vtohbw71UVxdkWh10_OUH.KkudkgIdJNuSvL4gBamV.MkzqP7 iyC1SEw-- Received: by 66.196.81.106; Thu, 30 Apr 2015 15:50:10 +0000 Date: Thu, 30 Apr 2015 15:50:09 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk Message-ID: <774960042.1674381.1430409009812.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1674380_206468600.1430409009807" Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 15:50:14 -0000 ------=_Part_1674380_206468600.1430409009807 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I prefer the IMAP example because it ties in to the rest of the doc cleanly= . =C2=A0I'll update it that way and get copy out today. =C2=A0 On Thursday, April 30, 2015 7:39 AM, Benjamin Kaduk wr= ote: =20 On Wed, 29 Apr 2015, Bill Mills wrote: > Everything up to the concrete example works for me. =C2=A0The example is > vaporware, I'd rather use a concrete one or leave it out. I think the SNI example is a concrete example, in that it is very clear which values are to be compared.=C2=A0 The fact that it is not a comparison which is performed by any extant software is a different issue. To continue along those lines, we frequently publish specifications that have not been (fully) implemented; I see our duty as to publish documents that say what should be done for correct and secure (inter)operation.=C2=A0= I recognize that not all checks are always implemeted everywhere, but that does not free us of our obligation to write documents containing all the security checks that we believe are relevant.=C2=A0 So, I believe that this text is useful and correct, and do not see merit in the objection raised thus far. However, I am not particularly tied to this particular example, and if you still wish to replace it with a different example (such as the one Stephen mentioned off-list, of an IMAP server configured only to serve example.com that should reject client response claiming to be for example.net), I can accept that for the goal of moving the document forward. -Ben ------=_Part_1674380_206468600.1430409009807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I p= refer the IMAP example because it ties in to the rest of the doc cleanly. &= nbsp;I'll update it that way and get copy out today.  



On Thursday, April 30, 2015 7:39 AM, Benjamin Kaduk <kaduk@= MIT.EDU> wrote:


On Wed, 29 Apr 2015, Bill Mills wrote:

> Everything up to the concrete example works for me.  The exa= mple is
> vaporware, I'd rather use a concrete one or = leave it out.

I think the SNI example = is a concrete example, in that it is very clear
which val= ues are to be compared.  The fact that it is not a comparison
which is performed by any extant software is a different issue.
To continue along those lines, we frequ= ently publish specifications that
have not been (fully) i= mplemented; I see our duty as to publish documents
that s= ay what should be done for correct and secure (inter)operation.  I
recognize that not all checks are always implemeted everywhe= re, but that
does not free us of our obligation to write = documents containing all the
security checks that we beli= eve are relevant.  So, I believe that this
text is u= seful and correct, and do not see merit in the objection raised
thus far.

However, I am not par= ticularly tied to this particular example, and if you
sti= ll wish to replace it with a different example (such as the one Stephen
mentioned off-list, of an IMAP server configured only to ser= ve example.com
that should reject client response claimin= g to be for example.net), I can
accept that for the goal = of moving the document forward.


-Ben


<= /div>
------=_Part_1674380_206468600.1430409009807-- From nobody Thu Apr 30 08:55:57 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 463371B2D39 for ; Thu, 30 Apr 2015 08:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPM7RF_FtEDh for ; Thu, 30 Apr 2015 08:55:54 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E05C1B2D34 for ; Thu, 30 Apr 2015 08:55:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 058A5BE53; Thu, 30 Apr 2015 16:55:53 +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 6Q_ZjNdkbm-O; Thu, 30 Apr 2015 16:55:52 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.30.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A033ABE59; Thu, 30 Apr 2015 16:55:51 +0100 (IST) Message-ID: <55425087.5050407@cs.tcd.ie> Date: Thu, 30 Apr 2015 16:55:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Bill Mills , Benjamin Kaduk References: <774960042.1674381.1430409009812.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <774960042.1674381.1430409009812.JavaMail.yahoo@mail.yahoo.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 15:55:55 -0000 On 30/04/15 16:50, Bill Mills wrote: > I prefer the IMAP example because it ties in to the rest of the doc cleanly. I'll update it that way and get copy out today. Great. I'll start the IETF LC as soon as I see that. (And in case anyone has an issue with that, they can of course raise such as a LC comment and we'll deal with it.) Thanks, S. From nobody Thu Apr 30 09:08:03 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4BEA1B2D3A for ; Thu, 30 Apr 2015 09:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRwEOIZZ6-NQ for ; Thu, 30 Apr 2015 09:07:59 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C641A88C6 for ; Thu, 30 Apr 2015 09:07:59 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-de-5542535e08cb Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id FA.D2.03355.E5352455; Thu, 30 Apr 2015 12:07:58 -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 t3UG7vEO015498; Thu, 30 Apr 2015 12:07:58 -0400 Received: from [18.101.8.227] (vpn-18-101-8-227.mit.edu [18.101.8.227]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t3UG7sHg012783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2015 12:07:56 -0400 Message-ID: <5542535A.4090804@mit.edu> Date: Thu, 30 Apr 2015 12:07:54 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Nathaniel McCallum , Nico Williams References: <1430138754.2682.10.camel@redhat.com> <20150429161716.GH6026@localhost> <1430401789.5004.21.camel@redhat.com> In-Reply-To: <1430401789.5004.21.camel@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgleLIzCtJLcpLzFFi42IRYrdT0Y0Ldgo1ONOoZXF08yoWi1PXjrBZ zP06i9WB2ePlqXOMHkuW/GTyeL/vKlsAcxSXTUpqTmZZapG+XQJXRlfjccaC96oVj99dZW5g 3CDXxcjBISFgIrH6amwXIyeQKSZx4d56ti5GLg4hgcVMEr+2f2UDSQgJbGSUuHKrAiJxhEli 94IDLCAJXgE1iT9r/7OC2CwCqhLr3q1gBrHZBJQl1u/fClYjKhAmMe33c1aIekGJkzOfgMVF BOIkHly9xwZyBLOAusTO3WCtwkCtZ1+dYofYWymxY/lGJhCbU8BIYseJ22BjmAX0JHZc/wVl y0s0b53NPIFRcBaSDbOQlM1CUraAkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrrFebmaJXmpK 6SZGUEBzSvLtYPx6UOkQowAHoxIP74d2x1Ah1sSy4srcQ4ySHExKorw+gU6hQnxJ+SmVGYnF GfFFpTmpxYcYJTiYlUR4zRyBcrwpiZVVqUX5MClpDhYlcd5NP/hChATSE0tSs1NTC1KLYLIy HBxKEryZIEMFi1LTUyvSMnNKENJMHJwgw3mAhn8EqeEtLkjMLc5Mh8ifYlSUEuddBJIQAElk lObB9cISzitGcaBXhHnFgoCqeIDJCq77FdBgJqDB5285gAwuSURISTUwmpw82fVa4NP7+80b M9kfeWkuctxq0e1Ze2riJTnFl1O++n+RY40Rm8u6uON55EzHOwqfa168TJrxYJs9o+ePpu/t yyRXFTBVOtw+LrRPNGznnU9PJ+20KDp/q1nH6XNd0e/AJM4Y+6Lu3kVCZwuZMnhinU6uqrTy ME7O9bQ0sg7/31SeKdWvxFKckWioxVxUnAgA3NG1bBMDAAA= Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 16:08:02 -0000 On 04/30/2015 09:49 AM, Nathaniel McCallum wrote: >> Pre-auth methods that don't depend on the client's clock are >> mostly >> an optimization. They are less of an optimization when failures >> count towards locking a principal, but still an optimization >> (since >> one can account for clock skew by adding one to N-strikes-you're- >> locked policies). > > As I stated in the draft: "where a timestamp is used, time > synchronization between the client and KDC becomes a point of > fragility." I think your paragraph here proves this point. Where > synchronization is off, extra messages are sent. I think this > qualifies as fragility. Hm, I would give a more nuanced description: In a normal scenario, the client can get the KDC's timestamp from the PREAUTH_REQUIRED error. This timestamp is unauthenticated, so using it pretty much defeats any freshness value the timestamp might add to the preauthentication protocol. Since there isn't much freshness value in that timestamp (an active or passive attacker immediately gets a ciphertext with which to conduct offline password dictionary attacks, rendering password lockout moot), the MIT krb5 client does use that timestamp for encrypted preauth, and no extra messages are sent even if the client's clock is off. When authenticating with a keytab, a client might choose to use optimistic encrypted timestamp preauth to indicate which key the client possesses. (The MIT krb5 client does not do this, and the MIT krb5 KDC does not use the result for key selection. The latter should definitely change and the former might change.) If this is done, clock skew could force a second exchange. I also thought it was weird to lead with timestamp issues in the draft. I'm not sure I would mention them all in section 1. >> - Section 1.2, the claim about why FAST is difficult to deploy >> requires >> more evidence, and I believe it's wrong. The problem with FAST is >> that it's difficult to make it a requirement for PA-ENC-TIMESTAMP >> because FAST is not universally available yet -- the tragedy of >> legacy forever. Sure, one has to deploy trust anchors, but then >> again, one doesn't have to (leap of faith), and one can (for >> machines >> that have "joined" a realm or hierarchy of realms). This is partly true. Unauthenticated anonymous PKINIT plus encrypted challenge would carry some of the advantages of SPAKE preauth. But there are a lot of missing pieces for clients without keytabs: * The MIT krb5 client only supports KDC-authenticated anonymous PKINIT at this time. That could change, but it would carry risks by complicating the client security model (e.g. we need to make sure not to do FAST OTP over the resulting channel). * The get_in_tkt stack would need to be augmented to try anonymous PKINIT FAST automatically. At the moment the user (or other external machinery) has to manually obtain anonymous tickets and then use those as armor. * Administrators have to turn on anonymous PKINIT; it's not on by default. To turn it on you have to generate a KDC certificate, even if the client won't verify it. * Anonymous PKINIT in MIT krb5 is slow right now because it only supports integer DH. It also increases the attack surface on the KDC significantly, because PKINIT is so complicated. Other implementations are in different states (e.g. Heimdal has supported ECDH PKINIT for many years), but I think have most of the same those missing pieces and some additional ones as well. SPAKE preauth doesn't currently exist, which is also a big missing piece. The advantages are that: 1. It's just a preauth mech. It provides all of its advantages without requiring any difficult changes to other parts of the stack. (It does require some non-difficult changes discussed in RFC 6113: supplying a single ETYPE-INFO2 value, cookie support within the KDC preauth framework, and MORE_PREAUTH_DATA_NEEDED support in the client and KDC.) If it performs well enough, it could become available and used by default, supplanting encrypted timestamp. 2. It supports second factor features which aren't currently supported by any standard. > I do think this document needs to justify why we just shouldn't use > FAST like how RFC 6560 does. This draft represents a departure from > the recently established precedent of second factors. The reason why > this departure is necessary is because of the above reasons. Agreed. RFC 6113 states that "Mechanism designers should design FAST factors, instead of new pre-authentication mechanisms outside of FAST." We are going against that advice, and need to justify why. (Of course nothing prevents SPAKE from being used as a FAST factor, and it builds on RFC 6113 features.) From nobody Thu Apr 30 09:12:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F66E1A1BD7 for ; Thu, 30 Apr 2015 09:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdLzvwBD8E-H for ; Thu, 30 Apr 2015 09:12:57 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FE611A1B91 for ; Thu, 30 Apr 2015 09:12:57 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t3UGCuKk014125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 30 Apr 2015 12:12:56 -0400 Received: from vpn-58-66.rdu2.redhat.com (vpn-58-66.rdu2.redhat.com [10.10.58.66]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3UGCtRk027891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 30 Apr 2015 12:12:56 -0400 Message-ID: <1430410375.5004.23.camel@redhat.com> From: Nathaniel McCallum To: "kitten@ietf.org" Date: Thu, 30 Apr 2015 12:12:55 -0400 In-Reply-To: <1430138754.2682.10.camel@redhat.com> References: <1430138754.2682.10.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 16:12:58 -0000 On Mon, 2015-04-27 at 08:45 -0400, Nathaniel McCallum wrote: > I have finally finished the first edition of SPAKE Preauth. You can > read it at this link: > http://www.ietf.org/id/draft-mccallum-kitten-krb-spake-preauth-00.txt > > Comments welcome! After getting many great comments from everyone, I decided to setup a git repo to track my changes. Pull requests are welcome! https://github.com/npmccallum/ietf Nathaniel PS - This also include the other drafts I have recently published. Pull requests are welcome on these as well. From nobody Thu Apr 30 09:38:26 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F221AC3FC for ; Thu, 30 Apr 2015 09:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5dJQFCT8OQO for ; Thu, 30 Apr 2015 09:38:24 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 76C1A1AC3F8 for ; Thu, 30 Apr 2015 09:38:24 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id A5DA994079; Thu, 30 Apr 2015 09:38:23 -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=bVP4fQy5Pebs5s akDu+MCo/agHY=; b=r5VCOO8QFrqWUnyCFCmceqlbRrZqw2VwvBWwnF35kMTPTv 1P261PnY77ND3n7nktx1Ec62RG3ph4vy3sNkvoOFRXE73Ktf+Z0VRi0uQwQJRaHo TJbBr6p9JXac0H8hAuqJ2RAGVgGhEswSjvYpms3+ptG5vc8e0bLF89Eoi0Lfo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 52A189406D; Thu, 30 Apr 2015 09:38:21 -0700 (PDT) Date: Thu, 30 Apr 2015 11:38:19 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150430163818.GB6026@localhost> References: <1430138754.2682.10.camel@redhat.com> <20150429161716.GH6026@localhost> <1430401789.5004.21.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430401789.5004.21.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 16:38:25 -0000 On Thu, Apr 30, 2015 at 09:49:49AM -0400, Nathaniel McCallum wrote: > On Wed, 2015-04-29 at 11:17 -0500, Nico Williams wrote: > > As I stated in the draft: "where a timestamp is used, time > synchronization between the client and KDC becomes a point of > fragility." I think your paragraph here proves this point. Where > synchronization is off, extra messages are sent. I think this > qualifies as fragility. Extra round trips != fragility. Fragility -> sometimes clients fail. In this case the extra round trips are merely sub-optimal behavior that users mostly don't notice, and which is greatly amortized anyways. Clients can sometimes fail, but only if they don't implement clock skew correction based on the timestamps in KRB-ERROR PDUs. Implementation issues don't really count for this argument unless implementation is particularly difficult, which it's not. > > IMO the time sync aspects of this are a bit overdone :) > > Maybe. I'll see if I can come up with wording you like better. I still > think it is worth mentioning however. But it's not really a motivating factor for this work, is it? It's just icing on the cake. > > - Section 1.1 is a bit weak. I don't think it's even necessary to > > explain PAKE in terms of DH key agreement either. > > > > The properties of a PAKE are: > > > > - provides authenticated key agreement with both parties > > contributing entropy to the shared secret; > > > > (And each exchange yields a different shared secret.) > > > > - is resistant to off-line dictionary attacks by eavesdroppers, > > even > > for small, simple passwordsj > > > > - "servers" store password equivalents; > > > > (In an augmented PAKE the server stores a verifier, but you're > > not > > proposing the use of an augmented PAKE.) > > > > - users "store" passwords. > > The intent of this section is to explain PAKE to those unfamiliar with > it. If such is not needed in this document, I can remove it. To me it reads like an explanation by the author to a younger version of the author :) Especially given the focus on DH. One can construct key agreement protocols with PFS using RSA instead of DH, so the focus on DH strikes me as accidental rather than fundamental. (Heck, I think I can construct EKE-like ZKPPs out of RSA as well.) I'd rather that the properties of a PAKE be listed and references to DH be left out in this section. > > - Section 1.2, the claim about why FAST is difficult to deploy > > requires > > more evidence, and I believe it's wrong. The problem with FAST is > > that it's difficult to make it a requirement for PA-ENC-TIMESTAMP > > because FAST is not universally available yet -- the tragedy of > > legacy forever. Sure, one has to deploy trust anchors, but then > > again, one doesn't have to (leap of faith), and one can (for > > machines > > that have "joined" a realm or hierarchy of realms). > > Well, that is not Red Hat's experience. We have FAST everywhere, but > we have people who don't want us to configure their client. This is > most especially true in open communities like Fedora where we are > working with volunteers. > > In these cases we have two options: > [...] > In contrast, PAKE allows a completely configless usage with no third > -party trust and no leap of faith. OK, this is what I was looking for, thanks. Nico -- From nobody Thu Apr 30 09:53:01 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4C31B2E23 for ; Thu, 30 Apr 2015 09:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKEvwY_p6eu2 for ; Thu, 30 Apr 2015 09:52:58 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A500A1B2E0A for ; Thu, 30 Apr 2015 09:52:58 -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 t3UGqtCA026949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 30 Apr 2015 12:52:55 -0400 Received: from vpn-58-66.rdu2.redhat.com (vpn-58-66.rdu2.redhat.com [10.10.58.66]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3UGqrai008772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Apr 2015 12:52:54 -0400 Message-ID: <1430412773.5004.26.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Thu, 30 Apr 2015 12:52:53 -0400 In-Reply-To: <20150430163818.GB6026@localhost> References: <1430138754.2682.10.camel@redhat.com> <20150429161716.GH6026@localhost> <1430401789.5004.21.camel@redhat.com> <20150430163818.GB6026@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 16:53:00 -0000 On Thu, 2015-04-30 at 11:38 -0500, Nico Williams wrote: > On Thu, Apr 30, 2015 at 09:49:49AM -0400, Nathaniel McCallum wrote: > > On Wed, 2015-04-29 at 11:17 -0500, Nico Williams wrote: > > > > As I stated in the draft: "where a timestamp is used, time > > synchronization between the client and KDC becomes a point of > > fragility." I think your paragraph here proves this point. Where > > synchronization is off, extra messages are sent. I think this > > qualifies as fragility. > > Extra round trips != fragility. Fragility -> sometimes clients fail. > > In this case the extra round trips are merely sub-optimal behavior > that > users mostly don't notice, and which is greatly amortized anyways. > > Clients can sometimes fail, but only if they don't implement clock > skew > correction based on the timestamps in KRB-ERROR PDUs. Implementation > issues don't really count for this argument unless implementation is > particularly difficult, which it's not. > > > > IMO the time sync aspects of this are a bit overdone :) > > > > Maybe. I'll see if I can come up with wording you like better. I > > still > > think it is worth mentioning however. > > But it's not really a motivating factor for this work, is it? It's > just > icing on the cake. Agreed. I'll de-emphasize it in the next edition. > > > - Section 1.1 is a bit weak. I don't think it's even necessary > > > to > > > explain PAKE in terms of DH key agreement either. > > > > > > The properties of a PAKE are: > > > > > > - provides authenticated key agreement with both parties > > > contributing entropy to the shared secret; > > > > > > (And each exchange yields a different shared secret.) > > > > > > - is resistant to off-line dictionary attacks by > > > eavesdroppers, > > > even > > > for small, simple passwordsj > > > > > > - "servers" store password equivalents; > > > > > > (In an augmented PAKE the server stores a verifier, but > > > you're > > > not > > > proposing the use of an augmented PAKE.) > > > > > > - users "store" passwords. > > > > The intent of this section is to explain PAKE to those unfamiliar > > with > > it. If such is not needed in this document, I can remove it. > > To me it reads like an explanation by the author to a younger > version of > the author :) Especially given the focus on DH. One can construct > key > agreement protocols with PFS using RSA instead of DH, so the focus > on DH > strikes me as accidental rather than fundamental. (Heck, I think I > can > construct EKE-like ZKPPs out of RSA as well.) > > I'd rather that the properties of a PAKE be listed and references to > DH > be left out in this section. Fair enough. My concern was to provide a good introduction to PAKE for those unfamiliar with it. But if we aren't worried about such, then we can just list the properties and move on. > > > - Section 1.2, the claim about why FAST is difficult to deploy > > > requires > > > more evidence, and I believe it's wrong. The problem with > > > FAST is > > > that it's difficult to make it a requirement for PA-ENC > > > -TIMESTAMP > > > because FAST is not universally available yet -- the tragedy > > > of > > > legacy forever. Sure, one has to deploy trust anchors, but > > > then > > > again, one doesn't have to (leap of faith), and one can (for > > > machines > > > that have "joined" a realm or hierarchy of realms). > > > > Well, that is not Red Hat's experience. We have FAST everywhere, > > but > > we have people who don't want us to configure their client. This is > > most especially true in open communities like Fedora where we are > > working with volunteers. > > > > In these cases we have two options: > > [...] > > In contrast, PAKE allows a completely configless usage with no > > third > > -party trust and no leap of faith. > > OK, this is what I was looking for, thanks. Glad we're on the same page now. I look forward to your comments/patches. :) Nathaniel From nobody Thu Apr 30 10:52:02 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E546D1ACD09; Thu, 30 Apr 2015 10:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vqbk9JZAUE3s; Thu, 30 Apr 2015 10:51:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C5BD1ACAD4; Thu, 30 Apr 2015 10:51:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150430175159.15897.78084.idtracker@ietfa.amsl.com> Date: Thu, 30 Apr 2015 10:51:59 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-22.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 17:52:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-22.txt Pages : 24 Date : 2015-04-30 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: https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-22 A diff from the previous version is available at: https:https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-22 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 nobody Thu Apr 30 10:53:17 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44521ACD4D for ; Thu, 30 Apr 2015 10:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaoC9FGiawMw for ; Thu, 30 Apr 2015 10:53:15 -0700 (PDT) Received: from nm48-vm2.bullet.mail.bf1.yahoo.com (nm48-vm2.bullet.mail.bf1.yahoo.com [216.109.115.157]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCFA01ACD3C for ; Thu, 30 Apr 2015 10:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430416394; bh=SJoPJ9B7fqn0Dlet/9n9JF39IiWBJNHra7zVnN+4UPs=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=oo9tXORDvv0DsXGI1K1T89ZvPDPR3fh5vpgMIn0uNw3RpWrOqX5DkMgOkRCvPK+oytm8OFHBIGoJMj0OT9LIS31ZwLHo9+y/oG38f5pOrGas5f1fAuTS7qj6eYrxwFROyZEsAOYD53GxHG871o09bFvdWmlCV57C9v3XLZg4xI+G+LCRWtjmarneBhPbYHJkdPtzHmq4mN4ydQHqp7fufT+sLdZtYzU0buk5QhqZ49sm6WOl36yJZ0KU1XlVX0KDsQ1N/5U8sRQpuZKpaiabBdnddMr/T21V7iiZ1xVVEnW3hxCyeEClQnenq9GI/nWUKnYUXCc/Hir5mis0mx+rcg== Received: from [98.139.215.142] by nm48.bullet.mail.bf1.yahoo.com with NNFMP; 30 Apr 2015 17:53:14 -0000 Received: from [98.139.212.250] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 30 Apr 2015 17:53:14 -0000 Received: from [127.0.0.1] by omp1059.mail.bf1.yahoo.com with NNFMP; 30 Apr 2015 17:53:14 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 68200.455.bm@omp1059.mail.bf1.yahoo.com X-YMail-OSG: sq2qvEUVM1lGVKouYcJ0eX_8r8NUoCdSOC_TXuM63IAppdo2sw63B.OgbNgJpE. CJnpRuWfNMG4oR6IYB.ftMXrl5m54gyfrx8NgrFvnZKHb9AkEb_DfXjOuH6YJy3.La9A_jOhlKz1 pcp8wqRMHhtvcIL7CLqRSHPi5Vc4t9LRtiifUxgkUAkGn12Gn_r4XXM5yTXhC19grNVkU7oILwCs NLT.0.BU9uSA5_i70mE0QlhDNA5ISS3EzgpDj9fyztT2cw3pqjMTf48Gucp26E4jA0lUa9sXH58G 9iDUa7Gc1D9DdWBjEfW5qV70xsHFnmubk7AAMV0RmG6LI2ktHGf3yyRCFyp.2YiSWU4EqUTIHGar 2pkQYF_qvJUw89XFc_R8eztkYyCMN7Ji_Dvt3HQymEeyOrz32LOeq3ZNcELTfqjNb7i.2gGPbZSf 5ccE1ObSn52Rhb0Y44bsXVNyweiPMybJyEoacrBIncD0sUpnkQhRamv9eCwmoZOMc6xLo4YHE0ub toB90qKYhOWF0 Received: by 76.13.26.138; Thu, 30 Apr 2015 17:53:13 +0000 Date: Thu, 30 Apr 2015 17:53:13 +0000 (UTC) From: Bill Mills To: Stephen Farrell , Benjamin Kaduk Message-ID: <27436242.1719797.1430416393240.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <55425087.5050407@cs.tcd.ie> References: <55425087.5050407@cs.tcd.ie> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1719796_400274900.1430416393239" Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 17:53:15 -0000 ------=_Part_1719796_400274900.1430416393239 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable posted=20 On Thursday, April 30, 2015 8:55 AM, Stephen Farrell wrote: =20 =20 On 30/04/15 16:50, Bill Mills wrote: > I prefer the IMAP example because it ties in to the rest of the doc clean= ly.=C2=A0 I'll update it that way and get copy out today.=C2=A0=20 Great. I'll start the IETF LC as soon as I see that. (And in case anyone has an issue with that, they can of course raise such as a LC comment and we'll deal with it.) Thanks, S. ------=_Part_1719796_400274900.1430416393239 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
posted



On Thur= sday, April 30, 2015 8:55 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie= > wrote:



On 30/04/15 16:50, Bill Mills wrote:
> I prefer the IMAP example because it ties in to the res= t of the doc cleanly.  I'll update it that way and get copy out today.=  

Great. I'll start the IETF LC = as soon as I see that.
(And in case anyone has an issue w= ith that, they can
of course raise such as a LC comment a= nd we'll deal
with it.)

Thanks,

S.


------=_Part_1719796_400274900.1430416393239-- From nobody Thu Apr 30 10:57:19 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC80E1B2E6F for ; Thu, 30 Apr 2015 10:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-3pO8lA5DUK for ; Thu, 30 Apr 2015 10:57:16 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7F31B2E6D for ; Thu, 30 Apr 2015 10:57:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ACE99BE7C; Thu, 30 Apr 2015 18:57:14 +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 ldAX_D83VGBy; Thu, 30 Apr 2015 18:57:13 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.30.127]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A1E82BE77; Thu, 30 Apr 2015 18:57:13 +0100 (IST) Message-ID: <55426CF9.1060306@cs.tcd.ie> Date: Thu, 30 Apr 2015 18:57:13 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Bill Mills , Benjamin Kaduk References: <55425087.5050407@cs.tcd.ie> <27436242.1719797.1430416393240.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <27436242.1719797.1430416393240.JavaMail.yahoo@mail.yahoo.com> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-oauth-21 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 17:57:17 -0000 On 30/04/15 18:53, Bill Mills wrote: > posted ... and LC requested now. Cheers, S > > > On Thursday, April 30, 2015 8:55 AM, Stephen Farrell wrote: > > > > > On 30/04/15 16:50, Bill Mills wrote: >> I prefer the IMAP example because it ties in to the rest of the doc cleanly. I'll update it that way and get copy out today. > > Great. I'll start the IETF LC as soon as I see that. > (And in case anyone has an issue with that, they can > of course raise such as a LC comment and we'll deal > with it.) > > Thanks, > S. > > > > From nobody Thu Apr 30 11:31:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5B01B2EA9; Thu, 30 Apr 2015 11:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFDcJKExi4B5; Thu, 30 Apr 2015 11:31:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA141AC44E; Thu, 30 Apr 2015 11:31:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150430183147.6167.76957.idtracker@ietfa.amsl.com> Date: Thu, 30 Apr 2015 11:31:47 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] Last Call: (A set of SASL Mechanisms for OAuth) to Proposed Standard X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 18:31:57 -0000 The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'A set of SASL Mechanisms for OAuth' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-05-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ballot/ No IPR declarations have been submitted directly on this I-D. This defines a way to use the obsolete OAUTH1.0a mechanism as well an OAUTH2 mechanism. That is deliberate and reasonable. From nobody Thu Apr 30 13:49:30 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1101A007F for ; Thu, 30 Apr 2015 13:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdSTaTNQqJS6 for ; Thu, 30 Apr 2015 13:49:28 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0128.outbound.protection.outlook.com [207.46.100.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BCA21A0060 for ; Thu, 30 Apr 2015 13:49:28 -0700 (PDT) Received: from BL2PR03MB212.namprd03.prod.outlook.com (10.255.230.151) by BL2PR03MB211.namprd03.prod.outlook.com (10.255.230.146) with Microsoft SMTP Server (TLS) id 15.1.160.10; Thu, 30 Apr 2015 20:49:27 +0000 Received: from BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.239]) by BL2PR03MB212.namprd03.prod.outlook.com ([169.254.15.239]) with mapi id 15.01.0160.009; Thu, 30 Apr 2015 20:49:27 +0000 From: Michiko Short To: Benjamin Kaduk Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt Thread-Index: AQHQXZiJ07vPZrskK0qMbSTckV74FZ0an2mggAAi1zCAAAm3AIAH5dPggD8GlGCAAwGSAIABk5AA Date: Thu, 30 Apr 2015 20:49:26 +0000 Message-ID: References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> <550339DA.6000109@mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: MIT.EDU; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:ed31::5] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB211; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BL2PR03MB211; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB211; x-forefront-prvs: 056297E276 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(13464003)(93886004)(106116001)(92566002)(19580395003)(19580405001)(122556002)(230783001)(76176999)(2900100001)(2950100001)(46102003)(50986999)(40100003)(76576001)(2171001)(86612001)(5001920100001)(87936001)(2656002)(99286002)(86362001)(54356999)(62966003)(77156002)(74316001)(102836002)(33656002)(5001960100002)(110136002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB211; H:BL2PR03MB212.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Apr 2015 20:49:26.1317 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB211 Archived-At: Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2015 20:49:30 -0000 Valid point. So the RFC has the option where the client requests and the KDC provides on= request.=20 Two other options: 1. client sends an AS ping without explicit request 2. client sends PKInit AS-REQ which fails with KDC responding with the fres= hness token. My understanding is that 1 is a non-starter for non-Microsoft implementatio= ns since accounts are typically configured to not require pre authenticatio= n which means that the KDC would return a TGT.=20 2 would result in double the PKInit AS-REQs. I would prefer not to have thr= ow away crypto operations and my expectation is that over time this would b= e how all the PKInit exchanges would work as realms protect against this at= tack. Additionally, although I am not aware of any implementations, this wo= uld be a hard blocker for anyone wanting to have user approval for using a = certificate. Also, I am not sure if this would set off security software be= cause it would increase AS-REQ failures which might be considered an attack= . Anything looking for an increase in AS-REQ failures would need to be upda= ted to look for a corresponding freshness token or filter out PKInit (unles= s it was trying to look for this attack). When we created the AS ping for A= ES we got a tons of inquiries due the increase in authentication failures w= ith the deployment of Windows Vista. -----Original Message----- From: Benjamin Kaduk [mailto:kaduk@MIT.EDU]=20 Sent: Wednesday, April 29, 2015 1:25 PM To: Michiko Short Cc: Greg Hudson; Sam Hartman; kitten@ietf.org Subject: RE: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt On Mon, 27 Apr 2015, Michiko Short wrote: > Time for me to publish a new draft since this one is expiring. > > We found a use case in our implementation of PKInit where the client=20 > must request a freshness token or else they will get a principal not=20 > found error, so we need to keep the client behavior. I would prefer to=20 > not make that MS-PKCA Microsoft extension. It there any problem with=20 > keeping the client language as is? Also we would prefer to keep token=20 > generation limited to the public key case. Yes, we are hoping to=20 > expand the number of customers who use PKInit, but there will still be=20 > customers for a while who do not, have old servers, etc. I think I've lost track of which client behavior is in question -- is this = just the part where the client sends an empty PA_AS_FRESHNESS padata to ind= icate support of freshness tokens and prompt the KDC to send one (in contra= st to having the KDC always send a freshness token on all requests or all r= equests being offered PKINIT)? It does not seem like a bad scheme to me in the abstract, but it seems that= if we permit it, than all clients wishing to use freshness tokens must be = prepared to implement it, in case they encounter a KDC which does not proac= tively provide freshness tokens. That's probably fine, but we should consc= iously take that choice instead of just falling into it. -Ben