Subject: [TLS] draft-urien-tls-keygen-00.txt

From: Pascal Urien <[email-masked]>
Date: Sun, 22 Jun 2008 20:09:52 +0200

Dear all,

The draft http://www.ietf.org/internet-drafts/draft-urien-tls-keygen-00.txt
  proposes a  keying infrastructure based on the TLS protocol.

  It suggests defining an additional Key Distribution Function (KDF)
  in order to deliver a set of cryptographic keys.

   In a peer to peer mode keys are directly produced as inputs of the 
KDF functions.

   For centralized architectures they are delivered through containers,
   secured with keys derived from the KDF function.

   I will attend to the next IETF meeting in Dublin, and i hope to present
   more precisely the scope of this proposal

Best Regards

Pascal

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Sun, 22 Jun 2008 11:24:47 -0700

It might be better to use a label other than "key expansion" in the KDF
since that is already used in TLS.

Mike

Pascal Urien wrote:
>   In a peer to peer mode keys are directly produced as inputs of the KDF 
> functions.
>

---

From: Pascal Urien <[email-masked]>
Date: Mon, 23 Jun 2008 10:20:03 +0200

Hi Mike,

   I agree on that point.

    Maybe the label used with KDF could be different according
   to different uses

Pascal

At 20:24 22/06/2008, Mike wrote:
>>   In a peer to peer mode keys are directly produced as inputs of 
>> the KDF functions.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 23 Jun 2008 14:20:41 +0200

It is a good idea to use different labels for different key usage.
Further, I would consider interactions between your document and the
following WG document:

http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-01.txt

You could refer to this for key label discussions.

/Simon

---

From: Pascal Urien <[email-masked]>
Date: Mon, 23 Jun 2008 18:11:09 +0200

Hi All,

  - There is a common point between the two proposals, i.e. use of 
TLS for key generation

  - In draft-ietf-tls-extractor-01.txt the TLS PRF function is used
  - In draft-urien-tls-keygen-00.txt a separate KDF function is used.
    Krawczyk, H (one of the HMAC designer) wrote a very interesting 
paper about tthe design of KDF functions
   "On Extract-then-Expand Key Derivation Functions and an HMAC-based 
KDF", http://www.ee.technion.ac.il/~hugo/kdf/, March 2008

   - The point that is not addressed by 
draft-ietf-tls-extractor-01.txt, is the case for which keys are 
pushed by server and not computed by
     both parties (client and server)

Pascal

At 14:20 23/06/2008, Simon Josefsson wrote:
> >>>The draft 
> http://www.ietf.org/internet-drafts/draft-urien-tls-keygen-00.txt

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 24 Jun 2008 15:48:56 -0400

After a brief look, the algorithm seems OK. But why not just use straight hash (say SHA) instead of HMAC in key derivation function?

 1.  If SHA (or whatever) hash function output possesses random properties - what's the advantage of employing HMAC construct? What does it add that hasn't been there already?
 2.  If SHA does not produce pseudo-random output - how does HMAC improve the situation?

(Yes I'm aware of HMAC advantages for MACing, but this is different. I've read <http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf>,  and still am not convinced.)

On 6/23/08 12:11 PM, "Pascal Urien" <[email-masked]> wrote:

Hi All,

Pascal

--
Regards,
Uri         [email-masked]

---

From: Pascal Urien <[email-masked]>
Date: Wed, 25 Jun 2008 17:56:28 +0200

Hi All,

In RFC 4306 (IKEV2) some PRF functions are already HMAC BASED

SKEYSEED is computed as PRK.

According to RFC 4306
=====================

For Transform Type 2 (Pseudo-random Function), defined Transform IDs are:

Name                             Number               Defined In
RESERVED                        0
PRF_HMAC_MD5                1                 (RFC 2104), [MD5]
PRF_HMAC_SHA1               2                 (RFC 2104), [SHA]
PRF_HMAC_TIGER              3                 (RFC 2104)
PRF_AES128_XCBC             4                 (RFC 3664)

Keying material is generated accorking to the selected prf

prf+(K,S) = T1 | T2 | T3 | T4 | ...

