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

[Valery Smyslov <[e-mail]>]

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",
> <http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-7>.
> 
> NEW
> [IKEV2-IANA]  IANA, "Internet Key Exchange Version 2 (IKEv2) Parameters",
> <https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12>

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec