Subject: [Ietf-krb-wg] Use of hash function from encryption profile

From: "Richards, Gareth" <[email-masked]>
Date: Tue, 6 Nov 2007 20:09:53 -0000

>From what I understand, the crypto functions available to a pre-auth
method are those described in sections 3 and 4 of RFC3961
(string-to-key, random-to-key, get_mic etc) but this set does not appear
to expose the unkeyed hash function defined as part of the encryption
algorithm profile.  Is there a method for using the hash function of the
encryption profile in a way that conforms to RFC3961?

Thanks

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

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 6 Nov 2007 16:33:25 -0500

> encryption profile in a way that conforms to RFC3961?

I guess what you're asking is if it's reasonable to say in a preauth  
spec, "here we invoke the unkeyed hash function associated with the  
indicated encryption type"?

I would say no.  While the "simplified profile" does specify the use  
of an unkeyed hash function, it's not required that the simplified  
profile be used, and it wouldn't be a good idea to restrict a preauth  
scheme to using those encryption algorithms based on the simplified  
profile.  Despite the recommendations of section 5, I would expect  
the next Kerberos cryptosystem that comes along to be based on one of  
the "authenticated encryption" modes that have become popular in  
recent years, many of which implement the authentication using the  
block encryption function, such that there may be no unkeyed version  
to use.

If you need an unkeyed hash function, I'd recommend either picking  
one and specifying it, or including an algorithm identifier in the  
message, or finding a way to negotiate it.

Ken

---

From: "Richards, Gareth" <[email-masked]>
Date: Tue, 6 Nov 2007 21:55:53 -0000

Ken,

Thanks for the response.

I was trying not to assume the simplified profile but was really asking
if it is reasonable to use the hash function used by the cryptosystem.
E.g. MD5 from DES-MD5, SHA1 from the AES algortihms etc.  But from what
you say, I cannot assume that there will be a basic hash function
available.

I could certainly add a method within the protocol to negotiate/specify
a hash algorithm but I was reluctant to do this since it would require
support within the client for something that may not be supported by the
enctype. 

Thanks

--Gareth

> > (string-to-key, random-to-key, get_mic etc) but this set does not 
> > appear to expose the unkeyed hash function defined as part of the 
> > encryption algorithm profile.  Is there a method for using the hash 
> > function of the encryption profile in a way that conforms 
> to RFC3961?
> 
> I guess what you're asking is if it's reasonable to say in a 
> preauth spec, "here we invoke the unkeyed hash function 
> associated with the indicated encryption type"?
> 
> I would say no.  While the "simplified profile" does specify 
> the use of an unkeyed hash function, it's not required that 
> the simplified profile be used, and it wouldn't be a good 
> idea to restrict a preauth scheme to using those encryption 
> algorithms based on the simplified profile.  Despite the 
> recommendations of section 5, I would expect the next 
> Kerberos cryptosystem that comes along to be based on one of 
> the "authenticated encryption" modes that have become popular 
> in recent years, many of which implement the authentication 
> using the block encryption function, such that there may be 
> no unkeyed version to use.
> 
> If you need an unkeyed hash function, I'd recommend either 
> picking one and specifying it, or including an algorithm 
> identifier in the message, or finding a way to negotiate it.

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 6 Nov 2007 18:47:43 -0500

> you say, I cannot assume that there will be a basic hash function

Right.

> support within the client for something that may not be supported  

True; unkeyed hashes aren't a general feature of the Kerberos  
cryptosystems.  But RFC 4120 does specify that AES256-CTS-HMAC- 
SHA1-96 must be supported, so SHA1 should be available in  
implementations of the current spec.  If you want to base a preauth  
system on RFC 4120, you could negotiate but specify that SHA1 must be  
implemented and available.

Ken

---

From: Larry Zhu <[email-masked]>
Date: Wed, 7 Nov 2007 01:26:36 -0800

Would it be reasonable to associate an unkeyed hash for each enctype? This way, Gareth does not need to invent a way to negotiate which unkeyed hash is mutually supported.

I can see SHA1 a good choice to associated with all existing enctypes, and we can define wider hashes for newer enctypes to be defined. This way it is probably cleaner.

--larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ken Raeburn
Sent: Tuesday, November 06, 2007 3:48 PM
To: Richards, Gareth
Cc: IETF Kerberos Working Group
Subject: Re: [Ietf-krb-wg] Use of hash function from encryption profile

Right.

Ken

---

From: "Richards, Gareth" <[email-masked]>
Date: Wed, 7 Nov 2007 12:18:13 -0000

> 
> > I could certainly add a method within the protocol to negotiate/ 
> > specify a hash algorithm but I was reluctant to do this 
> since it would 
> > require support within the client for something that may not be 
> > supported by the enctype.
> 
> implementations of the current spec.  If you want to base a 
> preauth system on RFC 4120, you could negotiate but specify 
> that SHA1 must be implemented and available.
> 
Thanks, I will probably go this route.

--Gareth

---

From: "Richards, Gareth" <[email-masked]>
Date: Wed, 7 Nov 2007 13:45:11 -0000

