From nobody Sun Jul 3 02:57:14 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3024E12D08F for ; Sun, 3 Jul 2016 02:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 EFWh7PX56K89 for ; Sun, 3 Jul 2016 02:57:11 -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 D637B12B074 for ; Sun, 3 Jul 2016 02:57:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 689F8BE47; Sun, 3 Jul 2016 10:57:09 +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 8i1ToIZ6fdJw; Sun, 3 Jul 2016 10:57:07 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 30F66BE3F; Sun, 3 Jul 2016 10:57:07 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1467539827; bh=5TdbplPFE6kVC51r9n7lMdqaDNk2IZhDhe5vumIy0a8=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=PRI7A+gNk47/HC30PMXFqUSQ80LX+JAWlO4NGozK6zweTLtegp2hib66mq/pINyFf dmqdxD0chF1zSZvWvZMq86YxB1g7RYsz55mrylbYPET6tt4RtPzJ6VpzMG0gLvJnLh GwL+K3dJF60IOMEbhhuisRI8a7wTxLLTZfGMu14g= To: Jeffrey Altman , Luke Howard , Benjamin Kaduk References: <677848B0-17A4-47A6-93EB-F9939654DBAC@padl.com> <12304a67-7cd8-9010-7164-abfd0a47d0d4@secure-endpoints.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <5778E173.3020707@cs.tcd.ie> Date: Sun, 3 Jul 2016 10:57:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <12304a67-7cd8-9010-7164-abfd0a47d0d4@secure-endpoints.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040307060605070204020206" Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org Subject: Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 09:57:13 -0000 This is a cryptographically signed message in MIME format. --------------ms040307060605070204020206 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I nearly just started the IETF last call for this, but then noticed these emails;-) Please ignore any status change emails you may have seen. Chairs - please tell me when you want me to start IETF LC. I did my AD review of it, and modulo this discussion being resolved, I think it's ready to go ahead. Thanks, S. On 28/06/16 12:58, Jeffrey Altman wrote: > +1 >=20 > On 6/28/2016 3:21 AM, Luke Howard wrote: >> I reckon let's do it "properly" even if at the expense of redundant te= xt. >> >> Sent from my iPhone >> >>> On 28 Jun 2016, at 11:49, Benjamin Kaduk wrote: >>> >>> Thanks, Michael. >>> >>> If the WG does want to treat the PRF octet-string input as a SP800-10= 8 >>> context and use a zero-byte separator, it seems like the "quick-and-d= irty" >>> patch would be to just stick one in after "prf" and then there would = be >>> another (somewhat superfluous) one appended after the octet-string by= >>> KDF-HMAC-SHA2. That might be easier than essentially inlining the >>> definitino of KDF-HMAC-SHA2 for just the PRF calculation. >>> >>> -Ben >>> >>>> On Mon, 27 Jun 2016, Michael Jenkins wrote: >>>> >>>> Ben, >>>> >>>> we'll get started on these. >>>> >>>>> On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk wr= ote: >>>>> >>>>> Hi Michael et al, >>>>> >>>>> As I was preparing the shepherd writeup for this document, I notice= d some >>>>> things that do not block the progression of the document but do req= uire >>>>> changes, and one item that may require further WG input. Can you p= repare >>>>> a new version with the changes mentioned below? >>>>> >>>>> The one item which would potentially affect the actual protocol: at= the >>>>> end of Section 5, the pseudo-random function seems to be using a SP= 800-108 >>>>> KDF but omits the zero byte between label and context. I think it = would >>>>> be better to have the zero byte -- do you remember whether there wa= s a >>>>> reason to omit it? (Adding the zero byte would require re-rolling = some >>>>> test vectors, to be clear.) >>>>> >>>>> Additionally, all document authors will need to confirm compliance = with >>>>> BCPs 78 and 79 for this document, namely that there are no intellec= tual >>>>> property concerns with the document that are not already disclosed.= >>>>> >>>>> Please add a normative reference to RFC 2104 for HMAC, first mentio= ned at >>>>> the end of Section 1. >>>>> >>>>> In Section 3, it might aid clarity to mention that the 0x00000001 i= nput to >>>>> HMAC() is the 'i' parameter from SP800-108 [indicating that this is= the >>>>> first block of output, even though it is the only block of output a= s >>>>> well]. >>>>> >>>>> In Section 4, it might be worth re-mentioning "where PBKDF2 is the >>>>> function of that name from RFC 2898" after the algorithm block, sin= ce most >>>>> everything else used there also gets clarified. (It is already cit= ed at >>>>> the beginning of the section, in the overview paragraph.) >>>>> >>>>> The document should be consistent about using "cipher state" as one= word >>>>> or two (RFC 3961 prefers the two-word form). It also makes a rathe= r >>>>> sudden appearance at the beginning of Section 5 with no explanatory= >>>>> introduction; it might help the reader to instead start with "The R= FC 3961 >>>>> cipher state that maintains cryptographic state across different >>>>> encryption operations using the same key is used as the formal >>>>> initialization vector [...]" On the next page, "cipherstate" is def= ined as >>>>> "a 128-bit initialization vector derived from the ciphertext", whic= h is >>>>> potentially misleading, since it can't be both used as the IV for a= nd >>>>> derived from the same ciphertext! Probably it's better to say "der= ived >>>>> from a previous (if any) ciphertext using the same encryption key, = as >>>>> specified below". >>>>> >>>>> Still in Section 5, in the definition of the encryption function (w= ell, >>>>> computing the cipherstate, really), I'm of two minds whether it's w= orth >>>>> mentioning that the case of L < 128 is impossible because of the 12= 8-bit >>>>> confounder. >>>>> >>>>> In the decryption function, can you add a note to the right of "(C,= H) =3D >>>>> ciphertext" that "[H is the last h bits of the ciphertext]"? >>>>> >>>>> In the pseudo-random function, please replace "base-key" with "inpu= t-key", >>>>> since the key input to the PRF is not expected to be a kerberos pro= tocol >>>>> long-term base key. >>>>> >>>>> In Section 6, the "associated cryptosystem"s are supposed to be >>>>> "AES-128-CTS" or "AES-256-CTS", but those strings do not appear els= ewhere >>>>> in the document. While the meaning is pretty clear, it's probably = better >>>>> to just say "aes128-cts-hmac-sha256-128 or aes256-cts-hmac-sha384-1= 92 as >>>>> appropriate". This does duplicate the preceding text, but we do wa= nt to >>>>> explicitly list the "associated encryption algorithm" as listed in = the >>>>> Checksum Algorithm Profile of Section 4 of RFC 3961. >>>>> >>>>> In Section 8.1, the acronym "TGT" is used, the only instance in the= >>>>> document. It's also potentially misleading, since ticket-granting = tickets >>>>> are generally objects that are issued to client principals by the A= S. >>>>> I'd go with "Cross-realm krbtgt keys" instead. >>>>> >>>>> The test vectors for key derivation have a parenthetical "constant = =3D >>>>> 0x...", but the term "constant" does not appear elsewhere in the do= cument. >>>>> The hex values are the label input for the HMAC, so we should call = them >>>>> that. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Ben >>>> >>>> >>>> >>>> -- >>>> 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 >>>> 443-634-3951 >>> >>> _______________________________________________ >>> 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 >> >=20 >=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 --------------ms040307060605070204020206 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDMw OTU3MDdaMC8GCSqGSIb3DQEJBDEiBCB1Hm7BuSsBGJMxK3Oy2SdwXgV7ewFVAK5WSFiFyOg2 WDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBI1hxiAS6E3fvmUkYHXdmTE9Njeqks1CpNcxlH0K4VWuKVpuCOLRDD K7UnoCIqfLdQTkBLBCYTJxz0d3ZDNhmiZeRUNJtpfiydEbUKgMlvD4XfldYP/p+YnJb+ksnu ZDANofVe/nBV5F1jgTIPDjszsKxDEpITXav8vpURquu4V4tQOc/zhQsxt+QMh1QI4YYCDgR9 90VIzQMyB06MeytZ7rcrq8M4AucoW6OhoBgunusKLwrVi7eDsTIbC4xkNXzuFTLR3FxbxRBN 0rAkEy80w42ugRt72i4URZUWgXLsRnQ3w2v32eo99iOahs+9P5I41bJdXIpJNFGAWY/fGTqF AAAAAAAA --------------ms040307060605070204020206-- From nobody Tue Jul 5 11:00:45 2016 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 262B112B060; Tue, 5 Jul 2016 11:00:40 -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.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160705180040.22387.60767.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2016 11:00:40 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 18:00:40 -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 of the IETF. Title : AES Encryption with HMAC-SHA2 for Kerberos 5 Authors : Michael J. Jenkins Michael A. Peck Kelley W. Burgin Filename : draft-ietf-kitten-aes-cts-hmac-sha2-10.txt Pages : 17 Date : 2016-07-05 Abstract: This document specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-10 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 Tue Jul 5 12:55:10 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E14D12D50B for ; Tue, 5 Jul 2016 12:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 0B9X-EfiQ6hU for ; Tue, 5 Jul 2016 12:55:03 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 4A6A112D583 for ; Tue, 5 Jul 2016 12:55:03 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id l188so141602767lfe.2 for ; Tue, 05 Jul 2016 12:55:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=zs0diCQlMBWKUT0Qii7iux8jxAk6uGl0cBujvmqM+Dc=; b=rPad65A5G9aQSgp/18X2Yb/NinyJt2OJBxtp3TGJrfLuS5SF/UgdMUCezSwSFjklKq uDuY1Bsq6Yva2omae4xEshqLuW2gdLuHA+3XrIZDCLohrtIN6VIFW5cyvAS/IlHPwnRC sU+VGmE5atmlQUzIoKcRtBoxhOpPqLrbrcaB+YO1utWx+aKgZPMa6L96ZGoVEmIxgs8h IHixpr1rbs9ntxQet2hgbIy2zEVqLAxAjKf5GNmgEkTBGx5Vc4qV3IhZd8fspbEsd/6J vz1luOPW4f0AoyJiQpw1epmX5stfRTMtTjSWFqJlvKqnWgMa2P6461fCsu1GVfSRt0Zh d2KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=zs0diCQlMBWKUT0Qii7iux8jxAk6uGl0cBujvmqM+Dc=; b=HNchGKjTo+M/yCxpM6l6W9A5FQwuQleuhGLht8CGutNJIl9CVfBpENPnlHVGUkMJuD eV5aDKhRSpR6I2rq2Cf2IKJIIKjocjDSTfmXvL8LzuxAi3DNhLE31VbvkGv4HI7rSpv6 sucM7870fMJse8yTFJ0W+QcpF5Bhn1FuJeYovyDZoLVnBXSPT7unZzTvNLrT88uDIIOB ACDis8WzzsP6/QI708I6u0gEdnPz6WOax0w+5/wMw2A11Elhx2iaDMfpv3R6ubAc67k5 TaD2z2xRMzcjmCv0Uw8Ns6fhTa74SgCcPvdsOfjI4fpbuFytXX0B7o4IzVnVFqaPjAcO lzHg== X-Gm-Message-State: ALyK8tIxPBwreyu+vNmsxiVX9dGf+MXizPqlHM5Sjb7LBEVuCGJ5NkoqLMavf2Bxh44uHk/Cb35imodmL//WBg== X-Received: by 10.25.84.65 with SMTP id i62mr5562775lfb.88.1467748501126; Tue, 05 Jul 2016 12:55:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.141.132 with HTTP; Tue, 5 Jul 2016 12:55:00 -0700 (PDT) In-Reply-To: <20160705180040.22387.60767.idtracker@ietfa.amsl.com> References: <20160705180040.22387.60767.idtracker@ietfa.amsl.com> From: Michael Jenkins Date: Tue, 5 Jul 2016 15:55:00 -0400 Message-ID: To: kitten@ietf.org Content-Type: multipart/alternative; boundary=001a11411f280783bf0536e8d44e Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 19:55:08 -0000 --001a11411f280783bf0536e8d44e Content-Type: text/plain; charset=UTF-8 The new draft-ietf-kitten-aes-cts-hmac-sha2 includes changes for all of Ben's comments. As for the KDF, we looked at both simply inserting a 0x00 between the "prf" and the octet string (leaving the extra 0x00 before the length bits intact), and fixing the KDF so that the prf was computed the same way as any other KDF. So in the end we decided that the cleanest and least likely to confuse option was to fix the KDF definition in Section 3 by adding an optional context field. Mike J On Tue, Jul 5, 2016 at 2:00 PM, wrote: > > 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 of the IETF. > > Title : AES Encryption with HMAC-SHA2 for Kerberos 5 > Authors : Michael J. Jenkins > Michael A. Peck > Kelley W. Burgin > Filename : draft-ietf-kitten-aes-cts-hmac-sha2-10.txt > Pages : 17 > Date : 2016-07-05 > > Abstract: > This document specifies two encryption types and two corresponding > checksum types for Kerberos 5. The new types use AES in CTS mode > (CBC mode with ciphertext stealing) for confidentiality and HMAC with > a SHA-2 hash for integrity. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-10 > > > 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/ > > _______________________________________________ > 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 443-634-3951 --001a11411f280783bf0536e8d44e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The new draft-ietf-kitten-aes-cts-hmac-sha2 includes = changes for all of Ben's comments. As for the KDF, we looked at both si= mply inserting a 0x00 between the "prf" and the octet string (lea= ving the extra 0x00 before the length bits intact), and fixing the KDF so t= hat the prf was computed the same way as any other KDF. So in the end we de= cided that the cleanest and least likely to confuse option was to fix the K= DF definition in Section 3 by adding an optional context field.

