On 01.08.23 04:02, Alan DeKok wrote:
On Jul 31, 2023, at 6:00 PM, Eliot Lear<l...@lear.ch> wrote:
We're not quite done. The following text needs to be removed, an additional
example added:
If there is no Phase 2 data, then the EAP
server MUST reject the session. There is no reason to have TEAP
devolve to EAP-TLS.
The intent was clarified in the next paragraph:
Note that the Phase 2 data could simply be a Result TLV with value
Success, along with a Crypto-Binding TLV and Intermediate-Result TLV.
This Phase 2 data serves as a protected success indication as
discussed in {{RFC9190}} Section 2.1.1
i.e. TEAP with outer client certificate and no Phase 2 crypto-binding seems
wrong.
IoT devices need a way to authenticate as TEAP is EAP-TLS under nominal
conditions. When a certificate is about to expire, then the expectation is
that either the client will issue a PKCS#10 request or the server will issue a
request action TLV with PKCS#10, so that the client knows the server wants it
to renew.
Sure.
Perhaps the text could just remove the last sentence about devolving to
EAP-TLS.
Yes, I think that would do nicely, thanks, along with the diagram
demonstrating it (I think I sent that along to you). Also, I would
suggest a small editorial change to help call out the really important
concept of outer versus inner, as follows:
OLD:
TEAP packets may include TLVs both inside and outside the TLS tunnel.
The term "Outer TLVs" is used to refer to optional TLVs outside the
TLS tunnel, which are only allowed in the first two messages in the
TEAP protocol. That is the first EAP-server-to-peer message and
first peer-to-EAP-server message. If the message is fragmented, the
whole set of messages is counted as one message. The term "Inner
TLVs" is used to refer to TLVs sent within the TLS tunnel. In TEAP
Phase 1, Outer TLVs are used to help establish the TLS tunnel, but no
Inner TLVs are used. In Phase 2 of the TEAP conversation, TLS
records may encapsulate zero or more Inner TLVs, but no Outer TLVs.
Methods for encapsulating EAP within carrier protocols are already
defined. For example, IEEE 802.1X [IEEE.802-1X.2013] may be used to
transport EAP between the peer and the authenticator; RADIUS
[RFC3579] or Diameter [RFC4072] may be used to transport EAP between
the authenticator and the EAP server.
NEW
Methods for encapsulating EAP within carrier protocols are already
defined. For example, IEEE 802.1X [IEEE.802-1X.2013] may be used to
transport EAP between the peer and the authenticator; RADIUS
[RFC3579] or Diameter [RFC4072] may be used to transport EAP between
the authenticator and the EAP server.
2.3 Outer TLVs versus Inner TLVs
TEAP packets may include TLVs both inside and outside the TLS tunnel
defined as follows:
Outer TLV: this term is used to refer to optional TLVs outside the
TLS tunnel, which are only allowed in the first two
messages in the TEAP protocol. That is the first,
EAP-server-to-peer message and first peer-to-EAP-server
message. If the message is fragmented, the whole set
of messages is counted as one message.
Inner TLV: this term is used to refer to TLVs sent within the TLS
tunnel.
In TEAP Phase 1, Outer TLVs are used to help establish the TLS
tunnel, but no Inner TLVs are used. In Phase 2 of the TEAP
conversation, TLS records may encapsulate zero or more Inner TLVs,
but no Outer TLVs.
This just reverses the order of two paragraphs and visually separates
outer / inner definitions. We could in theory do the same with phase
1/phase 2, but I think this is good enough.
Thanks,
Eliot
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
