Subject: [tcpm] Roman Danyliw's No Objection on draft-ietf-tcpm-ao-test-vectors-08: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 02 Mar 2022 10:36:14 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-tcpm-ao-test-vectors-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-ao-test-vectors/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for making this document to help validate implementations.

Thank you to Christian Huitema for the SECDIR review.

I didn’t not validate all of the examples.

** Section 3.1.5.  Since ISNs are part of the context needed to make the
traffic key (per Section 5.2 of RFC5925), should some statement be made about
their values in these example packets?

** Given the observed implementation errors noted in Section 8, consider
including a single detailed example per algorithm of how the appropriate
traffic key and MAC would be computed in an appendix.  For example, considering
Section 4.1.1, such a detailed example showing how to compute the traffic key
could be:

(fixed format font required to read it)

==[ snip ]==
Master_key: "testvector" (74 65 73 74 76 65 63 74 6F 72)
KDF_Alg: KDF_HMAC_SHA1
IPv4/TCP Packet:

     45 e0 00 4c dd 0f 40 00 ff 06 bf 6b 0a 0b 0c 0d
     ac 1b 1c 1d e9 d7 00 b3 fb fb ab 5a 00 00 00 00
     e0 02 ff ff ca c4 00 00 02 04 05 b4 01 03 03 08
     04 02 08 0a 00 15 5a b7 00 00 00 00 1d 10 3d 54
     2e e4 37 c6 f8 ed e6 d7 c4 d6 02 e7

Source IP (sip): 10.11.12.13 (0A 0B 0C 0D)
Destination IP (dip): 172.27.28.29 (AC 1B 1C 1D)
Source Port (sport): 59863 (E9 D7)
Destination Port (dport): 179 (00 B3)
Source ISN (sisn): FB FB AB 5A
Destination ISN (disn): 00 00 00 00

Send_SYN_traffic_key
= KDF_alg(master_key, input)
= HMAC-SHA1(master_key, i || Label || Context || Output_Length)

i = 1 (01)
Label= TCP-AO (54 43 50 2D 41 4F)
Context = sip || dip || sport || dport || sisn || disn
        = 0A 0B 0C 0D AC 1B 1C 1D E9 D7 00 B3 FB FB AB 5A 00 00 00 00
Output_Length = 160 bits (00 A0)

Send_SYN_traffic_key
= HMAC-SHA1 ( 74 65 73 74 76 65 63 74 6F 72,
              01 54 43 50 2D 41 4F 0A 0B 0C 0D AC 1B 1C 1D E9 D7
              00 B3 FB FB AB 5A 00 00 00 00 00 A0 )
= 6d 63 ef 1b 02 fe 15 09 d4 b1 40 27 07 fd 7b 04 16 ab b7 4f
==[ snip ]==

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 2 Mar 2022 15:06:31 -0800

Hi, Roman,

Thanks for your review. Comments below.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Mar 2, 2022, at 10:36 AM, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 

Yes - thanks for catching that; v09 will address this issue and correct the text in the known issues area (which is confusing on this point). 

> Section 4.1.1, such a detailed example showing how to compute the traffic key

Thanks - that’s a great suggestion. I’ll add that too.

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 3 Mar 2022 19:16:11 -0800

Hi, Roman,

On the two points below, I discussed it with Juhamatti and we have an updated response:

- the ISNs will be listed at the front of each section, for convenience

- HOWEVER, the test vectors are the definitive information; it is important only that they be verified. It is not typical for most TCP implementations to easily control the ISN, so these are NOT intended as configurations. However, if they were used as such, we provide the ISNs that would be used for configuration.

- as to the specific information on how to compose the information to create the MKT PRF inputs, it seems prudent to not provide that as an example. Such duplication of information from RFC 5926 provides implementation details that should never be necessary in practice. These vectors are for testing code only

As a result, the update just issued includes the ISNs in each section but omits the detail on how the connection info is composed to create the MKT input.

Please let us know if these postions are problematic or would like to discuss them further.

Joe

—

> On Mar 2, 2022, at 3:06 PM, [email-masked] wrote:
> 
> Hi, Roman,
> 
> www.strayalpha.com <http://www.strayalpha.com/>
> 
>> On Mar 2, 2022, at 10:36 AM, Roman Danyliw via Datatracker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ <https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/> 
>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-ao-test-vectors/ <https://datatracker.ietf.org/doc/draft-ietf-tcpm-ao-test-vectors/>
>> 
>> 
>>