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

[Valery Smyslov]

HI Roman!

> Hi Valery!
> 
> Thanks for -05.  Reducing the thread down to areas of discussion.
> 
> > -Original Message-
> > From: Valery Smyslov 
> > Sent: Thursday, October 26, 2023 11:51 AM
> > To: 'Roman Danyliw' ; ipsec@ietf.org
> > 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

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Roman Danyliw]

Hi Valery!

Thanks for -05.  Reducing the thread down to areas of discussion.

> -Original Message-
> From: Valery Smyslov 
> Sent: Thursday, October 26, 2023 11:51 AM
> To: 'Roman Danyliw' ; ipsec@ietf.org
> 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.  
 
> > ** 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
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul Wouters]

On Oct 26, 2023, at 18:26, Tero Kivinen  wrote:
> 
> 
> Of course, we could require that in the future all specs are written
> by AI, and that AI MUST follow all MUST rules set in previous RFCs :-)

The only winning move is not to play.___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Tero Kivinen]

Valery Smyslov writes:
> > ** Section 3.2
> > 
> > If more authentication methods are defined in future, the
> > corresponding documents must describe the semantics of the
> > announcements for these methods.
> > 
> > -- Should this be a s/must/MUST?
> 
> With my understanding of using BCP14 language, these keywords are
> usually concerned with protocols behavior. In this case the "must"
> is concerned with human (document authors) behavior :-)
> 
> That said, I understand that this may be interpreted differently, so
> if you think "MUST" is more appropriate here than "must", I'll be
> happy to make the change.

I think lowercase must is correct, as this is not protocol issue. 

I have also had a customers to come to me asking me which specific
lines of code implement every single MUST/SHOULD etc.

I already had difficulties to explaining which lines of code implement
some of the MUST NOTs, but it would be even harder to explain which
line of code implements the MUST given to future spec writers...

Of course, we could require that in the future all specs are written
by AI, and that AI MUST follow all MUST rules set in previous RFCs :-)

Ah, I just realized that does not work, as there is no way to give the
lines of code that implement that requirement in the AI...
-- 
kivi...@iki.fi

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Paul Wouters]

On Thu, 26 Oct 2023, Valery Smyslov wrote:


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).


(speaking as individual)

I'm okay with these changes.

Paul

___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Valery Smyslov]

Hi Roman,

thank you for your review, please see inline.

> Hi!
> 
> I performed an AD review of draft-ietf-ipsecme-ikev2-auth-announce-04.  
> Thanks for the work on this
> document.  I have the following feedback:
> 
> 
> ** Section 3.1
> If the initiator is configured to use Extensible Authentication Protocol 
> (EAP) for authentication in IKEv2
> (see Section 2.16 of [RFC7296]), then it SHOULD NOT send the 
> SUPPORTED_AUTH_METHODS
> notification.
> 
> -- Since SHOULD NOT vs. MUST NOT is used, under what circumstances would it 
> be appropriate to use
> EAP + SUPPORTED_AUTH_METHODS?

I was thinking that this might simplify implementations (initiator may always 
send this notify, responder will just ignore it).

But thinking more about this, I now understand, that this paragraph is 
incorrect and should be removed at all.
For the reason, that the sender of  SUPPORTED_AUTH_METHODS announces which auth 
methods it is ready
to accept as verifier, and in IKEv2 even in case of EAP the server (responder) 
always send AUTH payload
to authenticate itself to the initiator (which is done before the EAP starts). 
So, even in case of EAP
the initiator should verify the responder's identity using AUTH payload, thus 
sending SUPPORTED_AUTH_METHODS is OK.

> ** Section 3.2
> 
> If more authentication methods are defined in future, the corresponding 
> documents must describe the
> semantics of the announcements for these methods.
> 
> -- Should this be a s/must/MUST?

With my understanding of using BCP14 language, these keywords are usually 
concerned
with protocols behavior. In this case the "must" is concerned with human 
(document authors) behavior :-)

That said, I understand that this may be interpreted differently, so if you 
think
"MUST" is more appropriate here than "must", I'll be happy to make the change.

> ** Section 3.2
> The blob always starts with an octet containing the length of the blob 
> followed by an octet containing
> the authentication method. Authentication methods are represented as values 
> from the "IKEv2
> Authentication Method" registry defined in [IKEV2-IANA].
> 
> -- The reference in [IKEV2-IANA] is incorrect.  It should be pointing to 
> Parameter 12.
> 
> OLD
> [IKEV2-IANA]
> IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters",
> .
> 
> NEW
> [IKEV2-IANA]  IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters",
> 

Fixed, thank you.

> ** Section 3.2.3.  Please provide a normative reference DER.  I believe it is:
> 
>[X.690]ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
>   Information technology - ASN.1 encoding rules:
>   Specification of Basic Encoding Rules (BER), Canonical
>   Encoding Rules (CER) and Distinguished Encoding Rules
>   (DER).

Done (also added a reference to RFC 5280 for AlgorithmIdentifier, followed what 
is in RFC 7427).

> ** 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?

> ** 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).

Since the I-D submission is closed, the diff file is included with this message.

Regards,
Valery.

> Thanks,
> Roman
> ___
> IPsec mailing list
> IPsec@ietf.org
> 

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

[Roman Danyliw]

Hi!

I performed an AD review of draft-ietf-ipsecme-ikev2-auth-announce-04.  Thanks 
for the work on this document.  I have the following feedback:


** Section 3.1
If the initiator is configured to use Extensible Authentication Protocol (EAP) 
for authentication in IKEv2 (see Section 2.16 of [RFC7296]), then it SHOULD NOT 
send the SUPPORTED_AUTH_METHODS notification.

-- Since SHOULD NOT vs. MUST NOT is used, under what circumstances would it be 
appropriate to use EAP + SUPPORTED_AUTH_METHODS?

** Section 3.2

If more authentication methods are defined in future, the corresponding 
documents must describe the semantics of the announcements for these methods.

-- Should this be a s/must/MUST?

** Section 3.2
The blob always starts with an octet containing the length of the blob followed 
by an octet containing the authentication method. Authentication methods are 
represented as values from the "IKEv2 Authentication Method" registry defined 
in [IKEV2-IANA].

-- The reference in [IKEV2-IANA] is incorrect.  It should be pointing to 
Parameter 12.

OLD
[IKEV2-IANA]
IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters", 
.

NEW
[IKEV2-IANA]  IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters",


** Section 3.2.3.  Please provide a normative reference DER.  I believe it is:

   [X.690]ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
  Information technology - ASN.1 encoding rules:
  Specification of Basic Encoding Rules (BER), Canonical
  Encoding Rules (CER) and Distinguished Encoding Rules
  (DER).

** Section 5.  Please add the Security Considerations of the specifically 
negotiated auth methods apply.

** Section 6.  The “Notify Message Types - Status Types” registry has three 
fields.  Please formally say that this document should be the reference.

Thanks,
Roman
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec