Subject: [Ietf-krb-wg] Rechartering

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 16 Mar 2011 00:32:34 -0400

OK, folks.  Below is draft 00 of a proposed charter update for the
Kerberos working group.  I think this covers nearly all of the proposals
I'm aware of, with the exception of KX509, which is missing from this
draft only because I'm tired and haven't figured out how to write it up.

A couple of notes...

- This covers only the "Description of Working Group" part of the
  charter, which should be the only part needing group discussion.
  Milestones will be by agreement between the chairs, authors, and AD,
  and the rest is formulaic.

- I believe we work most effectively with a set of reasonable focused
  tasks, rather than a broad unrestricted mandate.  Therefore, the
  work items in this proposal tend to be fairly focused.  The major
  exception is enctype work, because it has been clearly demonstrated
  that we need the flexibility to adopt or review work in this area
  as needed and on an ongoing basis.

- Generally, I believe working groups should be chartered to solve
  specific problems, rather than to work on specific documents.  I
  also believe that charters should usually leave the working group
  free to choose the most appropriate solution or to develop more than
  one solution when circumstances warrant.  Therefore, the work items
  in this proposal tend to focus on a problem without mandating any
  particular solution, and except for the "Complete existing work"
  item, do not name specific documents.

- Formally, charter updates do not require working group consensus;
  rather, they are a matter for the IESG and the responsible AD.
  However, in practice, a charter which is supported by a consensus
  of the working group is likely to be adopted with little difficulty,
  especially if there is demonstrated support in the form of volunteers
  willing to contribute to, edit, and review documents.  Therefore, I
  intend to send this on only when I believe that such a consensus and
  support exists.

Please send any comments to me and/or to the list.

-- Jeff

Description of Working Group:

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 new crypto and preauthentication frameworks, support for initial
authentication using public keys, improved support for protecting
clients' long-term keys during initial authentication, support for
anonymous and partially-anonymous authentication, 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, such as exploring support
for new mechanisms for initial authentication, new cryptographic
technologies, and better integration of Kerberos with other systems
for authentication, authorization, and identity management.
In addition, several key features remain undefined.

The Kerberos Working Group will continue to improve the core Kerberos
specification, develop extensions to address new needs and technologies
related to the areas described above, and produce specifications for
missing functionality.

Specifically, the Working Group will:

* Complete existing work, including:
   - DHCP Option               (draft-sakane-dhc-dhcpv6-kdc-option-09.txt)
   - KDC Data Model            (draft-ietf-krb-wg-kdc-model-08.txt)
   - One-Time Passwords        (draft-ietf-krb-wg-otp-preauth-13.txt)
   - IAKERB                    (draft-ietf-krb-wg-iakerb-02.txt)
   - Single-DES Deprecation    (draft-lha-des-die-die-die-05.txt)

   - Hash agility for GSS-KRB5 (draft-ietf-krb-wg-gss-cb-hash-agility-05.txt)
   - Hash agility for PKINIT   (draft-ietf-krb-wg-pkinit-alg-agility-04.txt)
   - Referrals                 (draft-ietf-krb-wg-kerberos-referrals-11.txt)
   - Set/Change Password       (draft-ietf-krb-wg-kerberos-set-passwd-06.txt)

* Prepare and advance one or more standards-track specifications which
  update the Kerberos version 5 protocol in a backward-compatible way
  to support non-ASCII principal and realm names, salt strings, and
  passwords, and localized error reporting.
  
* Prepare and advance one or more standards-track specifications which
  update the Kerberos version 5 protocol in a backward-compatible way
  to enable future protocol revisions and extensions.

* Prepare, review, and advance standards-track and informational
  specifications defining use of new cryptographic algorithms in the
  Kerberos protocol, on an ongoing basis.

* Prepare and advance one or more standards-track specifications
  defining a generalized Principal Authorization Data (PAD) structure
  for conveying authorization-related information.

* Prepare and advance one or more standards-track specifications
  which define mechanisms for establishing keys and configuration
  information used during authentication between Kerberos realms.
  
* Prepare and advance a standards-track specification defining a
  format for the transport of Kerberos credentials within other
  protocols.

* Produce an LDAP schema for management of the KDC's database.

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Thomas Hardjono <[email-masked]>
Date: Wed, 16 Mar 2011 10:57:46 -0400

Jeff, Larry, Tim,

