preauth mechanism functioning at the client-side

[Marcus Watts]

> Date:    Mon, 13 Aug 2007 10:57:59 PDT
> To:      "Tim Alsop" <Tim.Alsop at cybersafe.com>, jaltman at secure-endpoints.com
> cc:      krbdev at mit.edu
> From:    "Gopal Paliwal" <gopalpaliwal at gmail.com>
> Subject: Re: preauth mechanism functioning at the client-side
> 
> Hi,
> Thanks for the reply.
> Currently the number 32 which I assigned for the new-preauth type is'nt
> having conflict with the existing ones as I did go thru RFC's & relevant
> code for this change.

The advice you got ("to use an unused number") is not quite accurate.

Here is the relevant text from RFC 4120:

"   padata-type
"      Indicates the way that the padata-value element is to be
"      interpreted.  Negative values of padata-type are reserved for
"      unregistered use; non-negative values are used for a registered
"      interpretation of the element type.
"

Any negative number is free for your experimental use.  At your stage of
development, this is probably precisely the right answer.  Once you have
something that works, then a positive number may be appropriate.  If
you want to share or deploy your implementation outside of your organization,
you should acquire a positive (registered) number.  If you want to use a
positive number, you need to ask that it be assigned to you.  In theory,
you should just have to ask to get a number; in practice, you will get
a better reception if you have a public document that describes how
you intend to use that number such that others can write interoperating
implementations--ideally, an RFC draft.  In this particular case, you may
also want to say why you can't instead extend pa-sam-challenge/response.

I believe most of the existing data structures in MIT kerberos should accept
negative pa types just fine.  You should probably avoid using -1 since MIT
likes to use that as a "wildcard" value in certain contexts.

				-Marcus Watts