Subject: [kitten] shepherd review of draft-ietf-kitten-krb-auth-indicator-02

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 25 Sep 2016 19:20:23 -0400 (EDT)

Hi all,

I've completed my shepherd review of
draft-ietf-kitten-krb-auth-indicator-02, and unfortunately it seems that
an additional revision may be needed.

It feels like some parts of the document are written as if the "short
strings" for comparison against known values are only for use when
presented back to the KDC, but other parts of the document describe it as
being used for policy decisions made by application services as well as
the KDC.  (If it was just the KDC that was handling it, the document would
not need to specify, since KDC-internal things need not
necessarily interoperate the way that public protocol elements do.)  There
is also the possibility (probability, really), of site-local values that
are specific to a given realm.  This is perhaps implied by the mention of
"the name of the Pre-Authentication mechanism used" but not stated
explicitly.  The interoperability requirements for site-local values are
less stringent, but there still needs to be a clear understanding of what
the contents of the protocol field should be.

So, I think that section 3 should be more stringent, saying something like
"strings that contain a colon character MUST be URIs that reference a
Level of Assurance Profile, leaving other strings available for
site-local use".

I also suspect that the last paragraph of the security considerations
should be rewritten in a normative fashion and moved to section 3, to make
it clear what the presence of a given string in the authdata indicates.
(Do we know of reasons why someone might use this AD element to indicate
something other than a positive indication that the indicated requirements
were met during the initial authentication?)

There's also some matter of form regarding the string
"AD-AUTHENTICATION-INDICATOR", which should probably just be used for the
definition of the ASN.1 type; the value 97 is the ad-type for which the
contents of-the ad-data field will be the DER encoding of the
AD-AUTHENTICATION-INDICATOR object.  So, I would just say "The KDC MAY
include authorization data of ad-type 97, wrapped in AD-CAMMAC, [...]" and
skip the line that's just

AD-AUTHENTICATION-INDICATOR 97

(and replace the colon with a full stop).

Some other editorial notes:

In the Abstract, s/the service tickets/service tickets/

In the Introduction, hyphenate "password-based".  It's probably good to
mention "or other preauthentication schemes" after public-key cryptography
(which, hmm, should probably also be hyphenated), and make it into a
comma-separated list.  Is "have" the best word in "[i]mplmentations that
have pre-authentication-mechanisms [...]"?  Maybe "offer", "support", or
"provide"?  In the last sentence of the first paragraph, maybe "strength
of the authentication that was used, for use as an input" would remove
some ambiguity.  In the second paragraph, maybe "to convey authentication
strength information", and "Elements of this type [will|MUST] appear
within an AD-CAMMAC".  Also, it's probably worth a clause briefly saying
why the CAMMAC is needed (to provide authenticity/integrity when a ticket
is presented back to the KDC).

The 2119 boilerplate doesn't list "NOT RECOMMENDED" but you don't use it,
so maybe it doesn't need to change.

In Section 3, it may be better to split the first sentence into two, so
"The KDC MAY copy it from a ticket-granting ticket into service tickets"
is a separate sentence, since the KDC can do the first without ever
needing to do the latter.

Still in Section 3, put a comma before "such as the name of the
Pre-Authentication mechanism used".  (Also, I sort-of want to ask "how
short is a short string?", but there's not really a useful answer to give,
particularly since the LoA URIs are in play and are likely to be longer
than non-URI strings.)

Thanks,

Ben

---

From: Greg Hudson <[email-masked]>
Date: Mon, 26 Sep 2016 12:28:26 -0400

On 09/25/2016 07:20 PM, Benjamin Kaduk wrote:
> the KDC.

Application servers can use auth indicators.  What parts of the document
imply that they are only used by the KDC?

> Level of Assurance Profile, leaving other strings available for

The existing text in section 3 is pretty clear to me, but if we need to
make it more clear, I suggest replacing:

    These
    strings MAY be site-defined strings that do not contain a colon such
    as the name of the Pre-Authentication mechanism used, or
    alternatively URIs that reference a Level of Assurance Profile
    [RFC6711].

with:

    Each string MUST be either:

    * A URI which references a Level of Assurance Profile [RFC6711].

    * A site-defined string, which MUST NOT contain a colon, whose
      meaning is determined by the realm administrator.

> were met during the initial authentication?)

That seems like a reasonable change to me.

> (and replace the colon with a full stop).

That change also seems okay to me.

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 26 Sep 2016 18:58:31 -0400 (EDT)

> imply that they are only used by the KDC?

I don't think there's anything explicit, just some implicit implication by
way of not concretely specifying the structure enough to be fully portable
without site-local configuration.

>       meaning is determined by the realm administrator.

That seems like an improvement to me, in that it is more likely to result
in interoperable implementations.

> That change also seems okay to me.

Thanks for the review.

-Ben

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 28 Sep 2016 12:41:16 -0400

> were met during the initial authentication?)

IMHO, I think this is not necessary. Section 3 already contains this
paragraph:

"Each UTF8String value is a short string that indicates that a
particular set of requirements was met during the initial
authentication."

This sentence is the normative definition of precisely what an
indicator is. The paragraph in the security considerations section is a
warning about what would happen if you tried to use indicators for
another purpose: ambiguity would arise. This is a security
consideration.

This warning is necessary precisely because the majority use of
indicators will be as site-defined strings.

---

From: Nathaniel McCallum <[email-masked]>
Date: Wed, 28 Sep 2016 12:50:12 -0400

I submitted a new draft with these changes. I only omitted the change
to the security considerations section. We can discuss that further if
need be. I stated my reasons for keeping the existing wording in
another email.

On Mon, 2016-09-26 at 12:28 -0400, Greg Hudson wrote:
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 30 Sep 2016 00:01:58 -0400 (EDT)

> need be. I stated my reasons for keeping the existing wording in

Thanks for the updates.  I do not insist on changes to the security
considerations text, but will not be surprised if a GenART/Opsdir/secdir
reviewer re-raises the question.

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.

-Ben