Dear all,
Please send Joe and I requests for presentation slots during IETF 103.
According to the preliminary agenda, we have a 2 hour session on Monday,
November 5, between 16:10-18:10 in room Boromphimarn 1/2.
Don't forget to include the title of your presentation, related drafts,
and the ap
Hi all,
Thank you for participating in the EMU session at IETF 103. A special
thank you to Jim for serving as the jabber scribe.
Minutes from the EMU session at IETF 103 have now been uploaded:
https://datatracker.ietf.org/meeting/103/materials/minutes-103-emu-00
Please report any issues by Nov
s: MAC is dependent on the based AKA authentication.
>
> s/based/base/
> s/AKA/AKA'/
>
>
>> On Nov 13, 2018, at 4:38 AM, Mohit Sethi M
>> wrote:
>>
>> Hi all,
>>
>> Thank you for participating in the EMU session at IETF 103. A special
>> thank yo
I would be very hesitant to mandate RFC 7924. Most EAP-TLS
implementations use existing TLS libraries rather than implementing
their own TLS stack. And many popular TLS libraries don't provide
support for RFC 7924. Please look at :
https://github.com/openssl/openssl/issues/5040 for example.
Us
Hi Alan,
Do you have experience with such cross method resumption? Are there any
deployments that make use of this?
My initial reaction is that such cross method session resumption should
be forbidden. That is because EAP-TLS has different security properties
where both the peer and server are
Hi Alan,
Thanks for bringing this up. I agree that we should take this
opportunity to fix other EAP methods which rely on TLS for the outer
tunnel. I think that these updates merit a separate document. But I am
not certain why the two documents need to be published simultaneously?
--Mohit
On
Hi John, Alan, and others,
The recommendations in this document may be used by all TLS-based EAP
methods. However, fragmenting large certificates and certificate chains
into many small messages is less of a problem when only one side
(server) is authenticating with certificates.
--Mohit
On 2/
Hi Alan,
On 2/5/19 3:13 PM, Alan DeKok wrote:
> On Feb 5, 2019, at 12:19 AM, Mohit Sethi M wrote:
>> Do you have experience with such cross method resumption? Are there any
>> deployments that make use of this?
>There are no deployments that make use of it. It'
lable).
--Mohit
On 2/5/19 3:16 PM, Alan DeKok wrote:
> On Feb 5, 2019, at 12:25 AM, Mohit Sethi M wrote:
>> Thanks for bringing this up. I agree that we should take this
>> opportunity to fix other EAP methods which rely on TLS for the outer
>> tunnel. I think that these updates
Hi Alan,
On 2/5/19 5:48 PM, Alan DeKok wrote:
> On Feb 5, 2019, at 10:18 AM, Mohit Sethi M wrote:
>> But session resumption is not simply about changing one byte in the EAP
>> conversation. If you look at Figure 2 of draft-ietf-emu-eap-tls13-03
>> (https://tools.ietf.org/ht
don't want EAP-TLS to lie around for that long.
Modular independent specs are better in my opinion.
--Mohit
On 2/5/19 5:46 PM, Alan DeKok wrote:
> On Feb 5, 2019, at 10:40 AM, Mohit Sethi M wrote:
>> One could use the same argument. Those only interested in implementing
>> EA
Hi Alan, John,
On 2/6/19 2:44 PM, Alan DeKok wrote:
> On Feb 6, 2019, at 3:54 AM, John Mattsson wrote:
>> 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: "Wh
Dear Dr. Pala,
On 2/12/19 7:36 PM, Dr. Pala wrote:
Hi all,
I am working on a draft for credentials management via EAP. When looking at the
different specifications, it seems a bit weird that EAP does not provide
Fragmentation control and requires each method to define their own way.
This, led
rently. However, for example,
EAP-TTLS RFC closed it tightly saying that even a single-fragment message
should have it nevertheless on its redundancy.
~Oleg
On Thu, Feb 14, 2019 at 1:54 PM Mohit Sethi M
mailto:mohit.m.se...@ericsson.com>> wrote:
Dear Dr. Pala,
On 2/12/19 7:36 PM, Dr. Pa
Dear all,
Some of you have already sent in a request for presentation time during
the EMU session @ IETF 104. Thank you!
For those who haven't, please send Joe and I requests for presentation
slots. We have a 2 hour session on Monday, March 25, between
09:00-11:00 in room Berlin/Brussels.
Do
Hi Jari and co-authors,
The WGLC for this document is now complete. Can you please address the minor
comments provided by John and upload a new version.
The following 2 papers on the AKA protocol were also brought to our attention:
1. https://eprint.iacr.org/2018/1175.pdf
2.
http://homepage.div
Dear all,
We have a 2 hour session tomorrow (Monday, 25th March) morning between
09:00-11:00 in room Berlin/Brussels.
If you are presenting, please send us your slides by midnight tonight.
If you have any last minute updates to the slides, we can also try to
upload newer versions tomorrow morn
Hi all,
Thank you for participating in the EMU session at IETF 104. A special
thank you to Max for taking the minutes and to Elliot for serving as the
jabber scribe.
Minutes from the EMU session at IETF 104 have now been uploaded:
https://datatracker.ietf.org/meeting/104/materials/minutes-104-e
Chair hat on:
The draft needs to be formally adopted as a working group item before moving to
last call.
Chair hat off:
I support the adoption of this draft as a working group item. This is a charter
item and the draft is simple enough to move forward rather quickly. The code
has been updated
There have been several reviews of different aspects of this draft in the past:
Jim provided a complete review here:
https://mailarchive.ietf.org/arch/msg/emu/ZDwpgyOL5eBPgyOGwXqxj1VhX-4
A discussion about the L-bit and fragmentation here:
https://mailarchive.ietf.org/arch/msg/emu/ZexFr7GROnvNO
In addition to my previous comment on this draft:
https://mailarchive.ietf.org/arch/msg/emu/eJ_xCqn7Eq2fzx6tuDS0PDdBwkI
I think that the title should be made more explicit to something along the
lines: Session-Id derivation for EAP-SIM, EAP-AKA and EAP-PEAP.
--Mohit
On 7/3/19 2:35 PM, IETF Sec
Dear all,
Thank you for a productive meeting @ IETF 105. We had discussed the new charter
text during the working group session in Montreal. Please find the same text
below. This text builds upon our current charter. Feel free to suggest changes.
RFC 2418 section 2.2 https://tools.ietf.org/html
Hi Michael,
On 8/22/19 10:46 PM, Michael Richardson wrote:
Mohit Sethi M <mailto:mohit.m.se...@ericsson.com>
wrote:
> At the same time, some new use cases for EAP have been identified. EAP
> is now more broadly in mobile network authentication. The group will
> upda
as NFC, dynamically generated QR codes, audio, and visible light.
Best regards, Rene
Forwarded Message
Subject:[Emu] Re-charter text
Date: Wed, 21 Aug 2019 08:13:51 +
From: Mohit Sethi M
<mailto:mohit.m.se...@ericsson.com>
To: emu@ietf.org<mailto:emu@
Dear all,
Please send in your comments on the charter text by Wednesday, September 18,
2019.
Joe and Mohit
On 8/21/19 11:13 AM, Mohit Sethi M wrote:
Dear all,
Thank you for a productive meeting @ IETF 105. We had discussed the new charter
text during the working group session in Montreal
The current re-charter text is now in github for convenient issue and change
tracking:
We have incorporated the suggestions from John and Rene to the current text:
https://github.com/emu-wg/charter/blob/master/emu-charter.md
Joe and Mohit
On 9/11/19 9:50 PM, Mohit Sethi M wrote:
Dear all
pervasive surveillance.
This last point, maybe could be divided in several sentences, since I find it
too long and, thus, hard to follow.
Many thanks for your efforts.
Best regards,
Georgios
On Sep 11, 2019, at 20:50, Mohit Sethi M
mailto:mohit.m.se...@ericsson.com>> wrote:
Dear all,
Hi,
Speaking purely as an individual contributor. I agree that this is a use-case
we should address. I am open to discussions whether it should be done in this
draft or separately and whether we should have a separate method type or use
the same.
@Elliot: I understand your discomfort with cons
I wouldn't say that TLS 1.3 is wrong but there is some stuff that could benefit
from further clarification. For example: the current TLS 1.3 spec requires
external PSKs to be provisioned for a specific hash function. Then there is
also the discussion on how does a server handle external PSK vs.
aft-ietf-emu-eap-tls13-07>
draft if that is what the general consensus is.
--Mohit
On 10/10/19 12:24 PM, Eliot Lear wrote:
Hi Mohit,
On 10 Oct 2019, at 09:55, Mohit Sethi M
mailto:mohit.m.se...@ericsson.com>> wrote:
@Elliot: I understand your discomfort with constraining TLS 1.3.
Yes, but I do not see how EAP would differ from any other TLS deployment with
external PSK.
Can you give an example of an existing TLS 1.3 deployment that offers both
resumption PSKs and external PSKs?
EAP-TLS would not be different from other TLS deployments with external PSKs.
However, so fa
external PSK before checking for resumption PSKs.
I think we can include EAP-TLS-PSK without major changes to the current
document. I only want to ensure that EAP-TLS-PSK does not leave any
implementation ambiguities.
--Mohit
On 10/10/19 7:18 PM, John Mattsson wrote:
> Mohit Seth
there are good
reasons not to limit the scope), I am also happy with the current text (since
allows EAP-CREDS to be discussed).
Thanks,
Max
On 9/21/19 6:16 AM, Mohit Sethi M wrote:
Hi Georgios,
Thanks for reading the charter. I have addressed your comments on github. Here
is the updated t
possible to participate to that meeting ? If so, can you please let us know the
meetings' details... ?
Last but not least - I sent you the request earlier for a slot at IETF 106 for
EAP-CREDS and I would like to confirm again with you we have the slot (I do not
recall seeing your reply to that
Hi Ben,
Thanks for the customary careful review. Answers in-line:
On 10/31/19 4:24 PM, Benjamin Kaduk via Datatracker wrote:
Benjamin Kaduk has entered the following ballot position for
charter-ietf-emu-05-02: No Objection
When responding, please keep the subject line intact and reply to all
em
Dear all,
Some of you have already sent in a request for presentation time during
the EMU session @ IETF 106. Thank you!
For those who haven't, please send Joe and I requests for presentation
slots. We have a 2 hour session on Monday, November 18, between
15:50-17:50 in room Hullet.
Don't for
Dear all,
This email initiates the working group last call (WGLC) for
draft-ietf-emu-eap-session-id
(https://tools.ietf.org/html/draft-ietf-emu-eap-session-id-01).0
If you have any remaining concerns or issues, please comment on the
mailing list before the WGLC expires on December 10, 2019.
T
Hi all,
Thank you for participating in the EMU session at IETF 106. A special
thank you to Eliot for volunteering as the minute taker.
Meeting minutes from the EMU session at IETF 106 have now been uploaded:
https://datatracker.ietf.org/meeting/106/materials/minutes-106-emu-00
Please report any
e with the provisions of BCP 78 and BCP 79 have already been
filed for draft-ietf-emu-eap-session-id?
--Mohit
On 11/26/19 3:08 PM, Mohit Sethi M wrote:
> Dear all,
>
> This email initiates the working group last call (WGLC) for
> draft-ietf-emu-eap-session-id
> (https://tools.ietf.or
Hi Alan,
On 12/28/19 3:29 PM, Alan DeKok wrote:
> On Dec 27, 2019, at 1:54 PM,internet-dra...@ietf.org wrote:
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-08
>Which adds some text about identities:
>
> It is REC
Hi Alan,
On 12/28/19 3:29 PM, Alan DeKok wrote:
> On Dec 27, 2019, at 1:54 PM, internet-dra...@ietf.org wrote:
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-08
>Which adds some text about identities:
>
> It is REC
On 1/16/20 6:07 AM, Benjamin Kaduk wrote:
> Is there anything better for implementations to actually do (as distinct
> from what we write down as recommendations) than to start setting up a
> parallel (purpose-specific) PKI now and trusting that in parallel with what
> they're currently doing, with
Hi Alan,
Thanks for your careful and detailed reviews. They are extremely helpful. We
have submitted a new version addressing your feedback.
Please see in-line for specific actions taken. Here you can see the diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-01.
--Mohit
On 3/2
Hi Russ,
You can listen here: https://youtu.be/YJLG4JUftqI?t=1144
We plan to support it in EAP-TLS-PSK instead:
https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00. We have
already added a reference to draft-ietf-tls-tls13-cert-with-extern-psk
and plan to use it. I think using an ext
everything that TLS 1.3 supports)
>
> I sympatise with earlier comments in the group that EAP should 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
Thank you Russ. We have updated the text as suggested:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-02
--Mohit
On 3/9/20 11:09 PM, Russ Housley wrote:
I read the document, and I think it is read to go after one editorial fix. The
term "trust anchor" is used many times in the doc
No hat!
I support the adoption of this document!
--Mohit
On 4/3/20 11:48 PM, Alan DeKok wrote:
> https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-01
>
>I haven't seen much discussion on the document. There are still some open
> questions:
>
> * should it be published simultaneousl
This is a call for adoption of draft-dekok-emu-tls-eap-types
(https://datatracker.ietf.org/doc/draft-dekok-emu-tls-eap-types/) as a
working group item.
Please indicate if you have any objections by May 4th, 2020.
Joe and Mohit
___
Emu mailing list
Em
Hi Alan,
On 4/19/20 7:18 PM, Alan DeKok wrote:
>
>> On Apr 18, 2020, at 4:13 PM, Joseph Salowey wrote:
>>
>> This is a call for adoption of draft-aura-eap-noob-08.txt [1] as a working
>> group item. This draft has been discussed in several IETF meetings and
>> would be the starting point for t
Dear all,
We did not have a face-to-face meeting in Vancouver for IETF 107. At
this point, the IETF 108 meeting in Madrid is also uncertain.
We are therefore considering a virtual interim meeting for EMU during
middle/end of May 2020. Here are some proposed dates and time slots:
https://doodle.
Dear all,
Reminder: please respond to the poll for a potential virtual interim in
May: https://doodle.com/poll/vxy5vc4g3cnegpdr
Joe and Mohit
On 4/20/20 2:11 AM, Mohit Sethi M wrote:
> Dear all,
>
> We did not have a face-to-face meeting in Vancouver for IETF 107. At
> this point,
Hi Max,
Tuomas can give you a definite answer. My understanding is that error
1001 should be sent by the server if the received identity does not
follow the requirements of draft-aura-eap-noob. Besides, implementing
the stricter checks of this draft is easier than validating the ABNF of
RFC754
Hi Eliot,
On 4/24/20 4:22 PM, Eliot Lear wrote:
Hi Mohit
On 24 Apr 2020, at 15:02, Mohit Sethi M
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
wrote:
Hi Max,
Tuomas can give you a definite answer. My understanding is that error
1001 should be sent by the server if the re
Mohit Sethi M wrote:
> Dear all,
>
> Reminder: please respond to the poll for a potential virtual interim in
> May: https://doodle.com/poll/vxy5vc4g3cnegpdr
>
> Joe and Mohit
>
> On 4/20/20 2:11 AM, Mohit Sethi M wrote:
>> Dear all,
>>
>> We did not have a fac
.
Joe and Mohit
On 4/20/20 1:53 AM, Mohit Sethi M wrote:
> This is a call for adoption of draft-dekok-emu-tls-eap-types
> (https://datatracker.ietf.org/doc/draft-dekok-emu-tls-eap-types/) as a
> working group item.
>
> Please indicate if you have any objections by May 4th, 2020.
&g
You have a chance to influence how the upcoming IETF meetings for this year are
organized. Please answer the survey if you haven't already. See the details
below.
Here is the link for your convenience: https://www.surveymonkey.com/r/5328FFJ
--Mohit
Begin forwarded message:
From: IETF Executiv
Hi Hannes,
I have submitted a new version of the draft which I believe addresses
your concerns. Here is a diff for your convenience:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-03
While Alan and Jouni have already provided excellent answers to most of
your comments, in-line you
e and Mohit
JOIN WEBEX MEETING
https://ietf.webex.com/ietf/j.php?MTID=mc9df4dccd3859204bde061bde4848491
Meeting number (access code): 618 538 077 Meeting password: Sx2edf4mWU3
On 5/5/20 11:38 AM, Mohit Sethi M wrote:
> The poll is now closed. We will have a 90-minute virtual interim meeting
&
Dear all,
Thank you for participating in the EMU virtual interim on Friday. A
special thank you to Max Crone for volunteering as the minute taker.
Meeting minutes and bluesheets from the virtual interim have now been
uploaded.
Minutes:
https://datatracker.ietf.org/meeting/interim-2020-emu-01/
I would add that there is also an early implementation of EAP-TLS-PSK:
https://github.com/rohitshubham/EAP-TLS-PSK
We had agreed that external PSK authentication for EAP-TLS will use a new
method type number. The draft for EAP-TLS-PSK
(https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-
Hi Roman,
Thanks for your usual careful review. I have submitted a new version
that hopefully addresses all the issues. Here is the diff for your
convenience: https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-10
Please see in-line for details on how we have handled each issue.
--Mohit
tant to add these since they are still in early phases
of development. However, I have now added a section titled "New
Certificate Types and Compression Algorithms". Hope this is sufficient.
>
> Ciao
> Hannes
>
> -Original Message-
> From: Mohit Sethi M
> Sent:
Hi Hannes,
Thanks for the follow up. I have submitted a new version which should
address your concerns. Here is a diff for your convenience:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-05
Please see in-line for details.
I believe that the draft is now ready for publication.
-
Hi Hannes,
On 6/12/20 11:29 AM, Hannes Tschofenig wrote:
A short follow-up on my own review:
I wrote:
"
Pre-Shared Key (PSK) authentication SHALL NOT be used except
for resumption.
"
What you want to say that that EAP-TLS MUST NOT use external PSKs. I wonder why
you want to rule that use
Hi Hannes,
Unfortunately you are wrong here. The design decision was in fact taken to
avoid changes to the underlying TLS implementation while also avoiding changes
to RFC 3748. To summarize:
Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP-TLS
is non-trivial. See hi
are to be expected.
--Mohit
The current solution in the draft, for example, does not work with
Mbed TLS because you cannot tell the stack to suddenly bypass the
encryption layer (after successfully establishing it) to send a
plaintext message.
Ciao
Hannes
*From:* Mohit Sethi M
*Sent
to
an unauthenticated peer in this case is fine.
I wonder how others feel about this change.
--Mohit
On 6/16/20 1:43 PM, Hannes Tschofenig wrote:
Hi Mohit,
See below. Thanks for your super quick response.
*From:* Mohit Sethi M
*Sent:* Tuesday, June 16, 2020 12:25 PM
*To:* Hannes
Hi all,
I am not a crypto expert and my knowledge of public key encodings is
based on my work with Rene Struik for a different draft.
The current text in draft-ietf-emu-aka-pfs-04 says "For P-256, the
length of this value is 32 bytes, encoded in binary". Shouldn't this be
33 bytes? And wouldn'
Hi Steve,
I have answered each question in-line.
On 6/29/20 2:54 AM, Steve Hanna via Datatracker wrote:
> Reviewer: Steve Hanna
> Review result: Not Ready
>
> Reviewer: Steve Hanna
> Review result: Not Ready
>
> I have reviewed this document as part of the security directorate's ongoing
> effort
Hi Max,
Good catch. This will be fixed in the next version!
--Mohit
On 7/3/20 12:21 PM, Max Crone wrote:
> Hi,
>
> I noticed that the examples messages in Appendix F
> (https://tools.ietf.org/html/draft-ietf-emu-eap-noob-01#appendix-F)
> use the curve name "Curve25519" in the JWK object. Howev
Dear all,
At the virtual IETF 108 meeting, we will have a 50 minute session on
Friday, July 31, between 13:00 - 13:50 UTC.
Please send Joe and I (emu-cha...@ietf.org) requests for presentation
slots.
Don't forget to include the title of your presentation, related drafts,
and the approximate a
a BIT STRING.
My conclusion is that the current draft is correct:
* For P-256, the length of this value is 32 bytes, encoded in
binary as specified in [FIPS186-4].
Russ
On Jun 24, 2020, at 1:10 AM, Mohit Sethi M
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
wrote:
Hi
Arghh. I feel very protected with unreadable URLs of fireeye. Fixed pointer to
the reference:
https://www.secg.org/SEC2-Ver-1.0.pdf
The relevant section is 2.7.1.
--Mohit
On 7/9/20 9:45 AM, Mohit Sethi M wrote:
Rene, Russ, and I had an offline email exchange about this issue. I think we
are
Hi Michael,
Thanks for the input. This is indeed something we should discuss at the
upcoming virtual EMU meeting.
Some colleagues (Ingles Sanchez et al.) have also investigated and documented
the savings that might result from the use of CBOR in EAP-NOOB:
https://hal.archives-ouvertes.fr/hal-0
Thanks Carsten. This is very valuable input for the working group before
it makes a critical decision.
--Mohit
On 7/11/20 4:40 PM, Carsten Bormann wrote:
> Hi Mohit,
>
>
>> On 2020-07-11, at 15:27, Mohit Sethi M
>> wrote:
>>
>> Hi Michael,
>>
>> T
Dear all,
draft-ietf-emu-eap-tls13 is currently in the state "AD Evaluation::AD
Followup". Our AD (Roman) had done an excellent review
(https://mailarchive.ietf.org/arch/msg/emu/k6K98OhuOQmbzSAgGWCtSIVv3Qk/), which
I addressed in version 10
(https://mailarchive.ietf.org/arch/msg/emu/IopJTjefyV
on the timing of the commitment message - which
was apparently an incorrect translation at the time. Interop has been tested
with FreeRADIUS and hostapd.
-Original Message-
From: Emu <mailto:emu-boun...@ietf.org> On Behalf Of Alan
DeKok
Sent: Monday, July 13, 2020 10:52 A
Dear all,
Instead of the usual 120 minutes, we have a 50 minute session for EMU @
IETF 108 on Friday, July 31st. Here is our current agenda for the meeting:
https://datatracker.ietf.org/doc/agenda-108-emu/
As you notice, the agenda is rather packed. There is no possibility to
extend the duratio
Dear all,
Thank you for participating in the EMU session at IETF 108. A special
thank you to Aleksi Peltonen for serving as the note taker.
Minutes from the EMU session at IETF 108 have now been uploaded:
https://datatracker.ietf.org/doc/minutes-108-emu/
Please report any issues by August 10, 2
Dear all,
Thanks all for the discussion on the commitment message.
draft-ietf-emu-eap-tls13-10
(https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-10) in figure 2 shows the
ticket establishment and commitment message:
EAP Peer EAP Server
I seem to agree with the consensus around the usage of close_notify
instead of a byte of 0x00. In fact, I can't even remember the reason for
that choice anymore.
The draft is now updated in github to specify the usage of close_notify:
https://github.com/emu-wg/draft-ietf-emu-eap-tls13
Here is t
Hi Terry,
Section 5.7 "Resumption" says:
> When resumption occurs, it is based on cached information at the TLS
> layer. To perform resumption in a secure way, the EAP-TLS peer and
> EAP-TLS server need to be able to securely retrieve authorization
> information such as certificate cha
, at 8:40 AM, Terry Burton wrote:
>> On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M
>> wrote:
>>> Section 5.7 "Resumption" says:
>>>
>>>> When resumption occurs, it is based on cached information at the TLS
>>>>layer. To perform
Hi Terry,
I surely must be missing something here:
Packet 6 is an EAP-Response from the peer. Packet 7 contains another
EAP-Response inside a RADIUS Access-Request? That doesn't make sense. EAP is
lock-step request-response protocol. The conversation you describe is incorrect.
My reading of RF
Hi Terry,
On 8/20/20 3:02 PM, Terry Burton wrote:
On Thu, 20 Aug 2020 at 10:00, Mohit Sethi M
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
wrote:
I surely must be missing something here:
Packet 6 is an EAP-Response from the peer. Packet 7 contains another
EAP-Response in
authenticator/server. Sending a NAK in the other direction would be a
violation of RFC 3748 and is not supported or implemented.
--Mohit
On 8/20/20 4:26 PM, Terry Burton wrote:
> On Thu, 20 Aug 2020 at 13:34, Mohit Sethi M
> wrote:
> <...snip...>
>> It's also contrary to
Hi Terry,
On 8/20/20 5:41 PM, Terry Burton wrote:
> On Thu, 20 Aug 2020 at 14:54, Mohit Sethi M
> wrote:
>> It would be a misinterpretation to say that everything from the
>> authenticator is an EAP-Request hence EAP-Failure is also a Request.
>> It's an EAP packe
Hi Alan,
On 8/21/20 3:50 PM, Alan DeKok wrote:
> On Aug 21, 2020, at 3:27 AM, Mohit Sethi M
> wrote:
>> Sorry for nitpicking here. But it is important to distinguish the two
>> components that comprise a AAA server: RADIUS server and EAP server. RFC
>> 3579 briefly al
Hi again,
On 8/23/20 7:12 PM, Alan DeKok wrote:
> On Aug 23, 2020, at 9:48 AM, Mohit Sethi M wrote:
>> Sorry, but you are missing context here. The discussion was no longer
>> about sending an EAP failure when no suitable EAP methods are available.
>> Terry and I were discus
Dear all,
This version includes additional clarifications on resumption suggested
by Terry Burton. Based on the mailing list discussion, we still use
1-byte of encrypted application data as the commitment message:
https://mailarchive.ietf.org/arch/msg/emu/6f36UTSysJ_xzGdkOtC4TDNTZbI/.
--Mohit
Hi Elwyn,
Thank you for the careful review. We have updated the draft based on
your feedback. Here is the diff for you convenience:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-06.
See our responses in-line.
--Mohit
On 10/24/20 1:44 PM, Elwyn Davies via Datatracker wrote:
> Rev
Hi Barry,
Thank you for the careful review. I have updated the draft in github
(https://github.com/emu-wg/eaptls-longcert). Here is the diff for your
convenience:
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eaptlscert.txt&url2=https://emu-wg.github.io/eaptls-lon
Hi Stefan,
Thank you for the review. I have updated the draft in github
(https://github.com/emu-wg/eaptls-longcert). Here is the diff for your
convenience:
https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eaptlscert.txt&url2=https://emu-wg.github.io/eaptls-longcert/d
Dear all,
Sorry for the radio silence. I have over-committed myself to too many things. I
think I have now read the entire discussion on OCSP.
EAP-TLS with TLS 1.3 is a working group document so the text will reflect
whatever the working group wants. The authors and contributors are at the
ser
ution using locally stored data.
If used in a local corporate context, a cache mechanism could be provided with
pre-loaded relevant certs.
But I don’t know how this may or may not interoperate with deployed base of EAP
implementations.
Stefan Santesson
On 2020-10-30, 14:48, "Moh
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 all,
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 authorizatio
t a CertificateEntry (except the trust anchor) without a valid
CertificateStatus extension as invalid and abort the handshake with an
appropriate alert.
--Mohit
On 11/1/20 6:48 PM, Michael Richardson wrote:
Mohit Sethi M
<mailto:mohit.m.sethi=40ericsson@dmarc.ietf.org>
wrote:
&
iate alert.
“
This sounds like a good compromise for me.
Ciao
Hannes
PS: Mohit, maybe you can help implement OCSP to EAP-TLS in Mbed TLS. I am
looking forward to see OCSP supported added to EDHOC by John.
From: Emu <mailto:emu-boun...@ietf.org> On Behalf Of
Mohit Sethi M
Sent: Saturday, Octob
is case, the “SHOULD” statement gives an implementer absolutely not idea
when or when it would be good to implement this feature.
Besides this, I don’t even believe that the TLS 1.3 spec gives you that freedom
for this specific feature anyway.
Ciao
Hannes
From: Mohit Sethi M
<mailto
1 - 100 of 143 matches
Mail list logo
