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

[Nico Williams <[e-mail]>]

On Tue, Nov 11, 2014 at 12:59:35PM -0500, Greg Hudson wrote:
> I support adopting this document.  My comments so far:

Thanks.

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

I thought we ended up saying that the null enctype does have a purpose
after all (was it about KRB-CRED?  I forget).  But yes.

> * 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?

That's covered in section 2.1.

> If the acceptor sent a KRB-ERROR2 without ke-continue-needed, it's not
> expecting another message, is it?

Ah, this is an editing error.  Thanks for catching this.

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

I was wondering about this.  If the acceptor can decrypt the Ticket but
not the Authenticator then there was a transmission error, and the
question is whether it's worth trying to recover from that.  My guess
now is "no".

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

What I'd like to say is that initiator _apps_ shouldn't bother sending
error tokens to acceptors.  Allowing the initiator _mech_ to produce
them (and the acceptor _mech_ to consume them) is an exercise in
completeness that would enable role reversal applications.

Perhaps we shouldn't care about role reversal applications (since we
have none).  But since this has been needed in the past (ISMS or some
such), I'd want a bit more discussion before discounting them
altogether.

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

Yeah, it's about abandonment.  There may well be no value to it because
apps always have to deal with timeouts anyways.  Not forcing a peer to
timeout is a matter of courtesy, but if the peer minimizes state kept
(as it should), it may not matter much.

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

Right (or more likely a dk in the same key hierarchy).

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

Yep, this is missing.

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

I thought I ripped that out completely in the latest version.  Did I
leave stray text about it?

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

Two reasons: a) the server might still want rcache avoidance, b) I
wanted to avoid having to extend AP-REP (though I'd be happy to extend
it anyways).  (b) is lame; (a) is not.

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

Not sure.

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

I think it might be.  Think of authz-data in the u2u TGT affecting what
appears in the service ticket in the end.

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

It's that or authz-data.

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

Again, I thought I'd ripped that out.

> * 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?

Either is fine with me.

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

Sure.  I was following tradition :)

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

OK.  Thanks!

Nico
--