Subject: Rechartering

From: Jeffrey Hutzelman <[email-masked]>
Date: Sat, 4 Nov 2006 00:12:41 -0500 (EST)

At the last IETF meeting, we had a discussion about updating our charter.
Based on that discussion, current work, and my impression of where things
are going, I've put together an initial proposal, which I've included
below.  This is in no way set in stone -- it's just a starting point for
some discussion, which I hope to have in San Diego.  Comments are welcome,
both here on the mailing list and during the meeting.

It should be noted that we don't actually get to define our own charter.
Working group charters are set by the IESG.  However, it is likely that
the IESG will approve a charter substantially similar to what we propose;
thus, this discussion is fairly important.

-- Jeff

Kerberos over the years has been ported to virtually every operating
system.  There are at least two open source versions, with numerous
commercial versions based on these and other proprietary implementations.
Kerberos evolution has continued in recent years, with the development
of a new crypto framework, publication of a new version of the Kerberos
specification, support for initial authentication using public keys, and
numerous extensions developed in and out of the IETF.

However, wider deployment and advances in technology bring with them both
new challenges and new opportunities, particularly with regard to making
initial authentication of users to the Kerberos system both convenient
and secure.  In addition, several key feature remain undefined.

The Kerberos Working Group will advance the state of the core Kerberos
specification, produce specifications for missing functionality, and
develop extensions to address new needs and technologies related to
improving the process of client authentication.

Specifically, the Working Group will:

* Complete existing work:
   [most of these should be done by charter time]
   - pkinit ECC
   - tcp-extensibility
   - naming
   - anon
   - set/change pw
   - Hash algorithm agility for RFC4121 (the Kerberos GSS-API mechanism)
   - Hash algorithm agility for RFC4556 (PKINIT)
   - referrals

* Advance the following existing specifications along the standards track:
  - Kerberos V5 specification 2 (RFC's 3961, 3962, 4120),
  - PKINIT (RFC's 4556 and 4557)
  - The Kerberos GSS-API mechanism (RFC 4121).

* Prepare and advance a specification for an updated, backward-compatible
  version of the Kerberos version 5 protocol which supports non-ASCII
  principal and realm names, salt strings, and passwords; insures that
  those portions of the protocol which are not encrypted are nonetheless
  authenticated whenever possible; and enables future protocol revisions
  and extensions.

* Develop a framework for preauthentication mechanisms, and evaluate
  proposals for preauthentication mechanisms to enable the use of
  one-time passwords and hardware tokens for initial authentication.

* Evaluate proposals for mechanisms to reduce or eliminate exposure
  of Kerberos clients' long-term keys to attack.

* Identify issues related to the current cross-realm model, and evaluate
  approaches for solving them.

Goals and Milestones: TBD [I expect to have a list at the meeting]

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 06 Nov 2006 13:43:17 +0100

> both here on the mailing list and during the meeting.

As per earlier discussions of my Kerberos V5 over TLS work, a
suggestion for the charter:

* Advance a specification to protect Kerberos using TLS, based on
  draft-josefsson-kerberos5-starttls-02.txt.

The latest Shishi release was recently updated to implement that
version of the draft.

Review and comments on the draft itself are appreciated:
http://josefsson.org/krb5starttls/draft-josefsson-kerberos5-starttls.txt

/Simon

---

From: "Douglas E. Engert" <[email-masked]>
Date: Mon, 06 Nov 2006 10:46:02 -0600

I believe there is a need to allow the user to have better control and
auditing over the delegation of credentials. The current method of
forwarding a full TGT can lead to compromises in a diverse cross realm
environment.

The failure to have this control limits the usefulness of Kerberos
in such environments, and discourages the deployment of Kerberos across
organizations.

It is not clear the best way to go about this. It could include policies
in the KDC to limit the max times a TGT could be forwarded. For auditing
it could include adding a reference to which host was involved in the
delegation.

One interesting approach might even be to having a user in run their own
realm! So all requests for forwarded tickets are routed back to the
user's personal realm where the KDC can notify the user. There are many
issues with this, and it is not well thought out, but it gives the end
user (or his KDC) control over the delegation process.

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444