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

[Benjamin Kaduk <[e-mail]>]

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 [mailto:[e-mail]] On Behalf Of Christian Huitema
> Sent: Saturday, December 31, 2016 6:20 PM
> To: 'IESG' <[e-mail]>; 'secdir' <[e-mail]>;
> [e-mail]
> 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