Subject: WG Last Call - krb-wg charter update

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 21 May 2007 01:32:58 -0400 (EDT)

Included below is the latest and, hopefully, final version of the new
charter proposal.  This incorporates the results of discussions in Prague
and on the mailing list in recent weeks.  I hope to be able to send this
to the IESG pretty much as-is, with two major exceptions:

(1) Unless the working group has consensus to adopt it and someone steps
    forward and volunteers to do the work, all references to the admin
    protocol work (data model and LDAP schema) will be removed.

(2) The milestone dates listed below were selected fairly aribitrarily
    by me, without consulting with anyone.  Those documents listed with
    dates in June should already be ready to go; they are waiting for me
    to either do writeups or start last calls.  June will be the month
    of last calls for this WG, as we clear most of our backlog.

    For anything listed after June, I would like to hear from authors,
    editors, and contributors as to whether the dates I list are realistic
    and, if not, what dates might be.

This message serves to start a two-week last call on this proposal, which
will expire on Monday, June 4, 2007 at 17:00 EDT (UTC 2100). Please send
any and all comments to the Kerberos working group mailing list,
[email-masked].

-- Jeff

======================================================================
==========    DRAFT Kerberos Working Group Charter - v04    ==========
======================================================================

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 continue to improve the core Kerberos
specification, develop extensions to address new needs and technologies
related to improving the process of client authentication, and produce
specifications for missing functionality,

Specifically, the Working Group will:

* Complete existing work:
   - ECC for PKINIT            (draft-zhu-pkinit-ecc-03.txt)
   - Set/Change Password       (draft-ietf-krb-wg-kerberos-set-passwd-05.txt)
   - Naming Constraints        (draft-ietf-krb-wg-naming-02.txt)
   - Anonymity                 (draft-ietf-krb-wg-anon-03.txt)
   - Hash agility for GSS-KRB5 (draft-ietf-krb-wg-gss-cb-hash-agility-00.txt)
   - Hash agility for PKINIT   (draft-ietf-krb-wg-pkinit-alg-agility-01.txt)
   - Referrals                 (draft-ietf-krb-wg-kerberos-referrals-08.txt)

* 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 extensions which reduce or eliminate exposure of Kerberos
  clients' long-term keys to attack and enable the use of alternate
  mechanisms for initial authentication.  This task will comprise the
  following items:
    - A model and framework for preauthentication mechanisms
    - A mechanism for providing a protected channel for carrying
      preauthentication data and/or a reply key between a Kerberos
      client and KDC, within the KDC_REQ/KDC_REP exchange.
    - Support for One-Time Passwords
    - Support for hardware authentication tokens
    - Support for using TLS to secure communications with Kerberos KDC's.

* Examine issues related to the current cross-realm model, produce a
  list of problems to be solved, and evaluate approaches to solving them.

* Develop extensions to Kerberos and a GSS-API mechanism (IAKERB) to
  enable Kerberos clients to communicate with a KDC by using a GSS-API
  acceptor as a proxy.

* Produce a data model for information needed by the KDC, and an LDAP
  schema for management of that data.
  [ Note: this item will be dropped if the WG does not come  ]
  [ to consensus that it should be included in the charter.  ]

Goals and Milestones:

   --DONE--  TCP Extensibility to IESG
   JUN 2007  ECC for PKINIT to IESG
   JUN 2007  Set/Change Password to IESG

   JUN 2007  Naming Constraints to IESG
   JUN 2007  Anonymity to IESG
   JUN 2007  Hash agility for GSS-KRB5 to IESG
   JUN 2007  Hash agility for PKINIT to IESG

   JUL 2007  WGLC on STARTTLS
   JUL 2007  WGLC on Referrals
   JUL 2007  WGLC on data model

   AUG 2007  Choose direction for Kerberos v5.3

   SEP 2007  WGLC on preauth framework
   SEP 2007  WGLC on cross-realm issues

   NOV 2007  WGLC on OTP
   NOV 2007  WGLC on hardware preauth

   MAR 2008  WGLC on Kerberos v5.3
   MAR 2008  WGLC on IAKERB
   MAR 2008  WGLC on LDAP schema

---

From: Quanah Gibson-Mount <[email-masked]>
Date: Mon, 21 May 2007 08:37:00 -0700

>     protocol work (data model and LDAP schema) will be removed.

I'm interested in the LDAP schema work, and would volunteer time to work on 
it.

--Quanah

--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra ::  the leader in open source messaging and collaboration

---

From: "Enrique Rodriguez" <[email-masked]>
Date: Mon, 21 May 2007 08:41:44 -0700

> I'm interested in the LDAP schema work, and would volunteer time to work on

Hi,

I'm also interested in the LDAP schema work and can put time towards it.

Enrique

---

From: Sam Hartman <[email-masked]>
Date: Fri, 25 May 2007 13:43:29 -0400

The charter looks OK, although I suggest you make a pass for grammar
before submitting.  I noticed one feature/features error and incorrect
trailing punctuation on a paragraph.

---

From: Shoichi Sakane <[email-masked]>
Date: Mon, 28 May 2007 16:45:20 +0900

Hi all,

>    AUG 2007  Choose direction for Kerberos v5.3

Kamada-san and I want to help the 1510ter to move forward.
In the milestone, there is "Choose direction for Kerberos v5.3" as an item.
What does it mean ?  Will we decide to remove some stuff or to keep going
on by AUG 2007 ?

---

From: Sam Hartman <[email-masked]>
Date: Wed, 30 May 2007 15:39:10 -0400

