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

From: <[email-masked]>
Date: Tue, 4 Jan 2011 11:42:51 -0500

> >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.
> 
> Yes, I'll agree with that.
> 
> >I'd be fine adding a mechanism for specifying salt, enctype and s2k 
> >params for OTP.
> 
> 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.
> 
> 

Are you propsing defining a new PA datatype similar to etype_info2?

Earlier versions of the OTP pre-auth ID had the following text in section 3.6:

   The salt and any additional parameters for string-to-key will be
   derived as described in section 3.1.3 of [RFC4120] using preauth data
   or default values defined for the particular enctype. 

The text was changed to the following to avoid using etype_info2 for anything other than the standard reply key.

   The enctype used for string-to-key SHALL be that of the Armor Key,
   the salt SHALL be the default salt for the principal requested in the
   AS-REQ and any additional parameters SHALL be the defaults for the
   encryption type.  

In order to define the salt, iteration count etc, but avoid reusing ETYPE-INFO2, maybe the text could be changed as follows:

   The enctype used for string-to-key SHALL be that of the Armor Key and 
   the salt and any additional parameters for string-to-key MAY be
   provided using PA-OTP-INFO preauth data.  If the PA-OTP-INFO2 is not provided then the
   default values defined for the particular enctype SHALL be used.  

PA-OTP-INFO ::= ETYPE-INFO2-ENTRY
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Thu, 13 Jan 2011 08:31:40 -0500

> > etype-info2 in such a mechanism.  I'm sure Larry will  be able to 
> > propose suitable text.
> > 
> > 
> 
> The text was changed to the following to avoid using 
> etype_info2 for anything other than the standard reply key.
> 
> In order to define the salt, iteration count etc, but avoid 
> reusing ETYPE-INFO2, maybe the text could be changed as follows:
> 

While working on the update to the OTP pre-auth draft, it occurred to me that instead of adding a new pre-auth type as described above, that it would probably be simpler to just extend the PA-OTP-CHALLENGE to allow the KDC to return the salt and s2kparams.

   PA-OTP-CHALLENGE ::= SEQUENCE {
      nonce            [0] OCTET STRING,
      otp-service      [1] UTF8String               OPTIONAL,
      otp-keyInfo      [2] SEQUENCE (SIZE(1..MAX)) OF OTP-KEYINFO,
	salt             [3] KerberosString           OPTIONAL,
      s2kparams        [4] OCTET STRING             OPTIONAL
      ...
    } 

    OTP-KEYINFO ::= SEQUENCE {
      flags            [0] OTPFlags, 
      otp-vendor       [1] UTF8String               OPTIONAL,   
      otp-challenge    [2] OCTET STRING (SIZE(8..MAX)) 
                                                    OPTIONAL,
      otp-length       [3] Int32                    OPTIONAL,
      otp-keyID        [4] OCTET STRING             OPTIONAL,
      otp-algID        [5] AnyURI                   OPTIONAL,
      supportedHashAlg [6] SEQUENCE OF AlgorithmIdentifier 
                                                    OPTIONAL,
      iterationCount   [7] Int32                    OPTIONAL,
      ...
    } 

I think that this should work OK in the four-pass mode where the KDC returns a PA-OTP-CHALLENGE in the KRB-ERROR response to the AS-REQ since if the salt and s2kparams are present then the client can use them in the key generation and use the default values if they are not present.  There is however a potential problem with the two-pass mode where the client sends a PA-OTP-REQUEST to the KDC in its initial AS-REQ rather than in response to a PA-OTP-CHALLENGE and so cannot have received a salt or any s2kparams in that transaction.  Maybe in this mode the client should always use the default values.

Any thoughts?

--Gareth

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 13 Jan 2011 14:56:40 -0500

--On Thursday, January 13, 2011 08:31:40 AM -0500 [email-masked] 
wrote:

> While working on the update to the OTP pre-auth draft, it occurred to me
> that instead of adding a new pre-auth type as described above, that it
> would probably be simpler to just extend the PA-OTP-CHALLENGE to allow
> the KDC to return the salt and s2kparams.
>

So, I was thinking in terms of extending PA-OTP-CHALLENGE to include an 
ETYPE-INFO2-ENTRY, but including the salt and s2kparams directly works as 
well, if the enctype is already known.

> I think that this should work OK in the four-pass mode where the KDC
> returns a PA-OTP-CHALLENGE in the KRB-ERROR response to the AS-REQ since
> if the salt and s2kparams are present then the client can use them in the
> key generation and use the default values if they are not present.  There
> is however a potential problem with the two-pass mode where the client
> sends a PA-OTP-REQUEST to the KDC in its initial AS-REQ rather than in
> response to a PA-OTP-CHALLENGE and so cannot have received a salt or any
> s2kparams in that transaction.  Maybe in this mode the client should
> always use the default values.

This is really no different from a client using a traditional password. 
The client may know up front that it should use non-default values; 
otherwise, it should use the defaults.  In either case, if what it picks is 
wrong, it has to fall back to a longer exchange to find out the correct 
values from the KDC.  It might even be desirable in this case for the 
client to indicate what values it used, so that if they are wrong, the KDC 
can reject the request and return correct values.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Jan 2011 20:25:48 -0500

I definitely prefer options that do not include new pa-types.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: <[email-masked]>
Date: Fri, 14 Jan 2011 12:42:39 -0500

> > While working on the update to the OTP pre-auth draft, it 
> occurred to 
> > me that instead of adding a new pre-auth type as described 
> above, that 
> > it would probably be simpler to just extend the PA-OTP-CHALLENGE to 
> > allow the KDC to return the salt and s2kparams.
> >
> So, I was thinking in terms of extending PA-OTP-CHALLENGE to 
> include an ETYPE-INFO2-ENTRY, but including the salt and 
> s2kparams directly works as well, if the enctype is already known.
> 
It is known.  The enctype for the generated keys will be the same as the armor key.

> > returns a PA-OTP-CHALLENGE in the KRB-ERROR response to the AS-REQ 
> > since if the salt and s2kparams are present then the client can use 
> > them in the key generation and use the default values if 
> they are not 
> > present.  There is however a potential problem with the 
> two-pass mode 
> > where the client sends a PA-OTP-REQUEST to the KDC in its initial 
> > AS-REQ rather than in response to a PA-OTP-CHALLENGE and so cannot 
> > have received a salt or any s2kparams in that transaction.  
> Maybe in 
> > this mode the client should always use the default values.
> 
> The client may know up front that it should use non-default 
> values; otherwise, it should use the defaults.  In either 
> case, if what it picks is wrong, it has to fall back to a 
> longer exchange to find out the correct values from the KDC.  
> It might even be desirable in this case for the client to 
> indicate what values it used, so that if they are wrong, the 
> KDC can reject the request and return correct values.
> 
In the standard password case, how does the client indicate what salt and s2kparams it has used if it doesn't wait for the PA-ETYPE-INFO2?

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 14 Jan 2011 13:12:18 -0500

--On Friday, January 14, 2011 12:42:39 PM -0500 [email-masked] 
wrote:

> In the standard password case, how does the client indicate what salt and
> s2kparams it has used if it doesn't wait for the PA-ETYPE-INFO2?

It doesn't.