where:
T1 = prf (K, S | 0x01)
T2 = prf (K, T1 | S | 0x02)
T3 = prf (K, T2 | S | 0x03)
T4 = prf (K, T3 | S | 0x04)

SKEYSEED = prf(Ni | Nr, g^ir)
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | 
SK_pr } = prf+(SKEYSEED, Ni | Nr | SPIi | SPIr )

KEYMAT = prf+(SK_d, Ni | Nr)
or
KEYMAT = prf+(SK_d, g^ir | Ni | Nr )

Pascal

At 21:48 24/06/2008, Blumenthal, Uri wrote:
>Content-Language: en
>Content-Type: multipart/alternative; boundary="_000_C486C7E8D23urillmitedu_"
>
>After a brief look, the algorithm seems OK. But 
>why not just use straight hash (say SHA) instead 
>of HMAC in key derivation function?
>
>    * If SHA (or whatever) hash function output 
> possesses random properties – what’s the 
> advantage of employing HMAC construct? What 
> does it add that hasn’t been there already?
>    * If SHA does not produce pseudo-random 
> output – how does HMAC improve the situation?
>
>(Yes I’m aware of HMAC advantages for MACing, 
>but this is different. I’ve read 
><<http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf>http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf>, 
>and still am not convinced.)
>
>
>On 6/23/08 12:11 PM, "Pascal Urien" 
><<[email-masked]>[email-masked]> wrote:
>
>Hi All,
>
>KDF", 
><http://www.ee.technion.ac.il/~hugo/kdf/>http://www.ee.technion.ac.il/~hugo/kdf/, 
>March 2008
>
> ><http://www.ietf.org/internet-drafts/draft-ietf 
> -tls-extractor-01.txt>http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-01.txt
> >
> >Pascal Urien <<[email-masked]>[email-masked]> writes:
> >
> > > Hi Mike,
> > >
> > >   I agree on that point.
> > >
> <http://www.ietf.org/internet-drafts/draft-urien-tls-keygen-00.txt>http://www.ietf.org/internet-drafts/draft-urien-tls-keygen-00.txt
> > >><[email-masked]>[email-masked]
><[email-masked]>[email-masked]
>Uri         <[email-masked]>[email-masked]

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Wed, 25 Jun 2008 13:16:39 -0400

>  In RFC 4306 (IKEV2) some PRF functions are already HMAC BASED

This does not answer my question. What benefits over SHA does HMAC-SHA provide here?

I suggest replacing HMAC-SHA with SHA for KDF, or providing rationale for using HMAC construct on top of SHA - and rationale better than "somebody else considered it a good idea". Showing how randomness of the output is measurably improved, or how an attack against key derivation mechanism is foiled by this mechanism could justify extra cost.

(Yes I'm aware of HMAC advantages for MACing, but this is different. I've read < http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf <http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf> >,  and still am not convinced.)

On 6/23/08 12:11 PM, "Pascal Urien" <[email-masked] <[email-masked]> > wrote:

Hi All,

Pascal

