Subject: WG Review: Recharter of Common Authentication Technology Next Generation (kitten)

From: IESG Secretary <[email-masked]>
Date: Thu, 8 Jul 2010 14:00:01 -0700 (PDT)

A modified charter has been submitted for the Common Authentication
Technology Next Generation (kitten) working group in the Security Area of
the IETF.  The IESG has not made any determination as yet.  The modified
charter is provided below for informational purposes only.  Please send
your comments to the IESG mailing list ([email-masked]) by Thursday, July
15, 2010.

Common Authentication Technology Next Generation (kitten)
--------------------
Current Status: Active Working Group

Last modified: 2010-07-08

Personnel:

Chair(s):
	Tom Yu <[email-masked]>
	Shawn Emery <[email-masked]>

Security Area Director(s):
	Tim Polk <[email-masked]>
	Sean Turner <[email-masked]>

Security Area Advisor:
	Tim Polk <[email-masked]>

Mailing Lists:
	General Discussion: [email-masked]
	To Suscribe: https://www.ietf.org/mailman/listinfo/kitten
	Archive:
http://www.ietf.org/mail-archive/web/kitten/current/maillist.html

Description of Working Group:

The Generic Security Services (GSS) API and Simple Authentication and 
Security Layer (SASL) provide various applications with a security 
framework for secure network communication.  The purpose of the Common 
Authentication Technology Next Generation (Kitten) working group (WG) is 
to develop extensions/improvements to the GSS-API, shepherd specific 
GSS-API security mechanisms, and provide guidance for any new SASL-
related submissions.
 
This working is chartered to specify the following extensions and 
improvements (draft-yu-kitten-api-wishlist-00) to the GSS-API:

* Provide new interfaces for credential management, which include the 
following:
	initializing credentials
	iterating credentials
	exporting/importing credentials

* Specify interface for asynchronous calls.

* Define interfaces for better error message reporting.

* Provide a more programmer friendly GSS-API for application developers.
 
This could include reducing the number of interface parameters, for 
example, by eliminating parameters which are commonly used with the 
default values.

This WG is also chartered to transition proposed SASL mechanisms as
GSS-API mechanisms:

* A SASL Mechanism for OpenID
	draft-lear-ietf-sasl-openid-00
* A SASL Mechanism for SAML
	draft-wierenga-ietf-sasl-saml-00

The transition from SASL to GSS-API mechanisms will allow a greater set 
of applications to utilize said mechanisms with SASL implementations 
that support the use of GSS-API mechanisms in SASL (draft-ietf-sasl-
gs2).

* Shepherd draft-ietf-sasl-digest-to-historic to publication.

This WG should review proposals for new SASL and GSS-API mechanisms, but
may take on work on such mechanisms only through a revision of this 
charter.  The WG should also review non-mechanism proposals related to 
SASL and the GSS-API. However, work that adds SASL or GSS-API support in 
application protocols should be handled by the application's WG.

Deliverables:

* GSS-API: initializing credentials
[editor: TBD]

* GSS-API: iterating credentials
[editor: TBD]

* GSS-API: exporting/importing credentials
[editor: TBD]

* GSS-API: specification for asynchronous calls
[editor: TBD]

* GSS-API: interfaces/improvements for better error message reporting
[editor: TBD]

* GSS-API: programmer friendly interfaces
[editor: TBD]

* GSS-API: transition SASL mechanism for OpenID
[editor: TBD]

* GSS-API: transition SASL mechanism for SAML
[editor: TBD]

* GSS-API: publish draft-ietf-kitten-gssapi-extensions-iana
[editor: Nicolas Williams]

* GSS-API: publish draft-ietf-kitten-gssapi-naming-exts
[editor: Leif Johansson]

* SASL: publish draft-melnikov-digest-to-historic
[editor: Alexey Melnikov]

Goals and Milestones:

June 2010	Submit naming-exts to the IESG as Proposed Standard
June 2010	WGLC on gssapi-extensions-iana
July 2010	Submit gssapi-extensions-iana to the IESG as Proposed Standard
TBD             Other Listed Work Items

