Subject: Comment on section 3: special salts (Re: krbrev - revisions to section 3)

From: Nicolas Williams <[email-masked]>
Date: Fri, 3 Aug 2001 12:59:56 -0400

Imagine this situation:

 - a site requires pre-authentication for all users

 - those users' hosts are configure to use pre-authentication to avoid
   having to do two AP_REQs (one without PA-ENC-TIMESTEAMP, eliciting a
   preauth-required error, and one with)

 - a user principal is renamed, and the user's old principal name is
   stored as a special salt for her keys in the KDC database

When that user logs in the KDC will respond to the initial AS_REQ with a
pre-auth failed error and, if I understand the revisions correctly, NO
ETYPE-INFO, meaning that the client cannot obtain the correct salt unless
it retries the AS_REQ with no pre-auth.

This means that in a site with a pre-auth required policy users with
"special" salts will always require THREE AS_REQs to obtain an initial
ticket!!

Could we have language introduced that "the KDC MAY/SHOULD include
ETYPE-INFO in KDC_ERR_PREAUTH_FAILED KRB-ERROR messages when the client
principal name has keys with special salts"?

If not, could we have language introduced that clients attempting an
AS_REQ with pre-auth should retry without pre-auth if the KDC responds
with KDC_ERR_PREAUTH_FAILED?

I prefer the first suggestion -- so few sites have support for principal
renaming that such a protocol change should cause no disruptions and it
is principal renaming that usually would lead to principals with special
salts.

Thanks,

Nico

On Fri, Jul 20, 2001 at 08:12:35AM -0700, Clifford Neuman wrote:
> All,
> 
> Changes to section 3 are now up.  The only change since the last
> version was removal of name canonicalization from the draft.  You can
> find the latest versions at.
> 
>  http://www.isi.edu/people/bcn/krb-revisions
> 
> I would like it if the feedback is as specific as possible, suggesting
> specific changes, or if you don't know the specific change, pointing
> out your concern.
> 
> Please first send the suggestion to me alone.  I will then either make
> the change and reply to the list (crediting your contribution of
> course), or I will reply to you individually to try to clarify or
> explain why I don't think the change is necessary.  At this point you
> can either reply to me individually, or to the list if you think there
> is an issue that needs discussion.  In all messages to me - or
> subsequently to the list, please include "krbrev -" as a prefix to the
> subject - it cause the message to go into a separate folder for easier
> tracking.
> 
> We will continue this revisions cycle through the meeting, so if you
> don't get changes to me today (I understand that is unlikely), still
> send them to me and I will update the version of the web site for
> continued discussion.  I will be submitting the draft in its current
> form up to noon (US PDT) today - to meet the 5PM (US EDT) deadline.
> 
> Clifford Neuman
--
. 

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.

---

From: Tom Yu <[email-masked]>
Date: 08 Aug 2001 07:26:15 -0400

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

NW> Imagine this situation:

NW>  - a site requires pre-authentication for all users

Pre-authentication where the client must encrypt something in its
secret key?  Or generalized preauth?

NW>  - those users' hosts are configure to use pre-authentication to avoid
NW>    having to do two AP_REQs (one without PA-ENC-TIMESTEAMP, eliciting a
NW>    preauth-required error, and one with)

NW>  - a user principal is renamed, and the user's old principal name is
NW>    stored as a special salt for her keys in the KDC database

NW> When that user logs in the KDC will respond to the initial AS_REQ with a
NW> pre-auth failed error and, if I understand the revisions correctly, NO
NW> ETYPE-INFO, meaning that the client cannot obtain the correct salt unless
NW> it retries the AS_REQ with no pre-auth.

It could be argued that the ETYPE-INFO should be sent in any situation
where the client's next logical step would be to send some padata
encrypted with its secret key.  We can fix this in a later revision.

NW> This means that in a site with a pre-auth required policy users with
NW> "special" salts will always require THREE AS_REQs to obtain an initial
NW> ticket!!

Not necessarily, if we do as explained above.

NW> Could we have language introduced that "the KDC MAY/SHOULD include
NW> ETYPE-INFO in KDC_ERR_PREAUTH_FAILED KRB-ERROR messages when the client
NW> principal name has keys with special salts"?

I do not know whether it is best to describe the behavior in a
functional way, or to enumerate all the possible error codes that
result in the sending of an ETYPE-INFO.  I would prefer to do so in a
functional way.

Hm.  I am now recalling that there was a bug in the MIT KDC code that
caused a bogus PA-PW-SALT to get sent out in the KRB-ERROR when
preauth was required.  The salt in the ETYPE-INFO was correct, though,
so perhaps we should point this out in the next draft: PA-PW-SALT
should be ignored when present in a KRB-ERROR message.

---Tom

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 8 Aug 2001 08:11:26 -0400

> secret key?  Or generalized preauth?

Well, the answer is "yes" to the first question. The answer to the
second question is: whenever the principal's long-term key is to be used
as key material for encrypting the resulting ticket.

[...]

> encrypted with its secret key.  We can fix this in a later revision.

Good.

> Not necessarily, if we do as explained above.

Right, which is also pretty much what I'm suggesting. My primary concern
is that it not be seen as a violation of the RFC that results from these
revisions for the KDC to include ETYPE-INFO on pre-auth failed
KRB-ERRORs. Similarly for the client.

> result in the sending of an ETYPE-INFO.  I would prefer to do so in a

The text I suggested was merely a start, primarily to make sure that
such behaviour would not be considered a violation of the RFC. I am not
trying to add requirements for implementors however.

> should be ignored when present in a KRB-ERROR message.

Interesting. Does MIT krb5 version 1.2.2 exhibit this bug?

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.-