On Nov 2, 2020, at 4:37 AM, Hannes Tschofenig wrote:
> IMHO the entire text in Section 5.7 reads a bit like you are giving
> implementation guidance. That would be great if John or you had written such
> code. I don’t know whether you have.
> You are given the reader the impression that there
9 AM
To: Hannes Tschofenig
<mailto:hannes.tschofe...@arm.com>; Mohit Sethi M
<mailto:mohit.m.se...@ericsson.com>;
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216
Hi Hannes,
As said, we added this text based on the request of
Thanks, Mohit, for the quick turn-over.
From: Mohit Sethi M
Sent: Monday, November 2, 2020 12:21 PM
To: Hannes Tschofenig ; Mohit Sethi M
; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec
Done as suggested:
https://github.com/emu-wg/draft-ietf
..@ericsson.com>;
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec
I now understand your issue with the sentence "An EAP-TLS peer and server
SHOULD support the use of HelloRetryRequest message.". I guess there is
t version of TLS 1.2 code already anyway, which
comes with sensible defaults. Do you have a different experience?
Ciao
Hannes
From: Mohit Sethi M
Sent: Monday, November 2, 2020 9:59 AM
To: Hannes Tschofenig ; Mohit Sethi M
; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates
; Mohit Sethi M
; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec
I now understand your issue with the sentence "An EAP-TLS peer and server
SHOULD support the use of HelloRetryRequest message.". I guess there is no need
for it, i.e., t
, 2020 6:06 PM
To: Hannes Tschofenig
<mailto:hannes.tschofe...@arm.com>;
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216
Hi Hannes,
This text and guidance was specifically requested by working group members like
Alan. Unless the
:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig
<mailto:hannes.tschofe...@arm.com>;
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec
Hi Hannes,
Jim Schaad had asked f
enig ; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec
Hi Hannes,
Jim Schaad had asked for this:
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/
It is still optional to use. The figure only shows what the exchange would look
lik
Hi Hannes,
This text and guidance was specifically requested by working group members like
Alan. Unless the text is wrong, I don't see any point in removing it. Other
TLS-based EAP methods are obviously free to use parts of this text relevant to
them. Note that their resumption and
Hi Hannes,
Jim Schaad had asked for this:
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/
It is still optional to use. The figure only shows what the exchange would look
like if a HRR was sent by the server.
--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi
Hi Hannes,
Thanks. I have opened several issues on github based on your review:
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues
--Mohit
On 10/21/20 11:55 AM, Hannes Tschofenig wrote:
Hi all,
Roman asked me to look at draft-ietf-emu-eap-tls13-11.
I have carefully read through
Hi Joe,
Thanks for the quick response.
[Joe] If the server is offering an expired or revoked certificate then that
needs to be remedied on the server.
Where do you believe the value of OCSP comes into the picture for this EAP-TLS
use case and what actions need to be taken when a notification
consideration is EAP-TLS 1.3. In my opinion any
document that deals with certificates ought to have some discussion on
revocation. In particular, EAP is deployed into an environment where some
revocation mechanisms may not work as expected because there is no network
access available to do out
m>>;
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear
mailto:40cisco@dmarc.ietf.org>> wrote:
+1. How does anyone even do OCSP without having first gotten onto the network?
[Joe] TH
ther mechanisms?
> Ciao
>
> Hannes
>
>
>
> *From:* Joseph Salowey
> *Sent:* Thursday, October 22, 2020 11:12 PM
> *To:* Eliot Lear
> *Cc:* Hannes Tschofenig ; emu@ietf.org
> *Subject:* Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
>
>
>
>
&g
Hi Alan,
> However, in the absence of another specification, we need to say *something*
> for EAP-TLS.
Why doesn't the group write that other document? There are several other EAP
methods that use certificates as well.
>> Wouldn’t this be a topic to address in ? IMHO
>> this would make
[Trimming]
> On 26 Oct 2020, at 16:26, Michael Richardson wrote:
>
>
>>> While this degenerate case of Authentication Server + OCSP Signer on the
>>> same
>>> machine is kinda dumb from a overall security point of view, it's still
>>> better than raw public keys.
>
>> Yes. Let’s think about
Michael:
>> I am aware of some places that generate an OCSP response for the entire
>> population of certificates, and those responsed are distributed to many
>> locations. I am not aware of anyone that distributes the OCSP
>> responder signature private key to multiple locations.
>
> Does
Russ Housley wrote:
>>> The second is, I think, that the EAP server (Authentication Server),
would run
>>> an OCSP responder locally so that it can mint it's own staples.
>>> AFAIK, each certificate can point to a different OCSP signer.
>>
>> Does anyone actually do that?
Eliot Lear wrote:
>> No. There are several steps before we get to raw public keys.
>>
>> The first is that the duration of the Staples could be lengthed to
accomodate
>> anticipated down time for the (now) critical OCSP responder.
>> A second part is that perhaps staples
>> The second is, I think, that the EAP server (Authentication Server), would
>> run
>> an OCSP responder locally so that it can mint it's own staples.
>> AFAIK, each certificate can point to a different OCSP signer.
>
> Does anyone actually do that?
I am aware of some places that generate an
> On 26 Oct 2020, at 15:19, Michael Richardson wrote:
>
> Signed PGP part
>
> Eliot Lear wrote:
>>> The EAP server is expected to frequently request a OCSP response from
>>> the OCSP responder (a server typically run by the certificate
>>> issuer). The OCSP response is then added to the
Eliot Lear wrote:
>> The EAP server is expected to frequently request a OCSP response from
>>the OCSP responder (a server typically run by the certificate
>>issuer). The OCSP response is then added to the Servers Certificate
>>message as long as it is valid. Before the OCSP
John Mattsson wrote:
> 1. Basically all TLS implementations support OSCP, and a majority
> support OSCP stapling (Certificate Status Request). Mbed is an
> exception rather than the rule.
Is this for server and client certificates, or just server certificates?
It seems that getting
Thanks, John. Please see below:
> On 26 Oct 2020, at 13:58, John Mattsson
> wrote:
>
> Hi Eliot,
>
> The EAP server is expected to frequently request a OCSP response from the
> OCSP responder (a server typically run by the certificate issuer). The OCSP
> response is then added to the
to
be real-time you need to make an online OCSP request-response to the OCSP
responder.
John
-Original Message-
From: Eliot Lear
Date: Monday, 26 October 2020 at 13:16
To: John Mattsson
Cc: "emu@ietf.org"
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
Hi
Hi John,
My question is one of pragmatics. In an offline industrial environment, what
is expected of the server to accomplish the stapling? Especially if the
request is nonced.
Eliot
> On 26 Oct 2020, at 13:08, John Mattsson
> wrote:
>
> Hi,
>
> When this was discussed in the group, it
Hi,
When this was discussed in the group, it was decided to not only mandate
revocation checking, but to also mandate OCSP stapling as is it often the only
viable solution to let an offline peer check the revocation status of the
server. We had a discussion on must-staple, and the decision was
On Oct 23, 2020, at 3:37 AM, Hannes Tschofenig
wrote:
> I do not understand certificate revocation checking is a topic specific to
> the use of TLS 1.3 in EAP-TLS.
It's not.
However, in the absence of another specification, we need to say *something*
for EAP-TLS.
> If this topic is
Tschofenig ; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear
mailto:40cisco@dmarc.ietf.org>> wrote:
+1. How does anyone even do OCSP without having first gotten onto the network?
[Joe] THat is what OCSP st
So I’m a client and include a certificate status request. The EAP server isn’t
talking to the CA at the moment. Does a nonce have to be used? If so… #fail.
If not, what prevents a replay? And if the answer is nothing, what is the
threat model we are addressing?
Joseph Salowey wrote:
> On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear
> wrote:
>> +1. How does anyone even do OCSP without having first gotten onto the
>> network?
> [Joe] THat is what OCSP stapling is supposed to solve since the OCSP
> messages are sent in the TLS
On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear
wrote:
> +1. How does anyone even do OCSP without having first gotten onto the
> network?
>
>
[Joe] THat is what OCSP stapling is supposed to solve since the OCSP
messages are sent in the TLS handshake. I believe there are some EAP-TLS
Hannes Tschofenig wrote:
> Thanks for the question. I am objecting to the mandatory use of OCSP for
TLS 1.3 in EAP-TLS.
> I am fine with having it optional.
okay, so it's not about the stapling, at all for you, it's about the OCSP
itself.
--
Michael Richardson. o O ( IPv6 IøT
+1. How does anyone even do OCSP without having first gotten onto the network?
Eliot
> On 21 Oct 2020, at 11:02, Hannes Tschofenig wrote:
>
> Hi all,
>
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
> believe this is a problem for implementations. This extra
Hi to all,
as an operator of a EAP-TLS server for eduroam at the University Bremen
I just want to give some of my thoughts here, feel free to read or
ignore them ;)
The eduroam environment is heavily used for BYOD, so we don't have any
opportunity to change certificates via a Device Management.
methods rely on OCSP?
Ciao
Hannes
-Original Message-
From: Michael Richardson
Sent: Wednesday, October 21, 2020 6:46 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
Hannes Tschofenig wrote:
> this draft mandates OCSCP stapl
Hannes Tschofenig wrote:
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS)
> and I believe this is a problem for implementations. This extra burden
> is IMHO unjustified. For the type of deployments where EAP is used
> there is no need for a mandatory
On Oct 21, 2020, at 5:02 AM, Hannes Tschofenig
wrote:
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
> believe this is a problem for implementations. This extra burden is IMHO
> unjustified. For the type of deployments where EAP is used there is no need
> for a
On Oct 21, 2020, at 5:00 AM, Hannes Tschofenig
wrote:
> the draft says it updates the earlier EAP-TLS version and claims that the
> updates are related to
>
> * Section 5.6 Authorization
> * Section 5.7 Resumption
>
> The content of Section 5.6 actually does not relate to EAP-TLS but is
Hi all,
Section 2.1.6 says:
"
An EAP-TLS peer and server SHOULD support the use of
HelloRetryRequest message.
"
My understanding of the TLS 1.3 specification is that the HelloRetryRequest is
not an optional-to-implement message but it is only optional to use.
Is there a reason to
Hi all,
the draft contains a number of cases where text from the TLS 1.3 specification
or other specifications is repeated. Often, only fragments are used, which can
easily fool the reader into believing that the omitted parts do not apply.
Hence, I would avoid the repetition where not
Hi all,
There are plenty of places in the draft where statements are made in a somewhat
sloppy manner.
Section 5.1:
" TLS 1.3 increases the number of
cryptographic parameters that are negotiated in the handshake.
"
Increases the number of parameters compared to what?
Section 5.1:
"
TLS
Hi all,
there are lots of editorial bugs in the text. I noticed many missing commas,
missing articles, etc.
I know that the RFC Editor does a great job in correcting all of those errors
but we have to do our work as well.
It would also be good to be consistent with the terms. How do you want
Hi all,
this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
believe this is a problem for implementations. This extra burden is IMHO
unjustified. For the type of deployments where EAP is used there is no need for
a mandatory certificate revocation checking with OCSP.
Hi all,
the draft says it updates the earlier EAP-TLS version and claims that the
updates are related to
* Section 5.6 Authorization
* Section 5.7 Resumption
The content of Section 5.6 actually does not relate to EAP-TLS but is generic
to all EAP methods. I don't think it even belongs in an
Hi all,
in an earlier email on this topic John wrote "I don't see why anybody would get
the impressions that the application data would be unencrypted, all application
data in TLS 1.3 is encrypted."
Even in the latest version of the draft (version -11) I can still find text
that says the
Hi all,
Roman asked me to look at draft-ietf-emu-eap-tls13-11.
I have carefully read through the document and I will post my reviews in
separate emails.
There are still lots of room for improvement.
Ciao
Hannes
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential
49 matches
Mail list logo