---

From: Tom Yu <[email-masked]>
Date: Mon, 12 Jul 2010 12:25:27 -0400

FYI, I just refreshed the "wishlist" Internet-Draft.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 12 Jul 2010 13:40:07 -0500

I would like to add a work item for KITTEN WG: a pair of TLS extensions
for optimizing SASL/GS2 authentication with channel binding to TLS.

The optimization is a round-trip optimization.

A TLS Hello extension would be used to optimize the SASL mechanism
negotiation: a client Hello extension requests a list of the server's
SASL mechanisms, while a server Hello extension provides that list.

The other round-trip optimization consists in allowing application data
to begin flowing sooner (immediately after the client's ChangeCipherSpec
and Finished messages) than TLS would normally allow, but only when that
"application data" consists of a SASL GS2 authentication message.

This means that a TLS and SASL GS2 with Kerberos handshake can happen in
two round-trips!

This is all described in draft-williams-tls-app-sasl-opt-03.  The I-D
needs some edits to be brought up to date with RFCs 5801, 5802 and 5929
(which are supposed to be issued today).

The TLS Hello extension for SASL mechanism negotiation should be
entirely non-controversial.  Even without the second extension (which is
not needed in the case of TLS session resumption) we'd get a 1-round-trip
optimization.

I believe the second extension should be agreeable to the TLS WG; with
it we get a total of two round-trips optimized (the first round-trip
always being a SASL mechanism negotiation).

I believe these round-trip optimizations are highly desirable.  The fact
that proposals have been made in the past to add GSS-API authentication
inside TLS is evidence of that proposition.  But we need a way to do
this that does not imply offensive changes to the TLS state machine; I
believe my proposal accomplishes this.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 12 Jul 2010 13:41:57 -0500

I forgot to take off the ietf-announce list from the Cc list.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 13 Jul 2010 20:13:43 +0100

<As an individual contributor>:

>believe my proposal accomplishes this.
I am happy for this topic to be a part of the charter. Similar ideas 
were proposed in other Apps areas (e.g. in Lemonade there was a proposal 
how to pipeline final leg of TLS exchange with some SMTP data). I am 
happy for this to be Experimental or Standard Track.

But I am hoping it is not just Nico and myself.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Jul 2010 13:17:38 -0600

> But I am hoping it is not just Nico and myself.

I'd be in favor of round-trip optimizations -- we could make use of
those in XMPP for sure. :)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 13 Jul 2010 14:41:12 -0500

On Tue, Jul 13, 2010 at 08:13:43PM +0100, Alexey Melnikov wrote:
> > [...]
> were proposed in other Apps areas (e.g. in Lemonade there was a
> proposal how to pipeline final leg of TLS exchange with some SMTP
> data). I am happy for this to be Experimental or Standard Track.

Funny, my I-D has a description of how SMTP might use the extension
besides for SASL authentication: e.g., to do EHLO before authentication.
And LDAP clients could do a search for the root DSE.

> But I am hoping it is not just Nico and myself.

I know there's been plenty of interest in adding GSS-API support to TLS.
Surely there will be interest in this design, since it accomplishes
that.  However, we might not be reaching the right audience by proposing
this on the KITTEN WG list, even if we all agree that KITTEN is the best
home for this work item.

I'm updating the I-D to reflect the just-issued RFCs 5801 and 5929, and
to simplify some things (apparently I left some brokenness from -02 in
-03, and re-reading I find -03 confusing).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Jul 2010 16:54:41 -0500

> (which are supposed to be issued today).

I've missed the I-D submission cut-off for -04.  I'm attaching -04.txt.
This version is much cleaned up and, I hope, much clearer than -03.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 14 Jul 2010 18:00:55 -0500

Martin Rex points out that what I call "early start" of the TLS
application record protocol is elsewhere called "false start".
Searching I found draft-bmoeller-tls-falsestart-00.

The upshot is, I think, that my proposal is likely uncontroversial.

Nico
--