Re: [kitten] draft-ietf-kitten-iakerb-02

[Benjamin Kaduk <[e-mail]>]

On Thu, 16 Oct 2014, Greg Hudson wrote:

> "tickts" is a typo.
>
> "Yes, the tags start at 1" might be more professionally stated as "Note
> that the tag numbers start at 1."

Thanks, patched in my local branch.

> "Since the GSS-API acceptor can act as a Kerberos acceptor, it always
> has an associated Kerberos realm."  This does not follow.  To be a
> Kerberos acceptor, all you need are some keys to decrypt AP-REQ
> authenticators with.  You might have keys from multiple realms.  There
> should be guidance on what to do if the acceptor has no default realm.

Well, it has at least one realm that it knows exists.  (I guess it need
not strictly speaking know where the KDCs for that realm are...)  This
case where the client needs to resolve an enterprise name but doesn't have
a local realm may not be terribly common, so it might be okay to just fail
the GSS negotiation at this point.  Alternately, the acceptor could pick
an arbitrary realm it can accept tickets from.  The latter seems to allow
things to work in more cases than the former, and I don't think it would
make any cases worse than the former, so I'll probably go with the latter.

> "(including the generic token framing of the GSSAPI-Token type from
> [RFC4121])" should reference RFC 2743, shouldn't it?

In 2743, the corresponding type is InitialContextToken, which is why I
made that choice.  Looking more carefully, it also has
SubsequentContextToken ::= innerContextToken ANY
so maybe that's less of an issue than I thought.  And 4121 refers back to
section 3.1 of 2743 as the normative source of the framing, "illustrated
by the following pseudo-ASN.1 structures", so I think you're right that
2743 is the right reference.

So, "including the generic token framing of the InnerContextToken type
from [RFC 2743]", then?


-Ben