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

Benjamin Kaduk <> Tue, 03 January 2017 06:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A14EC129434; Mon, 2 Jan 2017 22:20:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.321
X-Spam-Status: No, score=-7.321 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=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id h0JuWAZB_O89; Mon, 2 Jan 2017 22:20:10 -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 0B2F6129508; Mon, 2 Jan 2017 22:20:09 -0800 (PST)
X-AuditID: 1209190e-717ff70000005a86-bf-586b4298f449
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id D5.71.23174.8924B685; Tue, 3 Jan 2017 01:20:08 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id v036K76K029374; Tue, 3 Jan 2017 01:20:07 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v036K2Dt010607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 3 Jan 2017 01:20:04 -0500
Date: Tue, 3 Jan 2017 00:20:02 -0600
From: Benjamin Kaduk <>
To: Christian Huitema <>
Message-ID: <>
References: <005f01d263d5$84b14680$8e13d380$> <006f01d263d8$435dc430$ca194c90$>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <006f01d263d8$435dc430$ca194c90$>
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IRYrdT0Z3hlB1hcPSeqsXclt8sFpMbZ7Nb zPgzkdliwpvbrBZzv85itfiw8CGLA5vHrRmnWDyWLPnJ5PF+31W2AOYoLpuU1JzMstQifbsE rozv6/4xFsw2r3h2uIO9gXG6bhcjJ4eEgInEmf7lTF2MXBxCAm1MEhPW7mSEcDYwSjRf3cYM 4Vxhkti9dT4bSAuLgIrEtn9HGEFsNiC7ofsyM4gtIqAtsWb2PbBRzAKrGCXOfT0G1iAs4Cfx +vplFhCbV8BYYtP22WC2kECmxJNvrVBxQYmTM5+A2cwCWhI3/r0EGsQBZEtLLP/HARLmFLCS mH72LtguUQFliYYZD5gnMArMQtI9C0n3LITuBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN 9XIzS/RSU0o3MYJCm1OSbwfjpAbvQ4wCHIxKPLwdUVkRQqyJZcWVuYcYJTmYlER5oxmyI4T4 kvJTKjMSizPii0pzUosPMUpwMCuJ8JpaAOV4UxIrq1KL8mFS0hwsSuK8lzLdI4QE0hNLUrNT UwtSi2CyMhwcShK8jI5AjYJFqempFWmZOSUIaSYOTpDhPEDD60FqeIsLEnOLM9Mh8qcYFaXE eeNBEgIgiYzSPLheUOqRyN5f84pRHOgVYd7TDkBVPMC0Bdf9CmgwE9Dgr3HpIINLEhFSUg2M VkcPyPIZ3p12rk68e96N/KW1bvV2+YV/9yf33OKUyPyyQaujzef4RmvbYGHPIJaK0AMct/dH N0lOecSyapFb0hHPj4e3nT70fF1CkPLEvEb74hlsxlZatlnqF8/EKd7K/KDHdvSjPHur8sOb 9w9E5ElE61grp/+/GRzIsNZObofglSjOgIVKLMUZiYZazEXFiQA8aechGAMAAA==
Archived-At: <>
Cc:,,, 'IESG' <>, 'secdir' <>
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: Tue, 03 Jan 2017 06:20:11 -0000

Hi Christian,

Thanks for the review!

On Sat, Dec 31, 2016 at 06:39:21PM -0800, Christian Huitema wrote:
> 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
> 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.

I noticed the "Updates but doesn't really update" issue while preparing the
shepherd review, and opted to leave in the "Updates" marker since it's
probably something an implementor of 4120 should know about.
The "Assigned Numbers" section is a good idea, thanks for pointing it out
(and yes, you understand correctly).

Authors, can you prepare another update?

> 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? 

There is maybe some potential for confusion, though not, I think, at the
protocol level.  The authentication indicator should always originate from
the realm of orignial authentication, which is the realm of the client
principal (in general).  Even with some of the more exotic flows, like
anonymous (or semi-anonymous) principals and making cross-realm TGS
requests for foreign-realm TGTs, the client principal's realm is unchanged,
so at a protocol level, the meaning of "this realm asserts that this
authentication mechanism was used" remains clear.  The confusion is when
applications just check strings against a table without special-casing
foreign-realm principals (which is likely to happen and the natural thing
for application authors to do; I am not trying to belittle the issue
you raised).

In many cases, cross-realm operations occur when the administrators
of the different realms are tightly coordinated (or even the same
group), in which case they probably use the same semantics for the
authentication indicator.  In cases where the administrators of the
different realms are genuinely different organizations, there are already
risks for application services in such realms, such as for applications
that grant access to "valid user".  That said, the authentication indicator
does introduce a new type of risk, and it is appropriate to have some
text about it in the security considerations.

Authors, do you think you can come up with text, or should one of us
try to make a contribution?

> 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?

I don't think the WG looked at the consequences, no -- IIRC this requirement
was introduced at my urging due to the shepherd review, in order to
avoid conflict between the two classes of possible values.  If URIs must
be LoA profiles and site-local values must be not-URIs, then there is
no conflict.

My expectation is that what will happen in practice is that the site-local
short strings will actually be implementation-local, and the name of the
preauthentication plugin or module will be used, like "otp" or "pkinit"
or "spake".  I don't expect anyone to try to make globally unique values,
but of course there are always options like UUIDs or using alternate
separator characters for those who wish to try.  (It is debatable whether
UUIDs count as "short", but there is no enforcement on "short", so
they are in practice fair game.)

> What are application services supposed to do when they encounter URI or
> site-defined strings that they do not understand?

The same thing they do now (in practice) when receiving other unknown
authorization data types: ignore it.  (This is in violation of the
spec, that says unknown types should be treated as critical unless
wrapped in AD-IF-RELEVANT, but that behavior is not implemented in the
major implementations.)  That may end up being a default-deny or
default-permit mode, depending on the application service's configuration.

> 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?

If I remember the history of the document correctly, there is intentionally
no limit.  URIs for LoA profiles could end up being pretty long, and
there was a desire to not artificially limit those; it doesn't seem
worth complicating the semantics of the indicator just to impose a length
restriction on the non-URI strings.  As far as the number of elements in
the sequence, in practice there is probably no issue, since the
authentication indicator is issued by the KDC in response to the actual
authentication that occurred -- well-behaved KDCs should only include
as many strings as authentication methods were used (which is in practice
one or two at the moment, and probably not going to get much above three
ever).  There is always the concern about a client parsing
untrusted/unvalidated input, but the consumer should be validating the
MAC(s) in the CAMMAC container before parsing, and the implementation
ticket size (and similar) constraints will also limit the possible
size here.

So, probably no attacks (absent compromised KDCs, which have other
ways to wreak havoc) and probably no need for security consideration
mention.  I can't come up with any potential interoperability issues,
either, but I didn't spend a whole lot of time thinking about it.

Thanks again,