On Thu, 5 Jan 2023, at 20:13, [email protected] wrote:
> Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Filename : draft-ietf-emu-rfc7170bis-02.txt
> Pages : 101
> Date : 2023-01-05
Abstract:
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
[email protected]
https://www.ietf.org/mailman/listinfo/emu
