Re: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04
"Christian Huitema" <huitema@huitema.net> Sun, 01 January 2017 02:39 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 C47AF12955B for <secdir@ietfa.amsl.com>; Sat, 31 Dec 2016 18:39:30 -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=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 2TrV-BCnWJwJ for <secdir@ietfa.amsl.com>; Sat, 31 Dec 2016 18:39:29 -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 4B313129555 for <secdir@ietf.org>; Sat, 31 Dec 2016 18:39:29 -0800 (PST)
Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <huitema@huitema.net>) id 1cNW3T-0002h9-Bz for secdir@ietf.org; Sun, 01 Jan 2017 03:39:28 +0100
Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1cNW3R-0003IH-By for secdir@ietf.org; Sat, 31 Dec 2016 21:39:26 -0500
Received: (qmail 31999 invoked from network); 1 Jan 2017 02:39:24 -0000
Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.73]) (envelope-sender <huitema@huitema.net>) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for <draft-ietf-kitten-krb-auth-indicator.all@ietf.org>; 1 Jan 2017 02:39:24 -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, nkinder@redhat.com, npmccallum@redhat.com
References: <005f01d263d5$84b14680$8e13d380$@huitema.net>
In-Reply-To: <005f01d263d5$84b14680$8e13d380$@huitema.net>
Date: Sat, 31 Dec 2016 18:39:21 -0800
Message-ID: <006f01d263d8$435dc430$ca194c90$@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEaPs7iLwqOaTNknblhLQFEtN95CaKTMiaw
Content-Language: en-us
X-Originating-IP: 168.144.250.234
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: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.08)
X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49FXKwZbSflcvTu2SSy6NnOlTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqYq0msVkaLEgmxlAUfxVw4RcOb18WfxGyg6Om6u4YYm+3vXoyqU0cY7/gz Mk/VdBQ5hjoyEb9Oq0NWpyO3vrfYzS02aeiYw+GANPqwVsDMNz3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBcKaDTe3QRRhTm1Fh3Md1txQRCdMNhge1Unb77YyuZq7g0QgZeqquOR+3jgVIhh/+RBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU2Z0wfN9VTx9JdR4F4pphrEJ0EukYkH0+QwgTkvGReJqS3AA1zi4L4OJ0M18xnuBW/6 592ULW4vfh/b1HrXegYtT+0ZYmWVDcilzOi/IsK0IJxMmrh0EB+IMLHqHSY3hiG6elFFgxvixKHD +ndZqoQq0JFb5sY5yvsuaKnQYvhP+274nM+117vLjWiTA8zC3e5qTjAEzQR26Rr0dPOgWImrJASn HPpo89VhQ79BRQQ5y0H9asyhHPHrk1fOl/Hbtww=
X-Report-Abuse-To: spam@quarantine5.antispamcloud.com
X-Recommended-Action: accept
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/oV9Dol_ArebdtzD6ZHNaef9x7vg>
Subject: Re: [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:39:31 -0000
Copying to Nathan Kinder and Nathaniel McCallum, since their mail server rejects messages relayed by the IETF server. -----Original Message----- From: secdir [mailto:secdir-bounces@ietf.org] On Behalf Of Christian Huitema Sent: Saturday, December 31, 2016 6:20 PM To: 'IESG' <iesg@ietf.org>; 'secdir' <secdir@ietf.org>; draft-ietf-kitten-krb-auth-indicator.all@ietf.org Subject: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04 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 mailing list secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
- [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