Thanks for your comments Alan. Very helpful. See answers and comments below:
On Nov 16, 2017, Alan DeKok wrote:
>That's good. But as Bernard points out, there's no need to change
>EAP-TLS. You can just use TLS 1.3.
I don’t agree with that, see concrete details below.
>How so? 5216 says (esse
Hi Bernard,
On Thu, Nov 19, 2017, Bernard Aboba wrote:
>The big question is "Why not create a new EAP method"?
>The overall intent seems to be to create an pre-shared key EAP method
>optimized for 5G,
>based on EAP-TLS v1.3.
I don’t know why you have gotten the idea that the intent is pre-s
On Dec 21, 2017, Alan DeKok wrote:
>The question I have is whether we can do anything to EAP-TLS to address the
>issue. Answering that question >requires a deeper dive into TLS.
In TLS 1.3, ECC is mandatory to support. This drastically reduces the sizes of
certificates and signatures (public k
Session-Id SHALL be derived from the
exporter_master_secret using the TLS exporter interface.
Comments appreciated.
Cheers,
John
On 2018-01-09, 14:16, "internet-dra...@ietf.org"
wrote:
A new version of I-D, draft-mattsson-eap-tls13-01.txt
has been successfully submitt
TLS 1.3 also changes which of the certificates that can be omitted. TLS 1.2
(and earlier) only allows omitting the self-signed root certificate while TLS
1.3 allows omitting any trust anchor certificate. This would be useful in cases
where the possessed trust anchors are known.
TLS 1.2: "the se
Hi Joe,
I’d like us to discuss the use of EAP-TLS with TLS 1.3 as well as strategies on
how to avoid fragmentation due to large certificates and certificate chains in
all versions of EAP-TLS. I plan to submit a new version of
draft-mattsson-eap-tls13.
Cheers,
John
A new version of I-D, draft-mattsson-eap-tls13-02.txt
has been successfully submitted by John Mattsson and posted to the
IETF repository.
Name: draft-mattsson-eap-tls13
Revision: 02
Title: Using EAP-TLS with TLS 1.3
Document date:
A diff from the last version can be found here:
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-mattsson-eap-tls13-02.txt&url2=https://www.ietf.org/id/draft-ietf-emu-eap-tls13-00.txt
Except editorials, the main change is that the Exporter labels has been changes
to conform wi
Hi,
This looks very good, I looked through the document quickly and have some
mostly editorial comments.
- I think the document still need to have the first-page header "Updates:
4187". My understanding of Obsoletes is that it replaces the older document and
that the new document can be used a
Now that draft-ietf-emu-eap-tls13 and draft-ietf-emu-rfc5448bis has been
adopted, I think it is time to start discussing the remaining things that the
working group has been charted to do.
I think Perfect Forward Secrecy (PFS) and privacy are very important targets
for the group. RFC 7258 (Perv
John: Thanks Jouni, very good comments. Great to get feedback from
implementation. I think there is a slight mismatch between the assumptions in
TLS and EAP, in TLS the connection is assumed to stay open for a long time after
the client sends Finished, in EAP the connection is assumed to be closed
Hi Joe,
I would like to request time to discuss draft-ietf-emu-eap-tls13. The
discussion topics would be the issues highlighted by Jouni Malinen.
- EAP state machine and EAP TLS with 1.3
- Sending additional information in the Flags byte
- Send payload in EAP-Success
- Derivation of
Hi,
I reviewed the new -01 version. Looks very good. Some additional comments:
-- Section 1
- Section 5 and 6 is missing from the document structure description. Is this
intentional?
- OLD "updates to RFC 5448 AKA' and"
NEW "updates to RFC 5448 EAP-AKA' and"
-- Section 3
- Some of the lin
-emu-eap-tls13-01.txt
has been successfully submitted by John Mattsson and posted to the
IETF repository.
Name: draft-ietf-emu-eap-tls13
Revision: 01
Title: Using EAP-TLS with TLS 1.3
Document date: 2018-09-18
Group: emu
Pages: 19
URL:
https://
FYI,
NIST has decided to withdraw SP 800-120 “Recommendation for EAP Methods Used in
Wireless Network Access Authentication” on October 19, 2018. The document SP
800-120 is out of date and NIST is instead referring to relevant IETF standards.
https://csrc.nist.gov/publications/detail/sp/800-12
al Message-
From: "internet-dra...@ietf.org"
Date: Tuesday, 16 October 2018 at 22:30
To: Mohit Sethi , John Mattsson
Subject: New Version Notification for draft-ietf-emu-eap-tls13-02.txt
A new version of I-D, draft-ietf-emu-eap-tls13-02.txt
has been successfully submitted by John M
as well as reviews of the whole document are very
welcome.
Cheers,
John
-Original Message-
From: "internet-dra...@ietf.org"
Date: Monday, 22 October 2018 at 12:26
To: Mohit Sethi , John Mattsson
Subject: New Version Notification for draft-ms-emu-eaptlscert-01.txt
A new ve
veral editorials.
Cheers,
John
-Original Message-
From: "internet-dra...@ietf.org"
Date: Wednesday, 14 November 2018 at 13:20
To: Mohit Sethi , John Mattsson
Subject: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
A new version of I-D, draft-ietf-emu-eap-tls13-03.txt
-emu-eap-tls13 should
be updated when draft-ms-emu-eaptlscert gets adopted by the WG).
/John
-Original Message-
From: John Mattsson
Date: Wednesday, 14 November 2018 at 13:50
To: "emu@ietf.org"
Subject: FW: New Version Notification for draft-ietf-emu-eap-tls13-03.txt
Hi,
We
Hi,
The draft "Using EAP-TLS with TLS 1.3" (draft-ietf-emu-eap-tls13-03) specifies
the use of EAP-TLS with TLS 1.3:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13
https://github.com/emu-wg/draft-ietf-emu-eap-tls13
In Bangkok the EMU WG decided to analyse if some of the known attacks on TL
Hi,
RFC 8446 defines the TLS-Exporter interface as:
TLS-Exporter(label, context_value, key_length)
draft-ietf-emu-eap-tls13 is using the exporter interface without context:
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128)
IV = TLS-Exporter("EXPORTER_EAP_T
Hi Alan,
Great news that you have done interoperability testing of EAP-TLS 1.3 and that
you have not found any major issues.
I think it is very good to inform implementors about the use of the length
values to ensure combability. I have added your suggested text to the GitHub.
https://github.c
Hi Alan
I think you accidently took the key derivation from
draft-mattsson-eap-tls13-00. The key derivation in draft-mattsson-eap-tls13-03
is:
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material", "", 128)
IV = TLS-Exporter("EXPORTER_EAP_TLS_IV", "", 64)
Method-Id=
Hi Alan,
The intention with "All other parameters such as MSK and EMSK are derived as
specified in EAP-TLS [RFC5216], Section 2.3." was to only mention changes
compared to RFC 5216.
Avoiding potential confusion is a very important goal to avoid incompatible
implementations. I think we should m
>Sure. The question then becomes one of encoding. For types < 256, 1 octet is
>>enough. For others, it should be a 32-bit number in network byte order.
Maybe we can state that it is the EAP Method Type value in network byte order
with any leading bytes of value zero removed? Then 13 is encode
Hi Alan,
>> Should all of the following be added to draft-ietf-emu-eap-tls13?
>>
>> MSK = Key_Material(0, 63)
>> EMSK = Key_Material(64, 127)
>> Enc-RECV-Key = MSK(0, 31)
>> Enc-SEND-Key = MSK(32, 63)
>> RECV-IV = IV(0, 31)
>> SEND-IV = IV(32, 63)
> I think
Hi Alan, David,
I also strongly agree that all TLS-based EAP methods in use should be capable
of working with TLS 1.3. You make a very strong case that this need to happen
as soon as possible and that the most practical approach is to add the
information to draft-ietf-emu-eap-tls13. Just like w
Hi Alan,
The mentioned requirement comes from Section 2.4 of RFC 5216, which states
that:
"Since the ciphersuite negotiated within EAP-TLS applies only to the EAP
conversation, TLS ciphersuite negotiation MUST NOT be used to negotiate the
ciphersuites used to secure data."
However, I do not
> Alan DeKok ; wrote:
>
> Hmm... if the changes are too complex, it may be better to have a new
> document. I have a first draft written, and will be publishing it soon. It's
> only about 12 pages, but it goes through a lot of detail that is likely not
> relevant for the EAP-TLS document.
>
Ma
Hi Alan
> Alan DeKok ; wrote:
>
>> The mentioned requirement comes from Section 2.4 of RFC 5216, which states
>> that:
>>
>> "Since the ciphersuite negotiated within EAP-TLS applies only to the EAP
>> conversation, TLS ciphersuite negotiation MUST NOT be used to negotiate the
>> ciphersuite
Hi Alan,
Very good that this is discussed and highlighted.
My understanding is that TLS itself clearly allows a resumed connection to be
used for a completely different purpose. The ALPN specification (RFC 7301) says
that:
"When session resumption or session tickets [RFC5077] are used, the pre
Alan DeKok ; wrote:
>I would suggest then referencing or duplicating the above text, and saying
>something like:
>
>---
>Implementations SHOULD be capable of session resumption across different
>TLS-based EAP types. This recommendation is made for a few reasons. It is
>recommended by [RFC7301
Based on this discussion I suggest changing the title and the scope of
draft-ms-emu-eaptlscert
OLD: "Handling Large Certificates and Long Certificate Chains in EAP-TLS"
NEW: "Handling Large Certificates and Long Certificate Chains in TLS-based EAP
Methods"
The problem description, discussion,
Looks good!
I only have editorial comments
- "defintion"
- "implemementations"
- " Session-Id = 0x19 || client.random || server.random).
This definition is already in wide-spread use in multiple PEAP"
Should remove ")." and add a blank line.
- I noticed that this draft and draft-i
I think this is a very good discussion to have. Any problems with peer
authentication would (at least in theory) affect pure EAP-TLS as well. RFC 5216
states that:
RFC 5216: "While the EAP server SHOULD require peer authentication, this is not
mandatory, since there are circumstances in which p
Re: [Emu] Notes on session resumption with TLS-based EAP methods
Mohit Sethi M ; wrote:
>
>For me, an EAP-TLS server should not only refuse resumption if a client
>was not authenticated, it should also refuse resumption if the client
>was authenticated with other methods than certificates (suc
Hi,
I have reviewed this draft multiple times, I think this draft is very
well-written and ready to be published. A few minor comments:
- "3rd Generation Authentication and Key Agreement"
I see that this exact term was used in RFC 5448, but I find it quite strange. I
think the terminology is
Alan DeKok ; wrote:
>The issue with session resumption is much larger than just the EAP method.
>This subject should ideally be discussed in the "Security Considerations"
>section of the new EAP-TLS draft.
I agree
>i.e. We should define precisely what a "session" is.
>
>Right now, the draft t
Alan DeKok ;; wrote:
>This security bug was completely missed in RFC 5216. This new draft should
>rectify that error.
>
>i.e. using an NAI of "example.org" in the first session, and "example.com" in
>the second session.
>
>Not only is this entirely permitted by the current spec, it's not
Thanks for the suggested security consideration Alan! This helps a lot!
I'll will work with updating the draft during the next days. Your suggested
text look very good at a first readthrough.
Cheers,
John
___
Emu mailing list
Emu@ietf.org
https://ww
Hi,
As there was no objections, I made the following changes to the GitHub version
that will appear in draft-ietf-emu-eap-tls13-04
Section 2.1.1
OLD:
As stated in [RFC5216], the TLS cipher suite shall not be used to
protect application data. This applies also for early application
Welcome and thanks for your comments Oleg!
slon v sobstvennom palto ; wrote:
>Per my experience the existing fragmentation method described in EAP-TLS
>RFC 5216 serves good for all fragmentation needs. The method is reused by
>PEAP, EAP-FAST, TEAP and EAP-TTLS. There's an ambiguity in EAP-TLS RFC
Hi,
There seems to be agreement on the list to add security considerations on
authorization and resumption. With the text from Alan as a basis (thanks again
Alan!), I have added the sections below to draft-ietf-emu-eap-tls13.
Some high level changes from Alas text:
- Some considerations also
2019 at 21:06
To: Mohit Sethi , John Mattsson ,
Sean Turner
Subject: New Version Notification for draft-ms-emu-eaptlscert-02.txt
A new version of I-D, draft-ms-emu-eaptlscert-02.txt
has been successfully submitted by John Mattsson and posted to the
IETF repository.
Name: draft-ms-emu-
day, 11 March 2019 at 22:06
To: Mohit Sethi , John Mattsson
Subject: New Version Notification for draft-ietf-emu-eap-tls13-04.txt
A new version of I-D, draft-ietf-emu-eap-tls13-04.txt
has been successfully submitted by John Mattsson and posted to the
IETF repository.
Name: draft-ietf-em
Hi Oleg,
>I remember that some EAP-TLS/PEAP clients rejected not fragmented messages
>without L bit set, probably due to their wrong interpretation of EAP-TLS
>RFC. Would it worth to say something like "Implementation SHOULD accept
>unfragmented messages with and without L bit set" in addition to
Alan wrote:
>I've done a quick check. On reception, FreeRADIUS accepts the L bit for any
>type of message. It doesn't care >about fragments, just that the length is
>correct.
>
>For sending packets, FreeRADIUS sets the L bit only if it is sending
>fragments.
That is probably the correct be
Thanks for the thorough review Jim!
-Original Message-
From: Jim Schaad
Date: Wednesday, 20 March 2019 at 11:03
To: "draft-ietf-emu-eap-tl...@ietf.org"
Cc: 'EMU WG'
Subject: Review of draft-ietf-emu-eap-tls13-04
Resent-From:
Resent-To: John Mattsson ,
Resent
Noticed the following:
draft-ietf-emu-eap-tls13-04 defines the key hierarchy as
Type-Code= 0x0D
Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
Type-Code, 128)
IV = TLS-Exporter("EXPORTER_EAP_TLS_IV",
Jim Schaad wrote:
>> I suggest writing:
>>
>> TLS 1.3 introduced early application data which is not used in EAP-TLS. A
>> server which receives an "early_data" extension MUST ignore the extension
>> or respond with a HelloRetryRequest as described in Section 4.2.10 of RFC
>> 8446.
>
> That is be
https://tools.ietf.org/html/draft-sy-tls-resumption-group
This document will be discussed today in the TLS WG 11.20 - 12.20. Might be
interesting for the discussion on cross method resumption for TLS-based EAP
methods.
Cheers,
John
___
Emu mailing
does.
Use of this draft requires pre-distributing all intermediary certificates.
John
-Original Message-
From: TLS on behalf of John Mattsson
Date: Friday, 29 March 2019 at 10:30
To: "t...@ietf.org"
Subject: [TLS] Comment on draft-thomson-tls-sic-00
Hi,
I a
time on TLS 1.2.
Cheers,
John
-Original Message-
From: John Mattsson
Date: Friday, 29 March 2019 at 11:34
To: "t...@ietf.org"
Subject: Re: Comment on draft-thomson-tls-sic-00
Some more comments after reading the draft in detail.
- The abstract and introduction
Michael Richardson wrote:
>I implemented server side EAP-SIM and EAP-AKA back 16 some years ago.
>Based upon the many emails I got asking for help configuring EAP-SIM, and
>the zero I got for EAP-AKA, I have never been sure to what extend AKA
>really go out there. Is the nano-SIM in my phone SIM
I think it is of utter importance that PFS for AKA gets published and deployed.
The great SIM heist was a disaster for cellular security. The extension of the
heist is not known, and the report from Gemalto was a joke trying to sweep
thing under the rug. Potentially billions of secret keys where
eers,
John
-Original Message-
From: "internet-dra...@ietf.org"
Date: Sunday, 26 May 2019 at 12:01
To: Mohit Sethi , John Mattsson ,
Sean Turner
Subject: New Version Notification for draft-ms-emu-eaptlscert-03.txt
A new version of I-D, draft-ms-emu-eaptlscert-03.txt
h
raft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the EAP Method Update WG of the IETF.
Title : Using EAP-TLS with TLS 1.3
Authors : John Mattsson
Mohit Sethi
Filename
I think this should be moved forward quickly.
If Alan submits the -01 version that was promised in February :) (including
changes addressing Mohit's comments) I think the chairs should do adoption and
WGLC quickly after each other.
Cheers,
John
-Original Message-
From: Emu on behalf
I support adoption. I do not have any more comments at the moment, but I will
review the next version.
Good that this draft is moving forward. Now that RFC5448bis and EAP-TLS 1.3 are
past WGLC it would be good if we could have some more discussion regarding the
other two drafts concerning TLS-b
Hi,
Based on the discussion on the list and at the meeting today I suggest the
following changes to Section 2.1, 2.5, and figures. When we agree I will make a
commit to GitHub and submit a new version of the draft.
With the solution suggested by Jim, there should be no need to force
NewSession
text fragment for commit need to be chosen so that the
string does not collide with any other strings used.
Cheers,
John
-Original Message-
From: John Mattsson
Date: Wednesday, 24 July 2019 at 20:49
To: Alan DeKok , Jouni Malinen , Jim
Schaad
Cc: EMU WG
Subject: Re: [Emu] WGLC completed for
Hi,
Minor comments on the 01 version. Otherwise I think the document is ready for
WGLC.
- I agree with Mohit that the title should be changed to something like
"EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP"
- Abstracts in RFCs cannot have references. [RFC5247] and [AKAP] need to be
Message-
From: Alan DeKok
Date: Monday, 29 July 2019 at 00:51
To: Jim Schaad
Cc: Jouni Malinen , John Mattsson , EMU
WG
Subject: Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05
On Jul 28, 2019, at 5:09 PM, Jim Schaad wrote:
>
> I cannot speak to PEAP, but it
work item of the EAP Method Update WG of the IETF.
Title : Using EAP-TLS with TLS 1.3
Authors : John Mattsson
Mohit Sethi
Filename: draft-ietf-emu-eap-tls13-06.txt
Pages : 28
Date
The draft should probably mention X25519 which is the name of the
Diffie-Hellman function defined in RFC 7748. Curve25519 is the group.
- "as specified in Section 2 of [RFC8031] and Section 6.1 of [RFC7748]."
Why refering to two different RFCs?
- The security considerations could sa
Dear chairs,
Looks good to me. Some mostly editorial comments:
- "EAP method" vs. "EAP type"
Just noticed that different documents in EMU WG use these two different terms.
I any of them preferred?
- "TLS and SIM cards"
"SIM cards" is just one side of AKA. There are several network nodes invol
See comments inline
-Original Message-
From: Alan DeKok
Date: Thursday, 12 September 2019 at 15:56
To: Aura Tuomas
Cc: EMU WG , "draft-ietf-emu-eap-tl...@ietf.org"
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from:
Resent to: John Mattsson ,
R
verifies the Finished message.
I don't see why this would be more of a problem in EAP-TLS with TLS 1.3 that in
any other application of EAP-TLS.
/John
-Original Message-
From: Alan DeKok
Date: Wednesday, 18 September 2019 at 15:07
To: "Owen Friel (ofriel)"
Cc: John Mat
chaad , 'Alan DeKok'
Cc: "draft-ietf-emu-eap-tl...@ietf.org" ,
'EMU WG'
Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from:
Resent to: John Mattsson ,
Resent date: Thursday, 19 September 2019 at 11:17
> -Original Messa
n leakage of
certificate sizes."
Cheers,
John
-Original Message-
From: Jim Schaad
Date: Saturday, 3 August 2019 at 23:53
To: "draft-ietf-emu-eap-tl...@ietf.org"
Cc: 'EMU WG'
Subject: POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from:
Resent to: John Mat
-
From: Alan DeKok
Date: Wednesday, 18 September 2019 at 15:21
To: "draft-ietf-emu-eap-tl...@ietf.org" ,
EMU WG
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from:
Resent to: John Mattsson ,
Resent date: Wednesday, 18 September 2019 at 15:21
Just re-r
The changes from -06 to -07 are based on the comments from Jim and Alan
- Mention record padding where it makes sense (introduction, state machine, and
privacy considerations)
- Mention that fig 1 contains neither HelloRetryRequest nor Post-Handshake
messages
- Use the term Commitment Message in
Joseph Salowey wrote:
> Is the current published version up to date with the rest of the comments?
Yes, to my knowledge, the current draft handles all the other comments. If we
decide to leave EAP-TLS PSK discussions for another draft, I think
draft-ietf-emu-eap-tls13-07 is ready to move forwa
not suitable for IoT. I
strongly think we need an EAP method with PSK + PFS for IoT, and the easiest
way to achieve that seems to be EAP-TLS-PSK.
Cheers,
John
From: Eliot Lear
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey
Cc: John Mattsson ,
"draft-ietf-emu-eap-tl...@iet
the main specification.
From: Mohit Sethi M
Date: Thursday, 10 October 2019 at 09:55
To: John Mattsson , Eliot Lear ,
Joseph Salowey
Cc: John Mattsson ,
"draft-ietf-emu-eap-tl...@ietf.org" , EMU WG
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Hi,
Speaking pure
rnal-psk-importer fills a
gap in the TLS 1.3 protocol, but is not a game changer in any way.
John
From: Mohit Sethi M
Date: Thursday, 10 October 2019 at 10:03
To: Eliot Lear , John Mattsson
Cc: "draft-ietf-emu-eap-tl...@ietf.org" ,
John Mattsson , EMU WG
Subject: Re: [Emu] POST WGLC Comm
Mohit Sethi M mailto:mohit.m.se...@ericsson.com wrote:
> Can you give an example of an existing TLS 1.3 deployment that offers both
> resumption PSKs and external PSKs?
Don’t know if it is deployed anywhere, but OpenSSL supports resumption of PSK
sessions. There was a bug that stopped it from
Hi,
I am happy to report that 3GPP just took the decision that nodes supporting
EAP-TLS shall support EAP-TLS with TLS 1.3. The changes apply to all 3GPP
Rel-16 nodes. [1]
The 3GPP profiling for TLS in EAP-TLS now follows the general 3GPP TLS
profiling, which mandates support of TLS 1.3, forbi
forward would be specify
the use of [ID-ietf-tls-tls13-cert-with-extern-psk] in the same new draft as
EAP-TLS with PSK authentication. Does that sound like an acceptable way forward?
Cheers,
John
-Original Message-
From: Russ Housley
Date: Monday, 13 January 2020 at 18:29
To: John Mattsson
Hi Alan,
Thanks for you many good suggestions. I tried to address all your comments and
include all your suggestions in a recent commit to github.
- I did not include an identity section as I did not see how it would fit with
the structure of RFC 5216 that the draft reuses. Instead I expanded t
Hi,
- The new version should address all the received comments from Alan and Russ
regarding EAP, TLS, and Certificate identities.
- New section on identities early in the document discussing identities and
pointing to other sections discussing identities.
- More information given on why some
mostly be a
transport for TLS and that the decisions of which authentication methods to
support should be taken by the TLS WG.
Cheers,
John
-Original Message-
From: Russ Housley
Date: Tuesday, 10 March 2020 at 18:48
To: Mohit Sethi M
Cc: John Mattsson , EMU WG
Subject: Re: [Emu] Late
hat you want to avoid EAP-TLS (cert), EAP-TLS (psk), EAP-TLS
(pwd), etc
John
-Original Message-
From: Alan DeKok
Date: Wednesday, 11 March 2020 at 12:26
To: John Mattsson
Cc: Russ Housley , Mohit Sethi M
, EMU WG
Subject: Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13
Chairs, Alan, WG
What is the status and plans for draft-dekok-emu-tls-eap-types? Several people
have expressed that they would like to see this kind of draft published shortly
after draft-ietf-emu-eap-tls13. But draft-dekok-emu-tls-eap-types appears
rather dead, it is still an individual draft
Hi,
Note that close_notify (no more data) is not an exact replacement for the
Commitment Message (no more handshake data). A change from 0x00 to close_notify
invalidates Figure 6: EAP-TLS unsuccessful client authentication in the
document.
EAP Peer
ient
authentication.
Cheers,
John
-Original Message-
From: Emu on behalf of John Mattsson
Date: Tuesday, 1 September 2020 at 10:10
To: Mohit Sethi M , Alan DeKok
, Jorge Vergara
Cc: Mohit Sethi M , Benjamin Kaduk ,
EMU WG
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3
EAP-Response/
EAP-Type=EAP-TLS >
< EAP-Success
Figure 1: EAP-TLS mutual authentication
Cheers,
John
-Original Message-
From: Alan DeKok
Date: Tuesday, 1 September 2020 at 14:51
To: John Mattsson
Cc: John Mattsson , Mohit Sethi M
, Jor
Hi,
I have reviewed draft-ietf-emu-tls-eap-types-01. Looks good. Two crypto related
comments below:
- "MAC is the MAC function negotiated in TLS 1.3."
There is no MAC function negotiated in TLS 1.3. Also, a modern TLS
implementation would not negotiate any MAC funtion in TLS 1.2 as they would
ssary to update any TEAP TLS 1.2
code, but it definitely feels like a worthwhile thing to do when the
implementation is anyway updated for TLS 1.3.
-Original Message-
From: Emu On Behalf Of Alan DeKok
Sent: Tuesday, September 1, 2020 1:59 PM
To: John Mattsson
Cc: emu@ietf.org
Subject: Re:
a need to
add a note like:
"Note that in TLS 1.3, all application data including the Commitment Message is
protected through authenticated encryption."?
John
-Original Message-
From: Alan DeKok
Date: Tuesday, 22 September 2020 at 15:17
To: Jorge Vergara
Cc: John Mattss
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
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
Looking at the references in the document:
"Suppressing Intermediate Certificates in TLS" has not been updated since March
2019. It looks like the TLS working group is not working on this extension. We
should maybe ask Martin, if he is planning to drive this in the future, or if
it has been rep
Hi Mohit,
Great! I agree.
John
-Original Message-
From: Mohit Sethi M
Date: Friday, 20 November 2020 at 09:11
To: John Mattsson , "emu@ietf.org"
Subject: Re: [Emu] I-D Action: draft-ietf-emu-eaptlscert-07.txt
Hi John,
On 11/20/20 7:33 AM, John Mattsson wrote:
> L
Hi,
TLS 1.3 (RFC 8446) Section 4.6.3 allows both client and server to send a
KeyUpdate Post-Handshake message. Doing so directly after the handshake and
without any application data being sent does not make that much sense, but is
allowed.
Should the draft say something about the KeyUpdate mes
Hi,
Looking at the GitHub version after the latest changes. I don't think the
tradeoffs make sense anymore.
- Full handshake is now 4.5 round-trips
- Resumption is now 4.5 round-trips.
This does not seem like a good tradeoff or optimization at all. If we instead
skipped Resumption, the full h
Hi,
I am not very happy with adding an additional dummy roundtrip to the 5G
certificate authentication. Fragmentation and slow databases can be optimized
away (short chains, small certs, 4K or 9K frames) but a mandatory extra
roundtrip stays forever.
Without fragmentation, EAP-TLS 1.3 is now w
Hi,
I can live with any version, the important thing is that interoperable
implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS
1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.
We (the authors) have addressed all the comments from IESG/TLS WG in GitHub
rg"
Date: Tuesday, 2 February 2021 at 17:28
To: John Mattsson , John Mattsson
, Mohit Sethi
Subject: New Version Notification for draft-ietf-emu-eap-tls13-14.txt
A new version of I-D, draft-ietf-emu-eap-tls13-14.txt
has been successfully submitted by Mohit Sethi and posted to the
IETF rep
Alan DeKok wrote:
>The diagram suggests that it's possible for the EAP-TLS server to separate the
>"TLS Finished" >messages from the "NewSessionTicket" message. There is no
>guidance as to how this is done. >After spending some time going through RFC
>8446 and OpenSSL docs / code, it's not cl
1 - 100 of 185 matches
Mail list logo
