Orie Steele has entered the following ballot position for draft-ietf-ipsecme-ikev2-auth-announce-09: No Objection
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: ---------------------------------------------------------------------- # Orie Steele, ART AD, comments for draft-ietf-ipsecme-ikev2-auth-announce-09 CC @OR13 https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-auth-announce-09.txt&submitcheck=True ## Comments Thanks to Marc Blanchet for the ARTART review, and to Valery for addressing his feedback. ``` 175 then the responder MAY choose not to send actual list of the 176 supported authentication methods in the IKE_SA_INIT exchange and 177 instead ask the initiator to start the IKE_INTERMEDIATE exchange for 178 the list to be sent in. ``` Why not "SHOULD not send..."? ``` 189 the SUPPORTED_AUTH_METHODS notification. Otherwise, the initiator 190 MAY start the IKE_INTERMEDIATE exchange just for this sole purpose by 191 sending an empty IKE_INTERMEDIATE request. The initiator MAY also 192 indicate its identity (and possibly the perceived responder's 193 identity too) by including the IDi payload (possibly along with the 194 IDr payload) into the IKE_INTERMEDIATE request. This information 195 could help the responder to send back only those authentication 196 methods, that are configured to be used for authentication of this 197 particular initiator. If these payloads are sent, they MUST be 198 identical to the IDi/IDr payloads sent later in the IKE_AUTH request. ``` Why not SHOULD instead of MAY? ``` 226 HDR, SAi1, KEi, Ni --> 227 <-- HDR, SAr1, KEr, Nr, [CERTREQ,] 228 [N(SUPPORTED_AUTH_METHODS)()] 230 HDR, SK {..., [IDi, [IDr,]]} --> 231 <-- HDR, SK {..., [CERTREQ,] 232 [N(SUPPORTED_AUTH_METHODS)(...)] } ``` Is the "()" vs "(...)" significant, or meant to indicate the empty IKE_INTERMEDIATE ? What does "(...)" expand to? ``` 347 Signature" (1), "DSS Digital Signature" (3), "ECDSA with SHA-256 on 348 the P-256 curve" (9), "ECDSA with SHA-384 on the P-384 curve" (10) 349 and "ECDSA with SHA-512 on the P-512 curve" (11). Note however, that 350 these authentication methods are currently superseded by the "Digital 351 Signature" (14) authentication method, which has a different ``` I think you mean P-521 curve, also known as secp521r1. ## Nits ``` 531 This appendix shows some examples of announcing authentication 532 methods. This appendix is purely informative; if it disagrees with 533 the body of this document, the other text is considered correct. ``` You will see errata filed either way... I recommend omitting the second sentence. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
