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

[Benjamin Kaduk <[e-mail]>]

On Mon, 26 Sep 2016, Greg Hudson wrote:

> On 09/25/2016 07:20 PM, Benjamin Kaduk wrote:
> > 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.
>
> Application servers can use auth indicators.  What parts of the document
> 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.

> > 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".
>
> 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.

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

> > 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?)
>
> That seems like a reasonable change to me.
>
> > 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).
>
> That change also seems okay to me.

Thanks for the review.

-Ben