[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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 ([]) 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 [] (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@[]) (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-SpamExperts-Domain: xsmtpout.mail2web.com
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=
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

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