I would think that this would be the best option if it could be done. 

> 
> Would it be reasonable to associate an unkeyed hash for each 
> enctype? This way, Gareth does not need to invent a way to 
> negotiate which unkeyed hash is mutually supported.
> 
> I can see SHA1 a good choice to associated with all existing 
> enctypes, and we can define wider hashes for newer enctypes 
> to be defined. This way it is probably cleaner.
> 
> --larry
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ken Raeburn
> > I was trying not to assume the simplified profile but was really 
> > asking if it is reasonable to use the hash function used by the 
> > cryptosystem.
> > E.g. MD5 from DES-MD5, SHA1 from the AES algortihms etc.  But from 
> > what you say, I cannot assume that there will be a basic 
> hash function 
> > available.
> 
> Right.
>

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 07 Nov 2007 12:03:08 -0500

> Thanks, I will probably go this route.

Note that any time a new standards track protocol uses a hash for its 
cryptographic properties, there must be a means of negotiatiing which 
algorithm is used, and SHA-1 must be defined and mandatory to implement.

In the case of extensions to Kerberos, when a key is known, it is usually 
desirable to use the operations exposed by RFC3961.

What will ths hash function be used for in this case?

-- Jeff

---

From: "Richards, Gareth" <[email-masked]>
Date: Wed, 7 Nov 2007 22:25:29 -0000

> Note that any time a new standards track protocol uses a hash 
> for its cryptographic properties, there must be a means of 
> negotiatiing which algorithm is used, and SHA-1 must be 
> defined and mandatory to implement.
> 
> In the case of extensions to Kerberos, when a key is known, 
> it is usually desirable to use the operations exposed by RFC3961.
> 
The problem is that in the current OTP pre-auth ID, the OTP value is
converted to a key using string-to-key and so in order to generate the
same key, the KDC needs to be able to obtain the OTP value.  If the KDC
is not the OTP server then possible solutions are for the KDC to obtain
the OTP values from the server or to have that server carry out the
string-to-key operation and return the result to the KDC.  Neither of
these is ideal.  

A possible alternative is to use a hash of the OTP instead and so use
random-to-key(hash(OTP)).  In this case, the OTP server would instead
only need to return a hash of the OTP value to the KDC.

However, since unkeyed hashes are currently not defined as part of the
enctype, I would need some means of negotiating the hash algorithm. 

--Gareth

---

From: "Tim Alsop" <[email-masked]>
Date: Wed, 7 Nov 2007 22:46:14 -0000

Gareth wrote :

> same key, the KDC needs to be able to obtain the OTP value.

With above in mind, how does RSA Auth Server allow this ? I asked RSA
this question about 2 years ago as we were thinking along these lines to
implement two-factor auth without a Kerberos password, but I was told
the ACE Server did not, and would not expose an interface for us to
call, where we can get the OTP value for a particular user. Also, the
OTP value entered by user will not always be an exact match, as at any
point in time the OTP value can have more than one valid value.

Regards,
Tim

---

From: "Henry B. Hotz" <[email-masked]>
Date: Wed, 7 Nov 2007 15:42:39 -0800

> point in time the OTP value can have more than one valid value.

. . . and I've asked the question, and so have at least two other  
people that I can name.  This has always been the problem with using  
RSA SecurID tokens with Kerberos.  If Gareth's protocol standards  
work convinces the company to change this policy then I think we will  
all be in his debt.

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

---

From: Ken Raeburn <[email-masked]>
Date: Wed, 7 Nov 2007 20:19:10 -0500

> negotiate which unkeyed hash is mutually supported.

I'm not sure we want to turn the Kerberos crypto spec into a general  
crypto facility, providing stuff that the core Kerberos protocol has  
no need for.  But we've already started down that road.  (And if we  
keep going further down that road, we should revise 3961 someday to  
incorporate the additions.)

So, if we define a future cryptosystem using CMAC for the "checksum",  
and specifying SHA-1 as an additional hash function, we need to  
update it if we want to move to SHA-2, even though the core Kerberos  
protocol doesn't care?

Do we really want to make SHA-1 be the required hash for  
cryptosystems already using hash functions that are weaker?  If  
people want good crypto, they should just be avoiding those  
altogether, and using MD5 for DES-MD5 would be more consistent...

Ken

---

From: "Tim Alsop" <[email-masked]>
Date: Thu, 8 Nov 2007 08:48:49 -0000

Henry,

The only way I can see RSA allowing this kind of access is if the auth
server is installed on the same host as the KDC and a private interface
is made available to get this information from auth server, e.g. via a
statically linked library. I doubt they would extend the existing API to
support this as it is something they would only want specific
vendors/developers to use.

We are an RSA Secured partner and are working with RSA to get our latest
release certified, but this will be our product that needs Kerberos
password as well as token value + pin. Then, we plan to try and find
ways to implement two-factor auth without Kerberos password, but this
will depend on the otp vendor helping us.

Thanks,
Tim

-----Original Message-----
From: Henry B. Hotz [mailto:[email-masked]] 
Sent: 07 November 2007 23:43
To: Tim Alsop
Cc: Richards, Gareth; Jeffrey Hutzelman; Ken Raeburn; IETF Kerberos
Working Group

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Nov 2007 11:23:57 -0500

