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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux