Bernard,
now I got your point :-)
Took a little bit longer
Hannes Tschofenig wrote:
Hi Bernard,
we did not know how the server identity should look like.
Hence, we just said that it is a blog. I guess the same approach was
used in PAX.
Ciao
Hannes
Bernard Aboba wrote:
Just
Hi Jouni,
thanks for the detailed comments. Please find my response inline:
Jouni Malinen wrote:
draft-clancy-emu-eap-shared-secret-00.txt
KDFData:
What defines the arbitrary data (KDFData_Client and KDFData_Server)
that is to be included in the KDF? What is this used for? Chapter 7.4
Here is a forward from the EMU DT mailing list where I mentioned that we
did a formal analysis for EAP-GPSK.
As we update the protocol I will also reapply it again.
Ciao
Hannes
-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im
Auftrag von Tschofenig, Hannes
Hi Michaela,
M. Vanderveen wrote:
I agree with Lakshminath regarding the point about having actual
ciphersuites in a different RFC, so they can be updated.
I don't agree. Why would this be useful? You then have to read two
documents to implement the EAP method. It would be the same as
Hi all,
the current version of the document
http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt
still supports AES-EAX:
+---++-+---++
| CSuite/ | KS | Encryption | Integrity | Key Derivation |
|
Hi Joe,
this was recorded as issue#4:
http://www.tschofenig.com:8080/eap-gpsk/issue4
I think that we should put a separator in there.
Ciao
Hannes
Joseph Salowey (jsalowey) schrieb:
There currently is no separator between the identities in the GPSK key
derivation which means that 'a || bc'
We could also use the null character as separator.
Ciao
Hannes
M. Vanderveen schrieb:
I have heard from folks who actually implemented such key derivations
that the null character would work just as well.
*/Joseph Salowey (jsalowey) [EMAIL PROTECTED]/* wrote:
There currently is no
Hi all,
based on the feedback of Victor and Jouni we have updated the draft.
Please find the updated draft here:
http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-03.txt
We believe that the draft is ready for WGLC.
Ciao
Hannes
We discussed this already several times and this lead me to work on a
draft together with Thomas Otto:
http://tools.ietf.org/id/draft-otto-emu-eap-tls-psk-02.txt
Ciao
Hannes
Narayanan, Vidya wrote:
All,
I have a question on support for the TLS PSK ciphersuites in EAP-TLS.
Looking at the
Hi Vidya,
just a quick comment.
Narayanan, Vidya wrote:
All,
I reviewed the document and unfortunately, don't feel it is ready for
publication yet. I will only get into the meta issues here - nits can be
addressed later.
Major Comments:
---
1. Overall, I'm looking for a
I am not surprised to hear that EAP method authors agree that no further
EAP methods should be developed.
Part of the problem with EAP methods is that people should have started
to standardize them within the IETF several years ago. Unfortunately,
there was no interest by some of the EAP method
Hi all,
before we spend more time considering EAP tunneling methods like PEAP
and TTLS I would like to hear the opinion of our ADs on this subject.
So far, the working assumption was that EAP methods that tunnel EAP are
outside the scope of the working group. These statements were also
I see it a bit differently since I was at many EAP meetings where EAP
method authors wanted to work on standards track EAP methods.
Ciao
Hannes
Bernard Aboba wrote:
Part of the problem with EAP methods is that people should have
started to standardize them within the IETF several years ago.
expressed on the DT mailing list). This would, however,
require the TLS working group to work on the TLS Inner Application,
which I also think is useful. This approach was, however, ruled out by
the ADs.
Hannes Tschofenig wrote:
Hi all,
before we spend more time considering EAP tunneling methods
+ Channel Bindings (20 min)
- draft-clancy-emu-chbind-00.txt
- draft-clancy-emu-aaapay-00.txt
I haven't seen these documents and I cannot find them either
do you have pointers to them?
___
Emu mailing list
Emu@ietf.org
Hi Dan,
you are asking me which EAP methods support weak passwords?
If so, here are a few examples:
* TTLS
* PEAP
* EAP-PAX
* EAP-FAST
* EAP-IKEv2
Please note that I am not against doing the work; I would just like to
understand what the main motivation is.
Ciao
Hannes
Dan Harkins wrote:
Hi Bernard,
Bernard Aboba wrote:
Zero knowledge is definitely crypto-intensive. For example, to get both
privacy and strong password protection, at least two DHs are required.
However, there are circumstances where server-side certificates aren't
acceptable. Even in today, many/(most?)
To continue on the previous discussions about this subject (with a
different subject):
a) I believe the document does not do a good job in describing where you
plan to use this method in comparison to the already ongoing work on
tunneled mechanisms.
To quote Bernard on a previous mailing list
Hi Pasi,
thanks for the new round of comments.
[EMAIL PROTECTED] wrote:
Charles Clancy wrote:
See comments inline. An updated draft will be released shortly.
Also note that the new draft addresses Dan's comments about
resistance to dictionary attack.
Thanks for the update! I
Hi Alan,
a few questions inline. What is more important for me is what we could at
best accomplish during the meeting.
The following is the draft agenda for IETF 74. Please email
the chairs for any concerns or updates.
Blue sheets and Agenda updates
5 minutes
Hi Sam,
let us start with the problem description: You claim that EAP peer
implementations use PK-based authentication but do not do certificate
validation. This obviously introduces attacks (regardless of channel bindings,
or crypto bindings).
Any evidence that this is really a problem?
of work.
-Violeta
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
Sent: Thursday, January 12, 2012 12:43 PM
To: Cakulev, Violeta (Violeta)
Cc: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); emu@ietf.org
Subject: Re: [Emu] draft-cakulev
Thanks, Jouni. That's a good clarification.
-Original Message-
From: Jouni Malinen
Sent: Saturday, March 28, 2020 9:26 AM
To: Alan DeKok
Cc: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] My review ... was RE: I-D Action:
draft-ietf-emu-eaptlscert-02.txt
On Tue, Mar 24, 2020
to update the roundtrip limit.
Ciao
Hannes
PS: Why aren't you a co-author on this document? You know more about this than
anyone else.
-Original Message-
From: Alan DeKok
Sent: Tuesday, March 24, 2020 3:08 PM
To: Hannes Tschofenig
Cc: Michael Richardson ; emu@ietf.org
Subject: Re: [Emu]
Hi Michael, Hi draft authors,
> I was surprised to get to the end of the document without any suggestions
> about sending certificates by reference rather than value.
Having seen this statement from Michael I have reviewed the document. Two
generic observations about the draft:
1) Many
) deployment environment.. I
might, however, be on the wrong track here.
Having the references to where deployment problems with large
certificates/certificate chains occur would shine light on this aspect.
Ciao
Hannes
From: Eliot Lear
Sent: Tuesday, March 24, 2020 10:02 AM
To: Hannes Tschofenig
Cc
is different because it falls more in the category of home WiFi
usage. This doesn’t really use EAP in my understanding.
Ciao
Hannes
From: Eliot Lear
Sent: Tuesday, March 24, 2020 10:24 AM
To: Hannes Tschofenig
Cc: Michael Richardson ; emu@ietf.org
Subject: Re: [Emu] My review ... was RE: I-D Action
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
apling is supposed to solve since the OCSP messages
are sent in the TLS handshake. I believe there are some EAP-TLS
implementations that support OCSP, but I am not sure if it is actually deployed.
Eliot
On 21 Oct 2020, at 11:02, Hannes Tschofenig
mailto:hannes.tschofe...@arm.com>> wr
Hi Joe,
a few remarks below.
On Fri, Oct 23, 2020 at 12:38 AM Hannes Tschofenig
mailto:hannes.tschofe...@arm.com>> wrote:
Hi Joe,
I do not understand certificate revocation checking is a topic specific to the
use of TLS 1.3 in EAP-TLS.
[Joe] TLS 1.3 discusses OCSP and (SCT). OCSP st
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
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
Tschofenig ; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-09
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 tha
Thanks for the quick turn-over-time.
Looks good to me.
-Original Message-
From: Mohit Sethi M
Sent: Monday, June 15, 2020 11:31 AM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eaptlscert-04
Hi Hannes,
Thanks for the follow up. I have submitted a new version
Hi Mohit,
See below. Thanks for your super quick response.
From: Mohit Sethi M
Sent: Tuesday, June 16, 2020 12:25 PM
To: Hannes Tschofenig ; Mohit Sethi M
; emu@ietf.org
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13
Hi Hannes,
On 6/16/20 12:37 PM, Hannes Tschofenig wrote
the encryption layer
(after successfully establishing it) to send a plaintext message.
Ciao
Hannes
From: Mohit Sethi M
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13
Hi Hannes,
Unfortunately you
Hi Mohit,
Thanks for the super-detailed response.
Give me till tomorrow to parse your response. Glad to hear that you talked
about this topic already.
Ciao
Hannes
From: Mohit Sethi M
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] Commitment
Thanks for the update.
A few more minor comments on -04:
Section 4.1:
"TLS 1.3 [https://tools.ietf.org/html/rfc8446] requires implementations to
support ECC."
This is only true absent an application profile defining something else.
The UTA group has just adopted a WG item that defines such a
Hi all
I read through draft-aura-eap-noob-08 during the call for adoption.
The draft acknowledges that the concept of "onboarding" is a new term for an
old concept, namely network access authentication.
I like the draft from that point of view.
The content looks fine good and the design is
ogress.
Ciao
Hannes
-Original Message-
From: Mohit Sethi M
Sent: Saturday, May 9, 2020 10:49 AM
To: Hannes Tschofenig ; Michael Richardson
; emu@ietf.org
Subject: Re: [Emu] My review ... was RE: I-D Action:
draft-ietf-emu-eaptlscert-02.txt
Hi Hannes,
I have submitted a new version
Hi all,
This has probably been discussed extensively in the EMU group. I am sorry to
bring it up again but I believe this is a bad design decision. I raised it in
my short review just sent to the list but I believe it is worthwhile to point
it out separately.
draft-ietf-emu-eap-tls13
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 case out? It is a perfectly fine use case for
>
Hi all,
I took a quick look at the -09 draft.
Here are a few comments.
1. Introduction
The text in the introduction is confusing. To be honest, this document is
actually not needed because TLS allows you to negotiate version and features..
Obviously, the introduction does not say that and
Hi Mohit,
I am not quite sure how the process for Github issues works in this group. It
seems that you create the issues based on reviews, then you address them
yourself in the draft and you then close the issue yourself.
Is this how it works?
Ciao
Hannes
-Original Message-
From: Emu
Hi Mohit,
* I think it is a reasonable compromise for servers to implement OCSP
stapling. Clients can implement and use it, but they would be compliant even if
they don't. So the updated text would be (as Joe wrote in his email):
“
EAP-TLS servers supporting TLS 1.3 MUST implement
mplementer 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
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschof
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
Hi Mohit,
> Et voilà, we seem to be moving towards a consensus!
That’s indeed exciting.
> PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its
> high time.
Looking forward to it. I would then add the other pieces to TLS 1.3 to make it
complete.
> There have
Thanks, Mohit.
You could also delete the entire paragraph because it adds nothing to what is
already said in the TLS 1.3 spec.
See https://github.com/hannestschofenig/draft-ietf-emu-eap-tls13/pull/1
Ciao
Hannes
From: Mohit Sethi M
Sent: Monday, November 2, 2020 9:58 AM
To: Hannes Tschofenig
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
:36 PM
To: Hannes Tschofenig ; Mohit Sethi M
; Mohit Sethi M
; emu@ietf.org
Subject: Re: [Emu] Making Security Practical ... was RE: Moving towards less
security in 2020 - OCSP
Hi Hannes,
On 11/2/20 11:42 AM, Hannes Tschofenig wrote:
Hi Mohit,
> Et voilà, we seem to be moving towa
I agree with you, Eliot.
I don’t understand for what certificates we would be using OCSP in the EAP-TLS
context, and what would happen if OCSP checks fail.
Ciao
Hannes
From: Eliot Lear
Sent: Monday, November 2, 2020 12:27 PM
To: Hannes Tschofenig
Cc: Mohit Sethi M ; emu@ietf.org
Subject: Re
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,
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,
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,
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,
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,
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
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,
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
Maybe it is a terminology issue but TLS at least requires server-authentication.
From: Emu On Behalf Of Heikki Vatiainen
Sent: Monday, March 7, 2022 2:41 PM
To: Alan DeKok
Cc: EMU WG
Subject: Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3
On Fri, 4 Mar 2022 at 21:44,
Hi all,
I have read through and was wondering what
use case motivated the work on EAP over CoAP.
Where is it planned to be used?
Ciao
Hannes
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
) Working Group worked on this problem:
https://datatracker.ietf.org/wg/nea/about/
Josh
-Original Message-
From: Emu On Behalf Of Hannes Tschofenig
Sent: Friday, October 13, 2023 9:16 AM
To: emu@ietf.org
Subject: [Emu] Network Access Authentication and Attestation
Hi all,
in the AD review
.
Best Regards.
El 13/10/23 a las 10:27, Hannes Tschofenig escribió:
Hi all,
I have read through and was wondering what
use case motivated the work on EAP over CoAP.
Where is it planned to be used?
Ciao
Hannes
___
Emu mailing list
Emu
Hi Jan,
you cannot complain about the use of TLS in EAP when the EAP method you
propose relies on TLS. The TLS-based authentication is an essential part
of the FIDO solution. Without TLS it is completely insecure.
Regarding the key extractor use you describe below: I don't remember
this
Hi all,
in the AD review of the SUIT MUD draft, see
https://datatracker.ietf.org/doc/draft-ietf-suit-mud/ and
https://mailarchive.ietf.org/arch/msg/suit/xRT55NR6fAQuuSYmApXAdC-zO8U/,
Roman noted that we are assuming that an EAT-based attestation mechanism
is available for network access
Like Russ, I am happy to review the draft and contribute suggestions.
Regarding: Do you think this draft should be an EMU working group Item?
I also do not object.
From: Emu On Behalf Of Russ Housley
Sent: Wednesday, April 13, 2022 2:52 PM
To: Joe Salowey ; emu
Subject: Re: [Emu] Call for
Hi Meiling,
Maybe it would be useful to start working on a prototype implementation since
this could give useful insight into the specification work.
Ciao
Hannes
From: Emu On Behalf Of Meiling Chen
Sent: Thursday, May 5, 2022 5:15 AM
To: Joseph Salowey ; emu
Subject: Re: [Emu] Call for
Hi all,
I have a question about the alignment between the text in Section 3.1 of
draft-ietf-emu-bootstrapped-tls-01 and RFC 9258.
RFC 9258 describes how to import external PSKs for use with TLS 1.3.
It does so by defining a function with three inputs, namely an external
identity, an EPSK, and
Thanks, Owen.
-Original Message-
From: Owen Friel (ofriel)
Sent: Friday, December 16, 2022 12:31 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: RE: draft-ietf-emu-bootstrapped-tls
Thanks Hannes. These all make sense and are now all addressed in github and I
will include in draft-02
Hi all,
I have a simple question regarding draft-ietf-emu-bootstrapped-tls-01
Do you see the scope of this specification limited to the use for wired network
access? In Section 2.1 you describe the story as "use DPP if the device
bootstraps against a Wi-Fi network, or TLS-POK if the device
Thanks for sharing the link to the OpenSSL implementation, Heikki.
FWIW there is another EMU draft that also relies on RFC 7250 support ->
draft-ietf-emu-bootstrapped-tls
Ciao
Hannes
Am 03.03.2023 um 10:16 schrieb Heikki Vatiainen:
On Thu, 2 Mar 2023 at 03:34, Meiling Chen
wrote:
I
Hi Owen, Hi Dan,
Thanks for the recent -02 draft update, which addresses a few of my
remarks in my review
https://mailarchive.ietf.org/arch/msg/emu/VNCAFb4BTTOib27s1gIXUOEn_ng/
My question about the relationship with RFC 9258 was not answered and
hence I am giving it another try.
Here is
t to
employ this optimization will have to do a runtime check with every
bootstrap key it holds against the identity the client provides.
"
Let me know what you think.
Ciao
Hannes
Am 22.03.2023 um 20:12 schrieb Dan Harkins:
Hi Hannes,
Sorry for the delay in responding
On
74 matches
Mail list logo
