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

Benjamin Kaduk <> Thu, 05 January 2017 19:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 444CB129654; Thu, 5 Jan 2017 11:47:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.301
X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 1ziZHGatVHtu; Thu, 5 Jan 2017 11:47:36 -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 67443129653; Thu, 5 Jan 2017 11:47:36 -0800 (PST)
X-AuditID: 12074425-80fff70000001995-49-586ea2d7c2d9
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 61.0C.06549.7D2AE685; Thu, 5 Jan 2017 14:47:35 -0500 (EST)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id v05JlX8R011228; Thu, 5 Jan 2017 14:47:34 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id v05JlTRQ027616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Jan 2017 14:47:31 -0500
Date: Thu, 05 Jan 2017 13:47:29 -0600
From: Benjamin Kaduk <>
To: Christian Huitema <>
Message-ID: <>
References: <005f01d263d5$84b14680$8e13d380$> <006f01d263d8$435dc430$ca194c90$> <> <00c901d26766$566e9ae0$034bd0a0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <00c901d26766$566e9ae0$034bd0a0$>
User-Agent: Mutt/1.6.1 (2016-04-27)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IR4hTV1r2+KC/C4OUtPou5Lb9ZLCY3zma3 mPFnIrPF0c2rWCwmvLnNajH36yxWiw8LH7I4sHvcmnGKxWPJkp9MHu/3XWULYI7isklJzcks Sy3St0vgylje9Yyx4I17xZfnz1gbGPutuhg5OCQETCS6N2V1MXJxCAm0MUl8+T+DFcLZwCjx +fw0JgjnCpPEoy+n2boYOTlYBFQk5h3byw5iswHZDd2XmUFsEQFtiTWz74E1MAvsZpT4s38x E0hCWMBP4vX1yywgNq+AscThlsuMEFMPM0q8OPOQGSIhKHFy5hOwImYBLYkb/14ygdzHLCAt sfwfB0iYU8BK4sCfF6wgtqiAskTDjAfMExgFZiHpnoWkexZC9wJG5lWMsim5Vbq5iZk5xanJ usXJiXl5qUW6Fnq5mSV6qSmlmxhBQc7uorqDcc5fr0OMAhyMSjy8EV55EUKsiWXFlbmHGCU5 mJREeVNnAIX4kvJTKjMSizPii0pzUosPMUpwMCuJ8K6bB5TjTUmsrEotyodJSXOwKInzXsp0 jxASSE8sSc1OTS1ILYLJynBwKEnwci8EahQsSk1PrUjLzClBSDNxcIIM5wEaXgFSw1tckJhb nJkOkT/FqCglzlu5ACghAJLIKM2D6wUlIYns/TWvGMWBXhHm/QLSzgNMYHDdr4AGMwEN3h6Q DTK4JBEhJdXAWLu2W4M7yYXbpCTqTvMWsQ+bkuS3dvkWXXLl/WXqPSNuWw773RmnxUo2CU/k u/gzedM9V2PXtxcmmHyuLvFjXDzB05rha7e1/wTBpe/2pEwRLj0ZUb/L1Tog/mhuiuLXW8pT fu2NVD301OW8Q+N6nXQmvX/1+t967qmm9L37G7Rn9fGDnBMilViKMxINtZiLihMBVU0XNB0D AAA=
Archived-At: <>
Cc: 'secdir' <>,,,,, 'IESG' <>
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: Thu, 05 Jan 2017 19:47:39 -0000

On Thu, Jan 05, 2017 at 07:13:55AM -0800, Christian Huitema wrote:
> Thanks for the corrections. I checked the new draft version,
> draft-ietf-kitten-krb-auth-indicator-06, and the changes address my concern.
> The new section "4.  Assigned Numbers" provides a clear update to RFC 4120,
> and the added paragraph in the security section addresses cross-realm
> indicator collisions.

Thanks for finding the new document -- I was going to send you a pointer
today to confirm that it addressed your concerns, but you beat me to it.

> One point, though. The new section 4 states:
>    o  The table in Section 5.2.6 of RFC 4120 [RFC4120] is updated to map
>       the ad-type 97 to "DER encoding of AD-AUTHENTICATION-INDICATOR".
> Should that not be "DER encoding of AD-AUTHENTICATION-INDICATOR wrapped in a
> CANMAC container"?

I don't think so, but will loop in the WG to confirm.
The ad-type should indicate what is immediately inside the next encoding
layer of the ad-data.  So a Ticket might have an AuthorizationData that
contains ad-type 1 (AD-IF-RELEVANT), that itself contains AuthorizationData
with ad-type 96 (AD-CAMMAC), that in turn contains AuthorizationData with
ad-type 97 (AD-AUTHENTICATION-INDICATOR).  So, 97 should appear only at
the lowest level, and correspond to ad-data that's just the

But thanks again for double-checking!


> -----Original Message-----
> From: Benjamin Kaduk [] 
> Sent: Monday, January 2, 2017 10:20 PM
> To: Christian Huitema <>
> Cc: 'IESG' <>; 'secdir' <>;
> Subject: Re: [secdir] SECDIR review of
> draft-ietf-kitten-krb-auth-indicator-04
> 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' <>; 'secdir' <>;
> >
> > 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,
> Ben