[Swan-dev] the great algorithm rename

[Andrew Cagney]

On 22 June 2017 at 15:05, Paul Wouters <paul at nohats.ca> wrote:
> On Thu, 22 Jun 2017, Andrew Cagney wrote:
>
>> A two part "trivial" change I've had sitting here for some time is to
>> update logging so that algorithm names are more consistently qualified
>> and upper case.  For instance:
>>
>>    cipher: camellia -> CAMELLIA_CBC
>>    prf: sha -> HMAC_SHA1
>>    integ: sha2_256 -> HMAC_SHA2_256_128 (lets ignore truncbug for now)
>
>
> works for me, might need some prefix_stripping for readability.

I'd really like to get away from stripping prefixes and suffixes in
the output logs as it leads to ambiguous names.

>> -134 "ikev2-ike=aes128-sha1" #4: STATE_PARENT_I2: sent v2I2, expected
>> v2R2 {auth=IKEv2 cipher=aes_128 integ=sha1_96 prf=sha group=MODP2048}
>> +134 "ikev2-ike=aes128-sha1" #4: STATE_PARENT_I2: sent v2I2, expected
>> v2R2 {auth=IKEv2 cipher=AES_CBC_128 integ=HMAC_SHA1_96 prf=HMAC_SHA1
>> dh=MODP2048}
>
>
> While we are at it, I think "sent v2I2" should be replaced with "sent
> IKE_AUTH request" and similarly "sent IKE_AUTH reply" and that we use
> the exchange names properly.

I'll look, I suspect it is a different printf.

>> (I've got to wonder if the meaningless auth=IKEv2 should also be stripped
>> out)
>
>
> That is legacy mostly. In IKEv1, the IKE header told you if you were
> doing RSA or PSK, and that info displayed there. In IKEv2, that information
> is not in the IKE header, but inside the IKE_AUTH payload, so the code
> just writes "IKEv2" there. It should really pull the data from elsewhere
> and put in PSK, RSA, NULL or even NULL|RSA for asymmetric auth.

Does it know?  Only the INIT packets have been exchanged.

>> - for IKEv1 things are similar:
>>
>> -004 "westnet-eastnet-aggr" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA
>> established {auth=RSA_SIG cipher=3des_cbc_192 integ=sha
>> group=MODP1536}
>> +004 "westnet-eastnet-aggr" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA
>> established {auth=RSA_SIG cipher=3DES_CBC_192 integ=HMAC_SHA1_96
>> dh=MODP1536}

The above example is wrong, the new output for IKEv1 would be ... prf=HMAC_SHA1
but I'm not sure how IKEv1 that term is.

> Okau.
>
>> Part 2 then follows this up by replacing the IKEv1 centric
>> enum_show_shortb() calls found in ike_info.c and esp_info.c:
>>
>>                        "%s(%d)_%03d-%s(%d)-%s(%d)",
>>                        enum_show_shortb(&oakley_enc_names,
>>
>> ike_info->ike_encrypt->common.ikev1_oakley_id,
>>                                         &enc_buf),
>>                        ike_info->ike_encrypt->common.ikev1_oakley_id
>>
>> with ike_info->encrypt->common.name (et.al.).  The result is:
>>
>> -IKE algorithms found:  AES_CBC(7)_256-SHA2_256(4)-MODP2048(14)
>> +IKE algorithms found:  AES_CBC_256-HMAC_SHA2_256-MODP2048
>>
>> and, unlike before, the new output can be fed straight back into the
>> parser!
>
>
> Sounds good.
>
>> Hopefully I'll be able to push this in a few weeks,
>
>
> After v3.21 would be nice :)

Yea.