Mike J

= On Tue, Jul 5, 2016 at 2:00 PM, <internet-drafts@ietf.org><= /span> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Common Authentication Technology Next Gene= ration of the IETF.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= AES Encryption with HMAC-SHA2 for Kerberos 5
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael J. Jenkins
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Michael A. Peck
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Kelley W. Burgin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-kitten-aes-cts-hmac-sha2-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 17
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2016-07-05

Abstract:
=C2=A0 =C2=A0This document specifies two encryption types and two correspon= ding
=C2=A0 =C2=A0checksum types for Kerberos 5.=C2=A0 The new types use AES in = CTS mode
=C2=A0 =C2=A0(CBC mode with ciphertext stealing) for confidentiality and HM= AC with
=C2=A0 =C2=A0a SHA-2 hash for integrity.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/do= c/draft-ietf-kitten-aes-cts-hmac-sha2/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-= ietf-kitten-aes-cts-hmac-sha2-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdi= ff?url2=3Ddraft-ietf-kitten-aes-cts-hmac-sha2-10


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
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@g= mail.com - to read everywhere
443-634-3951
--001a11411f280783bf0536e8d44e-- From nobody Tue Jul 5 15:23:20 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E5D12B02C for ; Tue, 5 Jul 2016 15:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.927 X-Spam-Level: X-Spam-Status: No, score=-15.927 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 B4ca1D679pxn for ; Tue, 5 Jul 2016 15:23:17 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC0912B022 for ; Tue, 5 Jul 2016 15:23:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8325; q=dns/txt; s=iport; t=1467757397; x=1468966997; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=WRayx6JQop0EkBq9g98VTYDMLjansKEX0B5BaWPpwJQ=; b=H5fQ9EyWd4OL06sLjlTeJIC6PNuo7lNBtp+Zy/19KEvzdK8paI79H+ji aXIxBaCENfwD8QjTX2IkYK8yf6xt+dhjuXgVNYVz76llP+xiKoHHk+Skc M/vvFyFlYrU1x/wyIygFZeRGpSfgOy4Dl+RfSyaZ7N271kYri8d5g61dX 8=; X-Files: signature.asc : 496 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgD0MnxX/5tdJa1ZA4M+VnwGrTKME?= =?us-ascii?q?IF3IoUsSgKBLzgUAQEBAQEBAWUnhEwBAQQBAQEbUQsFCwIBCA4KLiEGCyUCBAE?= =?us-ascii?q?NBQ6ICAMPCA63Jw2EMQEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4JBYgfCIJNgkOBb?= =?us-ascii?q?TEmgmWCLwWOBIpbMgIBgy6BbG6GLoIQgWqEVoMuhTyGV4FAh3IBHjaCCByBTG4?= =?us-ascii?q?Bh1R/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,315,1464652800"; d="asc'?scan'208";a="294060257" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2016 22:23:01 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u65MN1um010332 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jul 2016 22:23:01 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 17:23:00 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 17:23:00 -0500 From: "Matt Miller (mamille2)" To: Jeffrey Altman , Luke Howard Thread-Topic: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 Thread-Index: AQHR0CCUuSaQZ9bq5EeM2+5UxA2/DZ/9uwMAgAC3QQCAAFyWAIAATXSAgAe5xoCAA/UOgA== Date: Tue, 5 Jul 2016 22:23:00 +0000 Message-ID: References: <677848B0-17A4-47A6-93EB-F9939654DBAC@padl.com> <12304a67-7cd8-9010-7164-abfd0a47d0d4@secure-endpoints.com> <5778E173.3020707@cs.tcd.ie> In-Reply-To: <5778E173.3020707@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-pgp-agent: GPGMail x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.129.24.54] Content-Type: multipart/signed; boundary="Apple-Mail=_DD92C132-49D4-4CA7-A2C9-08C2C785D204"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: Cc: "kitten@ietf.org" , "draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org" Subject: Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 22:23:19 -0000 --Apple-Mail=_DD92C132-49D4-4CA7-A2C9-08C2C785D204 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello All, Thanks to Mike for submitting the update so quickly. It appears to me that -10 addresses all the concerns raised. Are there any objections to moving forward with IETF Last Call with this revision? For convenience, the latest revision can be found here: https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-10 Thanks, - Kitten Chairs > On Jul 3, 2016, at 03:57, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > I nearly just started the IETF last call for this, but then > noticed these emails;-) Please ignore any status change > emails you may have seen. >=20 > Chairs - please tell me when you want me to start IETF LC. >=20 > I did my AD review of it, and modulo this discussion being > resolved, I think it's ready to go ahead. >=20 > Thanks, > S. >=20 > On 28/06/16 12:58, Jeffrey Altman wrote: >> +1 >>=20 >> On 6/28/2016 3:21 AM, Luke Howard wrote: >>> I reckon let's do it "properly" even if at the expense of redundant = text. >>>=20 >>> Sent from my iPhone >>>=20 >>>> On 28 Jun 2016, at 11:49, Benjamin Kaduk wrote: >>>>=20 >>>> Thanks, Michael. >>>>=20 >>>> If the WG does want to treat the PRF octet-string input as a = SP800-108 >>>> context and use a zero-byte separator, it seems like the = "quick-and-dirty" >>>> patch would be to just stick one in after "prf" and then there = would be >>>> another (somewhat superfluous) one appended after the octet-string = by >>>> KDF-HMAC-SHA2. That might be easier than essentially inlining the >>>> definitino of KDF-HMAC-SHA2 for just the PRF calculation. >>>>=20 >>>> -Ben >>>>=20 >>>>> On Mon, 27 Jun 2016, Michael Jenkins wrote: >>>>>=20 >>>>> Ben, >>>>>=20 >>>>> we'll get started on these. >>>>>=20 >>>>>> On Sun, Jun 26, 2016 at 11:03 PM, Benjamin Kaduk = wrote: >>>>>>=20 >>>>>> Hi Michael et al, >>>>>>=20 >>>>>> As I was preparing the shepherd writeup for this document, I = noticed some >>>>>> things that do not block the progression of the document but do = require >>>>>> changes, and one item that may require further WG input. Can you = prepare >>>>>> a new version with the changes mentioned below? >>>>>>=20 >>>>>> The one item which would potentially affect the actual protocol: = at the >>>>>> end of Section 5, the pseudo-random function seems to be using a = SP800-108 >>>>>> KDF but omits the zero byte between label and context. I think = it would >>>>>> be better to have the zero byte -- do you remember whether there = was a >>>>>> reason to omit it? (Adding the zero byte would require = re-rolling some >>>>>> test vectors, to be clear.) >>>>>>=20 >>>>>> Additionally, all document authors will need to confirm = compliance with >>>>>> BCPs 78 and 79 for this document, namely that there are no = intellectual >>>>>> property concerns with the document that are not already = disclosed. >>>>>>=20 >>>>>> Please add a normative reference to RFC 2104 for HMAC, first = mentioned at >>>>>> the end of Section 1. >>>>>>=20 >>>>>> In Section 3, it might aid clarity to mention that the 0x00000001 = input to >>>>>> HMAC() is the 'i' parameter from SP800-108 [indicating that this = is the >>>>>> first block of output, even though it is the only block of output = as >>>>>> well]. >>>>>>=20 >>>>>> In Section 4, it might be worth re-mentioning "where PBKDF2 is = the >>>>>> function of that name from RFC 2898" after the algorithm block, = since most >>>>>> everything else used there also gets clarified. (It is already = cited at >>>>>> the beginning of the section, in the overview paragraph.) >>>>>>=20 >>>>>> The document should be consistent about using "cipher state" as = one word >>>>>> or two (RFC 3961 prefers the two-word form). It also makes a = rather >>>>>> sudden appearance at the beginning of Section 5 with no = explanatory >>>>>> introduction; it might help the reader to instead start with "The = RFC 3961 >>>>>> cipher state that maintains cryptographic state across different >>>>>> encryption operations using the same key is used as the formal >>>>>> initialization vector [...]" On the next page, "cipherstate" is = defined as >>>>>> "a 128-bit initialization vector derived from the ciphertext", = which is >>>>>> potentially misleading, since it can't be both used as the IV for = and >>>>>> derived from the same ciphertext! Probably it's better to say = "derived >>>>>> from a previous (if any) ciphertext using the same encryption = key, as >>>>>> specified below". >>>>>>=20 >>>>>> Still in Section 5, in the definition of the encryption function = (well, >>>>>> computing the cipherstate, really), I'm of two minds whether it's = worth >>>>>> mentioning that the case of L < 128 is impossible because of the = 128-bit >>>>>> confounder. >>>>>>=20 >>>>>> In the decryption function, can you add a note to the right of = "(C, H) =3D >>>>>> ciphertext" that "[H is the last h bits of the ciphertext]"? >>>>>>=20 >>>>>> In the pseudo-random function, please replace "base-key" with = "input-key", >>>>>> since the key input to the PRF is not expected to be a kerberos = protocol >>>>>> long-term base key. >>>>>>=20 >>>>>> In Section 6, the "associated cryptosystem"s are supposed to be >>>>>> "AES-128-CTS" or "AES-256-CTS", but those strings do not appear = elsewhere >>>>>> in the document. While the meaning is pretty clear, it's = probably better >>>>>> to just say "aes128-cts-hmac-sha256-128 or = aes256-cts-hmac-sha384-192 as >>>>>> appropriate". This does duplicate the preceding text, but we do = want to >>>>>> explicitly list the "associated encryption algorithm" as listed = in the >>>>>> Checksum Algorithm Profile of Section 4 of RFC 3961. >>>>>>=20 >>>>>> In Section 8.1, the acronym "TGT" is used, the only instance in = the >>>>>> document. It's also potentially misleading, since = ticket-granting tickets >>>>>> are generally objects that are issued to client principals by the = AS. >>>>>> I'd go with "Cross-realm krbtgt keys" instead. >>>>>>=20 >>>>>> The test vectors for key derivation have a parenthetical = "constant =3D >>>>>> 0x...", but the term "constant" does not appear elsewhere in the = document. >>>>>> The hex values are the label input for the HMAC, so we should = call them >>>>>> that. >>>>>>=20 >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Ben >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> 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 >>>>> 443-634-3951 >>>>=20 >>>> _______________________________________________ >>>> Kitten mailing list >>>> Kitten@ietf.org >>>> https://www.ietf.org/mailman/listinfo/kitten >>>=20 >>> _______________________________________________ >>> Kitten mailing list >>> Kitten@ietf.org >>> https://www.ietf.org/mailman/listinfo/kitten >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >>=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_DD92C132-49D4-4CA7-A2C9-08C2C785D204 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXfDNEAAoJEDWi+S0W7cO1dSwH/1x2rCJO1PkJ+EPbogdAkkGf qLlzc3aNVykIftLfHmsb6kAifAmYlRv+PuoA6WK4DPvXYkf2ZlfQMp6OTbozZvqn 3KbXsNVyN8hh9BSAOJnJ4t3nYQGZxT36NBXIO+80jiXPpiyBe/9Uz1EwKIkqcnM4 eTNJgqKTfZYpw3Rj9SLTXQ8413njAOtCwpaUo/vNBdt56jO2TpvoQVZ1l0RWoMjD XEcILrb+i7sQKvCZ17i9NIxJ5sYa5HJBFMkiuy9q23mPFS2mFcsTwKXQOjYVtfX1 6A7096kxrKkUX3/xdD4/VT6PBiGJAXQOmE1osAiiKLqeRoZcRAU0fllMBB0SHIM= =jB5X -----END PGP SIGNATURE----- --Apple-Mail=_DD92C132-49D4-4CA7-A2C9-08C2C785D204-- From nobody Tue Jul 5 16:56:00 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6DA12B00D for ; Tue, 5 Jul 2016 16:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.327 X-Spam-Level: X-Spam-Status: No, score=-3.327 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IJsBhd3Vig4N for ; Tue, 5 Jul 2016 16:55:56 -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 4D18212B02F for ; Tue, 5 Jul 2016 16:55:56 -0700 (PDT) Received: by us.padl.com with ESMTP id u65Ntp5B019749; Tue, 5 Jul 2016 19:55:53 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_2BE4811A-95C2-4A3D-A71C-8B56B237B657" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Luke Howard In-Reply-To: Date: Wed, 6 Jul 2016 09:55:50 +1000 Message-Id: <27A0CA43-3608-4CB0-88B6-F4B9F6021510@padl.com> References: <20160705180040.22387.60767.idtracker@ietfa.amsl.com> To: Michael Jenkins X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 23:55:58 -0000 --Apple-Mail=_2BE4811A-95C2-4A3D-A71C-8B56B237B657 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Updated aes-cts-hmac-sha2 branch of Heimdal. > On 6 Jul 2016, at 5:55 AM, Michael Jenkins = wrote: >=20 > The new draft-ietf-kitten-aes-cts-hmac-sha2 includes changes for all = of Ben's comments. As for the KDF, we looked at both simply inserting a = 0x00 between the "prf" and the octet string (leaving the extra 0x00 = before the length bits intact), and fixing the KDF so that the prf was = computed the same way as any other KDF. So in the end we decided that = the cleanest and least likely to confuse option was to fix the KDF = definition in Section 3 by adding an optional context field. >=20 > Mike J >=20 > On Tue, Jul 5, 2016 at 2:00 PM, > wrote: >=20 > 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 of the IETF. >=20 > Title : AES Encryption with HMAC-SHA2 for Kerberos 5 > Authors : Michael J. Jenkins > Michael A. Peck > Kelley W. Burgin > Filename : draft-ietf-kitten-aes-cts-hmac-sha2-10.txt > Pages : 17 > Date : 2016-07-05 >=20 > Abstract: > This document specifies two encryption types and two corresponding > checksum types for Kerberos 5. The new types use AES in CTS mode > (CBC mode with ciphertext stealing) for confidentiality and HMAC = with > a SHA-2 hash for integrity. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ = >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-10 = >=20 > A diff from the previous version is available at: > = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-aes-cts-hmac-sha2-10= = >=20 >=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 = . >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ = >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten = >=20 >=20 >=20 > --=20 > 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 > 443-634-3951 = _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- www.lukehoward.com soundcloud.com/lukehoward --Apple-Mail=_2BE4811A-95C2-4A3D-A71C-8B56B237B657 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Updated aes-cts-hmac-sha2 branch of Heimdal.

