Re: [Emu] RFC 7170 bis
On Jul 3, 2023, at 3:04 PM, Eliot Lear wrote: >> 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. It's technically fine. IIRC the "SHOULD NOT" is just that it doesn't make much sense to replicate EAP-TLS in another EAP type. However, if the functionality is not the same, then there is good reason behaviour similar to EAP-TLS. > 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. OK. I've already issued -07. I'll try to do some word-smithing around the subject, and issue -08 later this week. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] I-D Action: draft-ietf-emu-rfc7170bis-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This Internet-Draft is a work item of the EAP Method Update (EMU) WG of the IETF. Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1 Author : Alan DeKok Filename: draft-ietf-emu-rfc7170bis-07.txt Pages : 101 Date: 2023-07-03 Abstract: This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunnel, TLV objects are used to convey authentication-related data between the EAP peer and the EAP server. This document obsoletes RFC 7170. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-emu-rfc7170bis-07.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-rfc7170bis-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] RFC 7170 bis
On 03.07.23 19:08, Alan DeKok wrote:
On Jun 27, 2023, at 7:04 PM, Joseph Salowey 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
Re: [Emu] RFC 7170 bis
On Jun 27, 2023, at 7:04 PM, Joseph Salowey 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.
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?
Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] RFC 7170 bis
On Jun 29, 2023, at 10:48 AM, Eliot Lear wrote: > RFC 2315 uses the term, and I take "degenerate" here to mean that the PKCS#7 > object is not itself signed. This is how we implemented. OK. I will update doc document accordingly. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
