Orie Steele has entered the following ballot position for draft-ietf-emu-rfc7170bis-16: 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-emu-rfc7170bis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Orie Steele, ART AD, comments for draft-ietf-emu-rfc7170bis-16 CC @OR13 https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-16.txt&submitcheck=True Thanks for this document. I'm not familiar with EAP or TEAP, please keep this in mind when reviewing my comments. ## Comments ### Why SHOULD use private CA? ``` 561 included, but their use is discouraged. Systems SHOULD use a private 562 Certification Authority (CA) for EAP in preference to public CAs. ``` Perhaps the answer is obvious to experts, but I wondered what interoperability issue this addresses. ### Why not MUST? ``` 896 Implementations SHOULD limit the permitted inner EAP methods to a 897 small set such as EAP-TLS, EAP-MSCHAPv2, and perhaps EAP-pwd. There 898 are few reasons for allowing all possible EAP methods to be used in 899 Phase 2. ``` I wonder if there are really any reasons to allow all possible methods, and what impact they have on interop. ### Updates RFC9427? ``` 907 methods which can tunnel other EAP methods. As a result, this 908 document updates [RFC9427]. ``` Consider updating the abstract to reflect this: ``` 20 server. This document obsoletes RFC 7170 [and updates RFC 9427]. ``` ### Can this MAY be strengthened to a SHOULD? ``` 1142 current inner method. The side receiving a non-fatal Error TLV 1143 MAY decide to start a new inner method instead or to send back a 1144 Result TLV to terminate the TEAP authentication session. ``` ### NAK TLV Optionality ``` 1524 optional, it can ignore the unsupported TLV. It MUST NOT send a NAK 1525 TLV for a TLV that is not marked mandatory. If all TLVs in a message 1526 are marked optional and none are understood by the peer, then a NAK 1527 TLV or Result TLV could be sent to the other side in order to 1528 continue the conversation. ``` This section might be improved by eliminating the double negative: MUST NOT ... for .. not marked mandatory. And also recommending either Result TLV or NAK TLV for the all optional case. ### Request-Action TLV ``` 2084 If multiple Request-Action TLVs are in the request and none of 2085 them is processed, then the most fatal status should be used in 2086 the Result TLV returned. If a status code in the Request-Action 2087 TLV is not understood by the receiving entity, then it should be 2088 treated as a fatal error. ``` Since this is not SHOULD or MUST can this advice be ignored? There are only 2 fatal errors listed so far. Perhaps there should be a 2000-2999 error for Request-Action TLV status code not understood?, or simply say to use "2002 Unexpected TLVs Exchanged"? ``` 2090 After processing the TLVs or inner method in the request, another 2091 round of Result TLV exchange would occur to synchronize the final 2092 status on both sides. ``` I wonder if "would" is must, or MUST here? ### PAC TLV ``` 2261 [RFC7170] defined a Protected Access Credential (PAC) to mirror EAP- 2262 FAST [RFC4851]. However, implementation experience and analysis 2263 determined that the PAC was not necessary. Instead, TEAP performs 2264 session resumption using the NewSessionTicket message as defined in 2265 [RFC9190] Section 2.1.2 and Section 2.1.3. As such, the PAC TLV has 2266 been deprecated. ``` When deprecated TLV are encountered, should they be handled any differently than non deprecated TLV? Are there any Error TLV (info, warning, or fatal) that are recommended for processing deprecated TLV? Is the guidance in Section 4.2.12 of RFC7170 unchanged in this update? ## Nits ### anonymous NAI ``` 291 As discussed in [RFC9190] Section 2.1.7 and [RFC9427] Section 3.1, 292 the outer EAP Identity SHOULD be an anonymous NAI Network Access 293 Identifier (NAI) [RFC7542]. While [RFC3748] Section 5.1 places no ``` Perhaps this could be better phrased as: "SHOULD be an anonymous Network Access Identifier (NAI) as described in Section 2.4 of RFC7542." ### Remove "with" ? ``` 553 dnsName attribute containing an FQDN string. Server certificates MAY 554 also include with a SubjectDN containing a single element, "CN=" ``` ### Trusted Anchor store ``` 571 * when the peer has the Server's End Entity (EE) certificate pinned 572 or loaded directly into it's Trusted Anchor store [RFC4949]; ``` "Trusted Anchor store" is not defined in 4949, but "trust anchor information" is. ### Missing have? ``` 605 the authentication process. It will therefore no way of correlating ``` ### EAP-NAK vs NACK TLV ``` 810 Section 4.2.15 that contains the username and password. If it does 811 not wish to perform password authentication, then it responds with a 812 NAK TLV indicating the rejection of the Basic-Password-Auth-Req TLV. ``` Section 3.1 inherits the term "EAP-Nak" from RFC7170. Consider adding a parenthetical next to EAP-NAK explaining the relationship to NAK TLV. ### EMSK expand on first use ``` 885 an EMSK, and are vulnerable to on-path attacks. The construction of ``` ### use -> be ? ``` 1089 restarted, it is not clear when that would use useful (or used) for ``` ### configuration flag : NOT recommended vs NOT RECOMMENDED ``` 1176 Peer implementations MUST be configured so that by default, the 1177 current authentication session fails if the server cannot be 1178 authenticated. However, it is possible to have a configuration flag 1179 which permits access to networks where the server cannot be 1180 authenticated. Such configurations are NOT recommended, and further 1181 discussion is outside of the scope of this specification. ``` This configuration flag behavior sounds dangerous (or fun, or both). Just double checking that "NOT recommended" is intentionally not BCP 14 language "NOT RECOMMENDED". This might perhaps be clarified in security considerations, since this is the only occurrence of "configuration flag" in the document. ### degenerate (i.e. unsigned) ``` 1231 body of a PKCS#10 TLV (see Section 4.2.17). The TEAP server issues a 1232 Simple PKI Response using a PKCS#7 [RFC2315] degenerate (i.e. 1233 unsigned) "Certificates Only" message encoded into the body of a 1234 PKCS#7 TLV (see Section 4.2.16), only after an inner method has run 1235 and provided an identity proof on the peer prior to a certificate is 1236 being issued. ``` Consider reversing the parenthetical: ... issues a ... unsigned (i.e. degenerate) ... You might also consider providing guidance (possibly in Section 4.2.16) on the ContentInfo value per the Notes in Section 9.1 of RFC2315. ### piggybacking ``` 2158 To allow piggybacking an EAP request or response with other TLVs, the 2159 EAP-Payload TLV is defined, which includes an encapsulated EAP packet 2160 and a list of optional TLVs. The optional TLVs are provided for ``` Consider an alternative word. ### remove against? ``` 3426 TEAP implementations can mitigate against online "brute force" ``` _______________________________________________ Emu mailing list -- emu@ietf.org To unsubscribe send an email to emu-le...@ietf.org
