Subject: Re: [tcpm] Test vectors for RFC5925 algorithms?

From: [email-masked]
Date: Wed, 1 Apr 2020 10:30:02 +0300

Hello Joe,

> At best, those might be an addendum to RFC 5926. RFC 5925 deliberately does not specify any algorithms.

Thanks for your reply. Addendum to RFC 5926 sounds really good to me.

> However, TCP MD5 was widely deployed without any such test vectors in the RFC series (or elsewhere I could find, FWIW).

True. Still, RFC 2385 is only 4 pages long and implementation is very
simple. It had wide deployment from the beginning, I believe, so it
was easy to make implementations match.

I am currently working on a proprietary implementation of RFC
5925/5926. Even though the RFCs are ten years old, they have only a
few existing implementations. Test equipment vendors (IXIA, Spirent)
do not support it. Juniper does not use it, they seem to use their own
proprietary version. One fuzzing vendor seems to have HMAC-SHA1
implemented, but it is unclear is it according to the RFCs.
Guaranteeing interop looks quite difficult at the moment.

So if test vectors already exist somewhere (maybe unpublished), or
someone is willing to create them for the addendum draft referenced
above, I am certainly willing to verify them against my implementation
and report back.

> Joe

Thanks,
--
 Juhamatti

>
> > On Mar 31, 2020, at 3:44 AM, [email-masked] wrote:
> >
> > Hello,
> >
> > I have been searching for test vectors for RFC5925/5926 algorithms for
> > TCP AO and to my surprise it seems that such do not exist. Am I
> > correct here?
> >
> > Even though test vectors for HMAC SHA1 (RFC2202) and AES CMAC
> > (RFC4493) are available, it would be useful to have example test
> > vectors for frames using TCP AO - otherwise implementations end up
> > easily not to match. As RFC5925 is 47 pages, there is a room for error
> > and only one mismatch is needed for MACs not to match.
> >
> > I think publishing a new RFC for them would be good, but probably
> > takes some time. Even unofficial, but verified, test vectors on some
> > specified example frames (with and without TCP options), e.g. on this
> > mailing list or otherwise, would be a very good start to get TCP AO
> > more widely implemented. If such already are available somewhere,
> > please do let me know.
> >
> > Thanks,
> > --
> > Juhamatti
> >
> > _______________________________________________
> > tcpm mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: "Scharf, Michael" <[email-masked]>
Date: Wed, 1 Apr 2020 08:03:43 +0000

Have you checked other router vendors? For instance, the public Cisco IOS XE documentation lists TCP-AO support. And I have also heard that another main router vendor may implement TCP-AO (well, I am not familiar with Juniper). 

BTW, if there is some gap in the RFC series, the usual IETF process is just starting a new Internet-Draft, instead of waiting for somebody else to write something. It is not complex to write an Internet Draft. And TCPM is usually quite open to new work.

Michael

> -----Original Message-----
> From: tcpm <[email-masked]> On Behalf Of [email-masked]
> Sent: Wednesday, April 1, 2020 9:30 AM
> To: Joseph Touch <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [tcpm] Test vectors for RFC5925 algorithms?
> 
> Hello Joe,
> 
> > However, TCP MD5 was widely deployed without any such test vectors in the
> RFC series (or elsewhere I could find, FWIW).
>

---

From: [email-masked]
Date: Thu, 2 Apr 2020 10:27:57 +0300

Hello Michael,

> Have you checked other router vendors? For instance, the public Cisco IOS XE documentation lists TCP-AO support. And I have also heard that another main router vendor may implement TCP-AO (well, I…

I am aware that Cisco has an implementation. It is quite new, and
unfortunately I do have experience of it. If someone has, then that
may well be a very good candidate for test vectors.

> BTW, if there is some gap in the RFC series, the usual IETF process is just starting a new Internet-Draft, instead of waiting for somebody else to write something. It is not complex to write an Int…

I am not that familiar with the draft process. I agree that if test
vectors do not already exist, that may be the best path to go forward.
Here below is a draft outline that perhaps provides the information
needed to ensure compatible implementations. If there is some
consensus that proceeding with this would be useful, perhaps we can
use it as a starting point. We need to fill the verified test vectors
there eventually.

Test Vectors for Cryptographic Algorithms of the TCP Authentication
Option (TCP-AO)
-
Introduction
Key Derivation Functions Test Vectors
 * KDF_HMAC_SHA1
   - A test TCP/IP frame: syn snd key output
   - A test TCP/IP frame: syn rcv key output
   - A test TCP/IP frame: other snd key output
   - A test TCP/IP frame: other rcv key output
 * KDF_AES_128_CMAC
   - A test TCP/IP frame: syn snd key output
   - A test TCP/IP frame: syn rcv key output
   - A test TCP/IP frame: other snd key output
   - A test TCP/IP frame: other rcv key output
MAC Algorithms Test Vectors
 * HMAC-SHA-1-96
   - A test key with test TCP/IP frame: MAC output, MAC output without options
 * AES-128-CMAC-96
   - A test key with test TCP/IP frame: MAC output, MAC output without options
Security Considerations
Acknowledgements
References

Thanks,
--
 Juhamatti

---

From: Joseph Touch <[email-masked]>
Date: Thu, 2 Apr 2020 08:18:39 -0700

Hi, Juhamatti,

If you can provide the test vectors, I can prepare them into an Internet Draft with you. But let’s start with the first step and make sure all the pieces are in place first.

If you want to proceed that way, please contact me directly and we can go from there.

Joe

> On Apr 2, 2020, at 12:27 AM, [email-masked] wrote:
> 
> Hello Michael,
>

---

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 16 Apr 2020 16:31:41 +0000

Hi Juhamatti,

> From: [email-masked] <[email-masked]>
> Sent: Thursday, April 2, 2020 9:28 AM
> To: Scharf, Michael <[email-masked]>
> Cc: Joseph Touch <[email-masked]>; [email-masked]
> > Have you checked other router vendors? For instance, the public Cisco IOS XE
> documentation lists TCP-AO support. And I have also heard that another main
> router vendor may implement TCP-AO (well, I am not familiar with Juniper).
> 

Coming back to this, as I have just found another document: According to reference [1], Nokia SROS implements TCP-AO as well.

Michael

[1] Nokia SROS documentation at https://documentation.nokia.com/cgi-bin/dbaccessfilename.cgi/3HE15811AAAATQZZA01_V1_7450%20ESS%207750%20SR%207950%20XRS%20and%20VSR%20Basic%20System%20Configuration%20Guide%2020.2.R1.pdf

> 
> > BTW, if there is some gap in the RFC series, the usual IETF process is just
> starting a new Internet-Draft, instead of waiting for somebody else to write
> something. It is not complex to write an Internet Draft. And TCPM is usually
> quite open to new work.
>

---

From: [email-masked]
Date: Fri, 17 Apr 2020 09:20:22 +0300

Hello Michael,

> Coming back to this, as I have just found another document: According to reference [1], Nokia SROS implements TCP-AO as well.

Thanks! RFC 5925 and RFC 5926 are indeed listed as supported. Not many
configuration examples, though. As with Cisco, I do not personally
have experience of Nokia products. As Nokia SROS seems to have support
at some level, it may well be another candidate for test vectors.

--
 Juhamatti