Subject: [Ietf-krb-wg] WGLC comments: draft-ietf-krb-wg-otp-preauth-13, section 3.6 the default salt

From: Larry Zhu <[email-masked]>
Date: Fri, 17 Dec 2010 21:20:16 +0000

Speaking as an individual, I am concerned with the use of the default salt and the lack of recovery mechanisms if the client and the server have different values in the salt in the existing -13 draft. I would like to single out this issue in this separate thread and ask for comments in the group in the context of WGLC.

Gareth kindly refreshed my memory that section 4 of RFC4120 does define the default salt for a Kerberos principal. The default salt is useful to optimize away a round trip in some cases, but just relying on that would make OTP harder to deploy than necessary. I can see the following reasons on top of my head:
1) It is known that some implementation does case folding of the principal name and/or realm names, and many others do not. This can lead to different salt values from the client side than that of the KDC especially when two different code bases try to interop.
2) In addition, we have the infamous issue with regarding to if the first character in the username of the built-in "administrator" windows account is in upper case. Let's not start to alienate the involved user base :-).
3) Relying on the default salt has high potential to expose bugs that lead to hard failures in existing implementations when we incrementally update them to support OTP.

<chair hat on/>
I tend to think this is a generic Kerberos issue, not specific to OTP. I would like to get input from Kerberos implementers and administrators in this list before proceeding to the next steps for publication. Please share your data points.
<char hat off/>
Thanks,
--Larry

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 17 Dec 2010 16:44:12 -0500

--On Friday, December 17, 2010 09:20:16 PM +0000 Larry Zhu 
<[email-masked]> wrote:

>
> Speaking as an individual, I am concerned with the use of the default
> salt and the lack of recovery mechanisms if the client and the server
> have different values in the salt in the existing -13 draft. I would like
> to single out this issue in this separate thread and ask for comments in
> the group in the context of WGLC.
>
> Gareth kindly refreshed my memory that section 4 of RFC4120 does define
> the default salt for a Kerberos principal. The default salt is useful to
> optimize away a round trip in some cases, but just relying on that would
> make OTP harder to deploy than necessary. I can see the following reasons
> on top of my head: 1) It is known that some implementation does case
> folding of the principal name and/or realm names, and many others do not.
> This can lead to different salt values from the client side than that of
> the KDC especially when two different code bases try to interop. 2) In
> addition, we have the infamous issue with regarding to if the first
> character in the username of the built-in "administrator" windows account
> is in upper case. Let's not start to alienate the involved user base :-).
> 3) Relying on the default salt has high potential to expose bugs that
> lead to hard failures in existing implementations when we incrementally
> update them to support OTP.
>
> <chair hat on/>
> I tend to think this is a generic Kerberos issue, not specific to OTP. I
> would like to get input from Kerberos implementers and administrators in
> this list before proceeding to the next steps for publication. Please
> share your data points. <char hat off/>

I don't understand.  How is this not what PA-PW-SALT, PA-ETYPE-INFO, and 
PA-ETYPE-INFO2 are for?  In the absence of these PA-data, what would one 
expect to happen, other than use of the default salt and s2k parameters?

-- Jeff

---

From: Larry Zhu <[email-masked]>
Date: Fri, 17 Dec 2010 21:56:03 +0000

Use of etype info2 as you hinted would address the issue, but in the error message, should the OTP server/KDC resend a new OTP-challenge in case the salt value is incorrect (the KDC probably cannot differentiate if the salt is wrong or if the OTP code is wrong in some cases, but it can send back a PREAUTH_FAILED based on which under current spec no ETYE_INFO2 is expected to send along). Some hints would be needed to tell implementers how to recover from that situation in the context of OTP.

The existing RFC4120 text on ETYPE_INFO2 seems to suggest ETYPE_INFO2 is specific to encrypted timestamp  pa-data. If we for a moment imagine the KDC only supports OTP preauth types as Gareth defined, does the KDC have the obligation to send ETYPE_INFO2 in the error message if any, and the AS_REP? It certainly does not make sense to do that when PKINIT and only PKINIT is used.

-----Original Message-----
From: Jeffrey Hutzelman [mailto:[email-masked]] 
Sent: Friday, December 17, 2010 1:44 PM
To: Larry Zhu; [email-masked]
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] WGLC comments: draft-ietf-krb-wg-otp-preauth-13, section 3.6 the default salt

--On Friday, December 17, 2010 09:20:16 PM +0000 Larry Zhu <[email-masked]> wrote:

