[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] draft-urien-tls-keygen-00.txt
Title: Re: [TLS] draft-urien-tls-keygen-00.txt
> 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.
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" <Pascal.Urien@xxxxxxx <Pascal.Urien@xxxxxxxx> > 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 <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 <Pascal.Urien@xxxxxxxx> > 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 <TLS@xxxxxxxx>
> >> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
_______________________________________________
TLS mailing list
TLS@xxxxxxxx <TLS@xxxxxxxx>
https://www.ietf.org/mailman/listinfo/tls
--
Regards,
Uri
_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls