[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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?

  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" <Pascal.Urien@xxxxxxx> wrote:
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:
>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
>
>Pascal Urien <Pascal.Urien@xxxxxxx> writes:
>
> > 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:
> >>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:
> >>>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
> >>TLS@xxxxxxxx
> >> https://www.ietf.org/mailman/listinfo/tls


_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls


--
Regards,
Uri         uri@xxxxxxxxxx
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls