Re: [tcpm] Test vectors for RFC5925 algorithms?

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 am not familiar with Juniper).

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 Internet Draft. And TCPM is usually quite open to new work.

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

> Michael

Thanks,
--
 Juhamatti

> > -----Original Message-----
> > From: tcpm <tcpm-bounces@ietf.org> On Behalf Of juhamatk@gmail.com
> > Sent: Wednesday, April 1, 2020 9:30 AM
> > To: Joseph Touch <touch@strayalpha.com>
> > Cc: tcpm@ietf.org
> > Subject: Re: [tcpm] Test vectors for RFC5925 algorithms?
> >
> > 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, juhamatk@gmail.com 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
> > > > tcpm@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/tcpm
> > >
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm