Re: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04

"Christian Huitema" <> Sun, 01 January 2017 02:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C47AF12955B for <>; Sat, 31 Dec 2016 18:39:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2TrV-BCnWJwJ for <>; Sat, 31 Dec 2016 18:39:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B313129555 for <>; Sat, 31 Dec 2016 18:39:29 -0800 (PST)
Received: from ([] by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from <>) id 1cNW3T-0002h9-Bz for; Sun, 01 Jan 2017 03:39:28 +0100
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1cNW3R-0003IH-By for; 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) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 1 Jan 2017 02:39:24 -0000
From: "Christian Huitema" <>
To: "'IESG'" <>, "'secdir'" <>, <>, <>, <>
References: <005f01d263d5$84b14680$8e13d380$>
In-Reply-To: <005f01d263d5$84b14680$8e13d380$>
Date: Sat, 31 Dec 2016 18:39:21 -0800
Message-ID: <006f01d263d8$435dc430$ca194c90$>
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
Authentication-Results:; auth=pass smtp.auth=
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-Recommended-Action: accept
Archived-At: <>
Subject: Re: [secdir] SECDIR review of draft-ietf-kitten-krb-auth-indicator-04
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 [] On Behalf Of Christian Huitema
Sent: Saturday, December 31, 2016 6:20 PM
To: 'IESG' <>rg>; 'secdir' <>rg>;
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

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