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

[Nico Williams <[e-mail]>]

On Mon, Oct 27, 2014 at 10:25 AM, Greg Hudson <[e-mail]> wrote:
> On 10/24/2014 06:08 PM, Benjamin Kaduk wrote:
>> Well, it has at least one realm that it knows exists.  (I guess it need

The only methods of determining an acceptor's realm, available to an
IAKERB initiator, are:

 - referrals, starting with either or all of (in sequence) the client
principal's realm, or any other realm that the initiator might have
knowledge of

 - a resolver-style "search" of domain-style realms for a given
hostname (presumably with FAST for each TGS exchange to protect the
integrity of KRB-ERRORs)

Note that the KRB_AP_ERR_IAKERB_KDC_NOT_FOUND and
KRB_AP_ERR_IAKERB_KDC_NO_RESPONSE errors cannot be protected.  If this
error results during a resolver-style search, the initiator should
stop searching.

Question: presumably KRB_AP_ERR_IAKERB_* do not terminate the security
context exchange, and GSS_Accept_sec_context() returns
GSS_S_CONTINUE_NEEDED in those cases?  Although there should probably
be a maximum number of context tokens that the acceptor is willing to
exchange, past which it will need to return GSS_S_FAILURE, and then
how is _that_ communicated to the initiator??

(It might have been nice to have DNS TXT/whatever RRs for determining
target host principals' realms, and to proxy DNS[SEC] lookups in
IAKERB.  However, that seems like a lot of work.)

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

I agree: the latter.

> As an implementor, I would generally want to just call
> krb5_get_default_realm() and return an error if that fails.  But the RFC
> should say what error to return.

Hmmm.  Is there a standard notion of "default realm"?  We've seen a
number of cases where there's no configured default realm, where an
acceptor might have keys for principals in multiple realms, and so on.

I'd rather say that the initiator can use a zero-length realm to
indicate "I don't know where to send this" and the acceptor should
substitute a realm of its choice.  If the acceptor has many realms...
then the above question once more arises as to how we know when a
KRB-ERROR denotes that GSS_Accept_sec_context() returns
GSS_S_CONTINUE_NEEDED versus when it returns GSS_S_FAILURE.

> (I don't think MIT krb5 currently implements this part of IAKERB, since
> it wasn't present in the earlier draft that we used.)

Sure, but we're designing a protocol as much as documenting reality :)

>> So, "including the generic token framing of the InnerContextToken type
>> from [RFC 2743]", then?
>
> I think that's right.

*sigh*  Sure.

Nico
--