Subject: client and KDC behavior upon encounter of unknown PA-DATA

From: "Jacques A. Vidrine" <[email-masked]>
Date: Thu, 20 Mar 2003 18:19:51 -0600

Hi Guys,

I just realized that I can't seem to find a section of
kerberos-clarifications that clearly specifies the action that a KDC
should take when it receives a KRB_(AS|TGS)_REQ with an unknown padata
type; or the action that a client should take when it receives a
KRB_ERROR with an unknown e-data type.  It seems like at least one of
the two need to be able to ignore unknown preauth methods.

Maybe I'm missing it?  (The document has become so big it is hard to
skim! :-)

Cheers,
-- 
Jacques A. Vidrine <[email-masked]>          http://www.celabo.org/
NTT/Verio SME          .     FreeBSD UNIX     .       Heimdal Kerberos
[email-masked]     .  [email-masked]  .          [email-masked]

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 21 Mar 2003 08:49:39 -0800

I think the accepted criticality of Kerberos typed holes is that only
AD-DATA types are critical.  I think section 1.4.1 makes this more or
less clear (unfortunately it seems to treat message extensions on a par
with new types for typed holes).

With respect to the e-data thing, e-data is an OCTET STRING and no type
is associated with it.  Of course, for *some* errors it's become a
convention to treat e-data's content as the DER encoding of some typed
hole.  You must be referring to PA-DATA sent in the e-data field.
Obviously, the same criticality rules apply to typed holes sent as
e-data as apply to all Kerberos typed holes other than AD-DATA.

Cheers,

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 24 Mar 2003 09:12:17 -0800

On Mon, Mar 24, 2003 at 10:46:13AM -0600, Jacques A. Vidrine wrote:
> On Fri, Mar 21, 2003 at 08:49:39AM -0800, Nicolas Williams wrote:
>                     (An `extension' is not well-defined there, but
> padata is given as an example.)

Yes, I would like the text to discriminate between extensions to the
messages and new types for typed holes.  At this point it is not worth
changing the text.  I believe one can understand the text.

[...]
> > You must be referring to PA-DATA sent in the e-data field.
> I'm not so worried about criticality in this area.  I'm worried about
> stuff breaking. :-)
> 
> The two possibilities for breaking that I'm worried about are:
> 
>   (1) A client sends a KDC-REQ with no padata, and the KDC responds
>       with a KRB-ERROR containing preauthentication mechanisms not
>       described in Clarifications.  e.g. the e-data field contains
>       something like:
> 
>       METHOD-DATA:SEQUENCE {
>         PA-DATA:SEQUENCE {
>           padata-type[1]  = PA-ETYPE-INFO2(19),
>           padata-value[2] = OCTET-STRING { ETYPE-INFO2 ... }
>         },
>         PA-DATA:SEQUENCE {
>           padata-type[1]  = PA-FOO-EXTENSION(123),
>           padata-value[2] = OCTET-STRING { FOO-EXTENSION-DATA }
>         }
>       }
> 
>       I hope existing clients would ignore the PA-FOO-EXTENSION.  On
>       the other hand, the example of 1.4.2 almost, but not quite, says
>       that a KDC shouldn't send extensions here unless the client
>       indicated support for it in the first place.

This requirement was aimed at message extensions, not typed hole types.

>    (2) A client advertises support for an extension but the KDC does not
>        understand it.  e.g. the KDC-REQ padata field looks like
> 
>        padata[3] { SEQUENCE {
>          PA-DATA:SEQUENCE {
>            padata-type[1]   = PA-FOO-EXTENSION(123),
>            padata-value[2]  = OCTET-STRING { FOO-EXTENSION-DATA }
>          }
>        }
> 
>        I hope existing KDCs would not fail authentication when it saw
>        such an `advertisement'.  If any did so, then it would seem 
>        there's no way for a client to safely advertise support for an
>        extension :-)

Correct.  This is why PA-DATA are not "critical."

> My expectation is that none of this will cause problems, but I'm
> having a little trouble seeing a clear guarantee that such is the
> case.

I believe the trouble you're having may derive from the conflation of
message extensions and typed hole type additions in the text in section
1.4.1.

Cheers,

Nico
--

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Mon, 24 Mar 2003 10:46:13 -0600

On Fri, Mar 21, 2003 at 08:49:39AM -0800, Nicolas Williams wrote:
> with new types for typed holes)

Thanks, Nico: I think section 1.4.1+1.4.2 was what I was looking for,
mostly by example.  (An `extension' is not well-defined there, but
padata is given as an example.)

> hole.  

Actually, it is more than convention.  Section 3.1.3 says ``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 a
METHOD-DATA object will be stored in the e-data field of the KRB-ERROR
message to specify which pre-authentication mechanisms are
acceptable.'' 

      METHOD-DATA:SEQUENCE {
        PA-DATA:SEQUENCE {

       padata[3] { SEQUENCE {
         PA-DATA:SEQUENCE {

Cheers,

---

From: Sam Hartman <[email-masked]>
Date: Wed, 26 Mar 2003 15:39:53 -0500

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

    Nicolas> On Mon, Mar 24, 2003 at 10:46:13AM -0600, Jacques
    Nicolas> A. Vidrine wrote:
    >> (An `extension' is not well-defined there, but padata is given
    >> as an example.)

    Nicolas> Yes, I would like the text to discriminate between
    Nicolas> extensions to the messages and new types for typed holes.
    Nicolas> At this point it is not worth changing the text.  I
    Nicolas> believe one can understand the text.

I think the text may be more clear when the parts that were removed
for clarifications are added again.