IETF-96 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

Common Authentication Technology Next Generation (kitten) (WG)

Minutes   |   Jabber Logs  |   Mailing List Archives

Additional information is available at



Security Area Area Director(s):

Assigned Area Director

Status Update (provided 2016-07-20)

Since Buenos Aires, we have had one document advance to IETF LC
(draft-ietf-kitten-aes-cts-hmac-sha2); the WG is happy with it but the
secdir reviewer would have preferred different choices for the crypto and
that thread is not fully resolved yet.

Another draft, draft-ietf-kitten-pkinit-freshness, is on its way to the
IESG pending a shepherd writeup.

In an attempt to mitigate low working group energy, we have decided to
adopt a new scheme for obtaining and tracking document reviews, instead of
the traditional WGLC period before advancing documents to the IESG.
We'll still get document reviews on the mailing list, but we'll also have
a wiki page per document where the chairs (or other participants) will put
links to the review thread, along with which version of the document was
reviewed and any administrative comments about it.  Once the chairs feel a
document has gotten enough review, we'll let the WG list know we plan to
move it forward and start working on the shepherdd writeup right away,
without a fixed wait period for objections.  This way the reviews don't
all need to come in during a small time window of WGLC.

We hope that this scheme will help us clear the backlog of WG documents
we've accumulated, documents that ought to get published but are in some
sense "insufficiently interesting" to have people championing them and
keeping them moving.

Documents "ready for WGLC" that are good candidates for this experiment

draft-ietf-kitten-rfc6112bis (once a new revision gets posted; currently waiting for approval)


No Recordings Present

Meeting Slides:

No Slides Present


Request for Comments:

Charter (as of 2015-10-14):

The purpose of the Common Authentication Technology Next Generation
(Kitten) working group (WG) is to develop extensions/improvements to the
GSS-API and to the Kerberos authentication system, shepherd specific
GSS-API security mechanisms, and provide guidance for any new
SASL-related submissions.

This charter combines the work of the Kerberos WG and the kitten WG
(under the aegis of the kitten WG). In places, it identifies which WG
was previously home for that work.

The working group will develop extensions and/or updates to the GSS-API,
working on specific items regarding credential management, replay cache
avoidance, error reporting, and supporting stateless and/or distributed

The working group will also maintain and improve upon the Kerberos
protocol, working on items regarding internationalization considering
alignment with the precis work, new initial authentication types,
authorization framework/data, replay cache avoidance, cryptography
advances, interop with 3rd party authentication, and identity

In detail, both existing and new work items include:

Existing Working Group Items
SASL Mechanism for OAuth (draft-ietf-kitten-sasl-oauth)
SASL Mechansim for SAML-EC (draft-ietf-kitten-sasl-saml-ec)
GSS-API IANA Registry (draft-ietf-kitten-gssapi-extensions-iana)
KDC Model (draft-ietf-krb-wg-kdc-model)
PKINIT Hash Agility (draft-ietf-krb-wg-pkinit-alg-agility)
Kerberos IANA Registry (draft-ietf-kitten-kerberos-iana-registries)
Initial and Pass Through Authentication in Kerberos 5 (draft-ietf-krb-wg-iakerb)
Unencrypted Portion of Ticket Extensions (draft-ietf-krb-wg-ticket-extensions)

GSS-API Related
Provide new interfaces for credential management, which include the
initializing credentials
iterating credentials
exporting/importing credentials

Negotiable replay cache avoidance

Define interfaces for better error message reporting.

Specify an option for exporting partially-established security
contexts and possibly a utility function for exporting security
contexts in an encrypted form, as well as a corresponding utility
function to decrypt and import such security context tokens.

Specify one-time password / two-factor authentication needs for SASL
applications. This could be achieved through an explicit new
GSS-API/SASL mechanism (e.g., or if
the consensus is that due to usability reasons, it is preferable
to do OTP/2FA through an higher level protocol
(Kerberos/OpenID/SAML/SAML20EC/EAP?) then prepare a document
explaining the usability problem and provide pointers for

Kerberos Related

Prepare, review, and advance standards-track and informational
specifications defining new authorization data types for carrying
supplemental information about the client to which a Kerberos
ticket has been issued and/or restrictions on what the ticket can
be used for. To enhance this ongoing authorization data work, a
container format supporting the use cases of draft-ietf-krb-wg-pad
may be standardized.

Prepare a standards-track protocol to solve the use cases addressed
by draft-hotz-kx509-01 including new support for digital

Today Kerberos requires a replay cache to be used in AP exchanges in
almost all cases. Replay caches are quite complex to implement
correctly, particularly in clustered systems. High-performance
replay caches are even more difficult to implement. The WG will
pursue extensions to minimize the need for replay caching,
optimize replay caching, and/or elide the need for replay caching.

Prepare, review, and advance standards-track and informational
specifications defining use of new cryptographic algorithms in the
Kerberos protocol using the RFC3961 framework, on an ongoing
basis. Cryptographic algorithms intended for standards track
status must be of good quality, have broad international support,
and fill a definite need.

Prepare, review, and advance standards-track and informational
specifications of new pre-authentication types for the Kerberos
protocol, on an ongoing basis.

Prepare, review, and advance standards track updates and extensions to
RFC4121, as needed and on an ongoing basis.