I think the WG charter also needs to have language that express the
openness of the WG to the addition of well-defined new items (that are
not currently listed in the charter). It also need to define the
process to add such new items (beyond waiting for a recharter every
several years).

Otherwise we may have the situation where there are X number of items
progressing at glacial speed (because of one reason or another) and
the WG not accepting new items because these X items are stuck. Such a
situation would not encourage newcomers with new ideas to the WG.

ps. The draft looks good - I'll send other comments separately.

Thanks.

/thomas/

______________________________

> -----Original Message-----
> From: [email-masked] [mailto:ietf-krb-wg-
> [email-masked]] On Behalf Of Jeffrey Hutzelman
> Sent: Wednesday, March 16, 2011 12:33 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ietf-krb-wg] Rechartering
> 
> Kerberos working group.  I think this covers nearly all of the
> proposals I'm aware of, with the exception of KX509, which is
missing
> from this draft only because I'm tired and haven't figured out how
to
> write it up.
for
> authentication, authorization, and identity management.
>    - Hash agility for GSS-KRB5
(draft-ietf-krb-wg-gss-cb-hash-agility-
> 05.txt)
>    - Hash agility for PKINIT
(draft-ietf-krb-wg-pkinit-alg-agility-
> 04.txt)
>    - Referrals
(draft-ietf-krb-wg-kerberos-referrals-
> 11.txt)
>    - Set/Change Password
(draft-ietf-krb-wg-kerberos-set-passwd-
> 06.txt)
which
> * Prepare and advance one or more standards-track specifications
which

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Mar 2011 18:20:21 -0400

Jeff, you're missing Simo's PAD proposal.
Also, I'd like to propose the text Henry and I came up with for
consideration:

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

While that refers to a specific draft, it does not constrain the
technical solution, only the problem so I think it meets your
requirements.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Mar 2011 21:31:49 -0400

>Jeff, you're missing Simo's PAD proposal.

I don't think it's missing; it was among the things Thomas listed.  I will check again.

>technical solution, only the problem so I think it meets your

I agree; that text looks good to me and will be in the next draft.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 Mar 2011 21:49:07 -0400

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    >> Jeff, you're missing Simo's PAD proposal.

    Jeffrey> I don't think it's missing; it was among the things Thomas
    Jeffrey> listed.  I will check again.

It was in Thomas's proposal, but I thought your text was intended to be
a superset.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 17 Mar 2011 22:28:32 -0400

>It was in Thomas's proposal, but I thought your text was intended to be

It was.  Was I not broad enough?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tom Yu <[email-masked]>
Date: Thu, 17 Mar 2011 22:32:20 -0400

> It was in Thomas's proposal, but I thought your text was intended to be

I just checked, and I see it in Jeff's message from 3/16 that started
this thread.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Fri, 18 Mar 2011 13:33:21 -0500

> process to add such new items (beyond waiting for a recharter every

Rechartering to add new items is no big deal.  I'd rather have to recharter
than to have completely open-ended charters.  I don't mind chartered work
items written in very broad language, as long the language is still
significantly constrained relative to an open-ended charter.

> situation would not encourage newcomers with new ideas to the WG.

Out of charter items typically do make progress as individual submissions
before getting absorbed into the WG's charter.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 18 Mar 2011 15:47:30 -0400

> process to add such new items (beyond waiting for a recharter every

I don't; a charter is for setting the scope of a working group, not for 
defining process.  A charter can be broad, allowing for a variety of
work to be adopted without rechartering, or it can be narrowly focused
on specific problems.  Work that is in scope can be adopted more or less
by the chair saying so, though it has generally been our practice to ask
for consensus of the WG or of a meeting before doing so.  Work that is
out of scope requires rechartering; this is intended to allow an
opportunity for the responsible AD, the IESG, and the IETF at large to
review changes in the scope of a WG.

> situation would not encourage newcomers with new ideas to the WG.

That shouldn't happen, unless the problem is that the chairs are being
generally lame about everything, which I admit has happened from time to
time in this WG.  Last fall, I indicated that I wanted to see some
commitment to work on existing items, or else an indication those items
were no longer important to the WG, before picking up new work items.
This is a variation on finishing one task before starting the next,
which in my experience is a better way to get work done than starting
large numbers of tasks in parallel.  However, I didn't ask that those
items be _finished_ before picking up new work, only that some cycles be
allocated to them.

We have generally not avoiding starting new items when existing items
were stuck post-WGLC.  And in fact, I have argued in the past that it
was OK for us to adopt new work items when the cycles to work on those
items came from people not engaged in current items.  However, if we
have a bunch of things that are going nowhere because the authors are
cycle-starved or because people only pay attention to IETF work in the
couple of weeks leading up to a meeting, then adding more work won't
help.

So, while I'm not interested in defining "process" in a charter, there
is an open question as to how broad the scope of the WG should be.

Personally, I dislike broad, open-ended charters; I feel like we should
have a well-defined set of problems to work on at any given time.  This
WG had a very open-ended charter when it was formed, and I don't think
that served us particularly well.  At the time of our first recharter,
the prevailing view among IETF leadership seemed to be opposed to such
open-ended charters, and in favor of giving each WG a well-defined,
reasonably narrow scope.  Perhaps that has changed; perhaps not.  I do
think that in those days rechartering was a bigger deal than it is
supposed to be today.

The proposal I made tries to strike a balance between being open-ended
and being too restrictive.  I've listed problems, rather than solutions,
and some of the problems are worded fairly broadly.  And, I've included
an item for enctype work, which effectively allows us to pick up _any_
enctype work without rechartering.

I haven't included it, but I would also be open to a similar work item
allowing us to pick up "true" AD types (that is, those which carry
additional identifying information about the client or that restrict
what a ticket can be used for, but not non-AD protocol extensions that
happen to fit in the AD field).  The proposed PAD work would fall into
this category; so would AD types corresponding to SAML assertions, X.509
attribute certificates, or similar items.

I'd like to hear from the rest of the WG on the question of how broad a
scope we want and how open-ended the charter should be.

-- Jeff

---

From: "Henry B. Hotz" <[email-masked]>
Date: Fri, 18 Mar 2011 14:32:00 -0700

On Mar 18, 2011, at 12:47 PM, Jeffrey Hutzelman wrote:

> happen to fit in the AD field).

+1  (though I'm not volunteering)

Also as the number of AD types increases, the opportunity for conflicts among them increases.  I've decided this is mostly an administrative/deployment issue rather than a protocol issue, but it still seems like a concern the WG shouldn't completely ignore.
------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 25 Mar 2011 03:04:12 -0400

On Fri, 2011-03-18 at 14:32 -0700, Henry B. Hotz wrote:
> Also as the number of AD types increases, the opportunity for conflicts
>  among them increases.  I've decided this is mostly an
>  administrative/deployment issue rather than a protocol issue, but it
>  still seems like a concern the WG shouldn't completely ignore.

I have added an item along these lines, but it is fairly broad, and
whether it stays in will depend in part on whether there turns out to be
consensus for such an item.

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 25 Mar 2011 03:12:56 -0400

Version 01 of the draft charter appears below.  This should address all
of the specific comments, additions, and corrections I have received.

Except for Nico, I haven't heard much from the working group on the
question of how broad a scope we want or how open-ended the charter
should be.  I would like to hear more on this topic.  I also wouldn't
mind hearing from an AD or three...

-- Jeff

commercial versions based on these and other proprietary
implementations.

* Complete existing work, including:
   - DHCP Option
(draft-sakane-dhc-dhcpv6-kdc-option-10.txt)
   - KDC Data Model            (draft-ietf-krb-wg-kdc-model-09.txt)
   - One-Time Passwords        (draft-ietf-krb-wg-otp-preauth-16.txt)
   - IAKERB                    (draft-ietf-krb-wg-iakerb-02.txt)
   - Single-DES Deprecation    (draft-lha-des-die-die-die-05.txt)

   - Hash agility for GSS-KRB5
(draft-ietf-krb-wg-gss-cb-hash-agility-06.txt)
   - Hash agility for PKINIT
(draft-ietf-krb-wg-pkinit-alg-agility-05.txt)
   - Referrals
(draft-ietf-krb-wg-kerberos-referrals-12.txt)
   - Set/Change Password
(draft-ietf-krb-wg-kerberos-set-passwd-08.txt)

* 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.

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Mar 2011 07:30:44 -0400

Jeff, A couple of comments:

1) I propose to relax the backward compatibility constraints on the
non-ascii use case.  My rationale is to make sure that
just-send-utf8-tagged-as-general-string is specifically in scope as an
option.  As such:

* Prepare and advance one or more standards-track specifications which
  update the Kerberos version 5 protocol 
  to support non-ASCII principal and realm names, salt strings, and
  passwords, and localized error reporting. Maximizing backward
  compatibility is strongly desired.

2)  I think we should include Love's IANA draft in current work:

    - Assignment of Kerberos parameters to IANA
      (draft-lha-krb-wg-some-numbers-to-iana)

