Subject: [kitten] New I-D: multiple round trips for the krb5 GSS mech: draft-williams-kitten-krb5-extra-rt

From: Nico Williams <[email-masked]>
Date: Thu, 14 Feb 2013 11:29:57 -0600

I've just submitted draft-williams-kitten-krb5-extra-rt-00, an I-D
that proposes a multi-round trip extension to RFC4121.

The motivations for this are various, but mainly the ability to
recover from otherwise-fatal errors that lead to SSHv2 (when using
gss-keyex) and other such connections to fail and clients having to
reconnect.

This I-D also adds user2user support to the Kerberos GSS mechanism.  Finally!

See forwarded e-mail below.

(Yes, I know that I'm using '-' instead of '--' in the ASN.1 as
comments.  This is due to a missing feature in lyx2rfc, the remapping
of em dash to two en dashes.)

Nico

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Thu, Feb 14, 2013 at 11:24 AM
Subject: New Version Notification for draft-williams-kitten-krb5-extra-rt-00.txt
To: [email-masked]
Cc: [email-masked]

A new version of I-D, draft-williams-kitten-krb5-extra-rt-00.txt
has been successfully submitted by Nicolas Williams and posted to the
IETF repository.

Filename:        draft-williams-kitten-krb5-extra-rt
Revision:        00
Title:           Negotiation of Extra Round Trip for Kerberos V5
Generic Security Services Mechanism
Creation date:   2013-02-14
Group:           Individual Submission
Number of pages: 14
URL:
http://www.ietf.org/internet-drafts/draft-williams-kitten-krb5-extra-rt-00.txt
Status:
http://datatracker.ietf.org/doc/draft-williams-kitten-krb5-extra-rt
Htmlized:
http://tools.ietf.org/html/draft-williams-kitten-krb5-extra-rt-00

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 an extra pair of security context
   tokens in order to recover from certain errors.  Other benefits
   include: user2user authentication, authenticated errors (in some
   cases), and more.

The IETF Secretariat

---

From: Luke Howard <[email-masked]>
Date: Fri, 15 Feb 2013 12:08:55 +1100

* Presumably all tokens have the pseudo-ASN.1 wrapping, not just the new initiator token?

* Why feature negotiation in both AD and AP options?

-- Luke

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Feb 2013 19:41:01 -0600

> * Presumably all tokens have the pseudo-ASN.1 wrapping, not just the new initiator token?

Yes (since RFC4121 mandates that).

> * Why feature negotiation in both AD and AP options?

Err, no real reason.  Indeed, I think I can remove the AD for that.

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Feb 2013 15:50:44 -0600

Someone asked me, on IM I think, what's the difference between this
and DC style.  There are only two consequential differences:

1. DCE style is chosen by the initiator alone -the acceptor gets no
say in the matter- while this extension is at the acceptor's choice.
(see below though)

2. This extension allows for arbitrary round trips (though
implementations should impose a reasonable limit), and is generic
enough that it allows for various features that require more than one
round-trip: error recovery, replay cache avoidance, and user-to-user
authentication.  If we ever build a PFS extension we can even have the
acceptor issue a fast reauthentication ticket for itself that the
initiator can use to re-authenticate quickly while retaining forward
security from the initial authentication exchange with PFS.  And all
of this with the same mechanism OID!

#1 means that DCE style can only be used when the initiator has reason
to believe that the acceptor supports it, whereas this extension is
optional and the acceptor is free to use it or not.  This also means
that no req_flag (nor ret_flag, nor flag in the 0x8003 structure) is
needed -- you either get one round-trip or more, and at the acceptor
mechanism's choice, transparent to the application.  Mind you, apps
that request DCE style could be compatible with acceptors that don't
support it because the latter will respond with an AP-REP with the
pseudo-ASN.1 header, and that distinguishes the response token from a
DCE style response token.

There's other lesser differences, like that the pseudo-ASN.1 header is
always present in all the security context tokens in my proposal (as
RFC4121 wants it).

There is one important issue though: if there's another GSS mechanism
(with different mech OID, of course) for doing user-to-user (and there
is) then negotiation in the KDC_ERR_MUST_USE_USER2USER case could
result in failure where without this new feature it could have
resulted in success.  We can address this via configuration, or by
disallowing user-to-user in the KDC_ERR_MUST_USE_USER2USER case (the
acceptor could still ask for u2u though).

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 15 Feb 2013 16:13:44 -0600

I've posted a -01.