[14920] in Kerberos
Re: Can we rename a principal yet?
daemon@ATHENA.MIT.EDU (Douglas E. Engert)
Wed Aug 1 12:17:56 2001
Message-ID: <3B682BEC.1CB634AB@anl.gov>
Date: Wed, 01 Aug 2001 11:18:52 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
MIME-Version: 1.0
To: Nicolas Williams <Nicolas.Williams@ubsw.com>
CC: "Christopher P. Lindsey" <lindsey@mallorn.com>, kerberos@MIT.EDU
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Nicolas Williams wrote:
>
> On Wed, Aug 01, 2001 at 10:34:05AM -0500, Douglas E. Engert wrote:
> > Correct. The mod I spoke of, sets a key, and a SPECIAL salt, which in
> > our case was based on changing a realm name. This then works with the
> > client as long as you make sure +require_preauth is set.
>
> Why is +require_preauth required?
That was what it took to get it to work :-)
>
> Looking at the source it seems that if preauth is not required/used and
> there is a special key, then the KDC includes a pa-pw-salt pa-data item
> containing the special salt in the AS_REP, and the client code seems
> capable of using it.
>
Could be a problem, did not look, once we added the +require_preauth
> Is the pa-pw-salt code in MIT krb5 broken?
>
> At least we know (from what you say) that the MIT krb5 client lib and
> the MIT krb5 KDC both support the use of etype-info to communicate a
> special salt from the KDC to the client.
>
> What if the client includes a PA-ENC-TIMESTAMP in the initial AS-REQ but
> has the wrong salt? Will the KDC include the relevant etype-info in the
> KRB-ERROR?
Don't know. That may be the problem.
>
> The rfc/revisions seem to indicate that the KDC shouldn't (see section
> 3.1.3 of the revisions), yet it's perfectly ok to configure clients to
> always send PA-ENC-TIMESTAMP (knowing, ahead of time, that
> +require_preauth is likely to be set). And indeed, the MIT krb5 KDC
> will not include the hint padata if preauth failed.
>
> It seems to me that if a principal's key has a special salt and if an
> AS_REQ whose PA-ENC-TIMESTAMP references that key fails then the
> KRB-ERROR should actually include the etype-info for that key.
>
> Interesting failure modes lurk.
>
> Time to cross-post to the ietf-krb-wg list?
Not yet, all the developers who could say if this is a krb5-1.2.2 problem
or not, are on this list too.
>
> Nico
> --
> .
> -DISCLAIMER: an automatically appended disclaimer may follow. By posting-
> -to a public e-mail mailing list I hereby grant permission to distribute-
> -and copy this message.-
>
> Visit our website at http://www.ubswarburg.com
>
> This message contains confidential information and is intended only
> for the individual named. If you are not the named addressee you
> should not disseminate, distribute or copy this e-mail. Please
> notify the sender immediately by e-mail if you have received this
> e-mail by mistake and delete this e-mail from your system.
>
> E-mail transmission cannot be guaranteed to be secure or error-free
> as information could be intercepted, corrupted, lost, destroyed,
> arrive late or incomplete, or contain viruses. The sender therefore
> does not accept liability for any errors or omissions in the contents
> of this message which arise as a result of e-mail transmission. If
> verification is required please request a hard-copy version. This
> message is provided for informational purposes and should not be
> construed as a solicitation or offer to buy or sell any securities or
> related financial instruments.
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
