Re: [tcpm] Test vectors for RFC5925 algorithms?

Hi Juhamatti,

> -----Original Message-----
> From: juhamatk@gmail.com <juhamatk@gmail.com>
> Sent: Thursday, April 2, 2020 9:28 AM
> To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>
> Cc: Joseph Touch <touch@strayalpha.com>; tcpm@ietf.org
> Subject: 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.

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.
> 
> 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