I realize we need to deal with the discussion of that draft we had at
Beijing, but I still think we want to charter the work.

3) I find the following item confusing: I forget what it still covers:

---

From: Sam Hartman <[email-masked]>
Date: Mon, 28 Mar 2011 07:44:49 -0400

With my chair hat on:

First, I should state my opinion on charter scope.  I've been holding
off, but I think it is important for chairs to have an opinion on the
appropriate scope of a charter.  This is not an issue for WG consensus:
we'll feed the WG opinions to the AD, but the IESG and AD will
ultimately decide what the scope is. So, there are strong reasons for
chairs to have opinions and the arguments that typically apply for chair
neutrality do not apply here.

I believe it is strongly desirable to have a narrowly-scoped
charter. However, I also believe it is critical that chartering delays
not stop progress. So, I support a narrow charter now. However, if we
find that getting items added to a charter is delaying work on those
items, then I will be a proponent of a broad charter in the future.

Jeff and I spoke to our new AD yesterday regarding charter scope.

The chairs and Ad would prefer a narrowly scoped charter like the one
Jeff has posted.
It looks like the discussion in the WG is leaning towards that so far.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Mon, 28 Mar 2011 09:38:05 -0500

> It looks like the discussion in the WG is leaning towards that so far.

I made approving noises for this approach earlier, but the thought
occurred to me that we should compare KRB-WG to PKIX, PKIX being a
reasonable analog of Kerberos): PKIX's is not narrowly scoped.  PKIX
gets to take on any work items that evolve PKIX ("PKIX will continue
to track the evolution of ITU-T X.509 documents"), and that there is
sufficient participant interest in, and that are supported by the AD.

I'd be happy with the PKIX approach because the constraints on taking
new items are probably strong enough.

Nico

---

From: Thomas Hardjono <[email-masked]>
Date: Mon, 28 Mar 2011 11:45:04 -0400

________________________________________
>> From: [email-masked] [[email-masked]] On Behalf Of Sam Hartman [[email-masked]]
>> Sent: Monday, March 28, 2011 7:44 AM
>> To: Jeffrey Hutzelman
>> Cc: [email-masked]
>> Subject: [Ietf-krb-wg] Charter Scope
>> 
>> With my chair hat on:
>> 

>> items, then I will be a proponent of a broad charter in the future.

Thanks Sam & congrats on the co-chair role.

What will be the process for getting new items accepted as WG work items?
Is it through the usual humming consensus, absence of strong objections,
or simply prerogative of the chairs?

nb. Last March I asked the WG to accept Camellia enc-type as a WG items.
It is a year now, and it is still not a WG item (even though Camellia is a work item
in other IETF security working groups, and it is also an ISO standard).
Hence my question about "process".

/thomas/

---

From: Sam Hartman <[email-masked]>
Date: Tue, 29 Mar 2011 03:13:04 -0400

>>>>> "Thomas" == Thomas Hardjono <[email-masked]> writes:

    Thomas> nb. Last March I asked the WG to accept Camellia enc-type as
    Thomas> a WG items.  It is a year now, and it is still not a WG item
    Thomas> (even though Camellia is a work item in other IETF security
    Thomas> working groups, and it is also an ISO standard).  Hence my
    Thomas> question about "process".

Thomas, it's the opinion of the chairs that the working group has
consensus to adopt Camellia and that as part of approving this charter
Camellia will be added.  That is, while there is no Camellia specific
text in the charter body, you should see a milestone appear when we
discuss milestones, and when the charter is approved that milestone will
be present.  We se no need for additional WG discussion because we
believe that discussion has already happened.

We are not sure whether the WG has reached consensus on whether Camellia
is standards track.  We don't need to decide that to add the milestone,
accept the draft, or any of that.  One of us (I'm happy to do so) can go
review the discussion before LC and see if we've already reached
consensus there or wether we're going to need a bit more discussion.

In general, for items that are in scope, we will adopt based on the
consensus process.  We've often adopted work items before drafts are
final, although we also have waited for drafts from time to time.  Hums
are one tool in that process as is list discussion.

Hope that helps,

Sam hartman
Kerberos chair