Re: [tcpm] Review of draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01

["Gregory M. Lebovitz" <[e-mail]>]

inline...

At 04:46 PM 7/26/2009, Eric Rescorla wrote:
>$Id: draft-lebovitz-ietf-tcpm-tcp-ao-crypto-01-rev.txt,v 1.1 
>2009/07/26 22:40:47 ekr Exp $
>
>TECHNICAL
>S 3.1.
>This mixing of the KDF interface and the NIST 800-108 interface
>is extraordinarily confusing.

I'm not sure it's "mixing". Isn't one is a subset of the other? The 
KDF interface is an interface. The NIST thing is the actual 
concatenated construct which fulfills the Context.



>To recap:
>The input to the KDF requires:
>
>- Master Key
>- Context (i.e., the conn-data)

it's not just the Data_Block (updated lingo, per auth-opt-05). In 
order to follow SP800-180, the context is a few things concatenated, 
and Data_Block is one of the things.

>- Output length
>
>Now, as it happens, you're constructing your KDFs a la SP800-108,
>so you then use the relevant PRF with an input block constructed
>as:
>
>            ( i || Label || Context || Output_Length)
>
>But that is not a meaningful part of the interface to the KDF
>as far as AO is concerned. If you were (for instance) to define
>a new TLS PRF based KDF, you would not use i internally because
>the TLS PRF generates an arbitrary length string. Again, it's
>important to distinguish between the TCP-AO requirements and
>what this document happens to do.

I think this document is NOT just the generic interface - that's 
covered in auth-opt-05. This document reminds us of the generic 
interface, and then specifically defines how to do the SHA1 and 
AES-128 KDFs themselves. That's why we made it specific. Maybe I'm 
not understanding you?



>S 3.1.3.
>Wait, I don't remember agreeing to this. I'm happy to use these
>as labels in soem IANA registry, byt people's UI is not our
>business.

This is the years of IKE interop work which motivates this. 
Clarifying the UI representations to make it very easy on operators 
is a good thing. Others opinions on this UI guidance?



>EDITORIAL
>S 2.2.
>
>    The security issues driving the migration from SHA-1 to SHA-256 for
>    digital signatures [HMAC-ATTACK] [HMAC-ATTACK]do not immediately
>    render SHA-1 weak for this application of SHA-1 in HMAC mode.  The
>    security strength of SHA-1 HMACs should be sufficient for the
>    foreseeable future, especially given that the tags are truncated to
>    96 bits.  However, while it's clear that the attacks aren't practical
>    on SHA-1, these types of analysis are mounting and could potentially
>    pose a concern for HMAC forgery if they were significantly improved,
>    over time.  In anticipation of SHA-1's growing less dependable over
>    time, but given its wide deployment and current strength, it is a
>    "MUST" for TCP-AO today.  AES-128 CMAC is considered to be far
>    stronger algorithm, but may not yet have very wide implementation.
>    It is also a "MUST" to implement, in order to drive vendors toward
>    its use.
>
>This is simply not true. It's not at all clear that AES-128-CMAC is
>stronger than HMAC-SHA1, and I don't believe you could get anything
>like a consensus of cryptographers to say that it was. The
>MUST-MUST was taken on the basis of a WG hum. I'm fine with that,
>but this justification needs to be removed.

Since this is others' text, I'll let those others respond.





>S 2.3.
>        (1)  Key Derivation Functions (KDFs) which name a pseudorandom
>             function (PRF) and use a Master_Key and some connection-
>             specific Input with that PRF to produce Conn_Keys, the keys
>             suitable for authenticating and integrity checking
>             individual TCP segments.
>
>This is confusing. KDFs may or may not be constructed with PRFs.
>However, THESE KDFs are so constructed. If you're giong to have
>a document which applies to future KDFs, don't say PRF here.

it does say "which name", not "MUST name". Doesn't this cover your point?




>S 3.1.
>                       An octet of all zeros.  An optional data field
>                       used to indicate a separation of different
>                       variable length data fields.
>
>This is just dangling.

Done.



>    When invoked, a KDF runs a certain PRF, using the Master_Key as the
>    seed, and Input as the message input and produces a result of
>    Output_Length bits.  This result may then be used as a cryptographic
>    key for any algorithm which takes an Output_Length length key as its
>    seed.  A KDF MAY specify a maximum Output_Length parameter.
>
>Again, misplaced concreteness.
>
>
>Woah, I think my numbered list cut and paste here seems needs some
>major re-editing. It was intended for the mailing list, not for
>direct import into the document.

send text.



>S 3.1.1.
>
>It's a mistake to talk about "Output Length" as a property of the KDF.
>In principle, this KDF could generate any output length of your
>choice by using i=0, i=1, etc.. Why are you nailing it down?
>
>
>S 3.1.2.
>I strongly object to the use of this magic key string here.

discussed with Tim Polk. done. We're back to 0^128 as the key in -02.




>S 3.2.
>This whole Conn_Key(KDF) thing is confusing. What's it doing?

Honestly, I thought that was the notation you requested upon review 
of -00... I'll ping you offline.

I'm posting -02 now, because there was naming I needed to update to 
stay in sync with auth-opt-05 anyway.

Thx for the review,
Gregory.




>_______________________________________________
>tcpm mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/tcpm