[Swan] SHA2 support for ESP in KLIPS?

[David McCullough]

Paul Wouters wrote the following:
> On Mon, 24 Jun 2013, Elison Niven wrote:
> 
> ># ipsec auto --status shows SHA2 for ESP
> >algorithm ESP auth attr: id=5, name=AUTH_ALGORITHM_HMAC_SHA2_256,
> >keysizemin=256, keysizemax=256
> >algorithm ESP auth attr: id=6, name=AUTH_ALGORITHM_HMAC_SHA2_384,
> >keysizemin=384, keysizemax=384
> >algorithm ESP auth attr: id=7, name=AUTH_ALGORITHM_HMAC_SHA2_512,
> >keysizemin=512, keysizemax=512
> >
> >When I establish a connection using esp=aes128-sha2_256, pluto quits saying:
> >
> >"SHA2" #2: responding to Quick Mode {msgid:98d24ff3}
> >"SHA2" #2: ASSERTION FAILED at ikev1_quick.c:266: case 5 unexpected
> 
> Ugh. Normally those are caught with the default cause. I guess
> KERNEL_ALG is not defined when you compile with OCF?
> 
> David: should the following code always be compiled in, and not
> #ifdef'ed for KERNEL_ALG?

Beats me,  I thought that pluto looked in /proc/net/pf_key_registered or
/proc/net/pf_key_supported to see what was ok for klips.

> 
>                 case AUTH_ALGORITHM_HMAC_MD5:
>                         needed_len += HMAC_MD5_KEY_LEN;
>                         break;
>                 case AUTH_ALGORITHM_HMAC_SHA1:
>                         needed_len += HMAC_SHA1_KEY_LEN;
>                         break;
>                 default:
> #ifdef KERNEL_ALG
>                         if (kernel_alg_esp_auth_ok(pi->attrs.transattrs.
>                                                    integ_hash, NULL) == NULL) {
>                                 needed_len += kernel_alg_esp_auth_keylen(
>                                         pi->attrs.transattrs.integ_hash);
>                                 break;
>                         }
> #endif
>                 case AUTH_ALGORITHM_DES_MAC:
>                         bad_case(pi->attrs.transattrs.integ_hash);
>                         break;
> 
>                 }
> 
> In fact, why are AUTH_ALGORITHM_HMAC_MD5 and AUTH_ALGORITHM_HMAC_SHA1
> specifically named? Shouldn't the "default" case catch those too?

This is probably due to the fact that for cryptoapi,  klips still uses
its own SHA1/MD5.  I'm not so sure I even like KERNEL_ALG appearing in
userspace,  whatever differences we have here should be handled in
kernel_*.c shouldn't they ?

> >Now the SA establishes, but KLIPS is not able to decrypt SHA2
> >(SHA1 works fine) with error :
> 
> >ipsec_sa_getbyid: linked entry in ipsec_sa table for hash=107 of
> >SA:esp.38e80b33 at 10.103.7.155 requested.
> 
> I'll leave that one for David....

Yeah,  that means its probably not handling the larger hash correctly,  I
was expecting this may be the case,  but hoped it would be ok :-)

I'll try and have a look at it this week,

Thanks,
Davidm

-- 
David McCullough,  davidm at spottygum.com,   Ph: 0410 560 763