Subject: Re: [tcpm] DISCUSS and COMMENT: draft-ietf-tcpm-tcp-ao-crypto

From: Gregory Lebovitz <[email-masked]>
Date: Wed, 24 Mar 2010 01:49:07 -0700

Thanks for the review, Pasi. The changes indicated below will be issued
shortly in a -03 (along with Magnus SecDir review, Avshalom Houri's GenArt
review, and Alfred H's reviews. See inline...

On Wed, Mar 10, 2010 at 1:49 PM, Pasi Eronen <[email-masked]> wrote:

> Discuss:
>
> I have reviewed draft-ietf-tcpm-tcp-ao-crypto-02, and have couple of
> small concerns that I'd like to discuss before recommending approval
> of the document:
>
> - In other contexts where manually configured pre-shared keys are
> used, it has been found useful to specify some minimum requirements
> for management interfaces -- i.e. how the human-readable/entered input
> is converted to the octet string. For example, here's what
> draft-ietf-bfd-base said about this:
>
>   For interoperability, the management interface by which the
>   password is configured MUST accept ASCII strings, and SHOULD also
>   allow for the configuration of any arbitrary binary string in
>   hexadecimal form.  Other configuration methods MAY be supported.
>

Good catch. Your suggested text was added into:  the definition of
"Master_Key" in s3.1 "Key Derivation Functions", and I changed "password" to
"PSK", to fit the context.

>
> Something similar would be needed here, IMHO (and BTW, I don't think
> mandating support for UTF-8 or SASLprep is needed in this context).
>
> - It looks like many of the informative references need to be normative.
> At the very least, RFC 4493 (or NIST-SP800-38B, depending on which you
> prefer)

have replaced all instances of 4493 with NIST-SP800-38B

> and RFC 2104;

2104 moved to Normative

> and normative references to AES (FIPS 197)

added to Normative

> and
> SHA-1 (FIPS 180-3) are needed, too.
>

added to Normative

>
> - Section 3.1.1, "based on PRF-HMAC-SHA1 [RFC2404]": the pointer to
> RFC2404 here doesn't sound quite right (2404 doesn't define any PRFs;
> it's just one protocol that happens to use HMAC-SHA1). Perhaps just
> "based on HMAC-SHA1 [RFC2104][180-3]" would be sufficient? (also
> applies to pointers in 2.2, 3.1.1.1, and 3.2)
>

done, in all mentioned sections. removed 2404 from document.

>
> - Section 3.1.1, "based on AES-CMAC-PRF-128 [RFC4615]": This is also
> confusing, since the PRF in RFC 4615 uses a very different
> construction. Perhaps just "based on AES-CMAC [800-38B][FIPS197]"?
> (also applies to pointer in 3.1.1.2 )
>

done.

>
> - Section 3.1.1: "not an even multiple of the output size" initially
> confused me (why an odd multiple is not allowed?). "exact multiple",
> perhaps?
>

changed

>
> Comment:
>
> Idnits finds some missing/erronous references

remove the unused references

> (which really ought to
> have been fixed before sending this to IETF last call...)
>

agreed. Sorry about that.

Gregory

-- 
----
IETF related email from
Gregory M. Lebovitz
Juniper Networks