Subject: [Fwd: New version of kerberos clarifications]

From: "Douglas E. Engert" <[email-masked]>
Date: Thu, 06 Feb 2003 12:52:31 -0600

I talked to Cliff yesterday, and the Clarifications is ready to
go to WG last call next week, accept for the last two points 
he stated in the note below from 01/22/03.

We need to get these resolved. Sam and Nico have sent some e-mail
on the PA_ETYPE_INFO2  "etype info vs etype info 2"  which appears to
address the first qurstion. Can they send Cliff some proposed text. 

And I will also ask, based on Sam's first note on this, does this mean
that if the client supports AES, it must also support the etypo info 2
and i.e. the old etype info should never refer to new etypes.      

I don't believe anyone has addressed Cliff's second question
on KDC policy.

-------- Original Message --------
Subject: New version of kerberos clarifications
Date: Wed, 22 Jan 2003 23:43:28 -0800
From: Clifford Neuman <[email-masked]>
To: [email-masked]
References: <[email-masked]>

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: Nicolas Williams <[email-masked]>
Date: Thu, 6 Feb 2003 13:23:58 -0600

> address the first qurstion. Can they send Cliff some proposed text. 

Proposed text is below.

> and i.e. the old etype info should never refer to new etypes.      

Yes, the old etype-info should never refer to new enctypes.

Proposed text changes, for the second paragraph of section 3.1.3:

current:

   If required, the server pre-authenticates the request, and if the
   pre-authentication check fails, an error message with the code
   KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is
   required, but was not present in the request, an error message with
   the code KDC_ERR_PREAUTH_REQUIRED is returned and the METHOD-DATA
   field of the KRB-ERROR message will specify which pre-authentication
   mechanisms are acceptable.  Usually this will include PA-ETYPE-INFO
   and/or PA-ETYPE-INFO2 elements. If the server cannot accommodate an
   encryption type requested by the client, an error message with code
   KDC_ERR_ETYPE_NOSUPP is returned. Otherwise the KDC generates a
   'random' session key[3.3].

proposed:

   If required, the server pre-authenticates the request, and if the
   pre-authentication check fails, an error message with the code
   KDC_ERR_PREAUTH_FAILED is returned. If pre-authentication is
   required, but was not present in the request, an error message with
   the code KDC_ERR_PREAUTH_REQUIRED is returned and the METHOD-DATA
   field of the KRB-ERROR message will specify which pre-authentication
   mechanisms are acceptable.  Usually this will include PA-ETYPE-INFO
   and/or PA-ETYPE-INFO2 elements as described below. If the server
   cannot accommodate an encryption type requested by the client, an
   error message with code KDC_ERR_ETYPE_NOSUPP is returned. Otherwise
   the KDC generates a 'random' session key[3.3].

[BTW, should that be "If the server cannot accommodate _any_ ..." -
 obviously, if the server can accomodate at least one requested enctype
 then there is no error, today.]

Immediately after the fourth paragraph of section 3.1.3 add this:

   When the AS server must include pre-authentication data in a
   KRB-ERROR or in an AS-REP, it MUST use PA-ETYPE-INFO2, not
   PA-ETYPE-INFO, if and only if the etype field of the client's AS-REQ
   lists at least one "newer" encryption type, otherwise it MUST send
   both, PA-ETYPE-INFO2 and PA-ETYPE-INFO (both with an entry for each
   enctype).  A "newer" enctype is any enctype which is not a DES, 3DES
   or RC4 enctype defined in [RFC1510] or elsewhere prior to this RFC.

You may want to come up with better wording for "newer enctype".

Should section 8.1 make a note of this?

> I don't believe anyone has addressed Cliff's second question

Unfortunately I don't have enough context, from Cliff's note, to
understand what the second question is about.

Cheers,

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Thu, 06 Feb 2003 20:50:44 -0500

I believe I sent proposed text on point 2 to the list.  It was a two
word change.