Herbert:
Can you confirm the following. Thanks.
Rfc2404 - The Use of HMAC-SHA-1-96 within ESP and AH
For the support, I can't find any algorithm to be specified in the .craname of ahash_alg for Rfc2404.
From
http://www.freebsd.org/cgi/man.cgi?query=setkey&sektion=8
it says the following :
ALGORITHMS
The following list shows the supported algorithms. The protocol and algorithm are almost completely orthogonal. The following list of authentication algorithms can be used as aalgo in the -A aalgo of the protocol parameter:
algorithm keylen (bits) comment
hmac-sha1 160 ah: rfc2404
That leads me to believe, from crypto driver stand point, there is no need to have a new algorithm for hmac-sha-1-96 support. Instead, the agent SW(such as ipsec) should use "hmac(sha1)", and do the truncation of digested data from 160 bits to 96 bits.
I run a quick test. The input file to setkey command is defined as such ----
flush;
spdflush;
add 10.2.243.75 10.2.243.29 ah 0x604 -A hmac-sha1 0x8D967D88F6CAA9D714800AB3D48051D63F73A312;
add 10.2.243.29 10.2.243.75 ah 0x605 -A hmac-sha1 0x8D967D88F6CAA9D714800AB3D48051D63F73A314;
spdadd 10.2.243.75 10.2.243.29 any -P in ipsec ah/transport//use;
spdadd 10.2.243.29 10.2.243.75 any -P out ipsec ah/transport//use;
I use tcpdump. Clearly I can see 24 bytes of AH header of the ipsec packets. The header has 12 bytes of fixed information - Next (1), Ah len (1) ,Reserved (2), Spi (4) ,Sequence (4), and Auth result. (12 bytes)
Can you confirm the above? Thanks.
Regards,
Chemin
On Wed, Sep 11, 2013 at 07:16:13PM +0000, Hsieh, Che-Min wrote:
> Herbert:
>
> Can you confirm the following. Thanks.
>
> Rfc2404 - The Use of HMAC-SHA-1-96 within ESP and AH
>
> For the support, I can't find any algorithm to be specified in the .craname of ahash_alg for Rfc2404.
>
> From
> http://www.freebsd.org/cgi/man.cgi?query=setkey&sektion=8
> it says the following :
>
> ALGORITHMS
> The following list shows the supported algorithms. The protocol and algorithm are almost completely orthogonal. The following list of authentication algorithms can be used as aalgo in the -A aalgo of the protocol parameter:
>
> algorithm keylen (bits) comment
>
> hmac-sha1 160 ah: rfc2404
>
>
> That leads me to believe, from crypto driver stand point, there is no need to have a new algorithm for hmac-sha-1-96 support. Instead, the agent SW(such as ipsec) should use "hmac(sha1)", and do the truncation of digested data from 160 bits to 96 bits.
>
> I run a quick test. The input file to setkey command is defined as such ----
>
> flush;
> spdflush;
> add 10.2.243.75 10.2.243.29 ah 0x604 -A hmac-sha1 0x8D967D88F6CAA9D714800AB3D48051D63F73A312;
> add 10.2.243.29 10.2.243.75 ah 0x605 -A hmac-sha1 0x8D967D88F6CAA9D714800AB3D48051D63F73A314;
> spdadd 10.2.243.75 10.2.243.29 any -P in ipsec ah/transport//use;
> spdadd 10.2.243.29 10.2.243.75 any -P out ipsec ah/transport//use;
>
>
> I use tcpdump. Clearly I can see 24 bytes of AH header of the ipsec packets. The header has 12 bytes of fixed information - Next (1), Ah len (1) ,Reserved (2), Spi (4) ,Sequence (4), and Auth result. (12 bytes)
>
>
> Can you confirm the above? Thanks.
Yes, see net/xfrm/xfrm_algo.c.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt