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

[Benjamin Kaduk <[e-mail]>]

On Mon, 27 Oct 2014, Nico Williams wrote:

> ----- Forwarded message from [e-mail] -----
>
> A new version of I-D, draft-williams-kitten-krb5-extra-rt-02.txt
> has been successfully submitted by Nicolas Williams and posted to the
> IETF repository.
>
> Name:		draft-williams-kitten-krb5-extra-rt
> Revision:	02
> Title:		Negotiation of Extra Security Context Tokens for Kerberos V5 Generic Security Services Mechanism
> Document date:	2014-10-27
> Group:		Individual Submission
> Pages:		15
> URL:            http://www.ietf.org/internet-drafts/draft-williams-kitten-krb5-extra-rt-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-williams-kitten-krb5-extra-rt/
> Htmlized:       http://tools.ietf.org/html/draft-williams-kitten-krb5-extra-rt-02
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-williams-kitten-krb5-extra-rt-02
>
> Abstract:
>    This Internet-Draft proposes an extension to the Kerberos V5 security
>    mechanism for the Generic Security Services Application Programming
>    Interface (GSS-API) for using extra security context tokens in order
>    to recover from certain errors.  Other benefits include: user-to-user
>    authentication, authenticated errors, replay cache avoidance, and
>    others.
>
> ----- End forwarded message -----

Hmm, I guess I was slow in getting to this, and you put out an -03
already.

I read the -03.

My summary is: create a KRB-ERROR2 structure that the acceptor can return
when the initiator has opted in by setting a flag; KRB-ERROR2 has several
nice features compared to KRB-ERROR, including (1) can be encrypted, if a
key is available; (2) can indicate to the acceptor to retry with a
modified request; (3) can include a challenge nonce/freshness indicator;
(4) can include a TGT for use with user-to-user.  (It can also be sent
from initiator to acceptor when the initiator fails to process a received
KRB-ERROR2.)

The initiator includes (3) in the follow-up AP-REQ, proving freshness and
allowing the replay cache to be safely omitted.

Most of the draft is just laying out the details surrounding these and how
they are to be used.

The core extension seems like a fine thing to have so I would be okay with
adopting this as a WG document if we think we have the energy to advance
it properly.

I have some concerns that some of the text could be written differently
and be more clear, most notably section 2.

There are a few open questions tagged in the document:

   [[anchor1: Perhaps we should use a checksum 0x8003 [RFC4121]
   extension instead of authorization data in the authenticator.]]

This is for incorporating the challenge-nonce back into the reply, if I
understand correctly.  I'm not sure how well that would work if we want to
allow for stateless acceptors that use nonces similar to the pkinit
freshness tokens we've been discussing.


   [[anchor2: Question: how should we address this?  We could say "give
   priority to the user-to-user mechanism", but in some cases that might
   require changes to the acceptor side.]]

This refers to the potential for conflict with
draft-swift-win2k-krb-user2user, which I haven't read, so I can't say much
about.


   [[anchor3: We could use the GSS_EXTS_FINISHED extension from
   draft-ietf-kitten-iakerb to implement a strong binding of all context
   tokens.]]

I haven't thought about things hard enough to decide whether the gain in
strength of binding is worth the extra work.

-Ben