On 6 Jul 2016, at 5:55 AM, Michael Jenkins <m.jenkins.364706@gmail.com> wrote:

The new draft-ietf-kitten-aes-cts-hmac-sha2 = includes changes for all of Ben's comments. As for the KDF, we looked at = both simply inserting a 0x00 between the "prf" and the octet string = (leaving the extra 0x00 before the length bits intact), and fixing the = KDF so that the prf was computed the same way as any other KDF. So in = the end we decided that the cleanest and least likely to confuse option = was to fix the KDF definition in Section 3 by adding an optional context = field.

Mike J

On Tue, Jul 5, 2016 at 2:00 PM, <internet-drafts@ietf.org> = wrote:

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 of the IETF.

        Title          =  : AES Encryption with HMAC-SHA2 for Kerberos 5
        Authors         : = Michael J. Jenkins
                    =       Michael A. Peck
                    =       Kelley W. Burgin
        Filename        : = draft-ietf-kitten-aes-cts-hmac-sha2-10.txt
        Pages          =  : 17
        Date          =   : 2016-07-05

Abstract:
   This document specifies two encryption types and two = corresponding
   checksum types for Kerberos 5.  The new types use AES = in CTS mode
   (CBC mode with ciphertext stealing) for confidentiality and = HMAC with
   a SHA-2 hash for integrity.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac= -sha2/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2= -10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-aes-cts-h= mac-sha2-10


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/

