<pe...@akayla.com> wrote:
> Alan has issued -11 of draft-ietf-emu-rfc7170bis. He
> believes it covers all of the outstanding issues that needed to be
> resolved. We held up the WGLC until we could have our session at IETFSome people might find this URL useful: https://author-tools.ietf.org/diff?doc_1=RFC7170&doc_2=draft-ietf-emu-rfc7170bis%2F Reading the document from top-to-bottom for the first time in awhile (to do the Shepherd write-up), paragraph two of the Introduction, where EAP-FAST is mentioned seems to be aged. It's from 7170, but given that this is 7170bis, I wonder if the history is entirely accurate, or really still timely. section 2; paragraph 2, uses SHOULD several times without obvious exceptions. Could be it is MUST? } Upon successful execution of TEAP, the EAP peer and } EAP server both derive strong session key material that can then be } communicated to the network access server (NAS) for use in } establishing a link-layer security association. I feel like a reference is in order (but 7170 didn't have one). Figure 2: should TLV Encapsulation be narrower than TLS, so show that it fits into TLS? Ditto Inner EAP Method fits into TLV. > The TEAP version is not protected by TLS and hence can be modified in > transit. In order to detect a modification of the TEAP version, the I suggest: > The TEAP version is not protected by TLS and hence can be modified in > transit. In order to detect a bid-down attack, where the TEAP version is > modified, the (similar things are done in IKEv2, as well as in TLS; I don't know if a reference is worthwhile here) > be used in the case when the inner method provides mutual > authentication, key generation, and resistance to man-in-the-middle > and dictionary attacks. TLS ciphersuites that do not provide can you give an example of an inner method that does not do this? I assume EAP-PWD, but which others? Section 3.3: it might be useful to reviewers not steeped in EAP and roaming to understand how often *TLS* resumption is used in practice (maybe eduroam have some server stats they could share?), and how it is important when roaming from AP to AP. (I understand that *TEAP* is not well used in eduroam yet, but EAP-TLS is) If I did run EAP-TLS as an Inner method (whether once or twice), could I use resumption? > If a particular authentication method succeeds, the server SHOULD NOT > attempt a subsequent authentication method. For example, if a user this seems to contradict the first paragraph that says that multiple authentications are allowed. It might be worth saying that 3.4.2 is a TEAP-TLV thing, and not EAP-PWD. A most likely thing today for "Password" authentication is to use TOTP methods against a hardware token. (X9.9, SecureID, etc.) If I read correctly, a Crypto-Binding TLV is expected after every successful authentication method. If multiple passes occur, I'm unclear what to do with the multiple bindings. I think that they ought to be incremental. They can be checked each time though. section 3.5: I wonder if additional references to RFC6125 and the UTA-bis version of that might be more clear. I think that this section is going to get beat on by security review. I also suggest that rather than saying how it is to be matched, I suggest the section be more prescriptive in how certificates are expected to be formed. (I recognize that this text has not changed since 7170) section 3.6: tls-unique is replaced by TLS Exporter in TLS 1.3. I think that there is missing TLS 1.3 text here. section 3.7.2: > The EAP-Response packet sent by the peer may > encapsulate a TLS ClientHello handshake message, in which case the > TEAP server MAY allow the TEAP conversation to be restarted, or it > MAY contain a TEAP response with a zero-length message, in which case > the server MUST terminate the conversation with an EAP Failure What are some situations where a peer would expect to do a restart? Some kind of temporary resource exhaustion or something? ENORANDOMNUMBERSLEFTPLEASEWAITFORMORENEUTRINOS ?? Also, I wonder if the word "peer" above means "Peer", or just either end. To that end, I found "Peer" very confusing at times. section 3.7.3: maybe reorganize into point form. It seems like a long if-then-else, and maybe a case-when format would be easier. The edits since 7170 don't seem sufficient to clarify this section. section 3.9.: what is "server unauthenticated provisioning" (sounds like TEAP-BRSKI?) > TEAP peers MUST track whether or not server authentication has taken > place. When the server cannot be authenticated, the peer MUST NOT > request any services from it. so, if a TEAP (supplicant) peer can not validate the Server certificate, but it can get a MSK/EMSK that matches, then it can request "services" from it. (What are these services, if they aren't things that lead to an MSK? Ah, subsequent sections. Forward reference to 3.9.3 please) Mention is then made of "provisioning data" as a service. I think this section could use a rewrite. I suggest using this section to say WHAT TO DO, and then in Security Considerations, tell us what happens when that advice is not followed. That way implementers aren't dealing with a mix "DO X", with "watch out for Y" 3.9.1: tls-unique vs TLS 1.3 again. I think, unless there are in-the-field, two interoperable, versions of this section, that it be removed from this document, and put into a new document. The text in 3.9.2 is new, and frankly not all that useful. CSRs are not that complex, because 99% of the information that could be included in a CSR is useless, and CAs throw it out. I don't think this document needs to repeat the need for a CSP. > It is NOT RECOMMENDED to use certificates provisioned via TEAP with > any other protocol which uses TLS. Honestly, this renders the entire point of the provisioning aspect of this probably moot. I see that "4.2.18. CSR-Attributes TLV" references: > Servers and peers MUST follow the guidance provided in > [I-D.ietf-lamps-rfc7030-csrattrs] when creating the CSR-Attributes I will start a new thread on this topic. > 4.2.19. Identity-Hint TLV I think that this should be mentioned in section 3. Probably 3.2 or 3.4. Section 4.3, about TLV rules. Given that EAP fragments, but is subject to RADIUS and other layers dropped packets.. And that TLS assumes a TCP-like transport for its records, there is a question about whether one should pack more TLVs into a single TLS record, and let EAP fragment, or put fewer TLVs in, and have fewer fragments. Is there any advice here? We can't put certain things together, but can we split them out more? What if we care more about loss due to lost fragments, vs round-trips? 5.1 finally talks about TLS 1.3 exporters. section 5.7 says: "negotiate down", and I think the common term in the literature is "bid-down attack", and I think reviewers will prefer that term. s/Man-in-the-middle attacks/on-path active attacks/ 7.4.1 describes a mechanism where TLS 1.2 can use re-negotiation to get confidentiality of client certificates. That shouldn't be introduced in the SC, but needs to be described much easlier, and then referenced. Also, there is BCP14 language in the SC, which I really prefer never to see. It should be in the main body. Important nits: -- The abstract seems to indicate that this document obsoletes RFC7170, but the header doesn't have an 'Obsoletes:' line to match this. == Outdated reference: draft-ietf-emu-tls-eap-types has been published as RFC 9427 Some other nits worth looking at. Normative references that probably could be informative: [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 5226, DOI 10.17487/RFC5226, May 2008, <https://www.rfc-editor.org/info/rfc5226>. [RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna, "Tunnel Extensible Authentication Protocol (TEAP) Version 1", RFC 7170, DOI 10.17487/RFC7170, May 2014, <https://www.rfc-editor.org/info/rfc7170>. (yes, because we are obsoleting it, so you don't have to read it!) Informative references that probably need to be normative: [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object Classes and Attribute Types Version 2.0", RFC 2985, DOI 10.17487/RFC2985, November 2000, <https://www.rfc-editor.org/info/rfc2985>. [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, DOI 10.17487/RFC2986, November 2000, <https://www.rfc-editor.org/info/rfc2986>. MAYBE: [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <https://www.rfc-editor.org/info/rfc4086>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>. I suggest when listing the contributors for 7170, that they be listed using the markdown contributors: method, as that results in XML that is machine parseable. There is also a {{{First Last}}} for kramdown that results in XML. -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
