From nobody Thu Sep 1 13:17:19 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 C3DC012D782; Thu, 1 Sep 2016 13:17:15 -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.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147276103576.32168.16561985797578576426.idtracker@ietfa.amsl.com> Date: Thu, 01 Sep 2016 13:17:15 -0700 Archived-At: Cc: draft-ietf-kitten-aes-cts-hmac-sha2@ietf.org, kitten-chairs@ietf.org, kitten@ietf.org, The IESG , rfc-editor@rfc-editor.org Subject: [kitten] Document Action: 'AES Encryption with HMAC-SHA2 for Kerberos 5' to Informational RFC (draft-ietf-kitten-aes-cts-hmac-sha2-11.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: Thu, 01 Sep 2016 20:17:16 -0000 The IESG has approved the following document: - 'AES Encryption with HMAC-SHA2 for Kerberos 5' (draft-ietf-kitten-aes-cts-hmac-sha2-11.txt) as Informational RFC This document is the product of the Common Authentication Technology Next Generation Working Group. The IESG contact persons are Stephen Farrell and Kathleen Moriarty. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/ Technical Summary This document specifies new Kerberos encryption types that use the AES block cipher and cryptographic hashes from the SHA-2 family. They differ from the existing AES encryption types by using SHA-2 hashes instead of SHA-1 (and truncating at a longer length), using encrypt-then-MAC intsead of encrypt-and-MAC, and other changes to move closer towards current cryptographic best practices. It is expected that an updated Suite-B profile for Kerberos will make use of these new encryption types. Working Group Summary There is consensus for this document, which brings incremental improvements to the cryptography available for use with Kerberos. Initial individual drafts attempted to combine a Suite B profile and new encryption types into a single document, but the new encryption types have been split out into this document appropriately, with the Suite B profile to follow separately. This is a Informational document that specifies a new Kerberos encryption type; it does not need to update any Kerberos protocol elements. There will eventually be desire for another (set of) standards-track Kerberos encryption types, but it remains unclear whether that will be this set or some other cipher; there is no procedural reason to target standards-track at this time. Document Quality This document (and its predecessors) has received a large amount of attention and review from essentially all of the prominent WG contributors, spread out over a few years, and there are multiple implementations that are able to reproduce the supplied test vectors. Personnel Benjamin Kaduk is the document shepherd. Stephen Farrell is the responsible Area Director. RFC Editor Note Please add RFC4556 to the informative references in 10.2. It's mentioned in the security considerations but there's nothing in 10.2 at present. From nobody Fri Sep 2 18:12:44 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 834AD12D5B4 for ; Fri, 2 Sep 2016 18:12:42 -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 JrIw2Rknw0_Z for ; Fri, 2 Sep 2016 18:12:41 -0700 (PDT) Received: from sequoia-grove.secure-endpoints.com (sequoia-grove.secure-endpoints.com [IPv6:2001:470:1f07:f77:28d9:68fb:855d:c2a5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E2212D5B2 for ; Fri, 2 Sep 2016 18:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=secure-endpoints.com; s=MDaemon; t=1472865159; x=1473469959; i=jaltman@secure-endpoints.com; q=dns/txt; h=VBR-Info:Subject: References:To:From:Openpgp:Organization:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type; bh=KIMhqsBwsa8 dkZ0ilkgux36E6YbeEwQafe/e2+j4bIc=; b=bswhAYof1LEz1J0CF+NkvLrCP0f MqZKVWfXu9dQV8LeBUyenuWeBUIyMoxC24SNBUNTWMJI6etaq/u3xPD5KZe+X/Mc HDsXIOfahXg5grrkE/Jtugmhi2RlmkAe3EpnkxRiJYtoXL5V5mGTJly+mFuAKNXg vr6u4xdQ2Odz54Pw= X-MDAV-Result: clean X-MDAV-Processed: sequoia-grove.secure-endpoints.com, Fri, 02 Sep 2016 21:12:39 -0400 X-Spam-Processed: sequoia-grove.secure-endpoints.com, Fri, 02 Sep 2016 21:12:39 -0400 Received: from [IPv6:2001:470:1f07:f77:54cc:6135:d66f:2582] by secure-endpoints.com (Cipher TLSv1:AES-SHA:256) (MDaemon PRO v16.0.4) with ESMTPSA id md50001144393.msg for ; Fri, 02 Sep 2016 21:12:38 -0400 VBR-Info: md=secure-endpoints.com; mc=all; mv=vbr.emailcertification.org; X-MDRemoteIP: 2001:470:1f07:f77:54cc:6135:d66f:2582 X-MDHelo: [IPv6:2001:470:1f07:f77:54cc:6135:d66f:2582] X-MDArrival-Date: Fri, 02 Sep 2016 21:12:38 -0400 X-Authenticated-Sender: jaltman@secure-endpoints.com X-Return-Path: prvs=10545cf839=jaltman@secure-endpoints.com X-Envelope-From: jaltman@secure-endpoints.com X-MDaemon-Deliver-To: kitten@ietf.org References: <147276103576.32168.16561985797578576426.idtracker@ietfa.amsl.com> To: kitten@ietf.org From: Jeffrey Altman Openpgp: id=FA444AF197F449B24CF3E699F77A735592B69A04; url=http://pgp.mit.edu Organization: Secure Endpoints Inc. Message-ID: <9b612ac1-0288-dc0f-92b6-9045691ea872@secure-endpoints.com> Date: Fri, 2 Sep 2016 21:12:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147276103576.32168.16561985797578576426.idtracker@ietfa.amsl.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000005030708050801040808" Archived-At: Subject: Re: [kitten] Document Action: 'AES Encryption with HMAC-SHA2 for Kerberos 5' to Informational RFC (draft-ietf-kitten-aes-cts-hmac-sha2-11.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: Sat, 03 Sep 2016 01:12:42 -0000 This is a cryptographically signed message in MIME format. --------------ms000005030708050801040808 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 9/1/2016 4:17 PM, The IESG wrote: > The IESG has approved the following document: > - 'AES Encryption with HMAC-SHA2 for Kerberos 5' > (draft-ietf-kitten-aes-cts-hmac-sha2-11.txt) as Informational RFC Now that approval has been obtained from the IESG, can the encryption and checksum type numbers be allocated by the working group or do we have to wait for an IANA action? Jeffrey Altman --------------ms000005030708050801040808 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 SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwOTAzMDExMjM2WjAvBgkqhkiG9w0BCQQxIgQg CnWpSozhqZm/cTtB9kHrxUhO2iTL8BgyCZkwe/k9jG0wbAYJKoZIhvcNAQkPMV8wXTALBglg hkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBzAYJKwYBBAGCNxAEMYG+MIG7 MIGmMQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNV BAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlk YXRlZDE3MDUGA1UEAxMuU3ltYW50ZWMgQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHNQIQcBGDX/fzAS3ijWWeve3D7zCBzgYLKoZIhvcNAQkQAgsxgb6ggbswgaYxCzAJ BgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3lt YW50ZWMgVHJ1c3QgTmV0d29yazEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5TeW1hbnRlYyBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEc1 AhBwEYNf9/MBLeKNZZ697cPvMA0GCSqGSIb3DQEBAQUABIIBAJZL4HStpYo8lHgS5JlkXGt0 Qbj/1I8qmvseWTGS8FSlPPhvnE3I/ygkjbmHFgHr9N1k2r9WKkugV6nmKa3Q/connr64AHcr DRHSPTJ/tGAuMVYqSXXg7BV+p3ux+LPrzTxADXjPwZvbbZ9BVGMX65WCe1swUrjQx1yn0cw8 5Pre0gfN+4vcZcyZqe3r5bhQXjK/xW2hyLZivw22ac2IkJN0eTaMO3X631nAkJfzs+gov7vM kqiaQNlFhY8H5+yo3vXNU3EVMVjN4vNNYDuCcAZzftTTVMFjAAE9blWawIv3wWU+gzdTViex mHDg/EyPov7w4SBBPDLD6zM3vbnehdQAAAAAAAA= --------------ms000005030708050801040808-- From nobody Sun Sep 4 15:42: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 BCDFC12B0E1 for ; Sun, 4 Sep 2016 15:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.41 X-Spam-Level: X-Spam-Status: No, score=-8.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, 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 Fn4tFJcIfS_m for ; Sun, 4 Sep 2016 15:42:14 -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 90C5E12B0E0 for ; Sun, 4 Sep 2016 15:42:14 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B5C8683F3A for ; Sun, 4 Sep 2016 22:35:18 +0000 (UTC) Received: from rei.prd.blackhats.net.au (ovpn-116-25.phx2.redhat.com [10.3.116.25]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u84MZG7o017336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sun, 4 Sep 2016 18:35:18 -0400 Message-ID: <1473028515.26123.44.camel@redhat.com> From: William Brown To: kitten@ietf.org Date: Mon, 05 Sep 2016 08:35:15 +1000 Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-KyX8ILQzbn3++N1IxQfb" Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Sun, 04 Sep 2016 22:35:18 +0000 (UTC) Archived-At: Subject: [kitten] Request for feedback: draft-wibrown-ldapssotoken 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, 04 Sep 2016 22:42:16 -0000 --=-KyX8ILQzbn3++N1IxQfb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I would like to ask for feedback on the submission draft-wibrown-ldapssotoken [0]. Section 4 deals with the SASL component of the submission. I have been advised by Alexey Melnikov that this seems similar to rfc7628 [1] and rfc6595 [2]. The main difference that I see is that these rfcs rely on the external OAuth and SAML provider for tokens. As well, they have GSSAPI integrations. The implementation I am suggesting here is for a much simpler cryptographically based token, that is for "small deployments" IE where no other SSO such as KRB5, SAML or others are available. It's much more targeted around the communication and authentication to a Directory Server: but there is no reason it couldn't be use for simple crypto token sign on in other applications.=20 Thanks for your time and advice, [0] https://datatracker.ietf.org/doc/draft-wibrown-ldapssotoken/ [1] https://tools.ietf.org/html/rfc7628 [2] https://tools.ietf.org/html/rfc6595 --=20 Sincerely, William Brown Software Engineer Red Hat, Brisbane --=-KyX8ILQzbn3++N1IxQfb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABAgAGBQJXzKGjAAoJEISUiynM+PAgrhQP/Al6FwLmVPeU0F99hWFv2FkS 7kFS7yvO/pBTXDl1z3zCEt1yzF37+1YWZNZlXcWzbxDOb8fAMAqSPyhNarPWvM5d Wwzmx1UDl22lDudxBYgJdjWl3YwGkaL8GSUoT2d7QByqh1WdPzFEEsihA9W+Pt4P L2lV8Cf5sPilOI2UHL8EO6K60Wj7OsS2ZjhVDIqZxEx1vbLDY9t2YoskVcUJ6IPI 4C8CcOvaJivfnCRnYaOuP6x7Ykew00MYSDxg9ZgAZ91EMa2qRo//249OTVq7rXC7 fdaS5DB0CUFwgRXJM0MzoRlwbRwgy3ksQbuucXuVu3XtnhVYhdQ05FatfE2Cmstw zU224eK08FJsJOBoFCyL2zA94XdotPXBuwuS/UFpfIAQhJe72tRdD7EhVvSrlzq7 rpXvXATItOz6t143M3PVK1tdxilEBFFkMEHNNhutPICG+JEURYVGnR4oYlWP+g5N sGF4sDzhzmYPpKSrb0/QPw6+jnnd00lQ8bTa7bziSTXZ3XeNuQ/Tz9+vZkP63hm3 5RBvonk4QeOvv/x1nGos/PCHv4FV/Lmn9hUijAqXAxLzJWzGtep+zyIzsOH74TAg KNPSUcAHhxwSxY6odqfdVFp/MGyr0XYW+S5PtLCuVQvt6TwU+ebHPSnQiysr3SDM EzdCvIiEREGImPHj9fkl =YTE9 -----END PGP SIGNATURE----- --=-KyX8ILQzbn3++N1IxQfb-- From nobody Sun Sep 4 18:31: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 A794D12B11D for ; Sun, 4 Sep 2016 18:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.41 X-Spam-Level: X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.508, 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 PGPxA09MeTKY for ; Sun, 4 Sep 2016 18:31:11 -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 BE00A12B08D for ; Sun, 4 Sep 2016 18:31:11 -0700 (PDT) Received: by us.padl.com with ESMTP id u851V7Fd018236; Sun, 4 Sep 2016 21:31:09 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Luke Howard In-Reply-To: <1473028515.26123.44.camel@redhat.com> Date: Mon, 5 Sep 2016 11:31:06 +1000 Content-Transfer-Encoding: quoted-printable Message-Id: <900064F9-C173-49DE-9973-F7CE6A3762EE@padl.com> References: <1473028515.26123.44.camel@redhat.com> To: William Brown X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Request for feedback: draft-wibrown-ldapssotoken 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: Mon, 05 Sep 2016 01:31:14 -0000 Hi William, It would be worth mentioning in a Security Considerations section that = this protocol (like all bearer tokens) is vulnerable to replay attacks. Cheers, Luke > On 5 Sep 2016, at 8:35 AM, William Brown wrote: >=20 > Hi, >=20 > I would like to ask for feedback on the submission > draft-wibrown-ldapssotoken [0]. Section 4 deals with the SASL = component > of the submission. I have been advised by Alexey Melnikov that this > seems similar to rfc7628 [1] and rfc6595 [2]. The main difference that = I > see is that these rfcs rely on the external OAuth and SAML provider = for > tokens. As well, they have GSSAPI integrations. The implementation I = am > suggesting here is for a much simpler cryptographically based token, > that is for "small deployments" IE where no other SSO such as KRB5, = SAML > or others are available. It's much more targeted around the > communication and authentication to a Directory Server: but there is = no > reason it couldn't be use for simple crypto token sign on in other > applications.=20 >=20 > Thanks for your time and advice, >=20 > [0] https://datatracker.ietf.org/doc/draft-wibrown-ldapssotoken/ > [1] https://tools.ietf.org/html/rfc7628 > [2] https://tools.ietf.org/html/rfc6595 >=20 > --=20 > Sincerely, >=20 > William Brown > Software Engineer > Red Hat, Brisbane > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- www.lukehoward.com soundcloud.com/lukehoward From nobody Mon Sep 5 14:19: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 A2D2212B464 for ; Mon, 5 Sep 2016 14:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 PJuq63DYju_a for ; Mon, 5 Sep 2016 14:19:15 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 3CEFD12B297 for ; Mon, 5 Sep 2016 14:19:13 -0700 (PDT) X-AuditID: 1209190e-4afff70000003320-5d-57cde14f47db 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 CF.BB.13088.F41EDC75; Mon, 5 Sep 2016 17:19:12 -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 u85LJBDM013679; Mon, 5 Sep 2016 17:19: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 u85LJ7UT002971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Sep 2016 17:19:10 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u85LJ7jP021947; Mon, 5 Sep 2016 17:19:07 -0400 (EDT) Date: Mon, 5 Sep 2016 17:19:07 -0400 (EDT) From: Benjamin Kaduk To: Jeffrey Altman In-Reply-To: <9b612ac1-0288-dc0f-92b6-9045691ea872@secure-endpoints.com> Message-ID: References: <147276103576.32168.16561985797578576426.idtracker@ietfa.amsl.com> <9b612ac1-0288-dc0f-92b6-9045691ea872@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+NgFnrHIsWRmVeSWpSXmKPExsUixG6nrhvw8Gy4waotshZ/Vk5iszi6eRWL A5PHkiU/mTxO9p1nDWCK4rJJSc3JLEst0rdL4Mp4tfgXc8EPtorX19pYGhivsnYxcnJICJhI vP+6nqWLkYtDSKCNSWLT7NVgCSGBDYwS/XcNIBIHmSTadr9hg0jUS7z5v5cJxGYR0JJYfXsF O4jNJqAiMfPNRrAaEQFDibb/N8EGMQsIS6w/N4MZZJCwwGxGids/3oMlOAU8JHa83swCYvMK OEj0PehkhtjWxSjxbM05sKmiAjoSq/dPgSoSlDg58wkLxFQtieXTt7FMYBSYhSQ1C0lqASPT KkbZlNwq3dzEzJzi1GTd4uTEvLzUIl1jvdzMEr3UlNJNjKCg5JTk28E4qcH7EKMAB6MSD++G 0rPhQqyJZcWVuYcYJTmYlER5C1SBQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR47e8C5XhTEiur UovyYVLSHCxK4rxdMw6ECwmkJ5akZqemFqQWwWRlODiUJHhNHwA1ChalpqdWpGXmlCCkmTg4 QYbzAA0XA6nhLS5IzC3OTIfIn2LU5Vjw4/ZaJiGWvPy8VClxXrb7QEUCIEUZpXlwc8DJZDeT 6itGcaC3hHltQEbxABMR3KRXQEuYgJas230aZElJIkJKqoEx8hq/4q3jeUmu+z1CLKQ95qs9 FL6WZrlS+uI09s8Tr3zqf3h427Gva//5GDqrP329QD7g4Jr711SDt0vyx/5ftlJZ+Xex+Jf3 k5Lnb5+33zKBIS+cxUf9boxsqoTxhkuyWnunGOjMev9h20tu0+MfLW9Peyul+u3QvhO71yir L9T24+CxW23nqMRSnJFoqMVcVJwIAM3MyZgBAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Document Action: 'AES Encryption with HMAC-SHA2 for Kerberos 5' to Informational RFC (draft-ietf-kitten-aes-cts-hmac-sha2-11.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: Mon, 05 Sep 2016 21:19:17 -0000 On Fri, 2 Sep 2016, Jeffrey Altman wrote: > On 9/1/2016 4:17 PM, The IESG wrote: > > The IESG has approved the following document: > > - 'AES Encryption with HMAC-SHA2 for Kerberos 5' > > (draft-ietf-kitten-aes-cts-hmac-sha2-11.txt) as Informational RFC > > Now that approval has been obtained from the IESG, can the encryption > and checksum type numbers be allocated by the working group or do we > have to wait for an IANA action? IANA has to perform the allocation, but they seem to have already started taking action, as can be seen at the document history (https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/history/). (There was a two hour gap between the "In Progress" and "On Hold" state transitions.) Maybe that means they are asking the expert, though I did not think that the standards action policy required such consultation. -Ben From nobody Mon Sep 5 17:52:34 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 40D2412B096 for ; Mon, 5 Sep 2016 17:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.809 X-Spam-Level: X-Spam-Status: No, score=-5.809 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.508, 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 M-56RjJi2cbc for ; Mon, 5 Sep 2016 17:52:31 -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 9B65412B006 for ; Mon, 5 Sep 2016 17:52:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0DA97BE39; Tue, 6 Sep 2016 01:52:30 +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 mUgAqssiCaoC; Tue, 6 Sep 2016 01:52:28 +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 AB50FBDF9; Tue, 6 Sep 2016 01:52:27 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1473123148; bh=V49zNAjtVg4VNV7OqZ2PmL6fuq/V+qN/yB3PDjoPIW0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=H1mnb2iMo18vs4Rf2ntOf9RSvg4F23ot+9kMWudEZeooYw4TSfhA/XYWC+BbBtX60 1tSbSqQaPNV3jHjWITBSD7eoCPFHvbCM9hYrm2YaEUZxkwqH1miJmfYLBBkB+BPlXH yYJneaBOzp+gg0Tg4BmBNkNV/Ads8ZaQ4KxiB1tk= To: Benjamin Kaduk , Jeffrey Altman References: <147276103576.32168.16561985797578576426.idtracker@ietfa.amsl.com> <9b612ac1-0288-dc0f-92b6-9045691ea872@secure-endpoints.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <8d70c265-cb18-fb41-bfc5-b3169eb2da06@cs.tcd.ie> Date: Tue, 6 Sep 2016 01:52:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms000405000707080307040501" Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Document Action: 'AES Encryption with HMAC-SHA2 for Kerberos 5' to Informational RFC (draft-ietf-kitten-aes-cts-hmac-sha2-11.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, 06 Sep 2016 00:52:33 -0000 This is a cryptographically signed message in MIME format. --------------ms000405000707080307040501 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 05/09/16 22:19, Benjamin Kaduk wrote: > On Fri, 2 Sep 2016, Jeffrey Altman wrote: >=20 >> On 9/1/2016 4:17 PM, The IESG wrote: >>> The IESG has approved the following document: >>> - 'AES Encryption with HMAC-SHA2 for Kerberos 5' >>> (draft-ietf-kitten-aes-cts-hmac-sha2-11.txt) as Informational RFC >> >> Now that approval has been obtained from the IESG, can the encryption >> and checksum type numbers be allocated by the working group or do we >> have to wait for an IANA action? >=20 > IANA has to perform the allocation, but they seem to have already start= ed > taking action, as can be seen at the document history > (https://datatracker.ietf.org/doc/draft-ietf-kitten-aes-cts-hmac-sha2/h= istory/). > (There was a two hour gap between the "In Progress" and "On Hold" state= > transitions.) Maybe that means they are asking the expert, though I di= d > not think that the standards action policy required such consultation. If getting numbers assigned is important, please say why and we can see if it can happen sooner. Shouldn't be too long at all though. For future reference, please see [1] (I know the WG chairs know that, but maybe other folks may not) which allows WGs to ask for early allocations of codepoints. S. [1] https://tools.ietf.org/html/rfc7120 >=20 > -Ben >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten >=20 --------------ms000405000707080307040501 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MDYw MDUyMjdaMC8GCSqGSIb3DQEJBDEiBCBzgWW7CLe0kVjcXbXUen68yHTWZz9ivu4UCkxX1zhV jTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB5zXGfKCoCAgSSBbu06h4yty4Se68LSDNxXlitFnM3uK8c66evX+9p U7hDqZlDAnqbWbkif0ocyoCkIV4fej7LIbEcRW4RWHPAspx9W6jsxi4AF/LBQhnVlx3qg1I1 lgeeJWZueB1taUSscXJGoilAPT2KiAx397NvZss8bAMvMTgCq+My6ojDNzhHWxkcOYfDUX9/ w7Xx48XiWdN0DELObbxcYiujdJK24WfREcnsuJgmdU9i7Pk4dCHT4HsCsWSOlzxTwuBufsG0 Hqx/DECcqMFlyi+hfYfaowFIfy5YQSOQKRMOHiudf8qQgjmf6f1opcMIB/CyI+GT6JgbH1EP AAAAAAAA --------------ms000405000707080307040501-- From nobody Mon Sep 5 19:17:33 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 23B77128E19; Mon, 5 Sep 2016 19:17:29 -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.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147312824910.3005.15896054332400043476.idtracker@ietfa.amsl.com> Date: Mon, 05 Sep 2016 19:17:29 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-02.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, 06 Sep 2016 02:17:29 -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-02.txt Pages : 17 Date : 2016-09-04 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-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-rfc6112bis-02 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 Mon Sep 5 19:22: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 EC2D412B092 for ; Mon, 5 Sep 2016 19:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.41 X-Spam-Level: X-Spam-Status: No, score=-8.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, 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 Cpp7hPOCnLX7 for ; Mon, 5 Sep 2016 19:22:30 -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 55778128E19 for ; Mon, 5 Sep 2016 19:22:30 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F02C361E47; Tue, 6 Sep 2016 02:22:14 +0000 (UTC) Received: from rei.prd.blackhats.net.au (ovpn-116-7.phx2.redhat.com [10.3.116.7]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u862MCJR018754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Sep 2016 22:22:14 -0400 Message-ID: <1473128531.15290.4.camel@redhat.com> From: William Brown To: Luke Howard Date: Tue, 06 Sep 2016 12:22:11 +1000 In-Reply-To: <900064F9-C173-49DE-9973-F7CE6A3762EE@padl.com> References: <1473028515.26123.44.camel@redhat.com> <900064F9-C173-49DE-9973-F7CE6A3762EE@padl.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-cR7Q3lHvC3gXNORUzYAr" Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 06 Sep 2016 02:22:15 +0000 (UTC) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Request for feedback: draft-wibrown-ldapssotoken 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, 06 Sep 2016 02:22:32 -0000 --=-cR7Q3lHvC3gXNORUzYAr Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-09-05 at 11:31 +1000, Luke Howard wrote: > Hi William, >=20 > It would be worth mentioning in a Security Considerations section that th= is protocol (like all bearer tokens) is vulnerable to replay attacks. >=20 Thank you, this is a excellent point. I have added this section and updated the draft. https://tools.ietf.org/html/draft-wibrown-ldapssotoken-01 --=20 Sincerely, William Brown Software Engineer Red Hat, Brisbane --=-cR7Q3lHvC3gXNORUzYAr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAABAgAGBQJXzihTAAoJEISUiynM+PAgDi4QAJsLCMCXWVhoevNDDUIAemSZ i5PoihDpYgRHRj2NMHxkynIUkcIDg5GqPgKHlg1jcisYe2B2Vu3/oOYyrRz62HwN tPnDplZ2sUGJQEcfFGhpHD8Pae8+9Jf1OSNSK4RQInrhpp5gSAw3mZP3+8Iewent dV4t8LGZUMdCW8J65NBzcRk9+YvtCNJU/yOUrG6EgFsmc0vQVly3jdl2tn+NZhvF i31Uh5YIysbnlz2HifJBsbdkWIhJuE1BIegZ5z4lMDND23ZzimAnTqlRhwigBwKv asF8iTAkh+m8eihXd1SdJiRTAE67J4vUvx/qLhYvYe0IvaZGsV4jXpTaLaeBuhwt oajwTjBexRgXiBaOT47unodMrkkDX4g/9bOI3D6UIcdFtWf+IJBaNgAoCWrMfWcy E08BdwXscj25Q8W08RjVZxwuvSvoRkZEtHIj3iv0EGqzU5g2XePPt/DBpq8t2Go+ qd8B7hsZ0LBJ9BczmFr4OK2pNyBIm+v9g9+tzeiGf0kS+aQ9Tf8vw4VUYa4e9NxA pC3Wxqi2/6ImuGAcPim+ZBPUbxPJ7qPMiRAYNjZSI5pLU7kfsPE7t8usD+gquhq5 UXScuF18F8g5B28v4JkFjE1O4fU5R8nEq3BzLJAZANzMN3iVsV1ozOACqUFmbMVS HgIchOczyh6kpgH0mzA9 =5Jw3 -----END PGP SIGNATURE----- --=-cR7Q3lHvC3gXNORUzYAr-- From nobody Tue Sep 6 07:08: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 94A4212B1EC for ; Tue, 6 Sep 2016 07:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 FPaXpEAoKqES for ; Tue, 6 Sep 2016 07:08:28 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 2C38612B1D4 for ; Tue, 6 Sep 2016 07:08:23 -0700 (PDT) X-AuditID: 1209190f-ca7ff70000005401-d1-57cecdd6237f 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 (Symantec Messaging Gateway) with SMTP id 7D.C2.21505.6DDCEC75; Tue, 6 Sep 2016 10:08: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 u86E8LAt027220; Tue, 6 Sep 2016 10:08:21 -0400 Received: from [18.101.8.250] (vpn-18-101-8-250.mit.edu [18.101.8.250]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u86E8IvO019009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 6 Sep 2016 10:08:20 -0400 To: Stephen Farrell , Benjamin Kaduk , Jeffrey Altman References: <147276103576.32168.16561985797578576426.idtracker@ietfa.amsl.com> <9b612ac1-0288-dc0f-92b6-9045691ea872@secure-endpoints.com> <8d70c265-cb18-fb41-bfc5-b3169eb2da06@cs.tcd.ie> From: Greg Hudson Message-ID: <2d8b46c6-cb98-fe6b-c465-8bbd92c82ba0@mit.edu> Date: Tue, 6 Sep 2016 10:08:18 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <8d70c265-cb18-fb41-bfc5-b3169eb2da06@cs.tcd.ie> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42IR4hTV1r129ly4wYwtxhZ/Vk5iszi6eRWL xfS919gdmD3Wdl9l81iy5CeTx8m+86wBzFFcNimpOZllqUX6dglcGS8fNLEXPGGp2NDTzN7A +Iq5i5GTQ0LARKL3fhdbFyMXh5BAG5PEozezWCGcDYwSP/4/ZYdwjjBJbJh+jxHEERaYyShx dVc/mCMiMIFRYu7H9cwQZd8YJfbu62AFmcwsICyxfM1ZNhCbTUBZYv3+rSwgNq+AlcSf261g NSwCKhJTVzcygdiiAhESt1Z9ZISoEZQ4OfMJWD2ngK3E2fNv2SFm6knsuP4Lar68xPa3c5gn MArMQtIyC0nZLCRlCxiZVzHKpuRW6eYmZuYUpybrFicn5uWlFuma6OVmluilppRuYgQHsST/ DsY5Dd6HGAU4GJV4eCt2nwsXYk0sK67MPcQoycGkJMqrFggU4kvKT6nMSCzOiC8qzUktPsQo wcGsJMLbfQIox5uSWFmVWpQPk5LmYFES5+2acSBcSCA9sSQ1OzW1ILUIJivDwaEkwXvzDFCj YFFqempFWmZOCUKaiYMTZDgP0PAdIDW8xQWJucWZ6RD5U4y6HAt+3F7LJMSSl5+XKiXO23ca qEgApCijNA9uDjj5pHL8esUoDvSWMO82kFE8wMQFN+kV0BImoCXrdp8GWVKSiJCSamC0Z3r+ NFtSl7uxx+LrFAmGNUULg1/IBLyS9Y3cu9N+qbX561NTXdNfTpiaJia98WrkdCYmoQPCW30e 7frX0iG5mvHIvmKe7FdCU1dNeZf0fNX35DMH5Fa9ffi1SesGT9xbLtN9p6evSlr0kq1+pt77 NauaZc4u35CxNuHjkUX3909fvMdFbMavNCWW4oxEQy3mouJEACr/M54ZAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Document Action: 'AES Encryption with HMAC-SHA2 for Kerberos 5' to Informational RFC (draft-ietf-kitten-aes-cts-hmac-sha2-11.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, 06 Sep 2016 14:08:34 -0000 On 09/05/2016 08:52 PM, Stephen Farrell wrote: >> On Fri, 2 Sep 2016, Jeffrey Altman wrote: >>> Now that approval has been obtained from the IESG, can the encryption >>> and checksum type numbers be allocated by the working group or do we >>> have to wait for an IANA action? > If getting numbers assigned is important, please say why and > we can see if it can happen sooner. Shouldn't be too long at > all though. MIT krb5 and Heimdal are both interested in including aes-sha2 support in their next releases, but can't even add code to their respective master branches without IANA assignments. From nobody Tue Sep 6 09:14:49 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 230F1127058 for ; Tue, 6 Sep 2016 09:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.809 X-Spam-Level: X-Spam-Status: No, score=-5.809 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.508, 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 05GWMfuN3IBS for ; Tue, 6 Sep 2016 09:14:44 -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 A487412B05F for ; Tue, 6 Sep 2016 09:14:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 63482BE57; Tue, 6 Sep 2016 17:14:43 +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 Ft-WBKYQaCo2; Tue, 6 Sep 2016 17:14:42 +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 B9B54BE56; Tue, 6 Sep 2016 17:14:41 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1473178482; bh=mYzSD0sO3+waYecXmptocPD3Qe3R0QxPbbfy0obCOVI=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=09eZez3gM3394LTTZAXw8XmjqFg1CpJgmoy4Rv2BFiNu2jKAX+WF8rTLqv1G5dUUr ON4I4NB6lrQ4eETOfZE48d4OHWrDPyM8yQLZjG6/H1H+GNVanzlZYkPkdRT2hoUb2F iSS0xgwA39XVdVDH66jeJT2BkWyOHQGdKNqlxi4M= To: Greg Hudson , Benjamin Kaduk , Jeffrey Altman References: <147276103576.32168.16561985797578576426.idtracker@ietfa.amsl.com> <9b612ac1-0288-dc0f-92b6-9045691ea872@secure-endpoints.com> <8d70c265-cb18-fb41-bfc5-b3169eb2da06@cs.tcd.ie> <2d8b46c6-cb98-fe6b-c465-8bbd92c82ba0@mit.edu> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 6 Sep 2016 17:14:41 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <2d8b46c6-cb98-fe6b-c465-8bbd92c82ba0@mit.edu> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030208070802050602030005" Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] Document Action: 'AES Encryption with HMAC-SHA2 for Kerberos 5' to Informational RFC (draft-ietf-kitten-aes-cts-hmac-sha2-11.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, 06 Sep 2016 16:14:47 -0000 This is a cryptographically signed message in MIME format. --------------ms030208070802050602030005 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, I'm checking with IANA if we can speed things up. Cheers, S. On 06/09/16 15:08, Greg Hudson wrote: > On 09/05/2016 08:52 PM, Stephen Farrell wrote: >>> On Fri, 2 Sep 2016, Jeffrey Altman wrote: >>>> Now that approval has been obtained from the IESG, can the encryptio= n >>>> and checksum type numbers be allocated by the working group or do we= >>>> have to wait for an IANA action? >=20 >> If getting numbers assigned is important, please say why and >> we can see if it can happen sooner. Shouldn't be too long at >> all though. >=20 > MIT krb5 and Heimdal are both interested in including aes-sha2 support > in their next releases, but can't even add code to their respective > master branches without IANA assignments. >=20 --------------ms030208070802050602030005 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA5MDYx NjE0NDFaMC8GCSqGSIb3DQEJBDEiBCDy46P5f1Zw9chQ7h4cn6LBZT092fbG21wFxWo7wdwJ /TBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBbGeTEiXVfrVKfukjlHTvR/iEOP4rsJ+c4R3g02WvSos2nyu/Xm/uD dM15qJXuwjlMdNoP4+6rsNTNc4quyussndSovlZpqnJL2EHOFpysyKRHdz4ZKejhf2zFHlNh ixOm+pueBzoZ37nrQSivy2mLGmopLVvhNlYe6mGO4VbEBngdNb/IOLjTnmY8w8BUDjnTO07A y8vAvlyKzZOlG5DT8+ZerzaEiwP/ax/LxXhGDqXxNOUML7LzX0ODjlxScLk16Qo/BK0rRzOy XqYEQ+tbZmloYcmaGhHjgMHO6pdTXymxlBxemNPe6uukyDndNPc3Tkw6/fR/wHN8nP/MMfdF AAAAAAAA --------------ms030208070802050602030005-- From nobody Tue Sep 6 10:07:44 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 00BC512B040 for ; Tue, 6 Sep 2016 10:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.728 X-Spam-Level: X-Spam-Status: No, score=-5.728 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Xq1PD_K2sKlJ for ; Tue, 6 Sep 2016 10:07:41 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 A98A712B100 for ; Tue, 6 Sep 2016 10:07:41 -0700 (PDT) X-AuditID: 1209190e-343ff70000000ab6-32-57cef7db9663 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 91.B8.02742.BD7FEC75; Tue, 6 Sep 2016 13:07:40 -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 u86H7d7r024814 for ; Tue, 6 Sep 2016 13:07:39 -0400 Received: from [18.101.8.250] (vpn-18-101-8-250.mit.edu [18.101.8.250]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u86H7b8K005407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 6 Sep 2016 13:07:39 -0400 References: <147312824910.3005.15896054332400043476.idtracker@ietfa.amsl.com> To: kitten@ietf.org From: Greg Hudson Message-ID: Date: Tue, 6 Sep 2016 13:07:37 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147312824910.3005.15896054332400043476.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBIsWRmVeSWpSXmKPExsUixG6nonvn+7lwgzUfpC2Obl7F4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGXnm9kL9jJWzD3Vx9jAOI2xi5GTQ0LARGLOoadsILaQQBuT xORpul2MXED2MUaJ6ffesEA4t5gk7nTPZgWpEhZwlbjz4SArRIevxIfp75lBbBEBYYndW9+B 2WwCyhLr929lAbF5BawkfszbAVbPIqAisXj7FrBtogIRErdWfWSEqBGUODnzCVg9p4CfxMuX k5lAbGYBPYkd13+xQtjyEtvfzmGewMg/C0nLLCRls5CULWBkXsUom5JbpZubmJlTnJqsW5yc mJeXWqRrrJebWaKXmlK6iREUfJySfDsYJzV4H2IU4GBU4uGt2H0uXIg1say4MvcQoyQHk5Io r1ogUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb+03oBxvSmJlVWpRPkxKmoNFSZy3a8aBcCGB 9MSS1OzU1ILUIpisDAeHkgSvBUijYFFqempFWmZOCUKaiYMTZDgP0PB6sOHFBYm5xZnpEPlT jMYcz6ZdW8vEseDH7bVMQix5+XmpUuK8nV+BSgVASjNK8+CmgRNIKsevV4ziQM8J804FGcgD TD5w814BrWICWrVu92mQVSWJCCmpBkZfITvtCzn/+plz9ojIXy2vX6e27/rX89vvTvuqGMmV 9uNr8+3fU6bHmef/Xmqz9FoTq/hlBd3Tt//cdzRRs6p7evxoz6qzu3aXFT2WK5xd0HJU9t7/ l7fPeoXo/Xrn8GHn2lb2FfLKdjJPLjxuj6mLZqv5V75PVJDFS+6WmnXqRsMT97wqq5OVWIoz Eg21mIuKEwGXs6kC+wIAAA== Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-rfc6112bis-02.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, 06 Sep 2016 17:07:43 -0000 On 09/05/2016 10:17 PM, internet-drafts@ietf.org wrote: > Filename : draft-ietf-kitten-rfc6112bis-02.txt I have reviewed the changes in this draft, and they look okay to me. From nobody Tue Sep 6 20:53:49 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 CBA1C12B159 for ; Tue, 6 Sep 2016 20:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.709 X-Spam-Level: X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, 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 kq-4gDzivGqL for ; Tue, 6 Sep 2016 20:53:46 -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 A104D12B135 for ; Tue, 6 Sep 2016 20:53:45 -0700 (PDT) X-AuditID: 12074425-f77ff70000002858-79-57cf8f486daa 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 (Symantec Messaging Gateway) with SMTP id BB.22.10328.84F8FC75; Tue, 6 Sep 2016 23:53: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 u873riQb031857 for ; Tue, 6 Sep 2016 23:53: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 u873rfJF003183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 6 Sep 2016 23:53:43 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u873recg013273; Tue, 6 Sep 2016 23:53:40 -0400 (EDT) Date: Tue, 6 Sep 2016 23:53:40 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: <1472155358.25965.9.camel@redhat.com> Message-ID: References: <1472155358.25965.9.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-730303982-1473220420=:5272" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMIsWRmVeSWpSXmKPExsUixCmqrOvRfz7c4P5rdYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEro+P2QdaCh3wVMxumMTUwvufuYuTkkBAwkTjZepS5i5GLQ0ig jUniS88yKOcYo8T7pR3sEM51JomlLw6ygbQICdRLvN5+FMxmEdCS+DZrM5jNJqAiMfPNRjBb REBYYvfWd8wgtrCAusTTry/YQWxOASOJZ8tfMYLYvAIOEpM79jFDzEyTeH3/MwuILSqgI7F6 /xQWiBpBiZMzn4DZzAL+EkteXGeewMg/C0lqFpIUhK0uceDTRUYIW1vi/s02tgWMLKsYZVNy q3RzEzNzilOTdYuTE/PyUot0LfRyM0v0UlNKNzGCwpLdRXUH45y/XocYBTgYlXh4K3afCxdi TSwrrsw9xCjJwaQkyqsWCBTiS8pPqcxILM6ILyrNSS0+xCjBwawkwnu593y4EG9KYmVValE+ TEqag0VJnLdrxoFwIYH0xJLU7NTUgtQimKwMB4eSBO8TkEbBotT01Iq0zJwShDQTByfIcB6g 4fPBhhcXJOYWZ6ZD5E8xKkqJ8yaAJARAEhmleXC94LSxm0n1FaM40CvCvDl9QFU8wJQD1/0K aDAT0OB1u0+DDC5JREhJNTAumrFWkquM/0KJj1bMXJ8Sl6RX8kKnr39zTPfcwiXunn9Y/zXT BcH4G8c/mLFa75/qZH56URfv7SgOs6Of1rLcUVrCV2cauHChG9Pq5663PvW98+001Gmcn2/D KuR3rvF/0sXTK6R/N038ZqDweoqXyXH32bczPwSe2jSvRuzY0klNMZ4GKQ+UWIozEg21mIuK EwEJLYlv9gIAAA== Archived-At: Subject: Re: [kitten] meeting in Seoul? 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, 07 Sep 2016 03:53:48 -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-730303982-1473220420=:5272 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE We've heard from Nathaniel; are there any other topics of interest at of before Seoul? -Ben On Thu, 25 Aug 2016, Nathaniel McCallum wrote: > On Wed, 2016-08-24 at 20:53 -0400, Benjamin Kaduk wrote: > > Hi all, > > > > Session requests are now open for IETF 97 in Seoul (November 13- > > 18).=C2=A0=C2=A0Does > > anyone have topic(s) they would like to cover there?=C2=A0=C2=A0If ther= e are no > > responses, I will assume that we will not meet and submit a session > > request to that effect. > > > > Please send in any topics by September 7. > > I would definitely like to discuss my three outstanding drafts: > =C2=A0 * Authentication Indicators > =C2=A0 * URI Discovery > =C2=A0 * SPAKE Preauth > > This discussion doesn't have to be in Seoul, though I may be there for > other reasons. > > In the case of Authentication Indicators, the authors feel this draft > is complete and is ready for WGLC. > > Regarding the other two drafts, I am about to issue new revisions > (today or tomorrow). I would very much like them to be adopted by the > working group. > > In the case of URI Discovery, we are close to merging a patch > supporting the feature. > =C2=A0 =C2=A0=C2=A0https://github.com/krb5/krb5/pull/481 > > In the case of SPAKE, we have a basic implementation working and plan > to expand it to support second features in the coming months. > =C2=A0 =C2=A0=C2=A0https://github.com/greghudson/krb5/tree/spake > > We would very much like to move these drafts along as quickly as > possible. > > Nathaniel > ---559023410-730303982-1473220420=:5272-- From nobody Tue Sep 13 07:57:08 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 E641F12B5C4; Tue, 13 Sep 2016 07:57:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.33.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147377862690.23612.8346486741220416524.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2016 07:57:06 -0700 Archived-At: Cc: kitten@ietf.org, kitten-chairs@ietf.org Subject: [kitten] kitten - Not having a session at IETF 97 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, 13 Sep 2016 14:57:07 -0000 Benjamin Kaduk, a chair of the kitten working group, indicated that the kitten working group does not plan to hold a session at IETF 97. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Tue Sep 13 08:58:21 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 8BDE912B3E6 for ; Tue, 13 Sep 2016 08:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.729 X-Spam-Level: X-Spam-Status: No, score=-5.729 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, 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 NU6cudq-wNL1 for ; Tue, 13 Sep 2016 08:58:10 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 4FE0B12B3D7 for ; Tue, 13 Sep 2016 08:30:24 -0700 (PDT) X-AuditID: 1209190e-39fff70000004b7a-a8-57d81b8eb96d 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 (Symantec Messaging Gateway) with SMTP id F2.C4.19322.E8B18D75; Tue, 13 Sep 2016 11:30:23 -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 u8DFUMJO003781 for ; Tue, 13 Sep 2016 11:30:22 -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 u8DFUJfd002791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 13 Sep 2016 11:30:22 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8DFUIEj011552; Tue, 13 Sep 2016 11:30:18 -0400 (EDT) Date: Tue, 13 Sep 2016 11:30:18 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: <1472155358.25965.9.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-2113249073-1473780618=:5272" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixCmqrdsvfSPc4LK/xdHNq1gcGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJVxsP03U8FzwYrP3zvYGxi7+boYOTkkBEwk3r1YxNTFyMUhJNDG JDH9zyF2COc4o8Ty1u9Qzg0mibsLJjNCOA2MEq1HD7GC9LMIaEu8/9nMDmKzCahIzHyzkQ3E FhEQlti99R0ziC0soC7x9OsLsBpOAUeJd6+mgdXwCjhIzPv0D2robEaJd3fegBWJCuhIrN4/ hQWiSFDi5MwnYDazQIDEzs0vGCcw8s9CkpqFJAVhq0sc+HQRytaWuH+zjW0BI8sqRtmU3Crd 3MTMnOLUZN3i5MS8vNQiXWO93MwSvdSU0k2M4MCU5NvBOKnB+xCjAAejEg9vwI/r4UKsiWXF lbmHGCU5mJREeeevAQrxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4X0neiNciDclsbIqtSgfJiXN waIkzts140C4kEB6YklqdmpqQWoRTFaGg0NJgrdICqhRsCg1PbUiLTOnBCHNxMEJMpwHaLgn SA1vcUFibnFmOkT+FKOilDhvtCRQQgAkkVGaB9cLThy7mVRfMYoDvSLM2wjSzgNMOnDdr4AG MwEN3gLyEW9xSSJCSqqBsW+J9DtJDWaN5l7jkvKJMWWrmQojr26o2h7lsLZ1qcNl1RkWN6r2 vPmn214btnVqmmtbmpDKjdNxj+89iYqZud7grQmj66/laRW8Trs7zx3dbFtvXLd38UL9LzOm Pmz7wWpwriHmeblscNmjiN11UwNbeXafyd+6oPyBRsCvm/KtKU8FdI5eVmIpzkg01GIuKk4E AJdnOuj3AgAA Archived-At: Subject: Re: [kitten] meeting in Seoul? 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, 13 Sep 2016 15:58:20 -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-2113249073-1473780618=:5272 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Having heard nothing else, I have submitted a "no meeting requested" meeting request, which should have sent mail here. If we do come up with additional topics, there is still a couple weeks in which we could change the request, if needed. -Ben On Tue, 6 Sep 2016, Benjamin Kaduk wrote: > We've heard from Nathaniel; are there any other topics of interest at of > before Seoul? > > -Ben > > On Thu, 25 Aug 2016, Nathaniel McCallum wrote: > > > On Wed, 2016-08-24 at 20:53 -0400, Benjamin Kaduk wrote: > > > Hi all, > > > > > > Session requests are now open for IETF 97 in Seoul (November 13- > > > 18).=C2=A0=C2=A0Does > > > anyone have topic(s) they would like to cover there?=C2=A0=C2=A0If th= ere are no > > > responses, I will assume that we will not meet and submit a session > > > request to that effect. > > > > > > Please send in any topics by September 7. > > > > I would definitely like to discuss my three outstanding drafts: > > =C2=A0 * Authentication Indicators > > =C2=A0 * URI Discovery > > =C2=A0 * SPAKE Preauth > > > > This discussion doesn't have to be in Seoul, though I may be there for > > other reasons. > > > > In the case of Authentication Indicators, the authors feel this draft > > is complete and is ready for WGLC. > > > > Regarding the other two drafts, I am about to issue new revisions > > (today or tomorrow). I would very much like them to be adopted by the > > working group. > > > > In the case of URI Discovery, we are close to merging a patch > > supporting the feature. > > =C2=A0 =C2=A0=C2=A0https://github.com/krb5/krb5/pull/481 > > > > In the case of SPAKE, we have a basic implementation working and plan > > to expand it to support second features in the coming months. > > =C2=A0 =C2=A0=C2=A0https://github.com/greghudson/krb5/tree/spake > > > > We would very much like to move these drafts along as quickly as > > possible. > > > > Nathaniel > > ---559023410-2113249073-1473780618=:5272-- From nobody Fri Sep 23 15:25:31 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 A432D12BCBB for ; Fri, 23 Sep 2016 15:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.237 X-Spam-Level: X-Spam-Status: No, score=-9.237 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 o5FDWtpsiI82 for ; Fri, 23 Sep 2016 15:25:27 -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 DE11E12BC9D for ; Fri, 23 Sep 2016 15:25:27 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8AA3365D1B; Fri, 23 Sep 2016 22:25:27 +0000 (UTC) Received: from dhcp137-207.rdu.redhat.com (dhcp137-207.rdu.redhat.com [10.13.137.207]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8NMPLce026540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 23 Sep 2016 18:25:26 -0400 Message-ID: <1474669521.30344.15.camel@redhat.com> From: Nathaniel McCallum To: kitten@ietf.org Date: Fri, 23 Sep 2016 18:25:21 -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.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 23 Sep 2016 22:25:27 +0000 (UTC) Archived-At: Cc: Matt Rogers , Simo Sorce Subject: [kitten] New URI Discovery Draft 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: Fri, 23 Sep 2016 22:25:29 -0000 https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-disc overy/ I've submitted a new version of the draft. This version matches the code that is now merged into MIT Kerberos. We need to move forward. If that is as an individual submission, then so be it. But we really can't wait any longer. So unless I hear some noise to the contrary ASAP, I plan to go this route. Nathaniel From nobody Sat Sep 24 09:30:03 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 85228127A90 for ; Sat, 24 Sep 2016 09:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.218 X-Spam-Level: X-Spam-Status: No, score=-9.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, 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 YKIx7Fw-LTCL for ; Sat, 24 Sep 2016 09:29:59 -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 42F7F127071 for ; Sat, 24 Sep 2016 09:29:59 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8AF95B815B for ; Sat, 24 Sep 2016 16:29:58 +0000 (UTC) Received: from pspacek.brq.redhat.com (ovpn-204-24.brq.redhat.com [10.40.204.24]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8OGTtit001245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Sep 2016 12:29:57 -0400 To: Nathaniel McCallum , kitten@ietf.org References: <1474669521.30344.15.camel@redhat.com> From: Petr Spacek Organization: Red Hat Message-ID: Date: Sat, 24 Sep 2016 18:29:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1474669521.30344.15.camel@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Sat, 24 Sep 2016 16:29:58 +0000 (UTC) Archived-At: Cc: Matt Rogers , Simo Sorce Subject: Re: [kitten] New URI Discovery Draft 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: Sat, 24 Sep 2016 16:30:01 -0000 On 24.9.2016 00:25, Nathaniel McCallum wrote: > https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-disc > overy/ > > I've submitted a new version of the draft. This version matches the > code that is now merged into MIT Kerberos. > > We need to move forward. If that is as an individual submission, then > so be it. But we really can't wait any longer. So unless I hear some > noise to the contrary ASAP, I plan to go this route. Hello, in general it makes sense. The new URI format opened an encoding-Pandora-box so it needs more work to make it fully specified. Here are nits I found in the 03 version of the draft: 1] > 4. Required URI Format > krb5srv:[flags]:transport:residual Nitpick: I do not really like naming "transport:residual". Something like "transport-type:transport-options" would be more descriptive. 2] Is this a good idea? > Flags are not considered critical, therefore flags that are not used > or unknown to the implementation SHOULD be ignored. Just wondering out loud, not insisting on it: If we say there is no criticality, it will be impossible to add later on. What about using capitalization to indicate criticality of a flag? Records with critical but unsupported flags should be skipped as if there were not present in DNS. Records with non-critical unsupported flags should be used as usual. Or maybe we can limit valid flags to lowercase ASCII letters for now so there is a room for extension in future? 3] In any case, there is disagreement between > 4.2. Flags > This field contains a sequence of zero or more case-insensitive vs. > 9.1. Kerberos Server Discovery Flags > 9.1.1. Registration Template > Value: A single unique ASCII character that identifies the entry, "A single unique ASCII character" is case-sensitive by definition. This conflicts with case-insensitivity defined in 4.2. 3] The draft is not clear on whether transport field is case-sensitive or not. > 4.3. Transport > 9.2. Kerberos Server Discovery Transport Types 4] Residual formats are not sufficiently specified: > 4.4. Residual > 9.2. Kerberos Server Discovery Transport Types > 9.2.2. Initial Registry Contents > > o Value: "udp" > o Description: User Datagram Protocol > o Residual Format: "host[:port]" > o Case Sensitive: None > o Default KDC Port: 88 > o Default Admin Service Port: 749 > o Default Password Service Port: 464 > o Reference: [RFC0768] There is no definition of "host" and there is none in RFC 768. Can it be IP(v?) address? Can it be DNS name? How this field should be encoded into the URI? > o Value: "tcp" > o Description: Transport Control Protocol > o Residual Format: "host[:port]" > o Case Sensitive: None > o Default KDC Port: 88 > o Default Admin Service Port: 749 > o Default Password Service Port: 464 > o Reference: [RFC0793] Again there is no definition of "host". Can it be IP(v?) address? Can it be DNS name? How this field should be encoded into the URI? > o Value: "kkdcp" > o Description: Kerberos Key Distribution Center Proxy Protocol > o Residual Format: https://host[:port][/path] This is technically URI inside URI, am I right? How is it encoded? Should usual %-encoding be used here? > 10.1. URI Format Examples suggest that %-encoding is not used. I would like to see this clearly specified and explained why not. At this point I would rather say "use URL as specified by [MS-KKDCP]" instead of specifying "https://host[:port][/path]". Also, to make this bullet-proof, I would mention that "/KdcProxy" must be explicitly specified in the URI record and is not implicitly assumed by clients. > o Case Sensitive: [/path] > o Default KDC Port: 443 > o Default Admin Service Port: 443 > o Default Password Service Port: 443 > o Reference: [MS-KKDCP] Other than that it makes sense and I'm looking forward to see this deployed! -- Petr^2 Spacek From nobody Sun Sep 25 16:20:42 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 D1F8412B040; Sun, 25 Sep 2016 16:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, 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 d9wiQBHHRgQn; Sun, 25 Sep 2016 16:20:35 -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 AB53612B047; Sun, 25 Sep 2016 16:20:29 -0700 (PDT) X-AuditID: 12074425-ed7ff700000024c2-1f-57e85bbb613e 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 8A.53.09410.BBB58E75; Sun, 25 Sep 2016 19:20:28 -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 u8PNKRYN024441; Sun, 25 Sep 2016 19:20:27 -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 u8PNKOiC014786 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 25 Sep 2016 19:20:26 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8PNKNf5007354; Sun, 25 Sep 2016 19:20:23 -0400 (EDT) Date: Sun, 25 Sep 2016 19:20:23 -0400 (EDT) From: Benjamin Kaduk To: draft-ietf-kitten-krb-auth-indicator@ietf.org 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+NgFjrIIsWRmVeSWpSXmKPExsUixG6nrrsn+kW4wdlz/BaHb+xitzi6eRWL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyjh/tZCmYL1fx8OYV9gbGGxJdjJwcEgImEn3XzjF1 MXJxCAm0MUmc/X+LBcLZyCjx9d59KOcQk8TJGWuYQVqEBBoYJRY89u1iZOdgEdCWOJgEEmUT UJGY+WYjWxcjB4eIgKHEyx4dkDCzgLDE+nMzwBqFBZwlvs17xgJi8wo4SBz9uAXMFhXQkVi9 fwpUXFDi5MwnLBC9WhLLp29jmcDINwtJahaS1AJGplWMsim5Vbq5iZk5xanJusXJiXl5qUW6 Fnq5mSV6qSmlmxjBIeWiuoNxzl+vQ4wCHIxKPLwLjj4PF2JNLCuuzD3EKMnBpCTKO+sCUIgv KT+lMiOxOCO+qDQntfgQowQHs5II79fQF+FCvCmJlVWpRfkwKWkOFiVx3q4ZB8KFBNITS1Kz U1MLUotgsjIcHEoSvC+igBoFi1LTUyvSMnNKENJMHJwgw3mAhteC1PAWFyTmFmemQ+RPMSpK ifMygSQEQBIZpXlwveCY382k+opRHOgVYd5wkCoeYLqA634FNJgJaPC3O09ABpckIqSkGhgF DOdblSzM2Zq5O1bYZs3890f6DvuXGD3NElh22Yv7XeWpXbnN2SdOc015lXzu3NTOlw0RB2+W pIsUdzAcbjtqzqH9MGTRpY5Jy1J0d5tw3M2dLJTge+Tqej9xp5TwYo/JwdJ+q48l5z4yXcMx Xb6A68SzNB8HPiE3efd/oftd/Vv+mv4q2abEUpyRaKjFXFScCADKpzqJ1AIAAA== Archived-At: Cc: kitten@ietf.org Subject: [kitten] shepherd review of draft-ietf-kitten-krb-auth-indicator-02 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, 25 Sep 2016 23:20:41 -0000 Hi all, I've completed my shepherd review of draft-ietf-kitten-krb-auth-indicator-02, and unfortunately it seems that an additional revision may be needed. It feels like some parts of the document are written as if the "short strings" for comparison against known values are only for use when presented back to the KDC, but other parts of the document describe it as being used for policy decisions made by application services as well as the KDC. (If it was just the KDC that was handling it, the document would not need to specify, since KDC-internal things need not necessarily interoperate the way that public protocol elements do.) There is also the possibility (probability, really), of site-local values that are specific to a given realm. This is perhaps implied by the mention of "the name of the Pre-Authentication mechanism used" but not stated explicitly. The interoperability requirements for site-local values are less stringent, but there still needs to be a clear understanding of what the contents of the protocol field should be. So, I think that section 3 should be more stringent, saying something like "strings that contain a colon character MUST be URIs that reference a Level of Assurance Profile, leaving other strings available for site-local use". I also suspect that the last paragraph of the security considerations should be rewritten in a normative fashion and moved to section 3, to make it clear what the presence of a given string in the authdata indicates. (Do we know of reasons why someone might use this AD element to indicate something other than a positive indication that the indicated requirements were met during the initial authentication?) There's also some matter of form regarding the string "AD-AUTHENTICATION-INDICATOR", which should probably just be used for the definition of the ASN.1 type; the value 97 is the ad-type for which the contents of-the ad-data field will be the DER encoding of the AD-AUTHENTICATION-INDICATOR object. So, I would just say "The KDC MAY include authorization data of ad-type 97, wrapped in AD-CAMMAC, [...]" and skip the line that's just AD-AUTHENTICATION-INDICATOR 97 (and replace the colon with a full stop). Some other editorial notes: In the Abstract, s/the service tickets/service tickets/ In the Introduction, hyphenate "password-based". It's probably good to mention "or other preauthentication schemes" after public-key cryptography (which, hmm, should probably also be hyphenated), and make it into a comma-separated list. Is "have" the best word in "[i]mplmentations that have pre-authentication-mechanisms [...]"? Maybe "offer", "support", or "provide"? In the last sentence of the first paragraph, maybe "strength of the authentication that was used, for use as an input" would remove some ambiguity. In the second paragraph, maybe "to convey authentication strength information", and "Elements of this type [will|MUST] appear within an AD-CAMMAC". Also, it's probably worth a clause briefly saying why the CAMMAC is needed (to provide authenticity/integrity when a ticket is presented back to the KDC). The 2119 boilerplate doesn't list "NOT RECOMMENDED" but you don't use it, so maybe it doesn't need to change. In Section 3, it may be better to split the first sentence into two, so "The KDC MAY copy it from a ticket-granting ticket into service tickets" is a separate sentence, since the KDC can do the first without ever needing to do the latter. Still in Section 3, put a comma before "such as the name of the Pre-Authentication mechanism used". (Also, I sort-of want to ask "how short is a short string?", but there's not really a useful answer to give, particularly since the LoA URIs are in play and are likely to be longer than non-URI strings.) Thanks, Ben From nobody Mon Sep 26 08:21:24 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 E856312B29F for ; Mon, 26 Sep 2016 08:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ksV7mEN-LnAc for ; Mon, 26 Sep 2016 08:21:21 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 04F1612B23A for ; Mon, 26 Sep 2016 08:21:18 -0700 (PDT) X-AuditID: 1209190c-ecfff700000039c9-7c-57e93ced7baf 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 (Symantec Messaging Gateway) with SMTP id 0E.A4.14793.DEC39E75; Mon, 26 Sep 2016 11:21:17 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id u8QFLG4i019374 for ; Mon, 26 Sep 2016 11:21:17 -0400 Received: from [18.101.8.139] (vpn-18-101-8-139.mit.edu [18.101.8.139]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8QFLF3I021433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 26 Sep 2016 11:21:16 -0400 To: kitten@ietf.org References: <1474669521.30344.15.camel@redhat.com> From: Greg Hudson Message-ID: <82ede944-b10a-f760-338e-f43cad6ef7c7@mit.edu> Date: Mon, 26 Sep 2016 11:21:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUixCmqrfvW5mW4wdLLmhZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsz+XawFq7gr1qxextjA+IOji5GTQ0LARGLq/8tsXYxcHEIC bUwSB95OZIRwjjNK3LkwmxnCuc0k8fL7XXaQFmEBXYmztxpYQGwRAWGJ3VvfARVxABWlSXze 7AASZhNQlli/fysLSJhXwEpi68MgkDCLgKrEntt/mEFsUYEIiVurPjKC2LwCghInZz4Bm8gp YCdx9EYjG4jNLKAnseP6L1YIW15i+9s5zBMY+WchaZmFpGwWkrIFjMyrGGVTcqt0cxMzc4pT k3WLkxPz8lKLdA31cjNL9FJTSjcxgkNPkmcH45k3XocYBTgYlXh4PQ4/DxdiTSwrrsw9xCjJ waQkyitj/DJciC8pP6UyI7E4I76oNCe1+BCjBAezkgjvFnOgHG9KYmVValE+TEqag0VJnLdr xoFwIYH0xJLU7NTUgtQimKwMB4eSBO9fa6BGwaLU9NSKtMycEoQ0EwcnyHAeoOGSNiDDiwsS c4sz0yHypxgVpcR5/1sBJQRAEhmleXC94NSQytH9ilEc6BVhXn+Qdh5gWoHrfgU0mAlo8NIT L0AGlyQipKQaGA8HxB/lVeDQ+LPjwvUgf4djDW9ZpzdnaYYu7vA1t6v8ePfT75iWBfkLFx2e d+brM6U9i/Xe1kcuEtgVspCLgbvY7oGrL3tQPv/D/ly2nVzvpTQurDt7oDZpN4NsSXDyRKfP JzlXBFVvu33X9X7Pji1H5R9PsbmYPtvyfOPkkhXM+mw2hqv+qSixFGckGmoxFxUnAgBOUaJf 6AIAAA== Archived-At: Subject: Re: [kitten] New URI Discovery Draft 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: Mon, 26 Sep 2016 15:21:23 -0000 On 09/24/2016 12:29 PM, Petr Spacek wrote: > Just wondering out loud, not insisting on it: > If we say there is no criticality, it will be impossible to add later on. I think that's fine. Let's not over-engineer this. > What about using capitalization to indicate criticality of a flag? It's definitely not worth introducing case-sensitivity to an otherwise case-insensitive DNS value format. > Or maybe we can limit valid flags to lowercase ASCII letters for now so there > is a room for extension in future? Criticality cannot be introduced later as an extension. But again, I don't think we need to engineer critical flags into this spec. Flags are only barely necessary at all. > There is no definition of "host" and there is none in RFC 768. > Can it be IP(v?) address? > Can it be DNS name? > How this field should be encoded into the URI? Per the implementation, it can be a DNS hostname, and IPv4 address, or an IPv6 address enclosed in square brackets. >> o Value: "kkdcp" >> o Description: Kerberos Key Distribution Center Proxy Protocol >> o Residual Format: https://host[:port][/path] > > This is technically URI inside URI, am I right? > How is it encoded? Should usual %-encoding be used here? % encoding is not used. Formally, you can imagine the https URI syntax being incorporated into the syntax of the krb5srv part. I'm not sure how best to express that in the document. From nobody Mon Sep 26 08:55:23 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 5C51F12B2F0 for ; Mon, 26 Sep 2016 08:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.218 X-Spam-Level: X-Spam-Status: No, score=-9.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, 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 EWqG_-UNnvnQ for ; Mon, 26 Sep 2016 08:55:20 -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 3257012B2D4 for ; Mon, 26 Sep 2016 08:55:20 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E6C446370D for ; Mon, 26 Sep 2016 15:55:19 +0000 (UTC) Received: from unused (unused [10.10.52.232] (may be forged)) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8QFtJTL010189; Mon, 26 Sep 2016 11:55:19 -0400 Message-ID: <1474905318.15526.31.camel@redhat.com> From: Matt Rogers To: Petr Spacek , Nathaniel McCallum , kitten@ietf.org Date: Mon, 26 Sep 2016 11:55:18 -0400 In-Reply-To: References: <1474669521.30344.15.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 26 Sep 2016 15:55:19 +0000 (UTC) Archived-At: Cc: Simo Sorce Subject: Re: [kitten] New URI Discovery Draft 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: Mon, 26 Sep 2016 15:55:22 -0000 On Sat, 2016-09-24 at 18:29 +0200, Petr Spacek wrote: > On 24.9.2016 00:25, Nathaniel McCallum wrote: > > > > https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service- > > disc > > overy/ > > > > I've submitted a new version of the draft. This version matches the > > code that is now merged into MIT Kerberos. > > > > We need to move forward. If that is as an individual submission, > > then > > so be it. But we really can't wait any longer. So unless I hear > > some > > noise to the contrary ASAP, I plan to go this route. > > Hello, > > in general it makes sense. The new URI format opened an encoding- > Pandora-box > so it needs more work to make it fully specified. Here are nits I > found in the > 03 version of the draft: > Hi Petr, thanks for reviewing!  > 1] > > > > 4.  Required URI Format > >    krb5srv:[flags]:transport:residual > Nitpick: I do not really like naming "transport:residual". Something > like > "transport-type:transport-options" would be more descriptive. > "transport-options" may make it seem that it's an optional field or carries something other than a hostname or URI for the client to contact. How about "transport-type:transport-target"? > > 2] Is this a good idea? > > > >    Flags are not considered critical, therefore flags that are not > > used > >    or unknown to the implementation SHOULD be ignored. > Just wondering out loud, not insisting on it: > If we say there is no criticality, it will be impossible to add later > on. > > What about using capitalization to indicate criticality of a flag? > Records > with critical but unsupported flags should be skipped as if there > were not > present in DNS. Records with non-critical unsupported flags should be > used as > usual. > > Or maybe we can limit valid flags to lowercase ASCII letters for now > so there > is a room for extension in future? I think avoiding having case-sensitive fields is the most appropriate thing to do for DNS data, our exception here being the path part of a KKDCP URL, which we can leave as defined by MS-KKDCP (see below) If we want to later add criticality to a flag then it could be a flag prepended by a '!' or some such character rather than using the case. > > > 3] In any case, there is disagreement between > > > > 4.2.  Flags > >    This field contains a sequence of zero or more case-insensitive > vs. > > > > 9.1.  Kerberos Server Discovery Flags > > 9.1.1.  Registration Template > >    Value:  A single unique ASCII character that identifies the > > entry, > > "A single unique ASCII character" is case-sensitive by definition. > This > conflicts with case-insensitivity defined in 4.2. > > > 3] The draft is not clear on whether transport field is case- > sensitive or not. > > > > 4.3.  Transport > > 9.2.  Kerberos Server Discovery Transport Types > I'll clear this up. > > 4] Residual formats are not sufficiently specified: > > > > 4.4.  Residual > > 9.2.  Kerberos Server Discovery Transport Types > > 9.2.2.  Initial Registry Contents > > > >    o Value: "udp" > >    o Description: User Datagram Protocol > >    o Residual Format: "host[:port]" > >    o Case Sensitive: None > >    o Default KDC Port: 88 > >    o Default Admin Service Port: 749 > >    o Default Password Service Port: 464 > >    o Reference: [RFC0768] > > There is no definition of "host" and there is none in RFC 768. > Can it be IP(v?) address? > Can it be DNS name? > How this field should be encoded into the URI? > > > > >    o Value: "tcp" > >    o Description: Transport Control Protocol > >    o Residual Format: "host[:port]" > >    o Case Sensitive: None > >    o Default KDC Port: 88 > >    o Default Admin Service Port: 749 > >    o Default Password Service Port: 464 > >    o Reference: [RFC0793] > > Again there is no definition of "host". > Can it be IP(v?) address? > Can it be DNS name? > How this field should be encoded into the URI? Good point, I'll clear this up as well. > > > > >    o Value: "kkdcp" > >    o Description: Kerberos Key Distribution Center Proxy Protocol > >    o Residual Format: https://host[:port][/path] > > This is technically URI inside URI, am I right? > How is it encoded? Should usual %-encoding be used here? > > > > 10.1.  URI Format Examples > suggest that %-encoding is not used. I would like to see this clearly > specified and explained why not. > > At this point I would rather say "use URL as specified by [MS-KKDCP]" > instead > of specifying "https://host[:port][/path]". I agree with this, especially since MS-KKDCP defines the URI with RFC3986 encoding rules. I think then the registration template can also leave out the case-sensitivity definition as the path is defined as case-sensitive with RFC3986. > > Also, to make this bullet-proof, I would mention that "/KdcProxy" > must be > explicitly specified in the URI record and is not implicitly assumed > by clients. > Sure, that makes sense.  Thanks again, Matt From nobody Mon Sep 26 09:01:55 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 E1B2412B303 for ; Mon, 26 Sep 2016 09:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.218 X-Spam-Level: X-Spam-Status: No, score=-9.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, 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 9LjAacgKhJzD for ; Mon, 26 Sep 2016 09:01:48 -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 6D82612B2FF for ; Mon, 26 Sep 2016 09:01:03 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 23D957EA96 for ; Mon, 26 Sep 2016 16:01:03 +0000 (UTC) Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.128.7]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8QG10LC014913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2016 12:01:02 -0400 To: Matt Rogers , Nathaniel McCallum , kitten@ietf.org References: <1474669521.30344.15.camel@redhat.com> <1474905318.15526.31.camel@redhat.com> From: Petr Spacek Organization: Red Hat Message-ID: Date: Mon, 26 Sep 2016 18:01:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1474905318.15526.31.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 26 Sep 2016 16:01:03 +0000 (UTC) Archived-At: Cc: Simo Sorce Subject: Re: [kitten] New URI Discovery Draft 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: Mon, 26 Sep 2016 16:01:55 -0000 On 26.9.2016 17:55, Matt Rogers wrote: > On Sat, 2016-09-24 at 18:29 +0200, Petr Spacek wrote: >> On 24.9.2016 00:25, Nathaniel McCallum wrote: >>> >>> https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service- >>> disc >>> overy/ >>> >>> I've submitted a new version of the draft. This version matches the >>> code that is now merged into MIT Kerberos. >>> >>> We need to move forward. If that is as an individual submission, >>> then >>> so be it. But we really can't wait any longer. So unless I hear >>> some >>> noise to the contrary ASAP, I plan to go this route. >> >> Hello, >> >> in general it makes sense. The new URI format opened an encoding- >> Pandora-box >> so it needs more work to make it fully specified. Here are nits I >> found in the >> 03 version of the draft: >> > > Hi Petr, thanks for reviewing! > >> 1] >>> >>> 4. Required URI Format >>> krb5srv:[flags]:transport:residual >> Nitpick: I do not really like naming "transport:residual". Something >> like >> "transport-type:transport-options" would be more descriptive. >> > > "transport-options" may make it seem that it's an optional field or > carries something other than a hostname or URI for the client to > contact. How about "transport-type:transport-target"? Sounds good. >> 2] Is this a good idea? >>> >>> Flags are not considered critical, therefore flags that are not >>> used >>> or unknown to the implementation SHOULD be ignored. >> Just wondering out loud, not insisting on it: >> If we say there is no criticality, it will be impossible to add later >> on. >> >> What about using capitalization to indicate criticality of a flag? >> Records >> with critical but unsupported flags should be skipped as if there >> were not >> present in DNS. Records with non-critical unsupported flags should be >> used as >> usual. >> >> Or maybe we can limit valid flags to lowercase ASCII letters for now >> so there >> is a room for extension in future? > > I think avoiding having case-sensitive fields is the most appropriate > thing to do for DNS data, our exception here being the path part of a > KKDCP URL, which we can leave as defined by MS-KKDCP (see below) > > If we want to later add criticality to a flag then it could be a flag > prepended by a '!' or some such character rather than using the case. Fine with me. The main point is that if we do not define criticality or at least reserved character now it will be impossible to enforce it on older clients. Maybe we can reserve "!" character now and say that character immediately following "!" must be ignored by clients implementing this version of the draft? >> 3] In any case, there is disagreement between >>> >>> 4.2. Flags >>> This field contains a sequence of zero or more case-insensitive >> vs. >>> >>> 9.1. Kerberos Server Discovery Flags >>> 9.1.1. Registration Template >>> Value: A single unique ASCII character that identifies the >>> entry, >> >> "A single unique ASCII character" is case-sensitive by definition. >> This >> conflicts with case-insensitivity defined in 4.2. >> >> >> 3] The draft is not clear on whether transport field is case- >> sensitive or not. >>> >>> 4.3. Transport >>> 9.2. Kerberos Server Discovery Transport Types >> > > I'll clear this up. > >> >> 4] Residual formats are not sufficiently specified: >>> >>> 4.4. Residual >>> 9.2. Kerberos Server Discovery Transport Types >>> 9.2.2. Initial Registry Contents >>> >>> o Value: "udp" >>> o Description: User Datagram Protocol >>> o Residual Format: "host[:port]" >>> o Case Sensitive: None >>> o Default KDC Port: 88 >>> o Default Admin Service Port: 749 >>> o Default Password Service Port: 464 >>> o Reference: [RFC0768] >> >> There is no definition of "host" and there is none in RFC 768. >> Can it be IP(v?) address? >> Can it be DNS name? >> How this field should be encoded into the URI? >> >>> >>> o Value: "tcp" >>> o Description: Transport Control Protocol >>> o Residual Format: "host[:port]" >>> o Case Sensitive: None >>> o Default KDC Port: 88 >>> o Default Admin Service Port: 749 >>> o Default Password Service Port: 464 >>> o Reference: [RFC0793] >> >> Again there is no definition of "host". >> Can it be IP(v?) address? >> Can it be DNS name? >> How this field should be encoded into the URI? > > Good point, I'll clear this up as well. > >> >>> >>> o Value: "kkdcp" >>> o Description: Kerberos Key Distribution Center Proxy Protocol >>> o Residual Format: https://host[:port][/path] >> >> This is technically URI inside URI, am I right? >> How is it encoded? Should usual %-encoding be used here? >>> >>> 10.1. URI Format Examples >> suggest that %-encoding is not used. I would like to see this clearly >> specified and explained why not. >> >> At this point I would rather say "use URL as specified by [MS-KKDCP]" >> instead >> of specifying "https://host[:port][/path]". > > I agree with this, especially since MS-KKDCP defines the URI with > RFC3986 encoding rules. I think then the registration template can also > leave out the case-sensitivity definition as the path is defined as > case-sensitive with RFC3986. > >> >> Also, to make this bullet-proof, I would mention that "/KdcProxy" >> must be >> explicitly specified in the URI record and is not implicitly assumed >> by clients. >> > > Sure, that makes sense. > > Thanks again, I'm happy to review it again. -- Petr^2 Spacek From nobody Mon Sep 26 09:28:40 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 4678C12B305; Mon, 26 Sep 2016 09:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 YSypOBtox-0b; Mon, 26 Sep 2016 09:28:31 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 EECF512B2BA; Mon, 26 Sep 2016 09:28:30 -0700 (PDT) X-AuditID: 1209190e-7fbff70000006339-1c-57e94cad88d6 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 (Symantec Messaging Gateway) with SMTP id 93.72.25401.DAC49E75; Mon, 26 Sep 2016 12:28: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 u8QGSTYo023009; Mon, 26 Sep 2016 12:28:29 -0400 Received: from [18.101.8.139] (vpn-18-101-8-139.mit.edu [18.101.8.139]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8QGSQB4017757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 26 Sep 2016 12:28:28 -0400 To: Benjamin Kaduk , draft-ietf-kitten-krb-auth-indicator@ietf.org References: From: Greg Hudson Message-ID: Date: Mon, 26 Sep 2016 12:28:26 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGIsWRmVeSWpSXmKPExsUixCmqrLvO52W4wUMvi8M3drFbHN28isWB yWPJkp9MAYxRXDYpqTmZZalF+nYJXBlX33awFOwRqjg8dwpLA+NRvi5GDg4JAROJljUsXYxc HEICbUwSdzYuYIRwNjJKfGpvYoNwjjJJLN3Yy9zFyMkhLBAk0bbpCCuILSIQJbF6/Tw2EFtI wEHixablYDazgLDE8jVnwWw2AWWJ9fu3soDYvAJWEov3HAeLswioSrw8sIYJxBYViJC4teoj I0SNoMTJmU/A6jkFHCUmdb1lgZipJ7Hj+i9WCFteYvvbOcwTGAVmIWmZhaRsFpKyBYzMqxhl U3KrdHMTM3OKU5N1i5MT8/JSi3SN9XIzS/RSU0o3MYKDU5JvB+OkBu9DjAIcjEo8vAuOPg8X Yk0sK67MPcQoycGkJMorY/wyXIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb7cXUI43JbGyKrUo HyYlzcGiJM7bNeNAuJBAemJJanZqakFqEUxWhoNDSYJXABiFQoJFqempFWmZOSUIaSYOTpDh PEDDL3mDDC8uSMwtzkyHyJ9iVJQS590OkhAASWSU5sH1gpNHKkf3K0ZxoFeEedVAVvAAEw9c 9yugwUxAg5eeeAEyuCQRISXVwCj4YPqOf0c71okwLQ+9sMPhztrFz23PJfAp3LzF/+vq396T 2sL68uHH3BLWlnw2aMoQXW0TZMrnVRa38uaPrN7TJ6RcxNu38Sp77+ifeEXj26G5PpIPVjxl NXvwgGFB2r7dL8tvLdiaX/J04pbQp//uy0+x6/4iajGRYdG+/VcNlJQD3h2wcTZTYinOSDTU Yi4qTgQAdkqNxfkCAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] shepherd review of draft-ietf-kitten-krb-auth-indicator-02 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: Mon, 26 Sep 2016 16:28:38 -0000 On 09/25/2016 07:20 PM, Benjamin Kaduk wrote: > It feels like some parts of the document are written as if the "short > strings" for comparison against known values are only for use when > presented back to the KDC, but other parts of the document describe it as > being used for policy decisions made by application services as well as > the KDC. Application servers can use auth indicators. What parts of the document imply that they are only used by the KDC? > So, I think that section 3 should be more stringent, saying something like > "strings that contain a colon character MUST be URIs that reference a > Level of Assurance Profile, leaving other strings available for > site-local use". The existing text in section 3 is pretty clear to me, but if we need to make it more clear, I suggest replacing: These strings MAY be site-defined strings that do not contain a colon such as the name of the Pre-Authentication mechanism used, or alternatively URIs that reference a Level of Assurance Profile [RFC6711]. with: Each string MUST be either: * A URI which references a Level of Assurance Profile [RFC6711]. * A site-defined string, which MUST NOT contain a colon, whose meaning is determined by the realm administrator. > I also suspect that the last paragraph of the security considerations > should be rewritten in a normative fashion and moved to section 3, to make > it clear what the presence of a given string in the authdata indicates. > (Do we know of reasons why someone might use this AD element to indicate > something other than a positive indication that the indicated requirements > were met during the initial authentication?) That seems like a reasonable change to me. > There's also some matter of form regarding the string > "AD-AUTHENTICATION-INDICATOR", which should probably just be used for the > definition of the ASN.1 type; the value 97 is the ad-type for which the > contents of-the ad-data field will be the DER encoding of the > AD-AUTHENTICATION-INDICATOR object. So, I would just say "The KDC MAY > include authorization data of ad-type 97, wrapped in AD-CAMMAC, [...]" and > skip the line that's just > > AD-AUTHENTICATION-INDICATOR 97 > > (and replace the colon with a full stop). That change also seems okay to me. From nobody Mon Sep 26 10:02:33 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 B05A612B30C for ; Mon, 26 Sep 2016 10:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.218 X-Spam-Level: X-Spam-Status: No, score=-9.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, 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 H1Psvng7gKxc for ; Mon, 26 Sep 2016 10:02:29 -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 573D112B24B for ; Mon, 26 Sep 2016 10:02:29 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 035F3C04B923 for ; Mon, 26 Sep 2016 17:02:29 +0000 (UTC) Received: from unused (unused [10.10.52.232] (may be forged)) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8QH2SSX012594; Mon, 26 Sep 2016 13:02:28 -0400 Message-ID: <1474909347.15526.41.camel@redhat.com> From: Matt Rogers To: Petr Spacek , Nathaniel McCallum , kitten@ietf.org Date: Mon, 26 Sep 2016 13:02:27 -0400 In-Reply-To: References: <1474669521.30344.15.camel@redhat.com> <1474905318.15526.31.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 26 Sep 2016 17:02:29 +0000 (UTC) Archived-At: Cc: Simo Sorce Subject: Re: [kitten] New URI Discovery Draft 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: Mon, 26 Sep 2016 17:02:31 -0000 On Mon, 2016-09-26 at 18:01 +0200, Petr Spacek wrote: >  > Fine with me. The main point is that if we do not define criticality > or at > least reserved character now it will be impossible to enforce it on > older > clients. Maybe we can reserve "!" character now and say that > character > immediately following "!" must be ignored by clients implementing > this version > of the draft? > I'm thinking that the flag should not be ignored, but just that in this version of the draft '!' is reserved but ignored and no criticality is assumed on the following flag. In a future version the '!' could indicate that the following flag is critical. Regards, Matt From nobody Mon Sep 26 10:10:15 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 0B06912B316 for ; Mon, 26 Sep 2016 10:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.217 X-Spam-Level: X-Spam-Status: No, score=-9.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, 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 6kVPaIc_DMYY for ; Mon, 26 Sep 2016 10:10:13 -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 0ABDD12B312 for ; Mon, 26 Sep 2016 10:10:13 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CA51E67AF1 for ; Mon, 26 Sep 2016 17:10:12 +0000 (UTC) Received: from dhcp137-207.rdu.redhat.com (dhcp137-207.rdu.redhat.com [10.13.137.207]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8QHA1Q4011901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 26 Sep 2016 13:10:12 -0400 Message-ID: <1474909801.27445.4.camel@redhat.com> From: Nathaniel McCallum To: Petr Spacek , kitten@ietf.org Date: Mon, 26 Sep 2016 13:10:01 -0400 In-Reply-To: References: <1474669521.30344.15.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 26 Sep 2016 17:10:12 +0000 (UTC) Archived-At: Cc: Matt Rogers , Simo Sorce Subject: Re: [kitten] New URI Discovery Draft 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: Mon, 26 Sep 2016 17:10:15 -0000 On Sat, 2016-09-24 at 18:29 +0200, Petr Spacek wrote: > On 24.9.2016 00:25, Nathaniel McCallum wrote: > > https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service- > > disc > > overy/ > > > > I've submitted a new version of the draft. This version matches the > > code that is now merged into MIT Kerberos. > > > > We need to move forward. If that is as an individual submission, > > then > > so be it. But we really can't wait any longer. So unless I hear > > some > > noise to the contrary ASAP, I plan to go this route. > > > Hello, > > in general it makes sense. The new URI format opened an encoding- > Pandora-box > so it needs more work to make it fully specified. Here are nits I > found in the > 03 version of the draft: > > 1] > > 4.  Required URI Format > >    krb5srv:[flags]:transport:residual > > Nitpick: I do not really like naming "transport:residual". Something > like > "transport-type:transport-options" would be more descriptive. > > > 2] Is this a good idea? > >    Flags are not considered critical, therefore flags that are not > > used > >    or unknown to the implementation SHOULD be ignored. > > Just wondering out loud, not insisting on it: > If we say there is no criticality, it will be impossible to add later > on. > > What about using capitalization to indicate criticality of a flag? > Records > with critical but unsupported flags should be skipped as if there > were not > present in DNS. Records with non-critical unsupported flags should be > used as > usual. > > Or maybe we can limit valid flags to lowercase ASCII letters for now > so there > is a room for extension in future? > > > 3] In any case, there is disagreement between > > 4.2.  Flags > >    This field contains a sequence of zero or more case-insensitive > > vs. > > 9.1.  Kerberos Server Discovery Flags > > 9.1.1.  Registration Template > >    Value:  A single unique ASCII character that identifies the > > entry, > > > "A single unique ASCII character" is case-sensitive by definition. > This > conflicts with case-insensitivity defined in 4.2. There is actually a bigger issue here which is that referring to it as "ASCII character" is too broad. What we really want here are the letters a-z. > 3] The draft is not clear on whether transport field is case- > sensitive or not. > > 4.3.  Transport > > 9.2.  Kerberos Server Discovery Transport Types > > > > 4] Residual formats are not sufficiently specified: > > 4.4.  Residual > > 9.2.  Kerberos Server Discovery Transport Types > > 9.2.2.  Initial Registry Contents > > > >    o Value: "udp" > >    o Description: User Datagram Protocol > >    o Residual Format: "host[:port]" > >    o Case Sensitive: None > >    o Default KDC Port: 88 > >    o Default Admin Service Port: 749 > >    o Default Password Service Port: 464 > >    o Reference: [RFC0768] > > > There is no definition of "host" and there is none in RFC 768. > Can it be IP(v?) address? > Can it be DNS name? > How this field should be encoded into the URI? > > >    o Value: "tcp" > >    o Description: Transport Control Protocol > >    o Residual Format: "host[:port]" > >    o Case Sensitive: None > >    o Default KDC Port: 88 > >    o Default Admin Service Port: 749 > >    o Default Password Service Port: 464 > >    o Reference: [RFC0793] > > > Again there is no definition of "host". > Can it be IP(v?) address? > Can it be DNS name? > How this field should be encoded into the URI? > > >    o Value: "kkdcp" > >    o Description: Kerberos Key Distribution Center Proxy Protocol > >    o Residual Format: https://host[:port][/path] > > > This is technically URI inside URI, am I right? > How is it encoded? Should usual %-encoding be used here? > > 10.1.  URI Format Examples > > suggest that %-encoding is not used. I would like to see this clearly > specified and explained why not. > > At this point I would rather say "use URL as specified by [MS-KKDCP]" > instead > of specifying "https://host[:port][/path]". > > Also, to make this bullet-proof, I would mention that "/KdcProxy" > must be > explicitly specified in the URI record and is not implicitly assumed > by clients. > > >    o Case Sensitive: [/path] > >    o Default KDC Port: 443 > >    o Default Admin Service Port: 443 > >    o Default Password Service Port: 443 > >    o Reference: [MS-KKDCP] > > > > Other than that it makes sense and I'm looking forward to see this > deployed! > > From nobody Mon Sep 26 15:58:41 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 47F3212B36D; Mon, 26 Sep 2016 15:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, 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 5BhoN7roMMsz; Mon, 26 Sep 2016 15:58:38 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 4FEB412B369; Mon, 26 Sep 2016 15:58:38 -0700 (PDT) X-AuditID: 1209190c-9efff7000000241d-1f-57e9a81bd2f1 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 (Symantec Messaging Gateway) with SMTP id 2E.7C.09245.B18A9E75; Mon, 26 Sep 2016 18:58:36 -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 u8QMwYCn027173; Mon, 26 Sep 2016 18:58: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 u8QMwVq4011798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 26 Sep 2016 18:58:34 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8QMwV64004786; Mon, 26 Sep 2016 18:58:31 -0400 (EDT) Date: Mon, 26 Sep 2016 18:58:31 -0400 (EDT) From: Benjamin Kaduk To: Greg Hudson 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+NgFrrNIsWRmVeSWpSXmKPExsUixCmqrCuz4mW4wZ5pMhaHb+xitzi6eRWL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgy/n5+wlgwRaxiyc2dzA2MKwW7GDk5JARMJH5e2sbe xcjFISTQxiRx9cFxKGcjo8SUlRuZIJxDTBIv1z9gg3AaGCUezfvDAtLPIqAtcb73G5jNJqAi MfPNRjYQW0RAUeL3yreMIDazgJPEsq2d7CC2sECQRNumI6xdjBwcnALWElPWpYGEeQUcJM72 NzGChIUE8iXmLrADCYsK6Eis3j+FBaJEUOLkzCcsEBO1JJZP38YygVFgFpLULCSpBYxMqxhl U3KrdHMTM3OKU5N1i5MT8/JSi3QN9XIzS/RSU0o3MYLDUJJnB+OZN16HGAU4GJV4eC3KX4YL sSaWFVfmHmKU5GBSEuXtnAkU4kvKT6nMSCzOiC8qzUktPsQowcGsJMLLuRwox5uSWFmVWpQP k5LmYFES5+2acSBcSCA9sSQ1OzW1ILUIJivDwaEkwSsO0ihYlJqeWpGWmVOCkGbi4AQZzgM0 XAxseHFBYm5xZjpE/hSjopQ4r/IyoIQASCKjNA+uF5wmdjOpvmIUB3pFmLcFpJ0HmGLgul8B DWYCGrz0xAuQwSWJCCmpBsYj19c+uxNx5Oi7o5F+DUv7nb3/aaq5ifzPtGCL3KIotJ7N94fW dqnjlxJNtq3M31Ab73pLboH/bldGHr6mMwuM0lak3d5teecP8/zTMRUb9dK/lSxvk9v3ysNn z+G+39P2LP/yOORM9r99m6wMHXZUL015VVT0fFamoe6RGcKH7RconN6kwpCoxFKckWioxVxU nAgAmLS0Ce4CAAA= Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-krb-auth-indicator@ietf.org Subject: Re: [kitten] shepherd review of draft-ietf-kitten-krb-auth-indicator-02 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: Mon, 26 Sep 2016 22:58:40 -0000 On Mon, 26 Sep 2016, Greg Hudson wrote: > On 09/25/2016 07:20 PM, Benjamin Kaduk wrote: > > It feels like some parts of the document are written as if the "short > > strings" for comparison against known values are only for use when > > presented back to the KDC, but other parts of the document describe it as > > being used for policy decisions made by application services as well as > > the KDC. > > Application servers can use auth indicators. What parts of the document > imply that they are only used by the KDC? I don't think there's anything explicit, just some implicit implication by way of not concretely specifying the structure enough to be fully portable without site-local configuration. > > So, I think that section 3 should be more stringent, saying something like > > "strings that contain a colon character MUST be URIs that reference a > > Level of Assurance Profile, leaving other strings available for > > site-local use". > > The existing text in section 3 is pretty clear to me, but if we need to > make it more clear, I suggest replacing: > > These > strings MAY be site-defined strings that do not contain a colon such > as the name of the Pre-Authentication mechanism used, or > alternatively URIs that reference a Level of Assurance Profile > [RFC6711]. > > with: > > Each string MUST be either: > > * A URI which references a Level of Assurance Profile [RFC6711]. > > * A site-defined string, which MUST NOT contain a colon, whose > meaning is determined by the realm administrator. That seems like an improvement to me, in that it is more likely to result in interoperable implementations. > > I also suspect that the last paragraph of the security considerations > > should be rewritten in a normative fashion and moved to section 3, to make > > it clear what the presence of a given string in the authdata indicates. > > (Do we know of reasons why someone might use this AD element to indicate > > something other than a positive indication that the indicated requirements > > were met during the initial authentication?) > > That seems like a reasonable change to me. > > > There's also some matter of form regarding the string > > "AD-AUTHENTICATION-INDICATOR", which should probably just be used for the > > definition of the ASN.1 type; the value 97 is the ad-type for which the > > contents of-the ad-data field will be the DER encoding of the > > AD-AUTHENTICATION-INDICATOR object. So, I would just say "The KDC MAY > > include authorization data of ad-type 97, wrapped in AD-CAMMAC, [...]" and > > skip the line that's just > > > > AD-AUTHENTICATION-INDICATOR 97 > > > > (and replace the colon with a full stop). > > That change also seems okay to me. Thanks for the review. -Ben From nobody Wed Sep 28 09:07:45 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 7EA6812B1FC for ; Wed, 28 Sep 2016 09:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.217 X-Spam-Level: X-Spam-Status: No, score=-9.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, 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 0BxyXzqubRcv for ; Wed, 28 Sep 2016 09:07:40 -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 71E6712B1F6 for ; Wed, 28 Sep 2016 09:07:40 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2F7FF6CB4A for ; Wed, 28 Sep 2016 16:07:40 +0000 (UTC) Received: from dhcp137-207.rdu.redhat.com (dhcp137-207.rdu.redhat.com [10.13.137.207]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8SG7dI1019169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Sep 2016 12:07:39 -0400 Message-ID: <1475078859.9001.4.camel@redhat.com> From: Nathaniel McCallum To: Petr Spacek , kitten@ietf.org Date: Wed, 28 Sep 2016 12:07:39 -0400 In-Reply-To: References: <1474669521.30344.15.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 28 Sep 2016 16:07:40 +0000 (UTC) Archived-At: Cc: Matt Rogers , Simo Sorce Subject: Re: [kitten] New URI Discovery Draft 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, 28 Sep 2016 16:07:42 -0000 On Sat, 2016-09-24 at 18:29 +0200, Petr Spacek wrote: > On 24.9.2016 00:25, Nathaniel McCallum wrote: > > https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service- > > disc > > overy/ > > > > I've submitted a new version of the draft. This version matches the > > code that is now merged into MIT Kerberos. > > > > We need to move forward. If that is as an individual submission, > > then > > so be it. But we really can't wait any longer. So unless I hear > > some > > noise to the contrary ASAP, I plan to go this route. > > > Hello, > > in general it makes sense. The new URI format opened an encoding- > Pandora-box > so it needs more work to make it fully specified. Here are nits I > found in the > 03 version of the draft: > > 1] > > 4.  Required URI Format > >    krb5srv:[flags]:transport:residual > > Nitpick: I do not really like naming "transport:residual". Something > like > "transport-type:transport-options" would be more descriptive. transport-info? transport-data? transport-spec? > 2] Is this a good idea? > >    Flags are not considered critical, therefore flags that are not > > used > >    or unknown to the implementation SHOULD be ignored. > > Just wondering out loud, not insisting on it: > If we say there is no criticality, it will be impossible to add later > on. > > What about using capitalization to indicate criticality of a flag? > Records > with critical but unsupported flags should be skipped as if there > were not > present in DNS. Records with non-critical unsupported flags should be > used as > usual. > > Or maybe we can limit valid flags to lowercase ASCII letters for now > so there > is a room for extension in future? I had proposed using case for criticality in another conversation and I'm increasingly coming to prefer this method if criticality is defined as "don't use this server if you don't understand the flag." Note that with either case-insensitivity or critical-uppercase we have the same number of letters. So I don't think there is any cost except the (minor) cost of updating the exiting MIT code. From nobody Wed Sep 28 09:48:33 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 E32FE12B646; Wed, 28 Sep 2016 09:48:28 -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.34.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147508130892.16696.14432212288541210748.idtracker@ietfa.amsl.com> Date: Wed, 28 Sep 2016 09:48:28 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-krb-auth-indicator-03.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: Wed, 28 Sep 2016 16:48:29 -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 : Authentication Indicator in Kerberos Tickets Authors : Anupam Jain Nathan Kinder Nathaniel McCallum Filename : draft-ietf-kitten-krb-auth-indicator-03.txt Pages : 5 Date : 2016-09-28 Abstract: This document specifies an extension in the Kerberos protocol [RFC4120]. It defines a new authorization data type AD- AUTHENTICATION-INDICATOR. The purpose of introducing this data type is to include an indicator of the strength of a client's authentication in service tickets so that application services can use it as an input into policy decisions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-auth-indicator/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-krb-auth-indicator-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-auth-indicator-03 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 Wed Sep 28 09:50:19 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 6A36312B635 for ; Wed, 28 Sep 2016 09:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.217 X-Spam-Level: X-Spam-Status: No, score=-9.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, 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 0uIrWSBtDiVo for ; Wed, 28 Sep 2016 09:50:17 -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 5259212B270 for ; Wed, 28 Sep 2016 09:47:50 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D7E233F1FA; Wed, 28 Sep 2016 16:41:17 +0000 (UTC) Received: from dhcp137-207.rdu.redhat.com (dhcp137-207.rdu.redhat.com [10.13.137.207]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8SGfHwa016608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Sep 2016 12:41:17 -0400 Message-ID: <1475080876.9001.7.camel@redhat.com> From: Nathaniel McCallum To: Benjamin Kaduk Date: Wed, 28 Sep 2016 12:41:16 -0400 In-Reply-To: References: 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.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 28 Sep 2016 16:41:17 +0000 (UTC) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] shepherd review of draft-ietf-kitten-krb-auth-indicator-02 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, 28 Sep 2016 16:50:18 -0000 On Sun, 2016-09-25 at 19:20 -0400, Benjamin Kaduk wrote: > I also suspect that the last paragraph of the security considerations > should be rewritten in a normative fashion and moved to section 3, to > make > it clear what the presence of a given string in the authdata > indicates. > (Do we know of reasons why someone might use this AD element to > indicate > something other than a positive indication that the indicated > requirements > were met during the initial authentication?) IMHO, I think this is not necessary. Section 3 already contains this paragraph: "Each UTF8String value is a short string that indicates that a particular set of requirements was met during the initial authentication." This sentence is the normative definition of precisely what an indicator is. The paragraph in the security considerations section is a warning about what would happen if you tried to use indicators for another purpose: ambiguity would arise. This is a security consideration. This warning is necessary precisely because the majority use of indicators will be as site-defined strings. From nobody Wed Sep 28 09:53:47 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 2D62112B621; Wed, 28 Sep 2016 09:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.217 X-Spam-Level: X-Spam-Status: No, score=-9.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, 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 cvtH_oIOjvTw; Wed, 28 Sep 2016 09:53:43 -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 6CBD112B697; Wed, 28 Sep 2016 09:50:13 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 28F0183E; Wed, 28 Sep 2016 16:50:13 +0000 (UTC) Received: from dhcp137-207.rdu.redhat.com (dhcp137-207.rdu.redhat.com [10.13.137.207]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8SGoC9I010539 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 28 Sep 2016 12:50:12 -0400 Message-ID: <1475081412.9001.8.camel@redhat.com> From: Nathaniel McCallum To: Greg Hudson , Benjamin Kaduk , draft-ietf-kitten-krb-auth-indicator@ietf.org Date: Wed, 28 Sep 2016 12:50:12 -0400 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 28 Sep 2016 16:50:13 +0000 (UTC) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] shepherd review of draft-ietf-kitten-krb-auth-indicator-02 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, 28 Sep 2016 16:53:45 -0000 I submitted a new draft with these changes. I only omitted the change to the security considerations section. We can discuss that further if need be. I stated my reasons for keeping the existing wording in another email. On Mon, 2016-09-26 at 12:28 -0400, Greg Hudson wrote: > On 09/25/2016 07:20 PM, Benjamin Kaduk wrote: > > It feels like some parts of the document are written as if the > > "short > > strings" for comparison against known values are only for use when > > presented back to the KDC, but other parts of the document describe > > it as > > being used for policy decisions made by application services as > > well as > > the KDC. > > > Application servers can use auth indicators.  What parts of the > document > imply that they are only used by the KDC? > > > So, I think that section 3 should be more stringent, saying > > something like > > "strings that contain a colon character MUST be URIs that reference > > a > > Level of Assurance Profile, leaving other strings available for > > site-local use". > > > The existing text in section 3 is pretty clear to me, but if we need > to > make it more clear, I suggest replacing: > >     These >     strings MAY be site-defined strings that do not contain a colon > such >     as the name of the Pre-Authentication mechanism used, or >     alternatively URIs that reference a Level of Assurance Profile >     [RFC6711]. > > with: > >     Each string MUST be either: > >     * A URI which references a Level of Assurance Profile [RFC6711]. > >     * A site-defined string, which MUST NOT contain a colon, whose >       meaning is determined by the realm administrator. > > > I also suspect that the last paragraph of the security > > considerations > > should be rewritten in a normative fashion and moved to section 3, > > to make > > it clear what the presence of a given string in the authdata > > indicates. > > (Do we know of reasons why someone might use this AD element to > > indicate > > something other than a positive indication that the indicated > > requirements > > were met during the initial authentication?) > > > That seems like a reasonable change to me. > > > There's also some matter of form regarding the string > > "AD-AUTHENTICATION-INDICATOR", which should probably just be used > > for the > > definition of the ASN.1 type; the value 97 is the ad-type for which > > the > > contents of-the ad-data field will be the DER encoding of the > > AD-AUTHENTICATION-INDICATOR object.  So, I would just say "The KDC > > MAY > > include authorization data of ad-type 97, wrapped in AD-CAMMAC, > > [...]" and > > skip the line that's just > > > > AD-AUTHENTICATION-INDICATOR 97 > > > > (and replace the colon with a full stop). > > > That change also seems okay to me. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > From nobody Wed Sep 28 09:54:25 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 ECEA412B62E for ; Wed, 28 Sep 2016 09:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.536 X-Spam-Level: X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xrAQZrH80JIy for ; Wed, 28 Sep 2016 09:54:20 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 A151712B270 for ; Wed, 28 Sep 2016 09:50:37 -0700 (PDT) X-AuditID: 1209190d-273ff7000000106a-fe-57ebf4dc5c30 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 60.D4.04202.CD4FBE75; Wed, 28 Sep 2016 12:50:36 -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 u8SGoZZh006006; Wed, 28 Sep 2016 12:50:36 -0400 Received: from [18.101.8.85] (vpn-18-101-8-85.mit.edu [18.101.8.85]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u8SGoXHg031955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 28 Sep 2016 12:50:35 -0400 To: Nathaniel McCallum , kitten@ietf.org References: <1474669521.30344.15.camel@redhat.com> <1475078859.9001.4.camel@redhat.com> From: Greg Hudson Message-ID: <7e9875ff-e02a-c268-a8fd-4d0a0a0f1b15@mit.edu> Date: Wed, 28 Sep 2016 12:50:33 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1475078859.9001.4.camel@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nonvny+twg/a3mhZHN69isZj7dRar A5PHkiU/mTze77vKFsAUxWWTkpqTWZZapG+XwJWxYsFLxoJXLBUHpmg0MH5j7mLk5JAQMJG4 8/goWxcjF4eQQBuTxIvzb8ASQgIbGSX29OZDJA4xSexeMp0dJCEsoCtx9lYDSxcjB4eIgL3E wsYEiPpeRolvS2tBbDYBZYn1+7eygNi8AlYSjxc9ZwOxWQRUJZZ+Oc4EYosKREjcWvWREaJG UOLkzCdg9ZwChhLbjq0Fq2EWUJf4M+8SM4QtL7H97RzmCYz8s5C0zEJSNgtJ2QJG5lWMsim5 Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSmlmxhBwcgpybuD8d9dr0OMAhyMSjy8Hadehwux JpYVV+YeYpTkYFIS5e24DRTiS8pPqcxILM6ILyrNSS0+xCjBwawkwtvxCSjHm5JYWZValA+T kuZgURLn7ZpxIFxIID2xJDU7NbUgtQgmK8PBoSTBu+ozUKNgUWp6akVaZk4JQpqJgxNkOA/Q 8N8gNbzFBYm5xZnpEPlTjLocC37cXsskxJKXn5cqJc6bA1IkAFKUUZoHNwecRFI5Ql8xigO9 JcxrA0wpQjzABAQ36RXQEiagJUtPvABZUpKIkJJqYGzeefbWv0uzthdrvDLlPfbhzSUt4SdV R2ZznP1QsTuS+7GQvvyJmMCJ39UaOU6bf41sVLTQOZYovC52GdeTo6VN5VPO/foh2vVY6l2C QW65W2MAb2qrmlq4qO4xM99Favmr+FymlgeWM8+5vHluXKK2kZnr9SNHtre6NjcG3Z6qMSlV ZafuAyWW4oxEQy3mouJEAMQRBw39AgAA Archived-At: Subject: Re: [kitten] New URI Discovery Draft 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, 28 Sep 2016 16:54:24 -0000 On 09/28/2016 12:07 PM, Nathaniel McCallum wrote: > transport-info? transport-data? transport-spec? I like transport-info. > I had proposed using case for criticality in another conversation and > I'm increasingly coming to prefer this method if criticality is defined > as "don't use this server if you don't understand the flag." My opinion hasn't changed; I still think we have no need for critical flags, and don't want to add complexity. (It's very normal to define an extensible protocol field with no support for critical values. padata and ticket flags are two examples that come to mind.) From nobody Thu Sep 29 11:45:59 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 EDF7312B1BD for ; Thu, 29 Sep 2016 11:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ebiquityinsights-com.20150623.gappssmtp.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 DqvVs5pHH5xi for ; Thu, 29 Sep 2016 11:45:56 -0700 (PDT) Received: from mail-yw0-x245.google.com (mail-yw0-x245.google.com [IPv6:2607:f8b0:4002:c05::245]) (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 E1D9012B19C for ; Thu, 29 Sep 2016 11:45:55 -0700 (PDT) Received: by mail-yw0-x245.google.com with SMTP id k17so7601475ywe.1 for ; Thu, 29 Sep 2016 11:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ebiquityinsights-com.20150623.gappssmtp.com; s=20150623; h=mime-version:reply-to:message-id:date:subject:from:to; bh=oHjBmlv3YRYwFzY+AvHq39xQpoO31Co6hlGufhm+dXc=; b=CWMEKNTwdo7WSAG+Fhs1kPr+h5xhcK7uCnxU1uLld53Gd09t64ztx7nR9ipneu6NSd Iqh+KORD102/AFDk9jF6JWT4QbG95TBKFzDA6ExXUPZU9VSNqaBU0A96rW8P+Wb+ISZ8 Ew8WFPyVBn00vDjPG0AEWtWwACXeaMJPiXIAUPshvdRKlVqyBijgGqrTzLLBnoB1g3yW 5znL+08Tnf8bQ194mWLqpk/qx7pEKXsOmNRrvccIzo8zj2h03R5S3jxkbqmkP8CVqdWk qCIb1Zcv+uH2EwKeICxjhAyxo0wsHyamaLEfrIBgSXhQG/2GP1AKITh4m/AHiVYINatx N7ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:message-id:date:subject :from:to; bh=oHjBmlv3YRYwFzY+AvHq39xQpoO31Co6hlGufhm+dXc=; b=AUVV1FcoS5kv4UnYHhBvzn+TuX9rYLgeSTvUBpyN3mw+WEaqLv6OaW7yWbU0yLW6Do MQ1YOEC2HB3RzK9z9AgZJ4t/k8GpG7JMTqBEZXLFJNqfpTNk+MGY9YjZ5fvwAQ9bdQtf g9RSGC/a2XMI3Ud0h06u5LknWyq9WDzB9XTuZtMiqyGCHyFoL301W9KwAmHz65WfNvD6 rmrZZqnTTUWt1HlwYAjT+St05JhbrG31phjdb2KyTqUyqoRo28sXRclhTki/43ot7zRN WrgTrL5Hr2qqKfvVGD1HOECxI/l25yIxuUJcVjmkCcZWCP6CkUmE1J+G4jSBS4JafkUr XP8w== X-Gm-Message-State: AA6/9RnCz0TNuCnsuH45k7Ekz6Wpzec597cKdVlY1X/fJIlmVDBMz0jOYNcQGzYFFqrnonB8J6RcerwkB4eQYw== MIME-Version: 1.0 X-Received: by 10.129.70.130 with SMTP id t124mr739571ywa.136.1475174755099; Thu, 29 Sep 2016 11:45:55 -0700 (PDT) Message-ID: <001a114d7042427151053da9e3c9@google.com> Date: Thu, 29 Sep 2016 18:45:55 +0000 From: Judy Bromley To: kitten@ietf.org Content-Type: multipart/alternative; boundary=001a114d7042427138053da9e3c6 Archived-At: Subject: [kitten] IANA Customer Feedback X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: judy.bromley@ebiquityinsights.com List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 18:45:58 -0000 --001a114d7042427138053da9e3c6 Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes Dear IANA Customer, ICANN strives to continuously improve its delivery of the IANA functions. In mid-September, we invited you to participate in the 2016 Annual Customer Survey. We have not heard from you yet and would be grateful if you could spare a few minutes to complete the survey before it closes on October 21, 2016. This short survey is being managed by Ebiquity, an independent research firm. Ebiquity is committed to protecting the confidentiality of all respondents, in line with the Code of Conduct of ESOMAR and CASRO. This means data is reported to ICANN in aggregate, so that all opinions are confidential and not attributed to any specific individual. Please complete the survey hosted at https://www.ebiquityinsights.com/E0210/index.pl?surveynumber=67389 which will remain open until October 21, 2016. ICANN will summarize the results and publish the summary in December 2016. We appreciate your time and helping us improve the delivery of the IANA functions. If you have any questions, please contact me at judy.bromley@ebiquityinsights.com or Marilia Hirano at marilia.hirano@icann.org. Yours sincerely, Judy BromleyAccount Director, Ebiquity If you would not like to receive further emails about this research project please reply to this message and type REMOVE in the subject line. --001a114d7042427138053da9e3c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear IANA Customer,

ICANN strives to continuously improve its deli= very of the IANA functions. In mid-September, we invited you to participate= in the 2016 Annual Customer Survey. We have not heard from you yet and wou= ld be grateful if you could spare a few minutes to complete the survey befo= re it closes on October 21, 2016.

This short survey is being managed by Ebiquity, an independent research firm. Ebiquity is committed to pro= tecting the confidentiality of all respondents, in line with the Code of Co= nduct of ESOMAR and CASRO. This means data is reported to ICANN in aggreg= ate, so that all opinions are confidential and not attributed to any specif= ic individual.

Please complete the survey hosted at https://www.ebiquityinsights.com/E0= 210/index.pl?surveynumber=3D67389 which will remain open until October 21, = 2016. ICANN will summarize the results and publish the summary in December = 2016.

We appreciate your time and helping us improve the delivery of the IANA = functions.

If you have any questions, please contact me at judy.bromley@ebiquityins= ights.com or Marilia Hirano at marilia.hirano@icann.org.

Yours sincerely,

Judy Bromley
Account Director, Ebiquity

If you would not like to receive further emails about this resear= ch project please reply to this message and type REMOVE in the subject line= .

--001a114d7042427138053da9e3c6-- From nobody Thu Sep 29 20:29:56 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 3CD5712B092 for ; Thu, 29 Sep 2016 20:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 HHm4hfCkRQ2Y for ; Thu, 29 Sep 2016 20:29:53 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 5EE9512B03F for ; Thu, 29 Sep 2016 20:29:52 -0700 (PDT) X-AuditID: 1209190d-9c3ff70000005d76-15-57eddc2fff82 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 C1.B4.23926.F2CDDE75; Thu, 29 Sep 2016 23:29:51 -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 u8U3ToHu028077; Thu, 29 Sep 2016 23:29: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 u8U3TlLJ020996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Sep 2016 23:29:50 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8U3TkuO010627; Thu, 29 Sep 2016 23:29:46 -0400 (EDT) Date: Thu, 29 Sep 2016 23:29:46 -0400 (EDT) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <1474669521.30344.15.camel@redhat.com> Message-ID: References: <1474669521.30344.15.camel@redhat.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+NgFnrHIsWRmVeSWpSXmKPExsUixG6nrqt/5224QVePpcXRzatYLOZ+ncXq wOSxZMlPJo/3+66yBTBFcdmkpOZklqUW6dslcGW0vnjDXtDIXrH37n72BsaLrF2MnBwSAiYS fzd9A7K5OIQE2pgkfi3dzQbhbGSUuPdpGwuEc4hJ4viVTUwQTgOjxLTN09hA+lkEtCUa7l0A m8UmoCIx881GsLiIgJ7Esn0TGEFsZgFhifXnZjCD2MICuhJnbzWwgNicAsYSL072g/XyCjhI nFh/iR3EFhIwkujb8QTMFhXQkVi9fwoLRI2gxMmZT1ggZmpJLJ++jWUCo8AsJKlZSFILGJlW Mcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrp5WaW6KWmlG5iBAUlpyTvDsZ/d70OMQpwMCrx8Aoo vw0XYk0sK67MPcQoycGkJMorexQoxJeUn1KZkVicEV9UmpNafIhRgoNZSYT32HWgHG9KYmVV alE+TEqag0VJnLdrxoFwIYH0xJLU7NTUgtQimKwMB4eSBO/7W0CNgkWp6akVaZk5JQhpJg5O kOE8QMNXgtTwFhck5hZnpkPkTzHqciz4cXstkxBLXn5eqpQ4b/ptoCIBkKKM0jy4OeBksptJ 9RWjONBbwry/QEbxABMR3KRXQEuYgJbkH30DsqQkESEl1cB4dGu65TMlk0t3C+yP+59aVDP5 NIPjKTkmjsnbtl95O1mnWU+3OP+Mb1/0U/UX6U85miZNens7Vmt56Aa1878WWhldiTbx+2qq MOfbpJ16Uaf/1pXzHHupI8bT79Yos7sua9lc/8eaJWvEMz7JPPdZJyymd8iiwDWcdbfD0jub dv0ty/eLrMxWYinOSDTUYi4qTgQAPrT+rgEDAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] New URI Discovery Draft 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: Fri, 30 Sep 2016 03:29:55 -0000 On Fri, 23 Sep 2016, Nathaniel McCallum wrote: > https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-disc > overy/ > > I've submitted a new version of the draft. This version matches the > code that is now merged into MIT Kerberos. > > We need to move forward. If that is as an individual submission, then > so be it. But we really can't wait any longer. So unless I hear some > noise to the contrary ASAP, I plan to go this route. The chairs talked about this, and it seems like we've made enough progress getting WG consensus on documents [that are now blocking on shepherd writeups] that we're probably in a state where accepting new WG documents can happen fairly soon. That said, we'd really like to get some more review on draft-ietf-kitten-rfc5653bis-03 so that can move forward as well. Any chance you'll be able to provide a review? Thanks, Ben From nobody Thu Sep 29 20:53:42 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 6EE3A12B030 for ; Thu, 29 Sep 2016 20:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.316, 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 0Q-JIMlYmFSJ for ; Thu, 29 Sep 2016 20:53:39 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 79EE012B02C for ; Thu, 29 Sep 2016 20:53:39 -0700 (PDT) X-AuditID: 12074423-e5fff7000000257a-10-57ede1c1c101 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 (Symantec Messaging Gateway) with SMTP id DC.54.09594.1C1EDE75; Thu, 29 Sep 2016 23:53:37 -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 u8U3raxQ005821; Thu, 29 Sep 2016 23:53: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 u8U3rWqD025315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Sep 2016 23:53:35 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8U3rWoN013565; Thu, 29 Sep 2016 23:53:32 -0400 (EDT) Date: Thu, 29 Sep 2016 23:53:31 -0400 (EDT) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <1474669521.30344.15.camel@redhat.com> Message-ID: References: <1474669521.30344.15.camel@redhat.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+NgFnrFIsWRmVeSWpSXmKPExsUixCmqrXvw4dtwg/vPZC2Obl7FYnF/YpzF 3K+zWC1+zF3E6sDisWTJTyaP9/uusgUwRXHZpKTmZJalFunbJXBlNG85xVjwSaRi7bRrTA2M /wW6GDk5JARMJD7/3s3axcjFISTQxiTRvXQ/G4SzkVFi8fz3jCBVQgKHmCT2LJSESDQwSny5 9IEVJMEioC3x7n0PWBGbgIrEzDcb2UBsEQE9iWX7JoDFmQViJC6svcsCYgsL6EqcvdUAZnMK GEu8ONkPNodXwEFicmMn1DIjib4dT9hBbFEBHYnV+6ewQNQISpyc+YQFYqaWxPLp21gmMArM QpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRlCQsrso72B82ed9 iFGAg1GJh1dA+W24EGtiWXFl7iFGSQ4mJVFe2aNAIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8 1+8B5XhTEiurUovyYVLSHCxK4rxdMw6ECwmkJ5akZqemFqQWwWRlODiUJHiXPgBqFCxKTU+t SMvMKUFIM3FwggznARp+HKSGt7ggMbc4Mx0if4pRUUqcd/59oIQASCKjNA+uF5xEdjOpvmIU B3pFmFcImFKEeIAJCK77FdBgJqDB+UffgAwuSURISQHj9fbzFQqrTodfOVv8V8hJi19M6Obj 97veONYUvbzg6SUevC0uZs2FyVcVvuRzyYhsiAzY8OmmjpDpdt8z/lxT/7syKy5lnjxNV6yl c90hic173upNUejXvvW26+aZUrtmsyXl7ROuNSr9P5Hvti2N/Yj7wnmz9ivuSJFg1H04f5Y/ g9j7S67nlFiKMxINtZiLihMB+IdHdP0CAAA= Archived-At: Cc: kitten@ietf.org, Matt Rogers , Simo Sorce Subject: Re: [kitten] New URI Discovery Draft 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: Fri, 30 Sep 2016 03:53:41 -0000 On Fri, 23 Sep 2016, Nathaniel McCallum wrote: > https://datatracker.ietf.org/doc/draft-mccallum-kitten-krb-service-disc > overy/ > > I've submitted a new version of the draft. This version matches the > code that is now merged into MIT Kerberos. A few comments (with no particular hat): Section 4.2.1, "master server" is only implicitly defined; would it be reasonable to say that such are "expected to be an authoritative source for KDC database information, not subject to propagation delay"? It's probably worth a forward reference to the IANA considerations somewhere in Section 4.2 to note how new flags can be allocated. Likewise for the transport types in 4.3 (as well as a list of the types specified by this document!). I'd be slightly tempted to reorder things so section 4 comes after sections 5, 6, and 7 (so that the queries come first and the field contents later), but that's really a stylistic question and subject to authorial discretion. Sections 5, 6, and 7 say "[t]arget SHOULD contain one of the URI formats specified in this document", but doesn't this document only contain one (required) URI format? Section 7 should probably note that the kadmin protocol is not standardized and consumers must be aware of the server implementation. (If we're really excited, we could even include a field to indicate what the server implementation is, but that would run the risk of introducing IETF politics at IETF LC or IESG review.) I don't believe that the kitten list can be a designated expert (and it's unclear what exactly the document is saying will be done for expert review). IIRC, the necessary things in this part are to give the IESG guidance for selecting Designated Expert(s) (e.g., well-known kerberos implementors, past or current krb-wg/kitten chairs, etc.), as well as instructions for what review/criteria the expert should apply when considering registration requests. Requiring the expert to call for open discussion on the kitten list can be part of the instructions to the expert, but probably ought not be the entirety of those instructions. Also, it's my understanding that IANA likes things to be written in the form "IANA has done $X", though for drafts, people tend to write "IANA [will do|has done]" with literal brackets and pipe. We already covered the non-case-sensitivity of the flags, but as a nit, the reference field should be to a document that describes the details of the flag. I don't see how the reference for the 'm' flag would not be "[this document]". The examples would be more useful if accompanied by prose description of what they mean. -Ben From nobody Thu Sep 29 21:02: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 68E2312B02C; Thu, 29 Sep 2016 21:02:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.316, 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 vAkdghe7QqQK; Thu, 29 Sep 2016 21:02:08 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 B208912B023; Thu, 29 Sep 2016 21:02:06 -0700 (PDT) X-AuditID: 12074422-ec3ff700000074b8-f3-57ede3bd561e 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 57.E5.29880.DB3EDE75; Fri, 30 Sep 2016 00:02:05 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id u8U424dL021519; Fri, 30 Sep 2016 00:02: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 u8U41wFO027020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 30 Sep 2016 00:02:01 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id u8U41wWE014624; Fri, 30 Sep 2016 00:01:58 -0400 (EDT) Date: Fri, 30 Sep 2016 00:01:58 -0400 (EDT) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <1475081412.9001.8.camel@redhat.com> Message-ID: References: <1475081412.9001.8.camel@redhat.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+NgFvrMIsWRmVeSWpSXmKPExsUixG6norv38dtwg6v/LSwO39jFbnF08yoW i7lfZ7E6MHssWfKTyeP9vqtsAUxRXDYpqTmZZalF+nYJXBl/bk1iLvjPVnHn9mz2BsbbrF2M nBwSAiYSrRP/s4HYQgJtTBJf1wl2MXIB2RsZJQ5s2sgO4Rxikjj7cQMrhNPAKHFuxx6wdhYB bYltJzqYQWw2ARWJmW82go0SEdCTWLZvAiOIzSzgJLFsayc7iC0sECTRtukIWC+ngKHEziNT WUBsXgEHifd7TjFCLJjKKLFn83ImkISogI7E6v1ToIoEJU7OfMICMVRLYvn0bSwTGAVmIUnN QpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdULzezRC81pXQTIzg8XZR2ME7853WIUYCD UYmHN0P1bbgQa2JZcWXuIUZJDiYlUV7Zo0AhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryWD4Fy vCmJlVWpRfkwKWkOFiVx3q4ZB8KFBNITS1KzU1MLUotgsjIcHEoSvFWPgBoFi1LTUyvSMnNK ENJMHJwgw3mAhq8FqeEtLkjMLc5Mh8ifYtTlWPDj9lomIZa8/LxUKXHeoyBFAiBFGaV5cHPA aWU3k+orRnGgt4R5d4BU8QBTEtykV0BLmICW5B99A7KkJBEhJdXA6Dn9wMPI1XxvNfr19y7u dF7r6KE2xWdnJNOsb4bb0x7NDTcUYJEx0UvmUvN7eqA0pjnuuhLLkx+Fwgefe85ecvX27Pd3 7lpseTLD7NJR9kTXeZbpLIzXBbhy4jhmb/t0Lu/PdMnMkN+7wvVsv+02LG3eIq173XiV3Vvu 0JZtW7fw3K5UNXlqqcRSnJFoqMVcVJwIAGkRI24GAwAA Archived-At: Cc: kitten@ietf.org, draft-ietf-kitten-krb-auth-indicator@ietf.org Subject: Re: [kitten] shepherd review of draft-ietf-kitten-krb-auth-indicator-02 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: Fri, 30 Sep 2016 04:02:09 -0000 On Wed, 28 Sep 2016, Nathaniel McCallum wrote: > I submitted a new draft with these changes. I only omitted the change > to the security considerations section. We can discuss that further if > need be. I stated my reasons for keeping the existing wording in > another email. Thanks for the updates. I do not insist on changes to the security considerations text, but will not be surprised if a GenART/Opsdir/secdir reviewer re-raises the question. I do have one question, though: the new version says that the CAMMAC requirement "exists to provide integrity protection from man-in-the-middle attacks", which is a bit odd, since AuthorizationData appear within the EncTicketPart (and the auth-indicator is not expected to appear "bare" in KDC-REQ or Authenticators, since it is supposed to be KDC-issued). So, unfortunately, that sentence still leaves me confused. -Ben From nobody Fri Sep 30 12:38:25 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 81DC412B025 for ; Fri, 30 Sep 2016 12:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.218 X-Spam-Level: X-Spam-Status: No, score=-9.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.316, 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 f6PpwpZd-SB4 for ; Fri, 30 Sep 2016 12:38:21 -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 B7D2412B1AF for ; Fri, 30 Sep 2016 12:38:21 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D63FB39C989; Fri, 30 Sep 2016 19:38:20 +0000 (UTC) Received: from vpn-54-177.rdu2.redhat.com (vpn-54-177.rdu2.redhat.com [10.10.54.177]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8UJcJp2013097; Fri, 30 Sep 2016 15:38:20 -0400 Message-ID: <1475264299.31392.45.camel@redhat.com> From: Matt Rogers To: Benjamin Kaduk , Nathaniel McCallum Date: Fri, 30 Sep 2016 15:38:19 -0400 In-Reply-To: References: <1474669521.30344.15.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Fri, 30 Sep 2016 19:38:21 +0000 (UTC) Archived-At: Cc: kitten@ietf.org, Simo Sorce Subject: Re: [kitten] New URI Discovery Draft 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: Fri, 30 Sep 2016 19:38:23 -0000 On Thu, 2016-09-29 at 23:53 -0400, Benjamin Kaduk wrote: Thanks for the review! > > A few comments (with no particular hat): > > Section 4.2.1, "master server" is only implicitly defined; would it > be > reasonable to say that such are "expected to be an authoritative > source > for KDC database information, not subject to propagation delay"? > With this re-wording would it be more appropriate to specify in the IANA definition for 'm' and not under 4.2? > It's probably worth a forward reference to the IANA considerations > somewhere in Section 4.2 to note how new flags can be allocated.  > Likewise > for the transport types in 4.3 (as well as a list of the types > specified > by this document!). > Ack. > I'd be slightly tempted to reorder things so section 4 comes after > sections 5, 6, and 7 (so that the queries come first and the field > contents later), but that's really a stylistic question and subject > to > authorial discretion. > Not a bad suggestion for the overall flow of the document. > Sections 5, 6, and 7 say "[t]arget SHOULD contain one of the URI > formats > specified in this document", but doesn't this document only contain > one > (required) URI format? > Yes, that's left over from a previous revision, so I'll correct that. > Section 7 should probably note that the kadmin protocol is not > standardized and consumers must be aware of the server > implementation. > (If we're really excited, we could even include a field to indicate > what > the server implementation is, but that would run the risk of > introducing > IETF politics at IETF LC or IESG review.) > > I don't believe that the kitten list can be a designated expert (and > it's > unclear what exactly the document is saying will be done for expert > review).  IIRC, the necessary things in this part are to give the > IESG > guidance for selecting Designated Expert(s) (e.g., well-known > kerberos > implementors, past or current krb-wg/kitten chairs, etc.), as well as > instructions for what review/criteria the expert should apply when > considering registration requests.  Requiring the expert to call for > open > discussion on the kitten list can be part of the instructions to the > expert, but probably ought not be the entirety of those instructions. > Also, it's my understanding that IANA likes things to be written in > the > form "IANA has done $X", though for drafts, people tend to write > "IANA > [will do|has done]" with literal brackets and pipe. > Ok, I'll work on revising this. > We already covered the non-case-sensitivity of the flags, but as a > nit, > the reference field should be to a document that describes the > details of > the flag.  I don't see how the reference for the 'm' flag would not > be > "[this document]". > I'll update this reference. Also, after some further discussion about the case-sensitivity and flag criticality issue, I think ultimately the right thing to do for this version of the draft is to just specify that the URI fields are case-sensitive and unknown flags must be ignored. A registered transport can then maintain any case-sensitive elements (such as the path extension for KKDCP) while the scheme, flags, and transport names will be registered with their literal values so there should not be any ambiguity on the case for those fields.  If later on a critical flag needs to be added, then this would leave it open to being a capital version of an existing flag or just a different character altogether. > The examples would be more useful if accompanied by prose description > of > what they mean. > Good point.  Thanks again, Matt