Re: [Gen-art] Genart last call review of draft-ietf-ipsecme-ikev2-auth-announce-06

[Reese Enghardt <[e-mail]>]

Hi Valery,

Thank you for the response and updates.

Please see inline:

On 4/1/24 06:08, Valery Smyslov wrote:
>> Abstract:
>>
>> As a non-expert reader, the following phrases appear to contradict each other:
>> "indicate the list of supported authentication methods" sounds like different
>> algorithms, "configured with multiple different credentials  to authenticate each
>> other" sounds like different certificates but potentially using the same algorithm. If
>> this proposal is most applicable to scenarios where IKEv2 partners use different
>> algorithms or methods, please consider saying so explicitly in the abstract.
> I'm a bit confused here. My interpretation is that "different credentials" includes the situation
> when these credentials can only be used with specific authentication methods
> (e.g., user may have a certificate and a PSK). So, I believe that the current text
> is adequate, but as a non-native speaker I might have missed some nuances.
> If this is the case, then can you propose a better wording?

No worries. If "different credentials" is commonly understood to include 
different authentication methods, then the text should stay as it is.

>> Please consider adding a sentence as additional motivation for this new
>> mechanism.
> I've added the following sentence to the Introduction:
>
>     Since IKEv2 requires that each peer uses exactly one authentication method
>     and doesn't provide means for peers to
>     indicate to the other side which authentication methods they support,
>     it is possible that in these situations the peer which supports wider
>     range of authentication methods (or authentication token formats)
>     improperly selects the method (or format) which is not supported by
>     the other side.

(Copied text from the thread with Paul)

Thank you, this is a great clarification and works well for me!


>> Section 5:
>>
>> "Note, that this is not a real attack, since NULL authentication should be allowed by
>> local security policy." Why is it not a real attack then? If NULL authentication is
>> allowed among other methods, surely downgrading to NULL authentication is still a
>> problem? Or should the second sentence instead say "NULL authentication should
>> NOT be allowed by local security policy"?
> There is no negotiation of the authentication method to be used in IKEv2,
> thus this is not a "downgrade". If your local policy allows peers to not authenticate
> on their discretion, then it is your choice. If they use NULL authentication
> in this case, they don't violate your policy, thus this is not an real attack.

Thanks, that's a great clarification, I initially missed the "there is 
no negotiation" part. Would you mind adding a sentence to the section, 
please?


Best,
Reese