_______________________________________________
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
443-634-3951
_______________________________________________
Kitten = mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

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

= --Apple-Mail=_2BE4811A-95C2-4A3D-A71C-8B56B237B657-- From nobody Tue Jul 5 18:54:13 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7D412D567 for ; Tue, 5 Jul 2016 18:54:12 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=secure-endpoints.com 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 j4Ah0vLVfZmE for ; Tue, 5 Jul 2016 18:54:10 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.ad.secure-endpoints.com [208.125.0.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B16312B061 for ; Tue, 5 Jul 2016 18:54:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1467770027; x=1468374827; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject:To: References:Cc:From:Openpgp:Organization:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type; bh=GU88to0uysc 4LnNkR36MwBpfF1J+DKgT8hFMOtMq+WE=; b=iorCSwe/uprckJ2B+7ubfFFiyEI MBtDXtiUPqIpwbaVLfBSiRD+MztbSMv0g5ZP3j4c2LcTJ6U3YGCK0wR6BJ7aVoEK DMQ0OkloNtMJqy33WAGaUTvRbXwd8RK7KBrqpQYqXDVJri5IuPlw6fDiURx6WHtW xI/L9Chx67Csj5WM= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Tue, 05 Jul 2016 21:53:47 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Tue, 05 Jul 2016 21:53:47 -0400 Received: from [x.x.x.x] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.0.3) with ESMTPSA id md50001113773.msg for ; Tue, 05 Jul 2016 21:53:45 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDArrival-Date: Tue, 05 Jul 2016 21:53:45 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=1995dbae91=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org To: "Matt Miller (mamille2)" , Stephen Farrell References: <677848B0-17A4-47A6-93EB-F9939654DBAC@padl.com> <12304a67-7cd8-9010-7164-abfd0a47d0d4@secure-endpoints.com> <5778E173.3020707@cs.tcd.ie> From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <6be15567-bc9b-9646-9c01-164becb9f530@secure-endpoints.com> Date: Tue, 5 Jul 2016 21:53:37 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090605040601050805000300" Archived-At: Cc: "kitten@ietf.org" , "draft-ietf-kitten-aes-cts-hmac-sha2@tools.ietf.org" Subject: Re: [kitten] shepherd review of draft-aes-cts-hmac-sha2-09 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 01:54:12 -0000 This is a cryptographically signed message in MIME format. --------------ms090605040601050805000300 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 7/5/2016 6:23 PM, Matt Miller (mamille2) wrote: > Hello All, >=20 > Thanks to Mike for submitting the update so quickly. >=20 > It appears to me that -10 addresses all the concerns raised. > Are there any objections to moving forward with IETF Last Call > with this revision? >=20 > For convenience, the latest revision can be found here: > https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-10 >=20 >=20 > Thanks, >=20 > - Kitten Chairs Thanks to Luke Howard the Heimdal implementation has been updated to draft 10 and the test vectors have been confirmed. https://github.com/heimdal/heimdal/commit/7e4f9f433132611b717c853d732a2b5= 22443a42a I am in favor of moving forward with the IETF Last Call for this document= =2E Jeffrey Altman --------------ms090605040601050805000300 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DFkwggYVMIIE/aADAgECAhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBCwUAMIGmMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5 bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3 MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH NTAeFw0xNTEyMjAwMDAwMDBaFw0xNjEyMjAyMzU5NTlaMIGvMS4wLAYDVQQDDCVQZXJzb25h IE5vdCBWYWxpZGF0ZWQgLSAxNDUwNTc0MTU1Njc5MSswKQYJKoZIhvcNAQkBFhxqYWx0bWFu QHNlY3VyZS1lbmRwb2ludHMuY29tMQ8wDQYDVQQLDAZTL01JTUUxHjAcBgNVBAsMFVBlcnNv bmEgTm90IFZhbGlkYXRlZDEfMB0GA1UECwwWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM0X8uixbo9Tu+sKS20bZeCbN9brFQbtkQ5x /6MrkGsQNTzQ/2WZFJzH89ZoC8auZRFQdA6/yh4wXdCNQ6hBO8Lom26t0LHGhoWtzdkP7MWu YeLMZiuOsC6N6ejHEbtt0KLjphNIUvBVFx5JQzgAwJ1I08LSZg/bIGAVF3SfLOVFu2Iiq5kj psHOv/ECV13fGSvYwBXJN1C1To6wxDgn4pl3m6fFfe4xiVEpc3t6GbKcI+4blK9w76fDaVXw U2uJQAG1UYxbChwocBmb3ka1MlUb2ug3oYBpnufD9zk8u3UqaFlfYyr6/2cr6fqiz1U4+xcb Q3otvVWwzRecpmPEiIcCAwEAAaOCAjIwggIuMAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQD AgWgMCAGA1UdJQEB/wQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4EFgQU2Pc1OxE6 W8hcBZ5L2346cucbFa8wJwYDVR0RBCAwHoEcamFsdG1hbkBzZWN1cmUtZW5kcG9pbnRzLmNv bTBsBgNVHSAEZTBjMGEGC2CGSAGG+EUBBxcBMFIwJgYIKwYBBQUHAgEWGmh0dHA6Ly93d3cu c3ltYXV0aC5jb20vY3BzMCgGCCsGAQUFBwICMBwaGmh0dHA6Ly93d3cuc3ltYXV0aC5jb20v cnBhMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzU3 ZGU3YTIzOGQ0NWQ4ZDRmYzcxZjhhNWM2YjgxYzkzL0xhdGVzdENSTC5jcmwwTgYIKwYBBQUH AQEEQjBAMD4GCCsGAQUFBzAChjJodHRwOi8vY2FjZXIuc3ltYXV0aC5jb20vbXBraS9zeW1j YzFpbmRzdWJjYWc1LmNydDAfBgNVHSMEGDAWgBRnGbY9pXm7M2DYLVPTjAk9B6wYcDArBgpg hkgBhvhFARADBB0wGwYSYIZIAYb4RQEQAQICBAGt7pITFgUxMDkyMjA5BgpghkgBhvhFARAF BCswKQIBABYkYUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3 DQEBCwUAA4IBAQBvO/+L6Tms91Ed1ZJzgT0y9jBK/Armb6Y/EnR1swCDMqRfBzGSGtzOCuN7 PteBvlaB5vmnwEwiZR/FtsDhhORd8Xy5wdmCunhwPbf0ClnBqichI+4UZNS5fCQTciIqHFxq 7EKuHOQm4/ssEH2Xr8yIpCd+Dx9oPEG7MqUno6oxcIDdur4iNKxOBtjWNiXM7rn733qtuFlw 1jIX3eFIsrBALikTU1UbY2KwfewXbiVaFWY0ysl5uOgfWdmj2xBk7aft/L/fnuyWyeeM9IBg 6vdUjPhmJwtFdEdefgP5cRRdYgG8zgJf8Rq84slkea0bwis8PvKVksJ/k2scaDHzKTe2MIIG PDCCBSSgAwIBAgIQBwKiGoW4S2WeGApu5vWjZTANBgkqhkiG9w0BAQsFADCByjELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVz dCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRo b3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmlt YXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IC0gRzMwHhcNMTUxMDAxMDAwMDAwWhcNMjUw OTMwMjM1OTU5WjCBpjELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0 aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMR4wHAYDVQQLExVQZXJzb25h IE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlN5bWFudGVjIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW+w0x SSLADLrvTi0XuLQw5TTSrAnuyYkAXfSuExGzE45VzyIYqCAGpv0ly2iUtKCCkA5ulpJE7hW5 tOz6z3k9adScH9wgmg4o1Q21xp468dRlGcCEM02O2orx1ie5A6DR+iicgpNs9w2FfVvpTpli /pNC0u4+s3FXhpdGy98N4caEWrMNj/X0EIoFXZ9oRuwIsFhCgva+LRBGpiQLJ/6YFFODk4Lb 6sA/T6JYYbVLcmkSXzNZ9vmzTABkzoXFhpIMbhzrKM9xqZCpdJl0JOtI4Q5daBKoAWbo7pqy L/g9zbd4JM6lYHzoFj1J8Qe6M74yK8JnoxbHb8DSWpQEwmtFAgMBAAGjggI+MIICOjA3Bggr BgEFBQcBAQQrMCkwJwYIKwYBBQUHMAGGG2h0dHA6Ly9wa2ktb2NzcC5zeW1hdXRoLmNvbTAS BgNVHRMBAf8ECDAGAQH/AgEAMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwEwUjAmBggrBgEF BQcCARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDov L3d3dy5zeW1hdXRoLmNvbS9ycGEwLwYDVR0fBCgwJjAkoCKgIIYeaHR0cDovL3Muc3ltY2Iu Y29tL3BjYTEtZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UE AxMRU3ltYW50ZWNQS0ktMi0yMTcwHQYDVR0OBBYEFGcZtj2lebszYNgtU9OMCT0HrBhwMIHx BgNVHSMEgekwgeahgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwg SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5 OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eSAtIEczghEAi1t1VoRUhQsAz684SM6xpDANBgkqhkiG9w0BAQsFAAOCAQEARhnkJ3U7vq/i 2qIUYI8eRJCBaStjSTWN6Xa6n5iPE4HXy/xlG/gOY96UKHT742/YySp6DlSmg64pSvYrUf09 OBK73WNF+2TMPlSGf05CbSO3HQv9+swNjpM1yuVF+c8vf3k9YxjHRyNK9qkUAK1+WVUaiSfb lKCROMb+QJWjYPZduMjFFu2cZmkURhBKynAqb9FQ4CYa01K0R3KLRdK9A7ml3NkI85CrdHCr yqBO8MBO5OC+T5ARYCcMKxzf52zKdbQl55FIqpK0UXVfKZtHFxy9yerPda11I8/yxd9aq7dr yru4XqvVo3DUaPMXepsLoBQ8++iBVmjoz118c7guvDGCBGIwggReAgEBMIG7MIGmMQswCQYD VQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHNQIQ cBGDX/fzAS3ijWWeve3D7zANBglghkgBZQMEAgEFAKCCAncwGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNzA2MDE1MzM3WjAvBgkqhkiG9w0BCQQxIgQg CeUEdtwsv0CiGOw7spAjndtqiDW0I3S3OO++Nd0puuAwbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7 MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHNQIQcBGDX/fzAS3ijWWeve3D7zCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt YW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1 AhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBAQUABIIBAKxKBcB46uY27d5G/wBouc4e 38aEgsp0+228dRVj0Ghu7WLfBioYek+T++zODs8Lc1wpsFzHuY/mWUHH8V6lx/yOJaeg6kKE nDnK14Zda9v+iIelT8AC4A4ZjVjCcn8ARFR3tRUSbW7iDFbTqmUTRhf1fYwAv6rzsemPJz4X Ii6h/Gc1/Tl04SIcZEt/bP36KJXFRKkDzNRUTj2lt/+SvNZa1dWzJ7Ml0HP+NzRQBCTp7YFv qMH2bV3f2mx7raR7VgvvPkduL4UyyEC01oSZH3GzTJL7THR+0JYRLSDWzaz9RfwzzEiu9w9U qBXDzRWW0f/5Smvz5P9wzOcBfr5l3XQAAAAAAAA= --------------ms090605040601050805000300-- From nobody Tue Jul 5 23:29:18 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8950712D59D for ; Tue, 5 Jul 2016 23:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 6YjNpDUNZk60 for ; Tue, 5 Jul 2016 23:29:14 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 3653C12D544 for ; Tue, 5 Jul 2016 23:29:12 -0700 (PDT) X-AuditID: 12074425-a63ff70000006cf5-59-577ca537469f 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 (Symantec Messaging Gateway) with SMTP id CB.23.27893.735AC775; Wed, 6 Jul 2016 02:29:11 -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 u666TAVu001345; Wed, 6 Jul 2016 02:29:11 -0400 Received: from [18.101.8.178] (vpn-18-101-8-178.mit.edu [18.101.8.178]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u666T8o0003892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 6 Jul 2016 02:29:09 -0400 To: Luke Howard , Michael Jenkins References: <20160705180040.22387.60767.idtracker@ietfa.amsl.com> <27A0CA43-3608-4CB0-88B6-F4B9F6021510@padl.com> From: Greg Hudson Message-ID: <577CA534.2050701@mit.edu> Date: Wed, 6 Jul 2016 02:29:08 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0 MIME-Version: 1.0 In-Reply-To: <27A0CA43-3608-4CB0-88B6-F4B9F6021510@padl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IRYrdT0TVfWhNusGCdjsXRzatYLO5e+s9u sezbVTYHZo+ds+6yeyxZ8pPJY+6HaSwBzFFcNimpOZllqUX6dglcGd1dHAVXmCsmPjjF1MDY zdzFyMkhIWAicfHmL6YuRi4OIYE2Jolrdx+yQDgbGCUWTv3MCuEcZpJ4cfckI0iLsICPxKkZ s5hAbBEBP4m/T44wQxTtYpSYtP4VG0iCWUBd4ujzJjCbTUBZYv3+rSwgNq+AmsT27xuABnFw sAioSHxakQwSFhWIkJi1/QcTRImgxMmZT8DKOQVsJHr2XGCEGKknseP6L1YIW15i+9s5zBMY BWYhaZmFpGwWkrIFjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdC30cjNL9FJTSjcxgoPXRXUH 45y/XocYBTgYlXh4JzyvDhdiTSwrrsw9xCjJwaQkysvyDSjEl5SfUpmRWJwRX1Sak1p8iFGC g1lJhFd+YU24EG9KYmVValE+TEqag0VJnJeRgYFBSCA9sSQ1OzW1ILUIJivDwaEkwXt6MVCj YFFqempFWmZOCUKaiYMTZDgP0HABkBre4oLE3OLMdIj8KUZdjgU/bq9lEmLJy89LlRLn3b4I qEgApCijNA9uDjjppHJsesUoDvSWMK/wEqAqHmDCgpv0CmgJE9CSny7VIEtKEhFSUg2MVkd5 uOOTA7wu3D10uT3bPiKFUfie9xc2qX2vQtLrZYWaPu2MbUgTsn/9ehqDy39Rj+97lP5yNk2U Cjwqc842qaruZn/6ytN/39lomYU1H4rPLrJf+V/FfK5H33wXiTu50XF777yYs/T/Udt05aqn KZ18Mse7rU9uW7E0bme2ineQ5gl2q5dKLMUZiYZazEXFiQAEJLrfFQMAAA== Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 06:29:16 -0000 On 07/05/2016 07:55 PM, Luke Howard wrote: > Updated aes-cts-hmac-sha2 branch of Heimdal. I also updated my Python and MIT krb5 implementations, and verified the new PRF test vectors. https://github.com/greghudson/pyk5/tree/aes-sha2 https://github.com/greghudson/krb5/tree/aes-sha2 (As before, there is no guarantee of commit stability for either of these branches, and they may disappear entirely after being merged into the relevant master branches.) From nobody Wed Jul 6 13:45:36 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBC4012D67B for ; Wed, 6 Jul 2016 13:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2U5ybptzFiv0 for ; Wed, 6 Jul 2016 13:45:32 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (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 5FA7A12D66E for ; Wed, 6 Jul 2016 13:45:32 -0700 (PDT) X-AuditID: 12074425-867ff700000015c6-30-577d6de90ef8 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 (Symantec Messaging Gateway) with SMTP id D5.E3.05574.AED6D775; Wed, 6 Jul 2016 16:45:30 -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 u66KjTux032738; Wed, 6 Jul 2016 16:45: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 u66KjQ2K030477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 6 Jul 2016 16:45:29 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u66KjQ9k029660; Wed, 6 Jul 2016 16:45:26 -0400 (EDT) Date: Wed, 6 Jul 2016 16:45:25 -0400 (EDT) From: Benjamin Kaduk To: Michael Jenkins In-Reply-To: Message-ID: References: <20160705180040.22387.60767.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixG6nrvsqtzbc4PYdE4ujm1exWCz7dpXN gclj56y77B5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4cu0Oe8EPkYqvqw+yNzB+4O9i5OSQEDCR 2PhoDWsXIxeHkEAbk8S/s/PYIJwNjBLbu+4xQTgHmSQ+L5nA0sXIAeTUS6x8wwXSzSKgJbFk 9URGEJtNQEVi5puNbCC2iICBxKJJ68BsZgFhifXnZjCD2MICfhKHtnWxgNicAoESc7t3sYPY vAIOEs/nNcNcwSixcfN1VpCEqICOxOr9U1ggigQlTs58wgIxVEti+fRtLBMYBWYhSc1CklrA yLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI10IvN7NELzWldBMjOCRdVHcwzvnrdYhRgINRiYd3 wvPqcCHWxLLiytxDjJIcTEqivCzfgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeGdk14YL8aYk VlalFuXDpKQ5WJTEeRkZGBiEBNITS1KzU1MLUotgsjIcHEoSvB9ygBoFi1LTUyvSMnNKENJM HJwgw3mAhr8AqeEtLkjMLc5Mh8ifYlSUEud9CLJVACSRUZoH1wtOGbuZVF8xigO9Isw7FaSd B5hu4LpfAQ1mAhr806UaZHBJIkJKqoFxYZ0yS05UsuadrHVnOi/7CEiHvo0673plGdPDgmSr +4ZRkqFdC9jbvpvI5ljZnW1ZLr080+XW0qfCC0+1ymifWOG8Pf/EjT/PY5LqVFzEVzuxHNub VZks9nq6gpuy18MPdqlnP81YLxO6v08gPqFfNeOer2De9kW5j79r3HzY1MdYqa529ZsSS3FG oqEWc1FxIgA97b7K9AIAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-10.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 20:45:35 -0000 The changes look good, thanks for putting them together so quickly. Also thanks to Luke and Greg for updating implementations and re-verifying test vectors. -Ben On Tue, 5 Jul 2016, Michael Jenkins wrote: > The new draft-ietf-kitten-aes-cts-hmac-sha2 includes changes for all of > Ben's comments. As for the KDF, we looked at both simply inserting a 0x00 > between the "prf" and the octet string (leaving the extra 0x00 before the > length bits intact), and fixing the KDF so that the prf was computed the > same way as any other KDF. So in the end we decided that the cleanest and > least likely to confuse option was to fix the KDF definition in Section 3 > by adding an optional context field. > > Mike J > > On Tue, Jul 5, 2016 at 2:00 PM, wrote: > > > > > 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 of the IETF. > > > > Title : AES Encryption with HMAC-SHA2 for Kerberos 5 > > Authors : Michael J. Jenkins > > Michael A. Peck > > Kelley W. Burgin > > Filename : draft-ietf-kitten-aes-cts-hmac-sha2-10.txt > > Pages : 17 > > Date : 2016-07-05 > > > > Abstract: > > This document specifies two encryption types and two corresponding > > checksum types for Kerberos 5. The new types use AES in CTS mode > > (CBC mode with ciphertext stealing) for confidentiality and HMAC with > > a SHA-2 hash for integrity. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-kitten-aes-cts-hmac-sha2-10 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-aes-cts-hmac-sha2-10 > > > > > > 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/ > > > > _______________________________________________ > > 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 > 443-634-3951 > From nobody Wed Jul 6 15:18:36 2016 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 890B212D0C3; Wed, 6 Jul 2016 15:18:34 -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.25.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160706221834.26832.49584.idtracker@ietfa.amsl.com> Date: Wed, 06 Jul 2016 15:18:34 -0700 Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-aes-cts-hmac-sha2@ietf.org, kitten-chairs@ietf.org Subject: [kitten] Last Call: (AES Encryption with HMAC-SHA2 for Kerberos 5) to Informational RFC X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 06 Jul 2016 22:18:34 -0000 The IESG has received a request from the Common Authentication Technology Next Generation WG (kitten) to consider the following document: - 'AES Encryption with HMAC-SHA2 for Kerberos 5' as Informational RFC 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 2016-07-20. 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 specifies two encryption types and two corresponding checksum types for Kerberos 5. The new types use AES in CTS mode (CBC mode with ciphertext stealing) for confidentiality and HMAC with a SHA-2 hash for integrity. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Wed Jul 6 17:55:11 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA82612B02F for ; Wed, 6 Jul 2016 17:55:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 fIYZPEbg7Ilh for ; Wed, 6 Jul 2016 17:55:08 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E7EA12B00D for ; Wed, 6 Jul 2016 17:55:08 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 3E5F4B8081; Wed, 6 Jul 2016 17:55:08 -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=Zu0i05AP5tplmA /B+1Tw56QkyrY=; b=HGzg57UmvkBDAdkHIl2DGsrEcmLRHRKP0tOyQm/PPrGOxM EuNf8/1HcDpXpUxCwQtsSq2fgeloHzAc4CT/bCiT8TwBKqZI3hkksr1WA9uSCbC/ 8uqM8DKF9RJo38p7WL1jDmyHBmIK9dM9yXhZgy4uJ8/t1P9SeHZybaehfx0zc= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPSA id 15105B806B; Wed, 6 Jul 2016 17:55:06 -0700 (PDT) Date: Wed, 6 Jul 2016 19:54:55 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20160707005452.GH4935@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Proposal for tracking document reviews and skipping WGLC X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 00:55:10 -0000 On Mon, Jun 20, 2016 at 11:58:08PM -0400, Benjamin Kaduk wrote: > Does this proposal seem reasonable? Yes. > If this proposal moves forward, there is a question of where to host the > wiki page: two choices that came up so far are a github wiki or an > IETF-hosted trac wiki, but we are not tied to those two options. My I'm not a fan of the IETF trac. I'm not a fan of the github issue tracker either, but, a) github is very convenient, b) its wiki is nice, c) this can all be blended (optionally) with using git[hub] for version control of each I-D, d) we can have an organization for the WG to be the umbrella for [a subset of] the WG's documents that every participant who asks can be made a member of. > understanding is that either one would require an account tied to that > provider in order to edit (to avoid wiki spam), so there would be some > barrier to entry in either case. However, perhaps more people already > have github accounts than IETF trac accounts, which lends some preference It's also becoming common to use github for IETF work. E.g., TLS 1.3. I'd consider other VCS services built around git too. > to github; indeed, other WGs are using github for document editing and > issue tracking already. Regardless of where the wiki is hosted, a wiki > account would not be needed in order to participate in document review; > comments can always be sent to the mailing list and the chairs are able to > edit the wiki page on behalf of others. Indeed, the mailing list must remain the ultimate consensus confirmation medium for now and the forseeable future. Nico -- From nobody Wed Jul 6 18:16:09 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB5512D15E for ; Wed, 6 Jul 2016 18:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 BO9aimRIYzC7 for ; Wed, 6 Jul 2016 18:16:05 -0700 (PDT) Received: from mailout.easymail.ca (mailout.easymail.ca [64.68.201.169]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9A5A12D0E1 for ; Wed, 6 Jul 2016 18:16:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailout.easymail.ca (Postfix) with ESMTP id ED8D1E263; Wed, 6 Jul 2016 21:16:04 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at mailout.easymail.ca Received: from mailout.easymail.ca ([127.0.0.1]) by localhost (easymail-mailout.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lp3c64Bmcifj; Wed, 6 Jul 2016 21:16:04 -0400 (EDT) Received: from [192.168.3.129] (24-205-82-163.dhcp.psdn.ca.charter.com [24.205.82.163]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout.easymail.ca (Postfix) with ESMTPSA id 36DB4E25C; Wed, 6 Jul 2016 21:16:04 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: "Henry B (Hank) Hotz, CISSP" In-Reply-To: <20160707005452.GH4935@localhost> Date: Wed, 6 Jul 2016 18:16:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160707005452.GH4935@localhost> To: Nico Williams X-Mailer: Apple Mail (2.2104) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Proposal for tracking document reviews and skipping WGLC X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 01:16:07 -0000 Given the necessary multitude of different username/password = combinations I need to avoid duplicating passwords already, I don=E2=80=99= t consider the need for yet another for an IETF wiki to be a serious = impediment. Agreed that *some* mailing list traffic is still necessary so the = otherwise-uninvolved have a chance to weigh in. > On Jul 6, 2016, at 5:54 PM, Nico Williams = wrote: >=20 > On Mon, Jun 20, 2016 at 11:58:08PM -0400, Benjamin Kaduk wrote: >> Does this proposal seem reasonable? >=20 > Yes. >=20 >> If this proposal moves forward, there is a question of where to host = the >> wiki page: two choices that came up so far are a github wiki or an >> IETF-hosted trac wiki, but we are not tied to those two options. My >=20 > I'm not a fan of the IETF trac. I'm not a fan of the github issue > tracker either, but, >=20 > a) github is very convenient, > b) its wiki is nice, > c) this can all be blended (optionally) with using git[hub] for = version > control of each I-D, > d) we can have an organization for the WG to be the umbrella for [a > subset of] the WG's documents that every participant who asks can be > made a member of. >=20 >> understanding is that either one would require an account tied to = that >> provider in order to edit (to avoid wiki spam), so there would be = some >> barrier to entry in either case. However, perhaps more people = already >> have github accounts than IETF trac accounts, which lends some = preference >=20 > It's also becoming common to use github for IETF work. E.g., TLS 1.3. >=20 > I'd consider other VCS services built around git too. >=20 >> to github; indeed, other WGs are using github for document editing = and >> issue tracking already. Regardless of where the wiki is hosted, a = wiki >> account would not be needed in order to participate in document = review; >> comments can always be sent to the mailing list and the chairs are = able to >> edit the wiki page on behalf of others. >=20 > Indeed, the mailing list must remain the ultimate consensus = confirmation > medium for now and the forseeable future. >=20 > Nico > --=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten Personal: hbhotz@oxy.edu https://www.linkedin.com/in/hbhotz/ From nobody Wed Jul 6 18:44:35 2016 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169AD12B020 for ; Wed, 6 Jul 2016 18:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 C0JvdT49VROn for ; Wed, 6 Jul 2016 18:44:32 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4056126579 for ; Wed, 6 Jul 2016 18:44:32 -0700 (PDT) Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id 182C72005DA24; Wed, 6 Jul 2016 18:44:32 -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:content-transfer-encoding; s= cryptonector.com; bh=YEOrdUoUrH0DzQog1gR+ZT+8qh4=; b=DiVVwptOO3v A8AUi1oYTSSJ2gApwCQk9T4ve8d3tB4f4msM+q/1YSIGroBJXvch6DVXq0ILkN07 E+tYDAUVF+VBnshMO3gyCNbbTZlOSqzZLF5qCAAe5K0iSH5pgd2b/mtzYJN9Igho u2enkvBmDkV/GPIQgvJlBU4dSrO0PoHo= Received: from localhost (108-207-244-100.lightspeed.austtx.sbcglobal.net [108.207.244.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPSA id B77642005D829; Wed, 6 Jul 2016 18:44:31 -0700 (PDT) Date: Wed, 6 Jul 2016 20:44:20 -0500 From: Nico Williams To: "Henry B (Hank) Hotz, CISSP" Message-ID: <20160707014419.GI4935@localhost> References: <20160707005452.GH4935@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Proposal for tracking document reviews and skipping WGLC X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2016 01:44:34 -0000 On Wed, Jul 06, 2016 at 06:16:02PM -0700, Henry B (Hank) Hotz, CISSP wrot= e: > Given the necessary multitude of different username/password > combinations I need to avoid duplicating passwords already, I don=E2=80= =99t > consider the need for yet another for an IETF wiki to be a serious > impediment. That's not what bothers me about thr tracker. From nobody Tue Jul 26 12:38:35 2016 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D42912D520; Tue, 26 Jul 2016 12:38:33 -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.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160726193833.30872.31544.idtracker@ietfa.amsl.com> Date: Tue, 26 Jul 2016 12:38:33 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 19:38:33 -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 of the IETF. Title : Anonymity Support for Kerberos Authors : Larry Zhu Paul Leach Sam Hartman Shawn Emery Filename : draft-ietf-kitten-rfc6112bis-01.txt Pages : 17 Date : 2016-07-26 Abstract: This document defines extensions to the Kerberos protocol to allow a Kerberos client to securely communicate with a Kerberos application service without revealing its identity, or without revealing more than its Kerberos realm. It also defines extensions that allow a Kerberos client to obtain anonymous credentials without revealing its identity to the Kerberos Key Distribution Center (KDC). This document updates RFCs 4120, 4121, and 4556. This document obsoletes RFC 6112 and reclassifies that document as historic. RFC 6112 contained errors and the protocol described in that specification is not interoperable with any known implementation. This specification describes a protocol that interoperates with multiple implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc6112bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-rfc6112bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-rfc6112bis-01 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/