>>>>> "Richards," == Richards, Gareth <[email-masked]> writes:

    >> 
    >> >>
    >> >> > I could certainly add a method within the protocol to
    >> negotiate/ >> > specify a hash algorithm but I was reluctant to
    >> do this >> since it would >> > require support within the
    >> client for something that may not be >> > supported by the
    >> enctype.
    >> >>
    >> >> True; unkeyed hashes aren't a general feature of the
    >> Kerberos >> cryptosystems.  But RFC 4120 does specify that
    >> AES256-CTS-HMAC- >> SHA1-96 must be supported, so SHA1 should
    >> be available in >> implementations of the current spec.  If you
    >> want to base a preauth >> system on RFC 4120, you could
    >> negotiate but specify that SHA1 must be >> implemented and
    >> available.
    >> >>
    >> negotiatiing which algorithm is used, and SHA-1 must be defined
    >> and mandatory to implement.
    >> 
    >> In the case of extensions to Kerberos, when a key is known, it
    >> is usually desirable to use the operations exposed by RFC3961.
    >> 
    Richards,> The problem is that in the current OTP pre-auth ID, the
    Richards,> OTP value is converted to a key using string-to-key and
    Richards,> so in order to generate the same key, the KDC needs to
    Richards,> be able to obtain the OTP value.  If the KDC is not the
    Richards,> OTP server then possible solutions are for the KDC to
    Richards,> obtain the OTP values from the server or to have that
    Richards,> server carry out the string-to-key operation and return
    Richards,> the result to the KDC.  Neither of these is ideal.

I think that both of these are better than:

    Richards,> A possible alternative is to use a hash of the OTP
    Richards,> instead and so use random-to-key(hash(OTP)).  In this
    Richards,> case, the OTP server would instead only need to return
    Richards,> a hash of the OTP value to the KDC.

A hash does not (except under the random oracle assumption) produce a
random value.  So it is not appropriate for input to random-to-key.

I don't like the idea of associating unkeyed hashes with enctypes for
the reasons Ken outlined.

--Sam as an individual

---

From: "Richards, Gareth" <[email-masked]>
Date: Thu, 8 Nov 2007 16:59:19 -0000

> A hash does not (except under the random oracle assumption) 
> produce a random value.  So it is not appropriate for input 
> to random-to-key.
> 
I realise that a hash function does not produces a random value.  The
only reason I mentioned random-to-key is that a hash would not be a
string and so I didn't think I could use string-to-key.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Nov 2007 12:26:55 -0500

>> Richards,> instead and so use random-to-key(hash(OTP)).  In
    >> this Richards,> case, the OTP server would instead only need to
    >> return Richards,> a hash of the OTP value to the KDC.
    >> 
    >> produce a random value.  So it is not appropriate for input to
    >> random-to-key.
    >> 
    Richards,> I realise that a hash function does not produces a

I think using string2key would be fine.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: "Richards, Gareth" <[email-masked]>
Date: Thu, 8 Nov 2007 17:53:21 -0000

>     Richards,> a hash of the OTP value to the KDC.
My concern is that there would be reluctance to support a system where
OTP servers need to release plaintext OTP values.  If the string-to-key
operation was carried out by the OTP Server then that would require the
server to have knowledge of how that function is implemented for the
enctypes supported by the KDC.

If hashes are used then it would not require knowledge of the enctype
since it would only require support for standard hash algorithms and
there would probably be less reluctance to support a system that only
required the release of hashes.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Thu, 8 Nov 2007 13:35:11 -0500 (EST)

> I think using string2key would be fine.

As it turns out, Kerberos cryptosystems don't have an operation that does
what you want.

What random-to-key does is take a random bitstring of a fixed size and
turn it into a suitable key.  It cannot be used on an arbitrary amount of
data, and it cannot be used on non-random data with useful results.  For
many enctypes, this is just going to be the identity function over the set
of strings of whathever the enctype's key length is.  For single-DES, it
operates on 64-bit strings and fixes up key parity.

On the other hand, string-to-key is defined to take UTF-8 key and salt
strings, and so an arbitrary bitstring may not be valid input.  This is a
real limitation as there exist enctypes (non-standard but widely deployed)
for which the first step in the string-to-key operation is to take the
UTF-8 input string and convert it to little-endian UCS2, which cannot be
done if the input is not valid UTF-8.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Thu, 08 Nov 2007 13:39:59 -0500

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

    Jeffrey> On the other hand, string-to-key is defined to take UTF-8
    Jeffrey> key and salt strings, and so an arbitrary bitstring may
    Jeffrey> not be valid input.  This is a real limitation as there
    Jeffrey> exist enctypes (non-standard but widely deployed) for
    Jeffrey> which the first step in the string-to-key operation is to
    Jeffrey> take the UTF-8 input string and convert it to
    Jeffrey> little-endian UCS2, which cannot be done if the input is
    Jeffrey> not valid UTF-8.

So, base64 your binary data or something like that.  Ugly, but should
work fine.