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

[Benjamin Kaduk <[e-mail]>]

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