On Fri, 7 Jun 2024, at 13:15, internet-dra...@ietf.org wrote:
> Internet-Draft draft-ietf-emu-rfc7170bis-19.txt is now available. It 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
>
On Tue, 12 Mar 2024, at 14:45, Jan-Frederik Rieckers wrote:
> On 12.03.24 13:45, Alexander Clouter wrote:
>> On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote:
>>> My understanding here is that the EAP server and client will not
>>> authenticate each other in EAP-TLS,
On Tue, 12 Mar 2024, at 12:37, Yanlei(Ray) wrote:
> My understanding here is that the EAP server and client will not
> authenticate each other in EAP-TLS, and all the authentication will be
> done in the " captive portal ". So why recommend EAP-TLS as a
> provisioning method? Just send the
On Thu, 7 Mar 2024, at 22:38, Peter Yee wrote:
> The deadline for feedback is March 21st. Yes, that's during IETF
> 119 but after the EMU time slot, so hopefully you will have
> formed an opinion by then, if not sooner. We hope to hear
> from lots of you!
>
> 1)
On Mon, 4 Mar 2024, at 19:11, Alan DeKok wrote:
> The downside is that CBOR is likely more expressive than TLVs, and
> perhaps what people should be moving towards. There's no reason to
> stick with TLVs simply because we've been using them for years. It's
> 2024, new technologies exist.
On Mon, 4 Mar 2024, at 10:06, Alexander Clouter wrote:
> On Fri, 1 Mar 2024, at 21:08, Jan-Frederik Rieckers wrote:
>> I just posted a new version of the EAP-FIDO draft.
>>
>> [snipped]
>>
>> Comments are welcome, as always.
>
> Trying to understa
On Fri, 1 Mar 2024, at 21:08, Jan-Frederik Rieckers wrote:
> I just posted a new version of the EAP-FIDO draft.
>
> [snipped]
>
> Comments are welcome, as always.
Trying to understand the need for 'Credentials IDs (PKIDs) in the
authentication request.
My thinking here is "I miss my EAP
On Sun, 3 Mar 2024, at 23:02, Alan DeKok wrote:
>> My proposal would be to just use a dummy (marked optional) Outer-TLV that
>> would be ignored by the other end to avoid this problem; sort of like
>> GREASE...but to fix an insecurity instead.
>
> I think that changes existing implementations.
On Sun, 3 Mar 2024, at 15:52, Alan DeKok wrote:
>> If not, then in theory a MITM might be able to remove the last
>> server-to-peer outer TLV and prepend it to the peer-to-server TLVs, or vice
>> versa, and the MAC would be the same. However, each side knows which outer
>> TLVs
>> it sent before
On Sat, 2 Mar 2024, at 18:20, David Mandelberg wrote:
>> Maybe a TEAPv2 could use ALPN for the TLS jacket to avoid this..erk, I think
>> I may have suggested something that could be retro fitted here without
>> impacting existing implementations; assuming they would just ignore the ALPN.
>
>
On Fri, 1 Mar 2024, at 21:08, Jan-Frederik Rieckers wrote:
> Comments are welcome, as always.
Section 4.1.2
-
It just popped up as an idea in my reply to the the SEC review of TEAP but...
EAP-TLS sub-methods have been copying the version bits since forever. Maybe it
is time to break
On Sat, 2 Mar 2024, at 03:21, David Mandelberg via Datatracker wrote:
>
> (nit) If I understand the TEAP version negotiation and Crypto-Binding
> correctly, the negotiated version is not cryptographically verified until
> either (1) after the first inner method is completed or (2) just before the
Hello,
On Thu, 28 Sep 2023, at 15:47, John Mattsson wrote:
>
> EDHOC is high level very similar to the TLS 1.3 handshake but has much
> smaller message sizes and is therefore useful in IoT. EAP-EDHOC is just
> EDHOC over EAP using the EAP-TLS request and response packet formats.
To help get me
On Mon, 28 Aug 2023, at 15:43, Heikki Vatiainen wrote:
>
>> If an inner method supports export of an Extended Master Session Key
>> (EMSK), then the IMSK SHOULD be derived from the EMSK as defined in
>> [RFC5295].
>
> Why the SHOULD? If something else is done, how could it work with other
>
On Sun, 27 Aug 2023, at 18:16, Heikki Vatiainen wrote:
> RFC 7170 and the current draft have diverged in how IMSK is calculated.
>
> In short:
> 1. RFC 7170 pass EMSK to TLS-PRF whereas the draft passes both EMSK and MSK
> to TLS-PRF.
> 2. While RFC 7170 adjusts only MSK to 32 octet length, the
On Sun, 27 Aug 2023, at 10:57, Heikki Vatiainen wrote:
> Weren't the observed differences against RFC 7170 one the main
> reasons why the draft was needed?
Exactly. In particular it was the use of the EAP-FAST-MSCHAPv2 key derivative
(reversed upper/lower bits) that triggered this and the fun
On Tue, 22 Aug 2023, at 15:57, internet-dra...@ietf.org wrote:
> 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
On Fri, 25 Aug 2023, at 19:10, Heikki Vatiainen wrote:
> When the outer TLS-based EAP is processed by a different EAP server than the
> inner EAP-TLS, then the why inner EAP-TLS resumption shouldn't be simply a
> matter of the EAP peer and the inner EAP server? In this case the outer EAP
>
On Fri, 18 Aug 2023, at 01:01, Michael Richardson wrote:
> I'm not sure it's sane to use EAP-TLS for Inner method myself.
If you mean in the general sense, I can imagine placing the user credential on
a hardware key whilst the machine credential is either a regular software
keychain or even
On Thu, 17 Aug 2023, at 23:33, Alan DeKok wrote:
>> If I did run EAP-TLS as an Inner method (whether once or twice), could I use
>> resumption?
>
> Uh... why didn't anyone mention this before? TEAP is a near-endless
> source of surprises and corner cases.
In fairness I think you could have
On Wed, 2 Aug 2023, at 18:49, Eliot Lear wrote:
> Keep this in mind: end devices should be presumed to be pressed for
> resources, and anything requiring additional unnecessary authentications
> should be avoided in that case.
I could imagine a realtime video streaming device that during a
On Fri, 28 Jul 2023, at 10:30, josh.howl...@gmail.com wrote:
> The fragmentation issue that Heikki mentions is specific to EAP over RADIUS,
> where RADIUS is using UDP transport. It isn’t a property of EAP itself, and
> so I don’t follow why this makes EAP impractical for IoT.
As the
On Sat, 25 Mar 2023, at 12:03, Eliot Lear wrote:
> I ask that as you consider this thread, you think beyond Basic-Auth to the
> PKCS operations.
>
I definitely am not qualified to think on this, I would be a fool to not yield
to those using those attributes!
Other than your group, is anyone
On Sat, 25 Mar 2023, at 01:08, Heikki Vatiainen wrote:
>>> If you are using eapol_test prior to a few TEAP patches (reversed EAP-FAST
>>> MSK calculation and ordering of the Cryptobinding processing) then it
>>> should just work out the box.
> I think the case in question where the inner methods
On Fri, 24 Mar 2023, at 18:41, Alexander Clouter wrote:
> On Fri, 24 Mar 2023, at 17:51, Heikki Vatiainen wrote:
>> The implementation was done based on the RFC and the draft but required
>> tailoring to make it interoperable with wpa_supplicant's eapol_test with
>> c
On Fri, 24 Mar 2023, at 17:51, Heikki Vatiainen wrote:
> My colleague has been working on a TEAP implementation.
"A new contestant has entered the arena..."
> The implementation was done based on the RFC and the draft but required
> tailoring to make it interoperable with wpa_supplicant's
On Fri, 10 Mar 2023, at 16:17, Eliot Lear wrote:
> In Section 4.2.9, the beginning text reads:
>
>> The Request-Action TLV MAY be sent by both the peer and the server in
>> response to a successful or failed Result TLV.
>
> I believe this text is overly restrictive, and should be relaxed to say:
On Tue, 7 Mar 2023, at 01:26, internet-dra...@ietf.org wrote:
> 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 WG of the IETF.
>
> Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
>
On Wed, 1 Mar 2023, at 01:44, Meiling Chen wrote:
> I would like to discuss EAP-TLS-IBS this time, Since last adoption process,
> we are still waiting for more people to be interested.
I thought the hold up was OpenSSL does not support RFC7250 without patching?
On Sat, 4 Feb 2023, at 01:40, Alan DeKok wrote:
>> Should we state somewhere that the client can "effectively rollback the
>> entire inner state machine" so Result TLV is not final for the whole session?
>>
>> Should the client be able to do this multiple times?
>
> I would say "no".
I really
On Thu, 2 Feb 2023, at 19:16, Alan DeKok wrote:
>> The documentation does not but I did see Appendix C.9 lets the client state
>> what it wants to do:
>>
>> https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-03#name-c9-peer-requests-inner-meth
>
> i.e. the client authenticates in
On Thu, 2 Feb 2023, at 18:31, Alan DeKok wrote:
> On Feb 2, 2023, at 2:22 AM, Eliot Lear wrote:
>> I am wondering if we should close this issue. At the end of the day, if the
>> client knows it's doing something like 2FA that requires an EAP method, it
>> can initiate.
>
> I'm not clear how
On Mon, 23 Jan 2023, at 14:05, Heikki Vatiainen wrote:
> On Tue, 17 Jan 2023 at 16:24, Alan DeKok
> wrote:
>>
>> On Jan 16, 2023, at 8:00 PM, Joseph Salowey wrote:
>> > [Joe] Speaking as a contributor, I would rather see the text deleted if
>> > no-one plans on implementing it. This would make
On Mon, 16 Jan 2023, at 13:54, Alan DeKok wrote:
> And as a related note, if the PAC goes away, so does the Authority-ID
> TLV, and related things like A-ID.
I was wondering what to do with A-ID[1] (and everything around PAC-Info) but
starting to figure that as you can stuff anything you want
On Fri, 13 Jan 2023, at 19:06, internet-dra...@ietf.org wrote:
> Title : TLS-based EAP types and TLS 1.3
> Author : Alan DeKok
> Filename: draft-ietf-emu-tls-eap-types-10.txt
> Pages : 22
> Date: 2023-01-13
The TEAP section will need a
On Mon, 9 Jan 2023, at 22:36, Alan DeKok wrote:
>> Section 3.3.1 - EAP Sequences
>>
>> * "Upon completion of each EAP method in the tunnel, the server MUST send an
>> Intermediate-Result TLV indicating the result of the inner EAP method. The
>> peer MUST respond to the Intermediate-Result TLV
On Mon, 9 Jan 2023, at 22:17, Heikki Vatiainen wrote:
> I'd say this is a major change because EAP-FAST-MSCHAPV2 can be directly
> integrated with Windows AD but EAP-pwd and EAP-EKE can not. This is not to
> bring back EAP-FAST-MSCHAPv2 but simply a note that Server Unauthenticated
>
On Mon, 9 Jan 2023, at 14:11, Heikki Vatiainen wrote:
>> On a related note, whilst we are here, it does raise the question on how we
>> got:
>>
>> "...the length is 64 octets..." and "First 32 octets of TLS-PRF(...)"
>>
>> The '0x00 || 0x40' (64 network order 16bit length concatenation) looks
On Thu, 5 Jan 2023, at 20:13, internet-dra...@ietf.org wrote:
> Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Filename: draft-ietf-emu-rfc7170bis-02.txt
> Pages : 101 <-- "now available over the counter to deal with
> insomnia..."
> Date
On Mon, 9 Jan 2023, at 07:53, Eliot Lear wrote:
> My suggestion is that this draft not be moved to WGLC until we have
> working code in hostap for it. Even better if FR and ISE also match and
> can test against MSFT.
FreeRADIUS interops with Win10/11 and hostapd (wpa_supplicant/eapol_test)
On Mon, 9 Jan 2023, at 03:34, Joseph Salowey wrote:
> The definition of the TLS-PRF is given in 5246 as:
>
> PRF(secret, label, seed) = P_(secret, label | seed)
>
> This construction only defines 3 parameters and does not define a length. I
> don't think current implementations include the
On Thu, 5 Jan 2023, at 20:13, internet-dra...@ietf.org wrote:
> Title : Tunnel Extensible Authentication Protocol (TEAP) Version 1
> Filename: draft-ietf-emu-rfc7170bis-02.txt
> Pages : 101
> Date: 2023-01-05
Abstract:
obseletes -> obsoletes
On Wed, 7 Dec 2022, at 13:48, Alan DeKok wrote:
> * perhaps mentioning TLS 1.3?
As the PEAP and EAP-TTLS RFCs do not there probably is no need to.
At some stage draft-ietf-emu-tls-eap-types will brand an 'Updated by ...' onto
those RFCs including RFC7170bis.
One question though is can an
On Wed, 4 Jan 2023, at 09:17, Alexander Clouter wrote:
>
> For TEAP (and similarly for FAST) we need to do more than just state
> "PACs are dead use NewSessionTicket"[1].
Looks like I jumped at this too quickly, there is some text from the original
RFC7170:
https://datat
On Tue, 27 Sep 2022, at 13:25, internet-dra...@ietf.org wrote:
> A New Internet-Draft 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 : TLS-based EAP types and TLS 1.3
> Author :
On Tue, 3 Jan 2023, at 21:34, Alan DeKok wrote:
> I've pushed back all of the fixes I know about based on discussion on
> the mailing list.
There is also some gold[1] to be found in https://github.com/emu-wg/teap-errata
that I am working through porting over.
I will blend this into my draft
On Tue, 3 Jan 2023, at 14:16, Eliot Lear wrote:
>> My expectation is that you use the EMSK from the outer-TLS authentication to
>> do this calculation.
>>
>> However, I now understand your point about the *value* of doing this.
>> Generating a Cryptobinding on the outer-TLS authentication does
On Tue, 3 Jan 2023, at 08:20, Eliot Lear wrote:
> My use case is IOT. I'm interested in two states:
>
> * Nominal: everything looks very similar to EAP-TLS.
> * Exceptional: a new certificate or a new trust anchor or something else is
> needed. In which case, I would expect the server to
On Mon, 2 Jan 2023, at 21:20, Alan DeKok wrote:
>> It shows it for the *first* method but not subsequent methods.
>
> Ah.
>
> And it doesn't show the inner EAP authentication method finishing with
> EAP Success or EAP Failure.
...and should continue to *not* show EAP Success/Failure for each
On Tue, 27 Sep 2022, at 13:25, internet-dra...@ietf.org wrote:
> A New Internet-Draft 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 : TLS-based EAP types and TLS 1.3
> Author :
On Mon, 2 Jan 2023, at 20:15, Alan DeKok wrote:
>> Appendix C.6 (Sequence of EAP Methods) will need to be updated to show this
>> too.
>
> The text has this, which seems sufficient:
>
> <- EAP-Request/
> EAP-Type=TEAP, V=1
>
On Thu, 1 Dec 2022, at 13:44, Eliot Lear wrote:
> Th proposed change is as follows:
>
>
>
>> 4.2.13. Crypto-Binding TLV
>>
>> The Crypto-Binding TLV is used to prove that both the peer and server
>> participated in the tunnel establishment and sequence of authentications. It
>> also provides
On Sat, 31 Dec 2022, at 17:14, Oleg Pekar wrote:
> Few initial comments:
>
> [snipped EAP sequences scene setting]
>
> Thus we considered in one of the previous discussions to say in Section 3.3.1
> of TEAP "Upon completion of each EAP __authentication__ method in the tunnel,
> the server MUST
On Thu, 1 Dec 2022, at 05:41, Eliot Lear wrote:
> No, but I would ask that we still have an interim to close the errata.
>
It was that Errata (stalled effort on GitHub) that helped me over the line in
implementing TEAP, so this definitely gets my nod of
Hello,
On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote:
> Based on interoperability testing, it looks like implementations
> followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170:
>
> http://lists.infradead.org/pipermail/hostap/2022-July/040639.html
>
>
Hello,
On Tue, 20 Sep 2022, at 20:50, Alan DeKok wrote:
>
>> Section 2.2 - TEAP
>> --
>> I do not think changing the language for the definition of the MAC used for
>> the Compound MAC was necessary.
>
> I don't see if changing the definition that much, There's just a
>
Hello,
On Fri, Sep 09, 2022 at 05:35:26PM -0400, Alan DeKok wrote:
I guess the argument is that those are the labels that are used in TEAP
(without exporter) and the same labels are used by EAP-FAST (with different
method ID). My main concern is that they labels are somewhat generic
Hello,
On Tue, Sep 06, 2022 at 09:57:02PM -0700, Joseph Salowey wrote:
I think we need to have some review of the EAP-FAST and TEAP sections
before publication. If we can't get the review then maybe we should remove
those sections. Is someone willing to step up and review these sections of
58 matches
Mail list logo
