Re: [IPsec] AD Review of draft-ietf-ipsecme-ikev2-auth-announce-04

[Valery Smyslov <[e-mail]>]

HI Roman!

> Hi Valery!
> 
> Thanks for -05.  Reducing the thread down to areas of discussion.
> 
> > -----Original Message-----
> > From: Valery Smyslov <[e-mail]>
> > Sent: Thursday, October 26, 2023 11:51 AM
> > To: 'Roman Danyliw' <[e-mail]>; [e-mail]
> > Subject: Re: [IPsec] AD Review of draft-ietf-ipsecme-ikev2-auth-announce-04
> 
> [snip]
> 
> > > ** Section 5.  Please add the Security Considerations of the specifically
> > negotiated auth methods apply.
> >
> > This is not a negotiation, this is announcement, just to help the other side to
> > correctly choose among several possible methods. Since this is a hint,
> > implementations may use it as other hints that are already available (e.g. CAs
> > from CERTREQ). Thus I'm not sure what specifically should be added to the
> > Security Considerations section. Do you have some proposed text?
> 
> I was looking primarily for a reminder that the different methods being suggested each have their own
> security considerations.

I think we can add the following text:

Security properties of different authentication methods varies.
Refer to corresponding documents, listed in [IKEV2-IANA] for 
discussion of security properties of each authentication method.

Note, that announcing authentication methods gives an eavesdropper
additional information about peers capabilities. If a peer advertises 
NULL authentication along with other methods, then active attacker 
on the path may force to use NULL authentication by removing
all other announcements. Note, that this is not a real attack, since
NULL authentication should be allowed by local security policy.
 
Regards,
Valery.

> > > ** Section 6.  The “Notify Message Types - Status Types” registry has
> > > three fields.  Please formally say that this document should be the reference.
> >
> > Done.
> >
> > I also have off-the-list conversation with Daniel Van Geest, who made some
> > good proposals, which I would also like to include in the draft if the WG agrees.
> >
> > 1. Specify that auth announcements are included into the
> > SUPPORTED_AUTH_METHODS notification
> >     in the order of their preferences for the sender. This doesn't break anything
> > (the receiver is free to ignore the order),
> >     but might help it to make the best choice.
> >
> > 2. Clarify that peers may send the SUPPORTED_AUTH_METHODS independently
> > of whether it was received
> >     (this is not a negotiation). This is what actually the draft says now, just stress
> > this for clarification.
> >
> > 3. Specify interaction with RFC 4739 (Multiple Authentication Exchanges in the
> > Internet Key Exchange (IKEv2) Protocol).
> >     In particular. allow sending multiple SUPPORTED_AUTH_METHODS
> > notifications in a message
> >     (also add a clarification that if multiple SUPPORTED_AUTH_METHODS
> > notifications are included in a message
> >      and the receiver doesn't know why, the all included announcements form a
> > single list).
> 
> I see this proposed text is in -05.
> 
> WG chairs: can you please check that this has consensus of the WG.
> 
> Thanks,
> Roman