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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 14 Oct 2014 10:55:13 -0400 (EDT)

Hi all,

I've made an update to the IAKERB document, hopefully including all the
review comments made on the -00 and -01.

It was a manual posting by the secretariat, so there does not appear to be
an announce email about it.  Here are some links:

HTML: https://tools.ietf.org/html/draft-ietf-kitten-iakerb-02

diff: https://tools.ietf.org/rfcdiff?url2=draft-ietf-kitten-iakerb-02.txt

-Ben

---

From: Greg Hudson <[email-masked]>
Date: Thu, 16 Oct 2014 16:38:04 -0400

"tickts" is a typo.

"Yes, the tags start at 1" might be more professionally stated as "Note
that the tag numbers start at 1."

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

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

On 10/14/2014 10:55 AM, Benjamin Kaduk wrote:
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 24 Oct 2014 18:08:44 -0400 (EDT)

> that the tag numbers start at 1."

Thanks, patched in my local branch.

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

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

---

From: Greg Hudson <[email-masked]>
Date: Mon, 27 Oct 2014 11:25:14 -0400

> make any cases worse than the former, so I'll probably go with 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.

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

> So, "including the generic token framing of the InnerContextToken type

I think that's right.

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Oct 2014 12:26:51 -0500

The best counter-measure against attacks on DNS SRV RR lookups is to
use FAST for the AS exchange, and preferably for TGS exchanges as
well.

Nit: section 6 is slightly incorrect as to not using FAST: it doesn't
expose PA-ENC-TIMESTAMP if... it's not used because the client uses
-say- PKINIT.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 27 Oct 2014 11:30:15 -0500

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

>> make any cases worse than the former, so I'll probably go with the latter.

I agree: the latter.

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

> 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

*sigh*  Sure.

Nico
--

---

From: Greg Hudson <[email-masked]>
Date: Tue, 28 Oct 2014 12:23:41 -0400

While examining the OIDs used by various Kerberos-related ASN.1 modules,
I noticed that the IAKERB draft does not define a full ASN.1 module at
all; it only presents fragments for IAKERB-HEADER and KRB-FINISHED.
There should be an appendix in the draft containing a full module, with
OID and appropriate imports declarations for the RFC 4120 types used.