Re: [IPsec] Paul Wouters' Yes on draft-ietf-ipsecme-ikev2-auth-announce-09: (with COMMENT)

[Valery Smyslov <[e-mail]>]

HI Paul,

thank you for your comments, please see inline.

> Paul Wouters has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-auth-announce-09: Yes
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-
> positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-auth-announce/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Note that the IANA registry involved here was renamed since the latest draft
> was written :)
> 
> Notify Message Type  -> Notify Message Status Type
> 
> "IKEv2 Notify Message Types - Status Types" -> IKEv2 Notify Message Status
> Type

This is already fixed in my local copy (the IANA was so kind to remind me about this change in a personal message :-))

> I wonder if it would make sense to somewhere explain that the authentication
> method refers to the AUTH payload, but that a separate peer ID check with its
> X.509 identity might need to be done, for which the CA cert that signed the EE
> cert could be using a different signature method? For example, the EE-cert
> could be using RSA-v1.5 while the AUTH payload could be using RSA-PSS. Or in
> some other way explain that peer ID proof checking is not "authentication" as
> used in this document?

Hmm... I'm not sure where to put this clarification and in which form.
I think that there is a chance of over-specification, that might add confusion.
You are talking only about signature authentication, and besides that
we have PSK. In addition, IKEv2 doesn't require peer ID to match 
X.509 identity, since they are linked via the local security policy
(i.e., it is the policy, which specify which IDs are acceptable and
which X.509 identities they correspond to, so the strict matching
of them is just a one particular case).
 
If think that this is a real concern, then do you have any concrete text in mind? 

Regards,
Valery.