Re: [kitten] Kerberos extra round trips I-D revised

[Greg Hudson <[e-mail]>]

I support adopting this document.  My comments so far:

* Encrypting in the null enctype/key isn't a formalized RFC 3961
concept.  The RFC will need to explicitly say what goes into the
EncryptedData message when encryption isn't possible.

* In section 2, there are two bullet points about whether the initiator
should attempt to recover, the first for receiving any KRB-ERROR2 and
the second for receiving a KRB-ERROR2 with the ke-continue-needed flag
set.  In the first bullet point, what does "attempt to recover" imply?
If the acceptor sent a KRB-ERROR2 without ke-continue-needed, it's not
expecting another message, is it?

* Do we really need to address the case where the acceptor can decrypt
the Ticket but not the Authenticator?  If not, we can get rid of
KrbErrorEncPartFlags and the receiver can easily deduce the key from the
EncryptedData and whether it sent an authenticator subkey.

* My preference is not to specify KRB-ERROR2 messages going from the
initiator to the acceptor under any circumstances.  It seems like a fair
amount of implementation complexity for minimal gain; at best the
acceptor is going to write something about the error to a log file.

* Section 2 says that an initiator MAY produce a token (softened from a
MUST in earlier draft versions), but section 2.2 says it MUST produce a
KRB-ERROR2 if it rejects an additional round trip.  Which is it?  I
assume there was some concern about early abandonment of the GSSAPI
exchange by one of the parties.  In my experience, this isn't a serious
problem.  The MIT krb5 GSS acceptor was doing early abandonment for many
releases due to a bug, and while it could obscure error conditions by
failing to send an error packet to the client, it didn't seem to break
any application protocols.

* If the initiator is going to send KRB-ERROR2 messages to the acceptor,
we need to specify what key it uses for encryption.  (The simplest
answer is to use the same key as the acceptor did.)

* I don't see any reference to key usages in the draft.  If the
initiator sends KRB-ERROR2 messages to the acceptor using the same key
as the acceptor used, it should use a different key usage to prevent
reflection attacks.

* How useful is service name redirection if it can only work when the
acceptor was able to decrypt the ticket?  (The draft bars service name
redirection via unencrypted KRB-ERROR2 for fairly obvious security reasons.)

* Does it make any sense to put a fast-reauth ticket in a KRB-ERROR2?
Wouldn't we want it in an AP-REP instead?  (That would render it out of
scope for this draft.)

* In the U2U flow, is there a reason not to use zero-length octet strings?

* Is case 2 of the U2U flow useful?  If not, it presents additional
attack surface on the initiator implementation for no good reason.

* I don't yet have a strong opinion on whether to add a
GSS_EXTS_FINISHED binding.  There might be a reason for it, but if we
can't think of one then I would prefer to avoid the extra complexity.

* Do we need new redir-srealm/redir-sname fields for redirection or
could we just use srealm/sname?  Section 5 says that srealm/sname must
mirror those in the Ticket, but I don't see the point of that
requirement; an attacker can't replay a KRB-ERROR2 for a different
ticket because the key won't match.

* Is it right to specify new ASN.1 type definitions to be added to the
RFC 4120 ASN.1 module, or should we create a new module with its own OID
and import declarations?

* Defining KrbErrorEncPartFlags as KerberosFlags seems like a bad fit;
it is conceptually an enumeration, not a bitmask.

I also have several thoughts about replay cache avoidance, but will put
those in a separate message.

Editorial comments:

* "SHALL have a the" -> "SHALL have the"
* "without no fifth token" -> "without a fifth token"