> have different values in the salt in the existing -13 draft. I would 
> like to single out this issue in this separate thread and ask for 
> comments in the group in the context of WGLC.
>
> Gareth kindly refreshed my memory that section 4 of RFC4120 does 
> define the default salt for a Kerberos principal. The default salt is 
> useful to optimize away a round trip in some cases, but just relying 
> on that would make OTP harder to deploy than necessary. I can see the 
> following reasons on top of my head: 1) It is known that some 
> implementation does case folding of the principal name and/or realm names, and many others do not.
> This can lead to different salt values from the client side than that 
> of the KDC especially when two different code bases try to interop. 2) 
> In addition, we have the infamous issue with regarding to if the first 
> character in the username of the built-in "administrator" windows 
> account is in upper case. Let's not start to alienate the involved user base :-).
> lead to hard failures in existing implementations when we 
> incrementally update them to support OTP.
>
> <chair hat on/>
> I tend to think this is a generic Kerberos issue, not specific to OTP. 
> I would like to get input from Kerberos implementers and 
> administrators in this list before proceeding to the next steps for 
> publication. Please share your data points. <char hat off/>

I don't understand.  How is this not what PA-PW-SALT, PA-ETYPE-INFO, and
PA-ETYPE-INFO2 are for?  In the absence of these PA-data, what would one expect to happen, other than use of the default salt and s2k parameters?

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Dec 2010 16:12:28 -0500

I believe etype_info2 is only appropriate for describing a classic reply
key.  Thus, I believe an OTP implementation should always use the
default salt and always ignore etype_info2.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 20 Dec 2010 17:38:57 -0500

>default salt and always ignore etype_info2.

I'll buy that argument to some extent, but I think we need to have some way of providing those parameters any time s2k is used.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Mon, 20 Dec 2010 18:07:59 -0500

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> "Sam Hartman" <[email-masked]> wrote:
    >> I believe etype_info2 is only appropriate for describing a
    >> classic reply key.  Thus, I believe an OTP implementation should
    >> always use the default salt and always ignore etype_info2.

    Jeffrey> I'll buy that argument to some extent, but I think we need
    Jeffrey> to have some way of providing those parameters any time s2k
    Jeffrey> is used.

Larry and I had a phone call about this.

I actually think using the default salt is fine, except that it makes
precomputation of keys harder for the KDC because of case folding and
the like.
However, I think you definitely want to be able to specify the iteration
count.
Also, once you do that, you might as well specify the salt.

My argument is that you should have some specific structure for the use
of s2k in question. It's not good to overloadetype_info2 to mean this is
the set of enctypes I support for your longterm key +this is the s2k
info for any random s2k usage that you might come across while running
the request.

I'd be fine adding a mechanism for specifying salt, enctype and
s2k params for OTP.

I believe Larry is looking into text to do this.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 20 Dec 2010 18:17:54 -0500

>info for any random s2k usage that you might come across while running

Yes, I'll agree with that.

>I'd be fine adding a mechanism for specifying salt, enctype and

It seems like it would be appropriate to reuse the form of etype-info2 in such a mechanism.  I'm sure Larry will  be able to propose suitable text.

---

From: "Henry B. Hotz" <[email-masked]>
Date: Mon, 20 Dec 2010 19:06:53 -0800

1) If we need to support case folding or some other nonstandard behavior, shouldn't that be done in an update to 4120?

2) I'm OK with the default salt being different for different PA mech's as long as it's clearly specified.  It's not my first choice though.  Seems simpler to keep it the same all 'round if that's workable.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Dec 2010 10:10:42 -0500

>>>>> "Henry" == Henry B Hotz <[email-masked]> writes:

    Henry> 1) If we need to support case folding or some other
    Henry> nonstandard behavior, shouldn't that be done in an update to
    Henry> 4120?  

It turns out that you don't actually need to violate 4120 for most case
folding support.
For client name canonicalization you do, and that's one of the reasons
why we should finish the referrals draft.

    Henry> 2) I'm OK with the default salt being different for
    Henry> different PA mech's as long as it's clearly specified.  It's
    Henry> not my first choice though.  Seems simpler to keep it the
    Henry> same all 'round if that's workable.

We're not proposing the default salt changing. The question is whether
PA mechs have the ability to specify a specific salt or whether that's
only for the long-term key.

Larry and Jeff seem to believe that would be a good idea. I don't care,
but believe that once you specify s2k params/iteration count (which I do
think is good), salt is easy and should be done at the same time.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg