Subject: [kitten] intended status and Updates: 4120 for draft-ietf-kitten-krb-auth-indicator-02

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 17 Nov 2016 01:13:44 -0600

Sorry for the long silence on this one; certain checklist steps
essentially require contiguous blocks of time that are sometimes hard
to come by.

One of the checklist items is to look at the intended status and any
documents updated by the draft; in a look through the archives it seems
that we never explicitly mentioned that this draft is labelled as
targetting Standards-Track and is marked as Updating RFC 4120.

I think that Standards-Track is fine, and there is not full agreement
in the IETF as to what exactly the "Updates" tag means (long thread at
https://www.ietf.org/mail-archive/web/wgchairs/current/msg14618.html).
The argument for keeping the "Updates" tag would be that it is adding
a new AD type that we want implementations of 4120 to also implement
(CAMMAC has a stronger argument for "Updates" since it replaces
KDC-ISSUED).

My default action is to leave the document as-is, with target status
of Standards-Track and Updates: 4120, but in lieu of having this
be part of a formal WGLC, I will explicitly call it out on the WG
list in case there are objections.

On Fri, Sep 30, 2016 at 12:01:58AM -0400, Benjamin Kaduk wrote:
> 
> I do have one question, though: the new version says that the CAMMAC
> requirement "exists to provide integrity protection from man-in-the-middle
> attacks", which is a bit odd, since AuthorizationData appear within the
> EncTicketPart (and the auth-indicator is not expected to appear "bare" in
> KDC-REQ or Authenticators, since it is supposed to be KDC-issued).  So,
> unfortunately, that sentence still leaves me confused.

I think this comment remains unaddressed.

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Thu, 17 Nov 2016 12:30:13 -0500

>> unfortunately, that sentence still leaves me confused.

I agree with Ben that this statement is incorrect.

If an auth indicator appeared with no container, or in an if-relevant
container, a server would not know if the value came from the KDC or
from the client (which can request arbitrary authdata at AS-REQ or
TGS-REQ time).

If an auth indicator appeared in a kdc-issued container, a server could
trust it, but the indicator couldn't be safely propagated over an
S4U2Proxy request.  Although that concern might not be relevant in all
deployments, we are requiring CAMMAC for simplicity, using the model
that CAMMAC is an upgraded kdc-issued.

I suggest removing the offending text; I cannot think of a pithy
replacement and I don't think we need it.