On 03.07.23 19:08, Alan DeKok wrote:
On Jun 27, 2023, at 7:04 PM, Joseph Salowey <j...@salowey.net> wrote:
We are nearing completion of RFC7170bis. There are a few open issues in
github - https://github.com/emu-wg/rfc7170bis/issues
Issue 21 - links to the errata to verify that they have been addressed in the draft and
provides text for resolving the errata. In many cases it might be easier to resolve as
"wait for document update". Please review to make sure the errata have been
correctly addressed.
Issue 20 - we are waiting on some flows on PKCS #10/#7 - I think Eliot has this
action item.
Issue 8 - is also a related item, perhaps these can be addressed together.
Issue 17 - this is a request to add mandatory to implement ciphersuites. Some
more discussion is needed on this.
Issue 15 - Discusses an issue with chained EAP methods and proposes that we add
some text and a new error message to address this problem. Do people think
this needs addressing?
Once we resolve these issues we can move the draft forward.
I've updated the document and will issue a new revision shortly.
There are a few questions coming from the updates.
RFC 3.3.1 says that TEAP should note devolve into EAP-TLS:
Further, when a client
certificate is sent outside of the TLS tunnel, the server MUST proceed
with phase 2, either for authentication or provisioning. 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.
Eliot notes that you can't renew a client certificate in EAP-TLS. Therefore, there
may be good reason to use TEAP in "client certificate only" mode.
I'll just add that the current TEAP support in wpa_supplicant supports
just this case.
There is a related question is for client certificates provisions via TEAP.
Section 3.8.1 says:
Provisioning of a peer's certificate is supported in TEAP by
performing the Simple PKI Request/Response from {{RFC5272}} using
PKCS#10 and PKCS#7 TLVs, respectively.
That's all well and good, but there is nothing which ties that certificate
to TEAP.
Do we want to say that the provisioned credentials MUST NOT be used for
anything other than TEAP?
I would suggest that we provide some guidance, but perhaps not
normative. The reason is that RFC 7170 states that the
Trusted-Server-Root TLV may return a list of certs, and it may be in
some cases to provision multiple root certificates. That having been
said, the text in that section is not as clear as it could be with
regard to the purpose of those other certs. In an enterprise
environment, it may be broadly desirable to inform an IOT device of a
trust anchor within the enterprise. On the other hand, if the device is
a collaboration device or some other human oriented system, that advice
taken blindly may lead to exposing communications on a personal system.
In short, my suggestion is to add some text in Security Considerations,
and some text suggesting that the primary use be for EAP authentication
and renewal, and that other uses should be considered carefully by
clients. This might also lead to an EKU discussion, and that might be
something we want to address here.
Eliot
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
