preauth mechanism functioning at the client-side
mdw at spam.ifs.umich.edu
Mon Aug 13 14:48:56 EDT 2007
> 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
> 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:
" 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.
More information about the krbdev