At 14:20 23/06/2008, Simon Josefsson wrote:
> http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-01.txt <http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-01.txt>
>
>Pascal Urien <[email-masked] <[email-masked]> > writes:
>
> > Hi Mike,
> >
> >   I agree on that point.
> >
> >>[email-masked] <[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>

_______________________________________________
TLS mailing list
[email-masked] <[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

--
Regards,
Uri

---

From: "Hugo Krawczyk" <[email-masked]>
Date: Wed, 25 Jun 2008 20:32:34 -0400

Pascal asked me to comment on this, especially in regards to Uri's questions.

Let me say that I did not read Pascal's document but I understand it
is based on the KDF scheme I have proposed and thoroughly analyzed in
the paper he cites, so I will respond on that basis.

Please refer to the page
http://www.ee.technion.ac.il/~hugo/kdf/
for details of the proposal, rationale, analysis etc.

As for Uri's questions.

I would have hoped that you would find answers to these questions in
the very detailed rationale in the paper. I suggest you read it
carefully.

The main reason for me to write such a paper is that the KDF subject
is non-trivial (even if it may seem that KDFs should be easy and
straightforward to build) and it raises many questions that one cannot
just answer in an email exchange.

Here are some points where using HMAC instead of the plain hash in
KDFs provides for a (much) better design:

- KDF functionality is a superset of PRF functionality (i.e., a KDF
needs to include the  PRF functionality for key expansion but it also
needs additional properties). Therefore, if one accepts that HMAC is
better as a PRF that a plain hash function such as SHA (and better
than the plain hash with a concatenated key) then the same is
certainly true for KDF which has more stringent requirements than PRF.

- HMAC as a mode of operation for hash functions preserves important
properties of the underlying hash function such as pseudo-randomness
(e.g. PRF), randomness (e.g. "random oracle"), and some important
extraction properties that are central (and crucial) for a good KDF.
Please refer to the paper for a comprehensive list of results on the
relevant cryptographic properties achieved by HMAC (and not by the
plain hash function). In particular, these results quantify the
quality of (pseudo) randomness output by the KDF as a function of the
assumptions on the underlying hash function.

- If you believe that SHA (or any other hash function) behaves as an
ideal random function then you can replace HMAC with the plain hash in
part of the KDF design (but even then you have to be careful, e.g. to
avoid extension attacks). But I do not think we should be in the
"mood" of over-trusting our hash functions. The last years have
reminded us of how shaky these functions can be so it is a prudent
engineering principle (and a sound theoretical methodology) to go for
designs that put as little trust as possible on the hash functions.
HMAC as a MAC and PRF is an example of such prudent methodology. There
is no reason not to apply the same principles to a basic primitive
such as a KDF.

- It is NOT true that you need to assume that the hash function is
"ideally random" to justify its use with HMAC in the KDF context. Much
weaker assumptions suffice for many applications and settings
(including instances of IKE and TLS). The paper explains these issues
in detail (maybe too much detail? :). The plain hash function does not
give you such guarantees. In particular, Merkle-Damgard iteration of
the compression function (e.g., plain SHA) does not preserve
pseudorandom or extraction properties even if the compression function
had them.

- If you follow the methodology of this proposal (what I call the
"extract-then-expand" paradigm), you can replace hash functions with
block ciphers if you prefer to trust those more than hash functions.

- There is no need to wait to see practical breakings of systems to
move to better designs, especially when the better designs have little
(if any) performance penalty (in the case of KDFs the extra block
hashed with HMAC is insignificant performance-wise).  It is enough
with the structural weaknesses and pitfalls presented by ad-hoc
schemes based on plain hash functions, and also discussed at length in
the paper,  to indicate that they are not the best designs we can wish
for.

I will stop here or I will start duplicating the many pages in my
paper (which hopefully is better written, and certainly more complete,
than anything said here).

Hugo

PS: I will be away for several weeks starting next week so I will not
be able to participate in discussions of these issues during that time
(but do not see that as a sign that I agree with everything that is
being said... :)

2008/6/25 Blumenthal, Uri <[email-masked]>:
> I suggest replacing HMAC-SHA with SHA for KDF, or providing rationale for
> using HMAC construct on top of SHA – and rationale better than "somebody
> else considered it a good idea". Showing how randomness of the output is
> measurably improved, or how an attack against key derivation mechanism is
> foiled by this mechanism could justify extra cost.
>
>
>
> After a brief look, the algorithm seems OK. But why not just use straight
> hash (say SHA) instead of HMAC in key derivation function?
>
> If SHA (or whatever) hash function output possesses random properties –
> what's the advantage of employing HMAC construct? What does it add that
> hasn't been there already?
> If SHA does not produce pseudo-random output – how does HMAC improve the
> situation?
>
> (Yes I'm aware of HMAC advantages for MACing, but this is different. I've
> read < http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf
> <http://www.ee.technion.ac.il/~hugo/kdf/kdf.pdf> >,  and still am not
> convinced.)
>
>
>> <http://www.ietf.org/internet-drafts/draft-ietf-tls-extractor-01.txt>
>>
>> >> <https://www.ietf.org/mailman/listinfo/tls>
>
>