[14919] in Kerberos
Re: Can we rename a principal yet?
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Wed Aug 1 11:55:25 2001
Date: Wed, 1 Aug 2001 11:50:59 -0400
From: Nicolas Williams <Nicolas.Williams@ubsw.com>
To: "Douglas E. Engert" <deengert@anl.gov>
Cc: "Christopher P. Lindsey" <lindsey@mallorn.com>, kerberos@MIT.EDU
Message-ID: <20010801115058.P22964@sm2p1386swk.wdr.com>
Mail-Followup-To: "Douglas E. Engert" <deengert@anl.gov>,
"Christopher P. Lindsey" <lindsey@mallorn.com>, kerberos@MIT.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <3B68216D.D420D3@anl.gov>; from deengert@anl.gov on Wed, Aug 01, 2001 at 10:34:05AM -0500
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?
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.
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?
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?
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.