>>>>> "Shoichi" == Shoichi Sakane <[email-masked]> writes:

    Shoichi> Hi all,
    >> AUG 2007 Choose direction for Kerberos v5.3

    Shoichi> Kamada-san and I want to help the 1510ter to move
    Shoichi> forward.  In the milestone, there is "Choose direction
    Shoichi> for Kerberos v5.3" as an item.  What does it mean ?  Will
    Shoichi> we decide to remove some stuff or to keep going on by AUG
    Shoichi> 2007 ?

Hi.

Nico, larry, Tom Yu and I have a proposal that we'd like to make to the WG  that may allow us to accomplish the goals of 1510ter more quickly.

I need to write up this proposal.

Jeff Hutzelman has said that he is open to the idea of allowing the WG
to consider the approsal.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Wed, 30 May 2007 16:36:57 -0500

This just came up yesterday in a phone conversation with NASA.

They are looking for a way to carry Level of Assurance information
in the TGT, especially if PKINIT was used.  See NIST 800-63 for a
set of guildlines defining the levels.

http://csrc.nist.gov/publications/nistpubs/800-63/SP800-63V1_0_2.pdf

This might be done as an additional piece of auth data with the level
or might even be a piece of auth data with the user's certificate.

I talked with Sam today, and he suggested that this would need to be
added to the charter, so I am sending this in today, hope it is not
to late.

-- 

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

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 31 May 2007 09:37:32 +0900

Hi Sam, 

> Nico, larry, Tom Yu and I have a proposal that we'd like to make to the WG
> that may allow us to accomplish the goals of 1510ter more quickly.

Thank you.  I see.  I will wait for the proposal.

Let me say our state.  For our (kamada and my) understanding, now we are
making a kind of the issue list of the 1510ter in order to make it prceed
more easier. We will send it to this list soon although you probably have
these things.

===
Shoichi Sakane
Yokogawa Electric Corporation

---

From: "Paul Rabinovich" <[email-masked]>
Date: Thu, 31 May 2007 15:17:11 -0400

Hello,

I'm new to this list so apologize if I don't follow the protocol.

The A&D industry where I work has a lot of interest in standardizing
name constraints for Kerberos principal names in X.509 certificates.
This is because the companies want to use one another's credentials to
get access to systems across enterprise boundaries (and to do the same
with their suppliers and customers). The primary vehicle of trust in the
A&D industry is CertiPath, a PKI bridge cross-certified with the Federal
Bridge, on the one hand, and with A&D companies, on the other. Currently
CertiPath puts X.500, RFC 822 and DNS name constraints in their
cross-certificates.

The primary form of user name in most cases is the User Principal Name
from Active Directory. Microsoft Certificate Server is already capable
of inserting UPNs as otherNames in the subjectAltName X.509 extension
and name constraints for UPNs in the nameConstraints extension.
Microsoft's relying parties (CAPI-based) can enforce these constraints.

There are two (or, maybe, one) problems with this approach: 1) UPNs are
encoded in a proprietary way although there is a standard encoding from
RFC 4556 and 2) UPN name constraints have proprietary syntax and
semantics in the absence of any standard.

I'd like to propose for this WG to produce a standard for syntax and
semantics of name constraints for Kerberos principal names. I can work
on fleshing out this standard based on preparatory work I already did.
Russ and Tim Polk have already seen some of it and suggested I talk to
the WG directly.

	Regards,
	PR

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 31 May 2007 16:49:53 -0400

On Wednesday, May 30, 2007 03:39:10 PM -0400 Sam Hartman 
<[email-masked]> wrote:

> Nico, larry, Tom Yu and I have a proposal that we'd like to make to the
> WG  that may allow us to accomplish the goals of 1510ter more quickly.
>

Right.  I sort of jumped the gun by including this milestone, but I felt it 
was appropriate because I expect to spend some meeting time discussing this 
proposal in Chicago, and hope that discussion will lead to a decision in a 
fairly short timeframe after.  If the proposal never materializes or the WG 
is not interested, then the milestone becomes a no-op, which is not a big 
deal.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 31 May 2007 16:54:28 -0400

> Russ and Tim Polk have already seen some of it and suggested I talk to

Comments on these two proposals?

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 31 May 2007 17:09:06 -0400

On Thursday, May 31, 2007 09:37:32 AM +0900 Shoichi Sakane 
<[email-masked]> wrote:

>> WG that may allow us to accomplish the goals of 1510ter more quickly. I
>> need to write up this proposal.

That's an excellent idea.  By all means, bring up any issues you have with 
active WG items - don't wait for a last call or the like; the way these 
things make progress is for people to talk about the problems they see, or 
changes they would like to see.

-- Jeff

---

From: "Paul Rabinovich" <[email-masked]>
Date: Thu, 31 May 2007 17:09:52 -0400

Jeff,

	We are working on a white paper outlining the A&D industry
requirements for propagation of authentication assurance information
across/through platforms, security frameworks, protocols, etc. Kerberos,
of course, would be one of them. Our work is based on NIST 800-63 as
well.
	So there is a requirement for this, and I think it's worthwhile
to address it.

	Regards,
	PR

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Jeffrey
Hutzelman
Sent: Thursday, May 31, 2007 4:54 PM
To: [email-masked]
Cc: Jeffrey Hutzelman
Subject: Re: WG Last Call - krb-wg charter update

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 31 May 2007 17:11:48 -0400

>     protocol work (data model and LDAP schema) will be removed.

Since I posted this, I've seen responses from two people indicating 
interest in the work.  However, there was also a lively discussion at the 
WG meeting in Prague, in which some people raised objections.  I didn't 
feel that discussion came to any real conclusion, so I'd like to invite the 
objectors to bring them up again here so we can continue to discuss them.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Thu, 31 May 2007 18:06:15 -0400

Question:

Who would author documents in this space?
Who would review documents?
who would implement?