Subject: Updating draft-ietf-cat-kerberos-set-passwd-06

From: Nicolas Williams <[email-masked]>
Date: Wed, 22 Jan 2003 17:13:43 -0600

Here's the initial list of changes I'd like to see happen.  Priority
number one is fixing the problems identified by Sam Hartman.  Obviously,
if we can't make any given change backwards compatibly with a deployed
version we have a problem and we may have to drop said change.

Comments?

 - Remove quoted RFC1510 ASN.1 from the set/change password doc and make
   RFC1510, or, rather clarifications a normative reference.

 - Make sending a KRB-PRIV in the same message as the AP-REQ optional
   when running over TCP (there's several good reasons for this,
   including: a) the ability to benefit from Kerberos extensions which
   will make it possible to get perfect forward security (PFS), and b)
   the ability to set multiple keys over a single session, etc...).

   Besides, one should want to complete mutual authentication before
   sending passwords, even if they are encrypted with KRB-PRIVs. No?

   Protocol messages after the initial message, when run over TCP or any
   other stream transport (oh yeah, we need to allow for use over SCTP)
   not containing an AP-REQ should contain KRB-PRIVs encrypted with the
   sub-session key of the last AP-REQ run over the same session.

 - Make the use of the new directional HostAddress type either
   RECOMMENDed or MUST and require support for it on the server side.

 - Throw extensibility markers into the ASN.1 SEQUENCE(s) defined in
   this draft.

 - Remove unused fields (that's what extensibility markers are for, no? :)

 - Add a client language tags field to ChangePasswdData so that the
   server can correctly localize the result strings.

 - Add a language tag to the server's response (hmmm, how? the response
   is not an ASN.1 structure... maybe it should be...).

 - Replace the two optional, mutually exclusive fields ('passwds' and
   'keys') of the ChangePasswdData SEQUENCE with a CHOICE, which the
   draft used to use some time ago.  This is likely to be contentious,
   going by past discussion on this very issue, but I would like to get
   consensus for this change if possible.

Cheers,

Nico
--

---

From: Clifford Neuman <[email-masked]>
Date: Wed, 22 Jan 2003 23:43:28 -0800

There is a new version of Kerberos clarifications reachable by
following the "current status of Kerberos Clarifications" link from
http://kerberos.us. 

This version has not yet been submitted to the secretariat.

There are a couple of issues still to be taken care of before that
happens.  These issues are listed in the link "issues still being
edited".

Most of these are editorial, and my project assistant will
be working on those tomorrow.  There are, however, two issues for
which I would like input from the those individuals who were
participants in the debate to settle what consensus was:

   For "older" enctypes the KDC should use PA-ETYPE-INFO in preference
   to PA-ETYPE-INFO2 unless the KDC has some indication that the client
   supports PA-ETYPE-INFO2 (e.g., if the client references a "newer"
   ...

I think we have agreement on what is right here, but not necessary on
how to describe it.

The second issue is:

  >   Matt> How about we change the text to state that the KDC makes  the
  >   Matt> decision based on policy and that the policy may be based  on
  >   Matt> ordinal value?
  > 
  > I wouldn't feel comfortable with that, but I'd be happy with sttating
  > that the KDC SHOULD use the ordered value from the list.  In the

In this message, I am only including enough of the discussion to
identify the item.  The full text of the discussion on this topic (at
least that part which I received) appears on the "issues being edited" link.

I would like to reach consensus on the specific changes that are to be
made to address these two concerns.  Once I have that, we should be
ready for last call.

Clifford Neuman

---

From: Sam Hartman <[email-masked]>
Date: Fri, 24 Jan 2003 13:01:07 -0500

>>>>> "Clifford" == Clifford Neuman <[email-masked]> writes:

    Clifford> will be working on those tomorrow.  There are, however,
    Clifford> two issues for which I would like input from the those
    Clifford> individuals who were participants in the debate to
    Clifford> settle what consensus was:

    Clifford>    For "older" enctypes the KDC should use PA-ETYPE-INFO
    Clifford> in preference to PA-ETYPE-INFO2 unless the KDC has some
    Clifford> indication that the client supports PA-ETYPE-INFO2
    Clifford> (e.g., if the client references a "newer" ...

    Clifford> I think we have agreement on what is right here, but not
    Clifford> necessary on how to describe it.

I'm failing to remember the resolution to this discussion although I
do remember it coming up?  Do we at least have clear resolution on
whether the KDC must include all enctypes in an etype-info2 if it
sends such a response?  I.E. does the client union the two sets
together or just use etype-info2?

    Clifford> The second issue is:

    >>  I wouldn't feel comfortable with that, but I'd be happy with
    >> sttating that the KDC SHOULD use the ordered value from the
    >> list.  In the

    Clifford> In this message, I am only including enough of the
    Clifford> discussion to identify the item.  The full text of the
    Clifford> discussion on this topic (at least that part which I
    Clifford> received) appears on the "issues being edited" link.

I think in section 3.1.3, changing

If there is more than one supported strong encryption type in the
etype list, the first valid strong etype for which an encryption key is
available is used.

to
If there is more than one supported strong encryption type in the
etype list, the KDC SHOULD use the first valid strong etype for which an encryption key is
available.

should address the concern.

---

From: Sam Hartman <[email-masked]>
Date: Fri, 24 Jan 2003 13:07:16 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> Here's the initial list of changes I'd like to see
    Nicolas> happen.  Priority number one is fixing the problems
    Nicolas> identified by Sam Hartman.  Obviously, if we can't make
    Nicolas> any given change backwards compatibly with a deployed
    Nicolas> version we have a problem and we may have to drop said
    Nicolas> change.

I don't think anyone claims to be deploying version 2 of this
protocol.  I think we need to avoid breaking version 1 implementations
or breaking what Microsoft has deployed, but not care about anything
claiming to be version 2.