Eliot
On 09.01.23 08:43, Alexander Clouter wrote:
On Thu, 5 Jan 2023, at 20:13, internet-dra...@ietf.org wrote:Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1 Filename : draft-ietf-emu-rfc7170bis-02.txt Pages : 101 Date : 2023-01-05Abstract: obseletes -> obsoletes Section 1.1 - Specification Requirements 'RFC2119'/'RFC8174' do they need to be turned into links like the other references? Section 2 - Protocol Overview "...the master secret for the session. If TEAP [LINE BREAK] Phase 2 is used to distribute..." - line break mid sentence Section 2.2 - Protocol-Layering Model We can take the opportunity to amend the layering diagram to be more lopsided to highlight that the outer-TLVs are on the 'outside' of the TLS jacket: +------------------------------------------+ | Inner EAP Method | Other TLV information | |------------------------------------------| | TLV Encapsulation (TLVs) | |------------------------------------------+---------------------+ | TLS | Optional Outer TLVs | |----------------------------------------------------------------| | TEAP | |----------------------------------------------------------------| | EAP | |----------------------------------------------------------------| | Carrier Protocol (EAP over LAN, RADIUS, Diameter, etc.) | +----------------------------------------------------------------+ Section 3.2 - TEAP Authentication Phase 1: Tunnel Establishment "man-in-the- middle" - stray space; due to markdown-to-HTML as it breaks over a newline "...server's identity that may be useful in helping the [LINE BREAK] peer select the appropriate credential..." - line break mid sentence Section 3.3.1 - EAP Sequences * "Upon completion of each EAP method in the tunnel, the server MUST send an Intermediate-Result TLV indicating the result of the inner EAP method. The peer MUST respond to the Intermediate-Result TLV indicating its result. If the result indicates success, the Intermediate-Result TLV MUST be accompanied by a Crypto-Binding TLV." This could be interpreted as the peer sends the Crypto-Binding TLV (without reading further) and not the server. Can we amend this to something more front loaded such as: "Upon completion of each EAP method in the tunnel, the server MUST send an Intermediate-Result TLV indicating the result of the inner EAP method. When the result indicates success it MUST be accompanied by a Crypto-Binding TLV. The peer MUST respond to the Intermediate-Result TLV indicating its own result and similarly on success MUST accompany the TLV with it's own Crypto-Binding TLV." Section 3.5 - TEAP Session Identifier The definition probably should be in a code block like the other definitions. Section 3.7 - Fragmentation I think this section should be removed as it adds nothing over RFC5216 section 2.1.5 (EAP Fragmentation) and doing a word diff it is mostly just word smithing changes that (at least for me) does nothing to improve understanding. If we want to keep it to minimise changes to RFC7170, I suggest we just truncate the section and state "go read RFC5216 section 2.1.5". Section 3.8 - Peer Services "Alternatively, peer services can be used if an inner EAP method providing mutual authentication and an Extended Master Session Key (EMSK) is executed and cryptographic binding with the EMSK Compound Message Authentication Code (MAC) is correctly validated." This can be read as if you can only do an unauthenticated server provisioning if the inner method provides an EMSK; note that EAP-(FAST)-MSCHAPv2 only provides an MSK. RFC5422 section 3.2.2 (EAP-FAST unauthenticated provisioning) states only EAP-FAST-MSCHAPv2 can be used for this. For RFC7170 are we allowed to use EAP-FAST-MSCHAPv2 for this? RFC7170 does not describe what is forbidden, and section 3.8.3 (Server Unauthenticated Provisioning Mode) does not say you cannot use an MSK (even a 'zero' based one). I suggest to reword this section to state (we we are allowed to use a non-zero MSK): "Alternatively, peer services can be used if an inner EAP method providing mutual authentication and an Master Session Key (MSK) and/or Extended Master Session Key (EMSK) that is executed and cryptographic binding with the Compound Message Authentication Code (MAC) which is correctly validated." Section 3.8.1 - PAC Provisioning "The peer MUST send separate PAC TLVs for each type of PAC it wants to be provisioned. Multiple PAC TLVs can be sent in the same packet or in different packets. The EAP server will send the PACs after its internal policy has been satisfied, or it MAY ignore the request or request additional authentications if its policy dictates." It is not explicitly stated that a server must respond to PAC TLVs in the order requested, it would though be hard to see how this could be implemented otherwise. Of course as PAC-Type (section 4.2.12.6) only supports the single value of 1 for 'Tunnel PAC', we may want to state for TEAP version one (1) *only* a single PAC may be requested whilst the server will only optionally service the first and ignore the rest? Afterall, the statement does say the client can send three requests and the server can ignore any of them, even arguably reply to request 1 and 3 and ignore 2. No idea how the peer could figure out what happened here without more signalling. I would recommend to reword this section to something more like: "The peer MAY only request a single Tunnel PAC it wants to be provisioned. Additional PAC TLVs MUST be ignored by the server. The EAP server will send the PAC after its internal policy has been satisfied, or it MAY ignore the request or request additional authentications if its policy dictates." Section 3.8.3 - Server Unauthenticated Provisioning Mode "Phase 2 EAP methods used in Server Unauthenticated Provisioning Mode MUST provide mutual authentication, provide key generation, and be resistant to dictionary attack. Example inner methods include EAP-pwd and EAP-EKE." As EAP-FAST-MSCHAPv2 is not resistant to dictionary attack[2] we need to tell people this. In practice, as anyone seen anything other than EAP-FAST-MSCHAPv2 actually be used for this? Win10/11 does not; and EAP-AKA/EAP-SIM is not exactly available to non-telcos, right? The other methods supported you would have the server (inner) identity available (ie. EAP-TLS) which opens the question why you would not also know the outer server identity. No idea what to do here. Section 4.2.3 - Identity-Type TLV Earlier in the parent section 4.2 states this TLV must be supported by all implementations but then the 'M' flag is set to optional (M=0). The wording in the section I do not think we should set this to M=1 (as Win10/11 does not) but maybe we need some language here to cover that though you must support it and respond to it, we mark it optional still? Not really sure what to do here, if anything. Section 4.2.5 - NAK TLV I cannot find the why it was changed (happened in draft-dekok-emu-rfc7170bis-00) so I probably missed the memo, but the length is >=6 in RFC7170 and here is =6 which seems wrong as there is a (albeit unused) TLV section in the attribute. This could break interop with existing 'RFC7170' implementations that may already do something here whilst implementers following RFC7170bis strictly would see an invalid length TLV. Similarly for '4.2.17 Trusted-Server-Root TLV'. Section 4.2.12 - PAC TLV Format It is not clear whether a PAC-Type sub-attribute should be in a PAC TLV or a PAC-Info TLV inside a PAC TLV...or why you would pick one over the other. PAC-Info is described only for the use case of a server sending it and as it includes a MUST for containing at least A-ID, A-ID-Info and PAC-Type which means a peer cannot send it as there is no good reason for the peer to send A-ID and it may not have the A-ID-Info anyway. I think it would help the reader to see an explicit statement of: * peer requesting PAC: PAC TLV[PAC-Type] * server provisioning PAC: PAC TLV[PAC-Key, PAC-Info[A-ID, A-ID-Info, PAC-Type], PAC-Opaque {or via NewSessionTicket}] ...assuming this is right as I have not seen a PAC provisioning in the wild. Section 4.2.12.5 - PAC-Acknowledgement TLV Unclear how this should be used, it looks like the peer could be expected to send: PAC TLV[PAC-Acknowledgement] After reading section 3.8.1 and getting confused, I am wondering now if this is actually: PAC TLV[PAC-Info{carbon copy of server sent TLV}, PAC-Acknowledgement] This would let the client acknowledge PACs out of order. Though this does not help the server side provisioning PACs out of order. Section 4.2.13 - Crypto-Binding TLV 'Crypto-Binding TLS' -> 'Crypto-Binding TLV' "The Crypto-Binding TLV MUST be exchanged and verified before the final Result TLV exchange, ..." - maybe want to include an ordering hint to *recommend* Intermediate-Result TLV is processed *before* the Crypto-Binding TLV and only to process the Crypto-Binding TLV when the result is success. "Flags -> TODO: What if there is just Basic-Password-Auth, and no EAP method?" - I would suggest "use a zero-MSK". It was suggested by Eliot[3] that this would be a good thing to mark under 'Security Considerations' to inform the reader that if they use a zero-MSK thing it opens a MitM possibility. We would be describe what I called makes an 'effective' Crypto-Binding TLV and what that buys you. Section 4.2.1[45] - Basic-Password-Auth-{Req,Resp} TLV Formatting goes poop as the Basic-Password-Auth-Req code block is missing one of the four '~' to terminate it. Also seems strange to have Basic-Password-Auth-Resp TLV marked as optional (M=0)...? Want me to spin up Win10/11 and see what it sets? Section 4.2.15 - PKCS#7 TLV "...in a degenerate Certificates Only PKCS#7 SignedData Content as defined in [RFC5652]." - I searched for 'degen' in RFC5652 and am no closer to understanding what the format should be. Am I right to infer is EncapsulatedContentInfo is omitted and "signed" is 'id-data'? Is this all that is to it? The problem for me is it is not obvious that "SignedData Content" (RFC7170) maps to "signed" (RFC5652). Also that "degenerate" (RFC7170) means "do not include signatures in TLV"? This makes no sense to me with my limited view of certificate chaining. Guessing as Eliot seems to have implemented this, he can help explain to people like me what to do? :) Section 4.3 - TLV Rules "The order of TLVs in TEAP does not matter, ..." We should though *recommend* an ordering to processing those TLVs as it already tripped one implementation[1]. Something like in descending priority: 1. Intermediate-Result-TLV 2. Cryptobinding-TLV 3. Result-TLV 4. EAP-Payload-TLV[Identity-Request] Though the order is not technically important, implementations may do unexpected things if the TLVs are delivered in a different order. For example, if an implementer is not careful with their state machine, they may attempt to verify (or generate) a Cryptobinding based on MSK for the 'authentication' method 'EAP-Identity' (ie. process EAP-Payload before Cryptobinding) which of course will be wrong (ie result in an MSK of all zeros). So maybe suggest "TLVs are sent in any order but the implementer must be aware that processing TLVs an in arbitrary order may have side effects on their state machine". Section 7.3 - Separation of Phase 1 and Phase 2 Servers "If the inner method is deriving EMSK, then this threat is mitigated as TEAP utilizes the mutual crypto-binding based on EMSK as described in [RFC7029]." - Again mentions here that only EMSK will bring you to comfort for crypto-binding which I think has implicatations for section 3.8.1 (unauthenticated server provisioning). Section 7.4 - Mitigation of Known Vulnerabilities and Protocol Deficiencies "To that extent, the TEAP authentication mitigates several vulnerabilities, such as dictionary attacks, by protecting the weak credential-based authentication method" - I think this ('dictionary attacks') is a false statement. Both EAP-FAST-MSCHAPv2 and Basic-Password-Auth can be just hammered. Maybe 'offline attack' would be a better fit here? Section 7.4.2 - Dictionary Attack Resistance I do not understand that TLS does provide any dictionary attack protection, right? Section 7.8 - Security Claims "Dictionary attack prot.: Yes" - maybe I am missing something, can someone point me to some reading material that explains how TLS protects from dictionary attacks? Appendix B - Major Differences from EAP-FAST "This version of TEAP MUST support TLS 1.2 [RFC5246]." - Section 3.2 and Appendix A.2 go further and mandate only 1.2 or later so we may want to change this to state "and NOT support TLS 1.1 or earlier" or words to that effect. Appendix C.1 - Successful Authentication We may want to update this (and the other sub-appendix sections): "(TEAP Start, S bit set, Authority-ID)" To be written as: "(TEAP Start, S bit set, O bit set, Authority-ID)" For me there is a little confusion caused by "PAC-Opaque in SessionTicket extension" which leads to a resumed session...which then leads to a refreshing of a PAC in a resumed session which conflicts with section 3.2.3 stating "A peer SHOULD NOT request that a new PAC be provisioned after the abbreviated handshake, as requesting a new session ticket based on resumed session is not permitted.". Now I have been blending to mean the same 'resumed' and 'abbreviated handshake' which probably means other readers will too. Maybe we should explicitly state somewhere: 'resumed session' - no inner authentication methods take place 'abbreviated handshake' - shorter TLS handshake Appendix C.5 - Fragmentation and Reassembly I would be included to remove this for the same reasons as section 3.7 (Fragmentation) earlier and it adds nothing more that RFC5216 provides already...which you must have implemented as a prerequisite to get as far as doing TEAP anyway. Appendix C.6 - Sequence of EAP Methods Amend: // Next EAP conversation started after successful completion of previous method X. The Intermediate-Result and Crypto- Binding TLVs are sent in next packet to minimize round trips. To: // Next EAP conversation started (with EAP-Request/Identity) after successful completion of previous method X. The Intermediate-Result and Crypto-Binding TLVs are sent in next packet to minimize round trips. I would suggest we move the following to above the previous 'Next EAP conversation' comment to lead the reader to handle Cryptobinding sooner rather than later in their implementation: // Compound MAC calculated using keys generated from EAP method X and the TLS tunnel. Amend immediately after that: Intermediate Result TLV (Success), Crypto-Binding TLV (Response), EAP-Payload-TLV [EAP-Type=Y] -> To: Intermediate Result TLV (Success), Crypto-Binding TLV (Response), EAP-Payload-TLV [EAP-Response/Identity (MyID2)] -> Appendix C.8 - Sequence of EAP Method with Vendor-Specific TLV Exchange Not sure this should go in 'EAP Sequences', but looks like we should help the reader and explicitly state somewhere that a sequence can be either a run of EAP-Payload TLV's or Vendor-Specific TLV's terminated with Intermediate-Result TLV (or Result TLV when used not in a sequence)? I probably would add a paragraph to the end of section 3.3.1 (EAP Sequences) stating something like: "Implementations wishing to use their own proprietary non-EAP based authentication method, may substitute the EAP-Payload TLV for the Vendor-Specific TLV and use this section without amendment; such as the interaction with Intermediate-Result TLV. It is valid to have a mix sequence of EAP-Payload TLV followed by Vendor-Specific TLV or vice versa." Appendix C.9 - Peer Requests Inner Method after Server Sends Result TLV We probably should include a note that a TEAP implementation probably does not want to send Result-TLV after a successful non-authenticating outer TLS handshake; the diagram shows a simplified exaggerated scenario. Maybe the diagram should have also added to it: "TLS client certificate" is sent or something. Appendix C.10 - Channel Binding Maybe this is the key to what to do for a Crypto-Binding when doing Basic-Password-Auth and then immediately sending Result TLV indicating Success. The implementation is RECOMMENDED to send a Channel-Binding TLV; which is not a 'MUST be implemented' TLV so optional. Thanks [1] https://lists.infradead.org/pipermail/hostap/2022-November/041123.html [2] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-chap/9b028a25-9205-48dd-a02c-df0f555a0558 [3] https://mailarchive.ietf.org/arch/msg/emu/2dBFiAx3r4JZs1UL1G8wtyAN6ZA/ _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
