RE: [saag] [Cfrg] Re: TCP-AO MAC algorithms

Thank you, Stephen,

>Sure.
>FIPS 140-x evaluation of crypto modules generally will NOT encompass 
>implementation of mechanisms used for anti-replay, e.g., the sequence 
>numbers used in IPsec or in TCP. This is because these mechanisms are 
>not part of a crypto algorithm definition. However, if these same 
>values are used as inputs to crypto algorithms, e.g., a MAC algorithm 
>or a confidentiality algorithm such as counter mode encryption, THEN 
>they become part of the evaluated code/hardware base. So, if one were 
>to use TCP sequence numbers in a MAC algorithm, and the algorithm 
>required the numbers to be unique, then all aspects of TCP sequence 
>number management would become part of the evaluated code base. In 
>general, one tries to minimize the size of the evaluated code and 
>hardware, to increase likelihood that the evaluation will succeed, to 
>reduce the need for re-evaluation when any of the evaluated 
>code/hardware changes, etc.

>This observation caused IPsec to decide to NOT reuse its anti-replay 
>sequence numbers for counter-mode encryption. Rather IPsec requires 
>carriage of the counter-mode, per-packet value in each packet header.

Here I agree that carrying the nonce (or an index/counter for nonce) with
the MAC is a good way for a nonce MAC algorithm to get express pass from
fips.

Sean

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg