[secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04
"Christian Huitema" <huitema@huitema.net> Sun, 01 January 2017 02:19 UTC
Return-Path: <huitema@huitema.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5101294C5 for <secdir@ietfa.amsl.com>; Sat, 31 Dec 2016 18:19:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 YPXjxyGnW_cf for <secdir@ietfa.amsl.com>; Sat, 31 Dec 2016 18:19:53 -0800 (PST)
Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 0BFE312947C for <secdir@ietf.org>; Sat, 31 Dec 2016 18:19:53 -0800 (PST)
Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1cNVkV-0000jQ-7x for secdir@ietf.org; Sun, 01 Jan 2017 03:19:52 +0100
Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1cNVkT-0005s3-1u for secdir@ietf.org; Sat, 31 Dec 2016 21:19:50 -0500
Received: (qmail 13791 invoked from network); 1 Jan 2017 02:19:45 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.73]) (envelope-sender <huitema@huitema.net>) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-kitten-krb-auth-indicator.all@ietf.org>; 1 Jan 2017 02:19:45 -0000
From: Christian Huitema <huitema@huitema.net>
To: 'IESG' <iesg@ietf.org>, 'secdir' <secdir@ietf.org>, draft-ietf-kitten-krb-auth-indicator.all@ietf.org
Date: Sat, 31 Dec 2016 18:19:43 -0800
Message-ID: <005f01d263d5$84b14680$8e13d380$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdJjz9rthG/Lz73xRBWGGHxi2Ncdfw==
Content-Language: en-us
X-Originating-IP: 168.144.250.215
X-SpamExperts-Domain: xsmtpout.mail2web.com
X-SpamExperts-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-SpamExperts-Outgoing-Class: unsure
X-SpamExperts-Outgoing-Evidence: Combined (0.13)
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49MJIIgmXWciG0xIgIHG/MnhTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqvAY+igCPflcnB0OXWJWhURcOb18WfxGyg6Om6u4YYm/7kEmnXo3gOTwoX Y1vmgeM5hjoyEb9Oq0NWpyO3vrfYKtU04a0dsdHkKEFmS31kUD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBkye6uEH7Y2FUSOL4rzI+gxQRCdMNhge1Unb77YyuZq5cyXcOfFJuTWiAUcVUWhq2RBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f1ZS3ljmeFVRIgA8pd5GE2NV TgVI3tePcP+0TP9kyYEYWLqMT076wgjiEYaAeBXL0geYUOp7A73HI6oJg7w/VodqDS3jhFVyYvjB Ar8iUjNZzB9tfY+mOJVw0e2xMRa7D2P5RYOa/miinTReZ5OdasFBlor8ikxQTKPsYxS4ne8tcQkv 3rfK9nOh84B6FNp+WtpjXhV8g5C9ZVdQH0yPWSY=
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/3u0KhQvNQvg9PgRufqTw-vnJCQ4>
Subject: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Jan 2017 02:19:55 -0000
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines a new type of Authorization Data for the Kerberos protocol. The new data type is used to convey authentication strength information to application services. It is intended to use when implementations support different type of authentication, for example password based, multi-factor, or public keys. The authentication strengths are identified by either an URI identifying a Level of Assurance (LoA) Profile registered with IANA (RFC 6711), or a site-defined string. These identifiers are wrapped in an AD-CAMMAC container defined in RFC 7751. The document is almost ready, by I wish a few issues were addressed before publication. My first issue is that the document describes an update to the Kerberos protocol specification, RFC 4120, but does not define the specific way in which RFC 4120 is updated. Could the draft be updated to include something like the section "6. Assigned Numbers" of RFC 7751? If I understand correctly, the changes are a new ad-type number 97, pointing to a CAMMAC container, in which the "elements" are encoded according to the syntax specified in Appendix A of the draft. Having that explained succinctly would help future readers. My second issue is with the use of site-defined strings. I understand that the site defined strings are defined by the administrator of a realm. What happens if these strings appear outside the original realm, for example in an environment connecting multiple realms? Don't we have a potential there for name collision? Should there not be some guidance to implementers? I note that the proposed short string syntax forbids use of the ":" character in site-defined strings. Did the WG look at the consequences of that choice? If site administrators cannot use the URI like syntax, what is the preferred way of defining unique strings and preventing collisions? What are application services supposed to do when they encounter URI or site-defined strings that they do not understand? The ASN.1 syntax defines the element as a "SEQUENCE OF UTF8String". The document mentions that "Each UTF8String value is a short string". How short exactly should these strings be? How many of them should an application expect in the "SEQUENCE OF" element? The syntax itself does not constrain the length or number of these strings. Are we not worried with potential interoperability issues? Could this be abused in some attacks? Should the security considerations mention that? -- Christian Huitema
- [secdir] SECDIR review of draft-ietf-kitten-krb-a… Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Benjamin Kaduk
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Benjamin Kaduk
- Re: [secdir] [kitten] SECDIR review of draft-ietf… Greg Hudson
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Christian Huitema
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Nathaniel McCallum
- Re: [secdir] SECDIR review of draft-ietf-kitten-k… Christian Huitema