Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-03.txt

2021-06-23 Thread John Mattsson
I agree that the document is ready for WG last call.

John

From: Emu  on behalf of Alan DeKok 

Date: Tuesday, 22 June 2021 at 15:10
To: EMU WG 
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-03.txt
  This is to address John's review, and to do some minor cleanups and textual 
fixes.

  I think the document should be ready for last call.  There are multiple 
interoperable implementations (client and server).  I believe it's important to 
publish this document at the same time as updates to EAP-TLS.

> On Jun 22, 2021, at 9:07 AM, 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  : Alan DeKok
>Filename: draft-ietf-emu-tls-eap-types-03.txt
>Pages   : 15
>Date: 2021-06-22
>
> Abstract:
>   EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS].  Many
>   other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as
>   FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many
>   vendor specific EAP methods.  This document updates those methods in
>   order to use the new key derivation methods available in TLS 1.3.
>   Additional changes necessitated by TLS 1.3 are also discussed.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/
>
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-tls-eap-types-03
>
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216

2021-06-20 Thread John Mattsson
Your suggestion looks good to me. I added a commit to RR #83

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83

From: Bernard Aboba 
Date: Saturday, 19 June 2021 at 16:47
To: John Mattsson 
Cc: Joseph Salowey , EMU WG 
Subject: Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216
I still find the proposed Section 2.1 confusing.  How about this?

"If the TLS implementation correctly implements TLS version negotiation, 
EAP-TLS will automatically leverage that capability.
The EAP-TLS implementation needs to know which version of TLS was negotiated to 
correctly support EAP-TLS 1.3 as well as to maintain backward compatibility 
with EAP-TLS 1.2.

TLS 1.3 changes both the message flow and the handshake messages compared to 
earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216] does not 
apply for TLS 1.3. Except for Sections 2.2 and 5.7 this document applies only 
when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, then [RFC5216] applies."






On Fri, Jun 18, 2021 at 10:15 PM John Mattsson 
mailto:john.matts...@ericsson.com>> wrote:
Hi Bernard,

Thanks for your comments on backward compatibility. I think PR #83 addresses 
your comments. I did not write anything about TLS 1.0 and TLS 1.1 as RFC 8996 
(which updates RFC 5216) formally forbids support and negotiation of these weak 
versions.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files<https://protect2.fireeye.com/v1/url?k=931ff3ea-cc84cac1-931fb371-866038973a15-a9a1d2b72b73651b=1=37b52464-2ebd-4ba4-aa0c-8087ad10b4ba=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-ietf-emu-eap-tls13%2Fpull%2F83%2Ffiles>

Below is how the two related paragraphs would look after merging #83.


1.  Introduction:

This document updates [RFC5216] to define how to use EAP-TLS with TLS 1.3. When 
older TLS versions are negotiated, RFC 5216 applies to maintain backwards 
compatibility. However, this document does provide additional guidance on 
authentication, authorization, and resumption for EAP-TLS regardless of the 
underlying TLS version used. This document only describes differences compared 
to [RFC5216]. All message flow are example message flows specific to TLS 1.3 
and do not apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state 
machine with the EAP state machine it is possible that new versions of TLS will 
cause incompatibilities that introduce failures or security issues if they are 
not carefully integrated into the EAP-TLS protocol. Therefore, implementations 
MUST limit the maximum TLS version they use to 1.3, unless later versions are 
explicitly enabled by the administrator.

2.1  Overview of the EAP-TLS Conversation:

TLS 1.3 changes both the message flow and the handshake messages compared to 
earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216] does not 
apply for TLS 1.3. EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 
[RFC5216] . TLS version negotiation is handled by the TLS layer, and thus 
outside of the scope of EAP-TLS. Therefore so long as the underlying TLS 
implementation correctly implements TLS version negotiation, EAP-TLS will 
automatically leverage that capability. Except for Sections 2.2 and 5.7 this 
document applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, 
then [RFC5216] applies. The EAP-TLS implementation needs to know which version 
of TLS that was negotiated.

Cheers,
John


From: Emu mailto:emu-boun...@ietf.org>> on behalf of 
Joseph Salowey mailto:j...@salowey.net>>
Date: Monday, 14 June 2021 at 01:54
To: Bernard Aboba mailto:bernard.ab...@gmail.com>>
Cc: EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216


On Sun, Jun 13, 2021 at 2:44 PM Bernard Aboba 
mailto:bernard.ab...@gmail.com>> wrote:
draft-ietf-emu-eap-tls13-16 Section 2.1 contains the following text:


   EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS 
version

   negotiation is handled by the TLS layer, and thus outside of the

   scope of EAP-TLS.  Therefore so long as the underlying TLS

   implementation correctly implements TLS version negotiation, EAP-TLS

   will automatically leverage that capability.

I am concerned that this statement is potentially misleading. An implementation 
of RFC 5216 that negotiates TLS 1.2 and utilizes the key hierarchy defined in 
RFC 5216 Section 2.3 will not interoperate with an implementation of 
draft-ietf-emu-tls13-16 that also negotiates TLS 1.2 and utilizes the key 
hierarchy defined in Section 2.3 of that document.

So in what sense is EAP-TLS 1.3 "backwards compatible" with EAP-TLS 1.2?

The only way this makes sense to me is if it is stated that 
draft-ietf-emu-eap-tls13 applies only when TLS 1.3 is negotiated, and that if 
TLS 1.2, 1.1 or 1.0 is negotiated, then RFC 5216 applies.


[Joe] Good point.  I think this is missing from the draft.  The EAP-TLS 
implementation does need to know which ve

[Emu] Review of draft-ietf-emu-tls-eap-types-02

2021-06-19 Thread John Mattsson
Hi Alan,

I reviewed draft-ietf-emu-tls-eap-types-02. Some minor comments:


- “The Type-Code is defined to be 1 octet for values smaller than 255.”

I think this should be “smaller than 254” as 0xFE = 254





- “Some implementations use the TLS "Finished" state as a signal that 
application data is now available.



As there is no formal “Finished” state, maybe better to write out that this 
happens after receiving and sending Finished messages (in any order). TLS 1.3 
formally defines this state and calls it CONNECTED.


- The following five derivations were removed from draft-ietf-emu-eap-tls13. I 
assume draft-ietf-emu-tls-eap-types should do the same

IV   = TLS-Exporter("EXPORTER_EAP_TLS_IV", Type-Code, 64)

Enc-RECV-Key = MSK(0, 31)

  Enc-SEND-Key = MSK(32, 63)

  RECV-IV  = IV(0, 31)

  SEND-IV  = IV(32, 63)



- OLD “EAP servers peers MUST NOT”

  NEW “EAP peers MUST NOT”





- The document use “Type ID”, “Type code” and “Type-Code”. Likely one is 
enough. I also notice that RFC 3748 use Code for a different purpose, does not 
use ID, and talks about “EAP Type Values”, “Method Type Values”. Would it be a 
good idea to change both draft-ietf-emu-eap-tls13 and 
draft-ietf-emu-tls-eap-types to use the term “type value”?





- List formatting

  “* EXPORTER: session key seed * EXPORTER: Inner Methods Compound Keys

   * EXPORTER: Session Key Generating Function * EXPORTER: Extended

   Session Key Generating Function * teapbind...@ietf.org”


- The draft mentions “commitment message” several times, but you are probably 
aware of that.


Cheers,
John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216

2021-06-18 Thread John Mattsson
Hi Bernard,

Thanks for your comments on backward compatibility. I think PR #83 addresses 
your comments. I did not write anything about TLS 1.0 and TLS 1.1 as RFC 8996 
(which updates RFC 5216) formally forbids support and negotiation of these weak 
versions.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files

Below is how the two related paragraphs would look after merging #83.


1.  Introduction:

This document updates [RFC5216] to define how to use EAP-TLS with TLS 1.3. When 
older TLS versions are negotiated, RFC 5216 applies to maintain backwards 
compatibility. However, this document does provide additional guidance on 
authentication, authorization, and resumption for EAP-TLS regardless of the 
underlying TLS version used. This document only describes differences compared 
to [RFC5216]. All message flow are example message flows specific to TLS 1.3 
and do not apply to TLS 1.2. Since EAP-TLS couples the TLS handshake state 
machine with the EAP state machine it is possible that new versions of TLS will 
cause incompatibilities that introduce failures or security issues if they are 
not carefully integrated into the EAP-TLS protocol. Therefore, implementations 
MUST limit the maximum TLS version they use to 1.3, unless later versions are 
explicitly enabled by the administrator.

2.1  Overview of the EAP-TLS Conversation:

TLS 1.3 changes both the message flow and the handshake messages compared to 
earlier versions of TLS. Therefore, much of Section 2.1 of [RFC5216] does not 
apply for TLS 1.3. EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 
[RFC5216] . TLS version negotiation is handled by the TLS layer, and thus 
outside of the scope of EAP-TLS. Therefore so long as the underlying TLS 
implementation correctly implements TLS version negotiation, EAP-TLS will 
automatically leverage that capability. Except for Sections 2.2 and 5.7 this 
document applies only when TLS 1.3 is negotiated. When TLS 1.2 is negotiated, 
then [RFC5216] applies. The EAP-TLS implementation needs to know which version 
of TLS that was negotiated.

Cheers,
John


From: Emu  on behalf of Joseph Salowey 
Date: Monday, 14 June 2021 at 01:54
To: Bernard Aboba 
Cc: EMU WG 
Subject: Re: [Emu] EAP TLS 1.3 backward compatibility with RFC 5216


On Sun, Jun 13, 2021 at 2:44 PM Bernard Aboba 
mailto:bernard.ab...@gmail.com>> wrote:
draft-ietf-emu-eap-tls13-16 Section 2.1 contains the following text:


   EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS 
version

   negotiation is handled by the TLS layer, and thus outside of the

   scope of EAP-TLS.  Therefore so long as the underlying TLS

   implementation correctly implements TLS version negotiation, EAP-TLS

   will automatically leverage that capability.

I am concerned that this statement is potentially misleading. An implementation 
of RFC 5216 that negotiates TLS 1.2 and utilizes the key hierarchy defined in 
RFC 5216 Section 2.3 will not interoperate with an implementation of 
draft-ietf-emu-tls13-16 that also negotiates TLS 1.2 and utilizes the key 
hierarchy defined in Section 2.3 of that document.

So in what sense is EAP-TLS 1.3 "backwards compatible" with EAP-TLS 1.2?

The only way this makes sense to me is if it is stated that 
draft-ietf-emu-eap-tls13 applies only when TLS 1.3 is negotiated, and that if 
TLS 1.2, 1.1 or 1.0 is negotiated, then RFC 5216 applies.


[Joe] Good point.  I think this is missing from the draft.  The EAP-TLS 
implementation does need to know which version of TLS is negotiated.   I agree 
that this draft applies to when TLS 1.3 is negotiated and not previous versions 
of TLS.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

2021-06-18 Thread John Mattsson
Hi Alan,

Thanks for your thorough review of version -16. Based on the suggested changes 
Joe made in GitHub issue #83, I have made commits to PR #83.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/84

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83




Below is a summary of the suggested changes to section 5 to address your 
comments:

>From Alan's review of section 5

Section 5.1 says:

[4] Cryptographic Negotiation: TLS 1.3 increases the number of
cryptographic parameters that are negotiated in the handshake. When
EAP-TLS is used with TLS 1.3, EAP-TLS inherits the cryptographic
negotiation of AEAD algorithm, HKDF hash algorithm, key exchange
groups, and signature algorithm, see Section 4.1.1 of [RFC8446].

Question: what does this mean in practice for EAP-TLS? i.e. this text
describes a capability. It does not describe what that capability
does, or how it benefits EAP-TLS.

Joe: How about:
"[4] Cryptographic Negotiation: The TLS layer handles the negotiation of 
cryptographic parameters. When EAP-TLS is used with TLS 1.3, EAP-TLS inherits 
the cryptographic negotiation of AEAD algorithm, HKDF hash algorithm, key 
exchange groups, and signature algorithm, see Section 4.1.1 of [RFC8446]."

John: I made a commit based on Joe’s suggestion to shorten this down. Having 
this text is a requirement from RFC 3748 if I am correct.



Section 5.2 says:

No updates to section 5.2 of [RFC5216].

This isn't true. Section 2.2 has substantial new text with new 
requirements, and new security impacts.

Joe: Add note that "Section 2.2 has additional discussion on identities."

John: I added "Note that Section 2.2 has additional discussion on identities."



Section 5.3 says:

While certificates may have long validity periods,

Comment: Certs issued by public CAs are generally short-lived, as in a year 
or so. It may be worth discussing this.

Joe: It's not clear what to add here.

John: Alan has a good point here. I suggest just deleting "While certificates 
may have long validity periods,". There is already text describing that 
certificates can have very short lifetimes.




Section 5.4 says:

Some deployments may permit no peer authentication for some or all
connections. When peer authentication is not used, implementations
MUST take care to limit network access appropriately for
unauthenticated peers

Q: Are these EAP server implementations? How does an EAP server limit 
network access for unauthenticated peers?

Joe: This should be address by PR #83 modifications for section 5.6.

John: Yes




Section 5.7 says:

There are a number of security issues related to resumption that are
not described in [RFC5216]. The problems, guidelines, and
requirements in this section therefore applies to all version of TLS.

NIT: These requirements are for EAP-TLS, and not TLS. This document does 
not apply new security requirements to the TLS protocol

Perhaps instead:

There are a number of security issues related to resumption that are
not described in [RFC5216]. The problems, guidelines, and
requirements in this section therefore applies EAP-TLS when is used
with any version of TLS.

Joe: This comment should already be addressed by PR #83 or draft 16 text.

John: Yes




Section 5.7 says:

If the EAP-TLS server or EAP client do not apply any authorization
policies,

NIT: EAP-TLS servers do not apply authorization policies. Perhaps explain 
that the EAP-TLS server is co-located with RADIUS / Diameter etc, and those 
apply policies.

NIT2: It's not clear how an EAP client would apply authorization policies. 
Perhaps just remove the reference to the EAP client.

Joe: Authorization should be discussed in the authorization section. Perhaps 
reword paragraph to:

   "The EAP-TLS server or EAP client MUST cache data during the
   initial full handshake sufficient to allow authorization decisions to be 
made during resumption. If cached data cannot be retrieved in a secure way, 
resumption MUST NOT be done."

John: I made a commit based on Joes suggestion above.



Cheers,
John

From: Joseph Salowey 
Date: Friday, 18 June 2021 at 22:30
To: Alan DeKok 
Cc: John Mattsson , Bernard Aboba 
, Mohit Sethi M , EMU WG 

Subject: Re: [Emu] draft-ietf-emu-eap-tls13-16.txt


On Thu, Jun 17, 2021 at 9:55 AM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On Jun 17, 2021, at 12:04 PM, John Mattsson 
mailto:john.matts...@ericsson.com>> wrote:
> I have made a single PR addressing all the currently listed issues in the way 
> suggested by Joe.
>
> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files<https://protect2.fireeye.com/v1/url?k=8c954de0-d30e77f9-8c950d7b-8682aaa22bc0-57cef0b953c698ab=1=5f99d0b2-df4f-4e46-93ae-df1ccc285e5d=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-ietf-emu-eap-

Re: [Emu] draft-ietf-emu-eap-tls13-16.txt

2021-06-17 Thread John Mattsson
Hi,

Thanks Joe for making such very clear and concrete issues on GitHub!

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues

I have made a single PR addressing all the currently listed issues in the way 
suggested by Joe.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files

- Does PR #83 address the currently listed issues?

- Are there any other remaining issues that are not listed on GitHub?

Cheers,
John

From: Emu  on behalf of Alan DeKok 

Date: Monday, 14 June 2021 at 02:22
To: Joseph Salowey , EMU WG 
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-16.txt
On Jun 13, 2021, at 7:49 PM, Joseph Salowey  wrote:
> [Joe]  The existing text already refers to relying on the underlying TLS 
> version negotiation.

  Yes.  I was trying to address the confusion between version negotiation and 
other handshake negotiation.

> [Joe]  I don't see a problem with covering new TLS handshake messages in the 
> document, however they are covered somewhat inconsistently.  Perhaps we 
> should cover them all in a "new handshake messages section".

  My point was that if the EAP layer doesn't need to do anything with those new 
handshake messages, then there isn't a need to mention them in the 
specification.

> TLS 1.3 introduces several new handshake messages including 
> HelloRetryRequest, NewSessionTicket, KeyUpdate.  In general, these messages 
> will be handled by the underlying TLS libraries and are not visible to 
> EAP-TLS, however there are a few things to note.
>
> The HelloRetryRequest is used by the server to reject the parameters offered 
> in the ClientHello and suggest new parameters.  When this message is 
> encountered it will increase the number of round trips used by the protocol.

  If that's the only change, then I would suggest there's no need for a section 
dedicated to HelloRetryRequest.  Perhaps just saying "there are a number of new 
messages in TLS 1.3 which affect round trips, but the EAP layer doesn't have to 
do anything other than exchange more TLS messages".

> [Joe]  OK how about adding:
>
> "An example of limiting network access would be to invoke a vendor's walled 
> garden or quarantine network functionality."

  Sounds good.

> >>   I don't understand why it's necessary to include discussion of TLS 
> >> negotiation in EAP, when that negotiation does not affect EAP in any way.
> > See above.
>
>   In short: TLS version negotiation does affect EAP-TLS.  HelloRetryRequest 
> messages do not.
>
> [Joe] The EAP TLS layer needs to know which TLS version was negotiated.  
> HelloRetryRequests affect the number of round trips in the exchange, but are 
> opaque with respect to EAP-TLS.

  Yes.  I was confused at Section 2.1.6. which essentially says 
"HelloRetryRequest is a new TLS message, here's a diagram of using it with 
EAP-TLS".   As an implementor, the immediate question is "What do I *do* with 
this message?"  and the answer is essentially "nothing".

  Pretty much every other section in the document says "this is new in TLS 1.3, 
and here's how to handle it".

> [Joe]  HelloRetryRequest is a feature of the underlying TLS library so the 
> RFC8446 Should determine the underlying behavior, specifying a different 
> behavior is problematic.

  Sure.

> >>   The updated text is clearer, but still does not address some of the 
> >> questions raised below about calling this out as a new requirement from 
> >> 5216, and what happens in an HA environment.
> > Please let us know a good reference to "implementation and
> > interoperability experience." about the upper limit on EAP packet
> > exchanges. This would also be useful for draft-ietf-emu-eaptlscert.
>
>   I posted references on this list previously:
>
> https://mailarchive.ietf.org/arch/browse/emu/?qdr=y
>
> [Joe] I think this is the wrong link.

  Yes.  The new mail archive interface is substantially worse than the older 
"mailman" interface.  It's difficult to follow threads, quickly search by 
dates, etc.

  In any case, this is the previous message:  
https://mailarchive.ietf.org/arch/msg/emu/y3d6KGFeImAeSLEqF6XqVMev2Zc/

> >>> Requiring a supplicant to be configured with a peer name is a new 
> >>> requirement from RFC 5216, and isn't called out as such.
> > I agree with you that we could benefit from more clarification on
> > relationship between section 2.2 and 5.2 of this draft vs. the old RFC
> > 5216. Do you have a suggestion how best to split the text and reflect
> > the updates to RFC5216?
>
>   Updating 2.2 with a note after the text on page 18 seems best:
>
> While this requirement to verify domain names is new, and was not mentioned 
> in [RFC5216], it has been widely implemented in EAP peers.  As such, we 
> believe that this section contains minimal new interoperability or 
> implementation requirements on EAP peers.
>
> [Joe] This does not seem to add to the specification.

  I agree that text doesn't add any new requirements to the specification.  
However, it's useful to make a note for 

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-16.txt

2021-06-11 Thread John Mattsson
Hi,

I think it would be good to first make sure that we have GitHub issues or pull 
requests for the remaining EAP-TLS issues.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13

The more I work with GitHub in IETF, the more I like it, both as an author or 
commenting on documents. It forces comments to be much more concrete, it makes 
sure that no issues are forgotten, and it makes it clearer why changes was made 
and the discussion behind it. Maybe the EMU WG should discuss and formalize a 
bit on how to work with GitHub at IETF 111.

Cheers,
John

From: Emu  on behalf of Joseph Salowey 
Date: Friday, 11 June 2021 at 20:25
To: Alan DeKok 
Cc: Roman Danyliw , Mohit Sethi M , 
emu@ietf.org 
Subject: Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-16.txt
Hi Folks,

I realize that there is frustration with the current document and process.  I 
ask that we all focus on finishing off the current document so that we can move 
it forward.  This does require that we consider the issues on the table.  I 
think we are close to the finish line.  I am asking the authors to help work 
through the final issues.

Please continue to remain professional in your discussions on the list.

Thanks,

Joe

On Fri, Jun 11, 2021 at 10:33 AM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On Jun 11, 2021, at 12:20 PM, Mohit Sethi M 
mailto:mohit.m.se...@ericsson.com>> wrote:
> I find it odd that you claim your suggestions have been ignored or rejected.

  So -16 does address my review from May 6?  Could you please go through my 
review of today, and point out in -16 where each of my comments was addressed?

  As a reminder, many of those comments go back to my earlier review of -13 on 
March 13.   So we now have -14, -15, and -16 which (so far as I can tell) don't 
address substantial portions of the reviews.

> We have created many issues on github  
> (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues?q=is%3Aissue+is%3Aclosed+Alan)
>  and submitted many pull requests addressing your comments 
> (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pulls?q=is%3Apr+Alan+is%3Aclosed).
>
> When I merged this PR in the morning: 
> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/71,
>  it looked like all of your comments had been addressed in the PR. Joe (the 
> other co-chair) had approved this PR?

  I had sent a review of -13 on March 3.  And another one May 6.  And another 
today.  The second and third reviews were largely copied from the first one.  
And contained issues which (so far as I can tell) have not been addressed, much 
less discussed.  These issues do not appear to be addressed in that PR.

> As authors of a working group document of a voluntary standards organization, 
> we have been doing voluntary service over the last several years. We started 
> working on this document in 2018 
> (https://datatracker.ietf.org/doc/html/draft-mattsson-eap-tls13). You have 
> been helping us with the document since the beginning. So thank you for your 
> voluntary service as well. While it is not mandatory, helping us with github 
> issues/PRs related to your reviews can help us ensure that your comments are 
> not inadvertently left unaddressed; and that this community effort moves 
> forward faster.

  I'm asking that my reviews be discussed and/or addressed, by the authors, in 
the WG.  I didn't expect to get that particular response.  It is distinctly 
unusual.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] EAP-TLS 1.3 - few more comments

2021-06-08 Thread John Mattsson
Hi,

I implemented the suggestions below in the following PR. Some of the editorial 
changes was merged directly to master.
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/78

I have also implemented all the thing in issue #58 (Alans review) in a PR
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/58
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/71

The PRs that Joe has approved has been merged into the master branch.

I will go through the mailing list soon and see if there are more comments on 
the draft.

John

From: Emu  on behalf of Oleg Pekar 

Date: Monday, 17 May 2021 at 16:25
To: Joseph Salowey 
Cc: EMU WG 
Subject: Re: [Emu] EAP-TLS 1.3 - few more comments
Thanks Joe, one comment regarding item #16 is inline below.

On Sun, May 16, 2021 at 9:52 PM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
Hi Oleg,

thanks for the review, comments below:

On Sun, May 16, 2021 at 1:55 AM Oleg Pekar 
mailto:oleg.pekar.2...@gmail.com>> wrote:
Hi, few more comments on the draft #15 
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/15/:

1)

2.1.1.  Authentication

The full handshake in EAP-TLS with TLS 1.3 always
   provide forward secrecy by exchange of ephemeral "key_share"
   extensions in the ClientHello and ServerHello (e.g. containing
   ephemeral ECDHE public keys).

—- comment:
should say “provides”

—

2)

2.1.1.  Authentication

After the EAP-TLS server has received an
   empty EAP-Response to the EAP-Request containing the TLS application
   data 0x00, the EAP-TLS server sends EAP-Success.

-- comment:
the phrase “empty EAP-Response” may be confusing. EAP-TLS RFC [RFC 5216] calls 
such messages as "EAP-Response packet of EAP-Type=EAP-TLS and no data" (Section 
2.1.3. Termination, 2.1.5.  Fragmentation). Suggest continue using the old RFC 
terminology since Figure 1 preserves the same messages names.

—

3)

2.1.1.  Authentication

Figure 1: EAP-TLS mutual authentication

-- comment:
"TLS Application Data 0x00)" lacks opening round bracket

—

4)

2.1.2.  Ticket Establishment

Figure 2: EAP-TLS ticket establishment

-- comment:
"TLS Application Data 0x00)" lacks opening round bracket

—

5)

2.1.3.  Resumption

Figure 3: EAP-TLS resumption

-- comment:
"TLS Application Data 0x00)" lacks opening round bracket

—

[Joe] Authors, please address the above nits.

6)

2.1.3.  Resumption

Providing a
   "key_share" and using the "psk_dhe_ke" pre-shared key exchange mode
   is also important in order to limit the impact of a key compromise.
   When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning
   that key leakage does not compromise any earlier connections.  It is
   RECOMMMENDED to use "psk_dhe_ke" for resumption.

-- comment:
The recommendation may be interpreted ambiguously. Is it recommended to TLS 
server to reject EAP-TLS session resumption from EAP-TLS peer and fallback to 
full handshake when there's no "psk_dhe_ke" extension?

[Joe] SHOULD and RECOMMENDED are a bit ambiguous.  Perhaps this can be replaced 
by something better:

"psk_dh_ke" MUST be used for resumption unless the deployment has a local 
requirement to allow configuration of other mechanisms."



—

7)

2.1.4.  Termination

In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a
   fatal error condition.  Failure to send TLS Error alerts means that
   the peer or server would have no way of determining what went wrong.
   EAP-TLS 1.3 strengthen this requirement.  Whenever an implementation
   encounters a fatal error condition, it MUST send an appropriate TLS
   Error alert.

-- comment:
It there a way to enforce sending TLS Error alert? Since the conversation is 
probably failed anyway after the case that requires sending TLS Error alert - 
there is no real feasible enforcement to be specified. I remember a lot of 
suffering due to EAP-TLS peers just broke connection with no indication of what 
was wrong, so admins cannot really reveal the cure for the failed 
authentication.

[Joe] This section does say that TLS error alerts MUST be sent.  Are you 
looking for something else?

—

8)

2.1.4.  Termination

Figure 6 shows an example message flow where the EAP-TLS server
   authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
   fails to authenticate to the EAP-TLS server and sends a TLS Error
   alert.

-- comment:
"the EAP-TLS peer fails to authenticate to the EAP-TLS server and sends a TLS 
Error" - there's an impression from this text that EAP-TLS peers sends a TLS 
error. However it is EAP-TLS server that does it. Should be clarified. Example 
of suggestion:

Figure 6 shows an example message flow where the EAP-TLS server
   authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
   fails to authenticate to the EAP-TLS server and the server sends a TLS Error
   alert.

[Joe] Authors please reword this 

Re: [Emu] EAP-TLS 1.3 Section 2.2 text

2021-06-08 Thread John Mattsson
Hi Oleg,

"If server name matching is not used, then peers may end up trusting
servers for EAP authentication that are not intended to be EAP
servers for the network. If name matching is not used with a public
CA bundle, then effectively any server can obtain a certificate which
will be trusted for EAP authentication by the Peer."

Do you have any concrete suggestions for improvements of this section Oleg?
This second part of the paragraph seems to discuss what happens if the
advice in the first half is not followed. When I conect to Ericsson's
internal WiFi network, I would expect checks that I am taking to the EAP
server, not the printer. I would also expect checks that I talk with
Ericsson EAP server, and not Huawei's or Nokia's EAP server. Should
Network be replaced by a better term?


Some comments from me on Section 2.2

"EAP peers MAY implement a trust on first
use (TOFU) mechanism where the peer trusts and stores the server
certificate during the first connection attempt."

This requires some security consideration, I think


"Iimplementations MAY rely on system-wide root CA
certificate bundles for authenticating the server certificate.
If server name matching is not used"

This seems to indicate that it is ok to not do any server authentication. The 
TLS CertificateVerify message does not give any authentication in itself, it 
only enables the application using TLS to do authentication.

Section 2.2. "Identity Verification" needs to match current deployments and 
uses of EAP-TLS. But if EAP-TLS does not even mandate server authentication, 
does it really make sense to mandate revocation?

Cheers,
John


From: Emu  on behalf of Oleg Pekar 

Date: Monday, 31 May 2021 at 17:46
To: Joseph Salowey 
Cc: stpe...@mozilla.com , EMU WG 
Subject: Re: [Emu] EAP-TLS 1.3 Section 2.2 text
This version is fine. Just the term "EAP servers for the network" still looks 
confusing to me. Maybe we can use instead the more detailed explanation that 
you provided above.

On Tue, May 25, 2021 at 7:45 AM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
I made some changes to the pull request to address some of the comments and 
make the text clearer:


The EAP peer identity provided in the EAP-Response/Identity is not

   authenticated by EAP-TLS.  Unauthenticated information MUST NOT be

   used for accounting purposes or to give authorization.  The

   authenticator and the EAP-TLS server MAY examine the identity

   presented in EAP-Response/Identity for purposes such as routing and

   EAP method selection.  EAP-TLS servers MAY reject conversations if

   the identity does not match their policy.  Note that this also

   applies to resumption, see Sections 2.1.3, 5.6, and 5.7.



   The EAP server identity in the TLS server certificate is typically a

   fully qualified domain name (FQDN) in the SubjectAltName (SAN)

   extension.  Since EAP-TLS deployments may use more than one EAP

   server, each with a different certificate, EAP peer implementations

   SHOULD allow for the configuration of a unique trusted root (CA

   certificate) to authenticate the server certificate and one or more

   server names to match against the SubjectAltName (SAN) extension in

   the server certificate.  To simplify name matching, an EAP-TLS

   deployment can assign a name to represent an authorized EAP server

   and EAP Server certificates can include this name in the list of SANs

   for each certificate that represents an EAP-TLS server.  If server

   name matching is not used, then peers may end up trusting servers for

   EAP authentication that are not intended to be EAP servers for the

   network.  If name matching is not used with a public root CA, then

   effectively any server can obtain a certificate which will be trusted

   for EAP authentication by the Peer.



   The process of configuring a root CA certificate and a server name is

   non-trivial and therefore automated methods of provisioning are

   RECOMMENDED.  For example, the eduroam federation [RFC7593] provides

   a Configuration Assistant Tool (CAT) to automate the configuration

   process.  In the absence of a trusted root CA certificate (user

   configured or system-wide), EAP peers MAY implement a trust on first

   use (TOFU) mechanism where the peer trusts and stores the server

   certificate during the first connection attempt.  The EAP peer

   ensures that the server presents the same stored certificate on

   subsequent interactions.  Use of a TOFU mechanism does not allow for

   the server certificate to change without out-of-band validation of

   the certificate and is therefore not suitable for many deployments

   including ones where multiple EAP servers are deployed for high

   availability.

On Thu, May 20, 2021 at 10:23 PM Joseph Salowey 
mailto:j...@salowey.net>> wrote:


On Wed, May 19, 2021 at 5:58 AM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On May 19, 2021, at 8:37 AM, Oleg Pekar 

Re: [Emu] Agenda items for EMU @ IETF 111

2021-06-08 Thread John Mattsson
Hi Meiling,

I just looked through this draft quickly.

- draft-ietf-tls-dtls13 specifies DTLS 1.3 which is not used in EAP-TLS. You 
likely want to reference RFC8446 or RFC8446bis.

- I don't really understand why a new EAP method is needed here, this just 
seems like ordinary EAP-TLS to me...


- TLS 1.2 was made obsolete in 2018. It should be phased out, not expanded with 
new fuctionality. This a -00 draft and would not be published as an RFC for a 
while, when TLS 1.2 would be even more obsolete.

- As TLS 1.3 mandates ephemeral diffie-hellman, the privacy is good. If new TLS 
1.2 is really needed, ephemeral diffie-hellman should be mandated as is done in 
RFC 7540. Otherwise the Private Key Generator (PKG) 
https://en.wikipedia.org/wiki/Identity-based_encryption can passivle eavesdrop 
on all encrypted application data (This matters for TLS and most TLS based EAP 
types, but not EAP-TLS).

Cheers,
John

From: Emu  on behalf of Meiling Chen 

Date: Friday, 4 June 2021 at 10:49
To: Mohit Sethi M , emu 

Subject: Re: [Emu] Agenda items for EMU @ IETF 111
Hi Mohit,
I need 5-10minites to introduce our changes for the new version 
draft-chen-emu-eap-tls-ibs-02,
https://datatracker.ietf.org/doc/draft-chen-emu-eap-tls-ibs/


Best,
Meiling

From: Mohit Sethi M
Date: 2021-06-04 15:44
To: emu@ietf.org
Subject: [Emu] Agenda items for EMU @ IETF 111
Dear all,

We have a requested a 1 hour session for EMU @ IETF 111. Please send the
chairs (emu-cha...@ietf.org) requests for presentation slots.

Don't forget to include the title of your presentation, related drafts,
and the approximate amount of time needed. Even if you don't have all
the information ready, at least let us know about your intention to
present. It would let us gauge if a 1 hour session is sufficient.

Joe and Mohit

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

2021-05-11 Thread John Mattsson
Hi Meiling,

In version 15 the group decided to go back more or less to how things worked in 
version 13 where protected TLS application Data 0x00 is send instead of 
close_notify.  This is changed in a lot of places in the draft.

A big change from -13 is that where protected TLS application Data 0x00 is not 
a protected success indication as defined in RFC 3748. That the server only 
sends EAP-success after this follow from it being a protected success 
indication.

When reading through the document to write this answer I saw that there was 
some leftover from the commitment message still in the draft. I made a PR to 
address this.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/69

EAP-success is not encrytpted in any way. It is defined in RFC 3748.

Cheers,
John

From: Emu  on behalf of Meiling Chen 

Date: Saturday, 8 May 2021 at 10:25
To: Joseph Salowey , emu 
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3

I have noticed that there is one modification in the Figure 1 flow diagram of 
edition 15.
edition 14 has TLS close_notify message, but in edition 15 changed into TLS 
application Data 0x00.
in the section 2.1.1, it says" TLS application data 0x00 is therefore to

   be interpreted as success after the EAP-Request that contains TLS

   application data 0x00.  After the EAP-TLS server has received an

   empty EAP-Response to the EAP-Request containing the TLS application
   data 0x00, the EAP-TLS server sends EAP-Success."
is the data 0x00 that mean not send any more handshake messages?
another question: what's the format of the EAP-success measge, plaintext ot 
ciphertext?

Best Regards,
Meiling

From: Joseph Salowey
Date: 2021-05-05 23:33
To: EMU WG
Subject: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3
This is the working group last-call for draft-ietf-emu-eap-tls13.  Please 
review the draft, focus on the recent changes and submit your comments to the 
list by May 20, 2021.

Thanks,

Joe

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-15
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-15
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Consensus call on EAP-TLS key derivation

2021-05-10 Thread John Mattsson
I don’t see any strong reasons to keep the -15 key derivation. I started to 
prepare a PR for the likely change back to -13.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/68

- Version 15 has the following wrong text that need to change. Key_Material can 
now be kept, but IV should be removed.

  “the Key_Material, IV, and Method-Id SHALL be derived”
  ”derivation of Key_Material, IV and Method-Id”

- The IANA table need to change.

- I would suggest to have the text agreed in -13 stating stating that the 
derivation from Key_Material is the same as in RFC 5216.

   The MSK and EMSK are derived in the same manner as with EAP-TLS 
[RFC5216], Section 2.3. The definitions are repeated below for simplicity:

   MSK = Key_Material(0, 63)
   EMSK = Key_Material(64, 127)

John

From: Emu  on behalf of Joseph Salowey 
Date: Sunday, 9 May 2021 at 19:54
To: EMU WG 
Subject: [Emu] Consensus call on EAP-TLS key derivation

We had discussion on the list on whether to include context in the key 
derivation, but we never closed on the issue of separating out the MSK and EMSK 
derivation.  As a result several implementers have gone down the path of 
implementing what is in draft 13 and not separating out the derivation.  The 
main difference is that draft 15 separated out the EMSK and MSK derivation 
using two different labels while draft 13 used a single label to derive key 
material which is partitioned into two keys.   The reason for the change was to 
enable different access control for these two different quantities for 
different callers, however in practice it is EAP-TLS application which needs 
access to both keys that is the caller of the TLS library so this separation is 
not particularly useful.   Therefore the recommendation is to align with 
implementation and derive the MSK and EMSK by partitioning the key material 
from the key material produced by a single label of the exporter function.

Please respond to the list if you support the change below or not to revert 
some of the text in the key derivation section.  If you object to the change 
please state why.  Please respond by May 20,2021.

Thanks,

Joe

The proposal is to use the following key derivation which is largely a 
reversion to draft 13:

Draft-15 Text:

Type-Code = 0x0D

MSK= TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64)

EMSK   = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64)

Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64)

Session-Id = Type-Code || Method-Id

Proposed New Text:

Type-Code = 0x0D

Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",

   Type-Code, 128)

MSK  = Key_Material(0, 63)

EMSK = Key_Material(64, 127)

Method-Id= TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",

   Type-Code, 64)

Session-Id = Type-Code || Method-Id



The rest of the text of the section remains the same as draft-15.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Key Derivation for EAP-TLS 1.3

2021-02-23 Thread John Mattsson
Appology accepted.

John

-Original Message-
From: Alan DeKok 
Date: Monday, 22 February 2021 at 14:41
To: John Mattsson 
Cc: EMU WG 
Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3

  I'd like to apologize to John for mis-stating what he said.  That attempt at 
paraphrasing his comments was wrong.

  I will summarize any technical issues I have in a separate thread.

  Alan DeKok


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Key Derivation for EAP-TLS 1.3

2021-02-19 Thread John Mattsson
Dear Alan,

It would very nice if you stopped putting words in my mouth and stopped 
accusing me personally for IETF procedures, which I feel you do.

Alan DeKok  wrote:
>> But these are more implementation guidance/history then security 
>> >requirements.
>
>  Do these issues affect security?  If the answer is "no", then they can >be 
> ignored.  If the answer is "yes", then they should be put in.

[John] I have not stated that I don't think your text should be put in the 
document. I do. And your suggested text certainly affect security. I simply 
meant that this was not the kind of requirements I personally was discussing 
and expecting. In fact, your text make me questioning if implementations are 
even following the RFC 5216 MUST or if we need to update some text.

[John] If EMU cannot agree on a a few high level sentences summarizing MUST 
requirements for secure server authentication, I have a hard time believing 
that current or future implementations are/will be secure.

[John] My role as one of the authors is not to decide what goes into the 
document or to produce all the text. After adoption, my role is to add text 
that there is WG consensus on. Sometimes that includes trying to come up with 
text based on the consensus.


>  You've approached this specification as a theoretical exercise in >protocol 
> design.  I've tried to explain that protocols are implemented in >the real 
> world, by real people.  As such, it is important for the document >to give 
> implementation guidance.  Further, it's very useful for >implementors to 
> understand *why* things are done a particular way.  >Explaining the reasons 
> for a particular choice helps implementors >understand the higher level 
> picture, which makes implementation easier.

[John] Except the first sentence, I agree with you. If you suggest guidance 
text and that text has WG consensus, me and Mohit will add it to the document 
(Given that the shepard and AD are ok with it). Most of your suggested 
resumption guidance text is e.g. in the document. Some of the *why* text you 
have requested has been about TLS 1.3, I think you need to ask people that took 
part in these specific discussions in the TLS WG for this. Futhermore, there 
was people recently suggesting that all TLS guidance was to be removed. Then it 
is hard to arguee that there is IETF consensus to add more.

[John] Note also that at this late state of the document process it is harder 
to harder to justify new technical changes that are not related ot the IESG 
review. 

>  There are any number of RFCs which take this approach.  Experience shows 
> >that specifications which do *not* have implementation guidance. too often 
> >result in insecure implementations.

[John] I know. There are also WGs that spearate the protocol specification and 
implementation guidance in different RFCs. I think we should have more of that, 
expecially for protocols where there is experiance on how implement.

>  There have been a number issues brought up by people who have *coded* >these 
> protocols, and *used* them in the real world.   You're opposing the >requests 
> to update the document with guidance that the implementors say >they need.  
> The reasons you give are largely from inexperience: "I don't >understand why 
> this matters".
>
>  Well, it does.  If you don't understand why, then please step aside, and 
> >let the work be done by others.   If you won't step aside, then please >stop 
> resisting guidance from people who have experience in this area.
>
>  To be perfectly frank: if this specification does not meet the needs of 
> >implementors, then they will ignore it, and go do whatever they want.  >This 
> particular specification will be ignored.  And once implementors are >ready, 
> they will bring a specification to the IETF which says "ignore the >previous 
> spec, this is what we actually did".
>
>Implementors have a long established a set of practices which are NOT >written 
>down in any standard.  These practices help to both secure the >network, and 
>make these systems easier to deploy.

[John] I don’t know what you think I have opposed. So far I can recall two 
significant chucks of established practice text that you have suggested. Text 
regarding resumption, which is now in the document, and recent practice text 
regarding authentication that I have NOT resisted. 

[John] Note that guidance text is not always easy for the WG to reach consensus 
about. Your resumption guidance text for example got quite a lot of comments 
both before and after it was put in the document.

>i.e.: Instead of fighting with standards bodies, implementors have gone >and 
>done their own thing, because the specifications are lacking.  Worse, >the 
>processes used by stan

Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

2021-02-18 Thread John Mattsson
My mistake, I read zero-bytes instead of zero-byte. The text is fine. Sorry for 
the spam.


---
Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer>

On 19 February 2021 at 07:49:15 CET, John Mattsson 
 wrote:

But if I missed something and implementors are fine with “Zero-byte”, I do not 
object. Zero-bytes is allowed by the TLS 1.3 specification and theoreticallty 
better as it is not send normally.



From: Emu  on behalf of John Mattsson 

Date: Friday, 19 February 2021 at 07:09
To: Joseph Salowey , EMU WG 
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3



Small nit: Zero-byte application record was removed in -06 as many TLS 
implementations did not support sending a Zero-byte application record. 
Zero-byte was then changes to send 0x00 but accept any application data. Other 
EAP-TLS based method might require longer specific stings like “EAP-Success”.



I think you questions are fine if the word “Zero-byte” is removed everywhere.



Cheers,

John



From: Emu  on behalf of Joseph Salowey 
Date: Friday, 19 February 2021 at 06:26
To: EMU WG 
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3



We have had a lot of productive discussion on this topic.  I feel comfortable 
calling consensus that we should add protected result indicators to EAP-TLS 1.3.



There also seems to be consensus to use TLS Failure alert for failure result 
indications.



How to represent success indicators is not as clear.  Fortunately, we have two 
options that seem to have some support.



1. Zero-byte application record.  Multiple implementations already use this 
mechanism and it is clear that the EAP-TLS peer and server "application" can 
receive and send this indicator.  There were additional concerns about the 
ordering of this application data record in the flight, but it seems that this 
should not be a problem as long as the TLS library is fed the entire EAP-TLS 
message containing the flight to process.



2. Close-Notify Alert.  This would use an existing TLS message to signal 
success.  We have had some implementation reports that the EAP-TLS server 
"application" can trigger the close_notify on at least one library.  I have not 
heard any news from implementers if close_notify is accessible to the EAP-TLS 
peer/supplicant "application".  I think it is not clear if the signal would be 
accessible to implementers for both the EAP-TLS peer and server.



I'd like to hear from implementers about their experience with this mechanism:



1. Have you implemented the zero byte application record signa? If not, why 
not?l

a. Is it sent after receiving the client finished?

b. Do you anticipate problems if the application record comes before or after a 
NewSessionTicket message?

c. did you run into any issues with this mechanism?



2. Have you implemented the close notify method? If not, why not?

a. Is it sent after receiving the client finished?

b. Were you able to cause the message to be sent for the server or determine 
that the message was received for the peer/supplicant?

c. Did you run into any issues with this mechanism?



Joe



On Sat, Feb 6, 2021 at 5:22 PM Joseph Salowey 
mailto:j...@salowey.net>> wrote:

There is growing support for mandating result indicators for EAP-TLS 1.3.  The 
result indicators help protect the EAP protocol exchange in the many different 
types of environments EAP-TLS is used and make the integration with the EAP 
state machine clearer.  This has the impact of adding a round trip to EAP-TLS 
1.3 making a total of 4.5 round trips.  It may be possible to optimize this 
exchange, but that would need further study and would be beyond the scope of 
this effort.



This consensus call has two parts:



1. Please respond to the list if you support adding explicit result indications 
of success and failure from the EAP Server to the EAP Peer in EAP-TLS 1.3.  If 
you object please respond to the list indicating why.



2. Please respond to the list if you support using TLS close_notify alert for a 
success indication and TLS error alert for a failure indication.  If you object 
please respond to the list indicating why.



This call will run for 1 week.  Please respond by February 15, 2021.



Thanks,



Joe


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Key Derivation for EAP-TLS 1.3

2021-02-18 Thread John Mattsson
Thanks Alan,

But these are more implementation guidance/history then security requirements.

"should configure all settings necessary to perform EAP-TLS in a secure manner" 
is extremely soft. If we put that in the document it has to be MUST.

RFC 5216 has the normative text:
   "Once a TLS session is established, EAP-TLS peer and server
   implementations MUST validate that the identities represented in the
   certificate are appropriate and authorized for use with EAP-TLS."

Can we update that to:
   "Once a TLS session is established, EAP-TLS peer and server
   implementations MUST validate that the identities represented in the
   certificate are appropriate and authorized for use with EAP-TLS on the 
specific link."

RFC 3748 use the term link, but I think path or network might also be ok.

Unless we can say that, it is very hard to justify the security claim of mutual 
authentication. Then we would likely have to explain that EAP-TLS only gives 
some very weak form of authentication.

Might also be that the text in quoted text in RFC 5216 is not how things are 
implemented. An alternative approach would be to check that the certificates 
are issues by a CA that is exclusively used for EAP-TLS in a specific network 
and ignore the identities.

/John

-Original Message-
From: Alan DeKok 
Date: Thursday, 18 February 2021 at 22:39
To: John Mattsson 
Cc: EMU WG , Martin Thomson , Benjamin Kaduk 

Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3

On Feb 18, 2021, at 10:38 AM, Alan DeKok  wrote:
>  Implementations largely fixed that years ago via a few methods:
> 
> * on initial connection to SSID, prompting the user to see if the certificate 
> is OK (historical, and less permitted these days)
> 
> * pre-provisioning SSID / CA certificate / user credentials to each machine
> 
> * certificate pinning so that the EAP server certificate is cached and 
> associated with an SSID / user credentials.  i.e. not just the CA cert.  This 
> caching prevents bad actors from getting their own certificate from the same 
> CA, and setting up their own "mirror" malicious SSID.
> 
>  The result is that this works for most situations, and is reasonably secure.

  Some suggested text, perhaps for Section 5.3, Certificate Validation:

  There are some proposed additions to the certificate validation text in 
Section 5.3 of RFC 5216:


  Experience shows that configuring EAP peers can be difficult and error-prone, 
especially when that configuration is performed manually by end users.  In 
order to avoid errors and insecure configurations, EAP-TLS peers SHOULD be 
provisioned via an automated process.  This process should configure all 
settings necessary to perform EAP-TLS in a secure manner, in its expected 
use-case(s).  These settings can include not only the certificate chain from 
certificate authority to client certificate, but also the expected EAP server 
certificate.  These settings can also include information about the protocol 
layers above or below EAP (MAC addresses, IP addresses, port numbers, WiFi 
SSID, etc.).

  Where these settings cannot be provisioned in an automated manner, the EAP 
peer SHOULD cache them after first use.  The peer SHOULD then present the 
EAP-TLS credentials only when all of the cached settings match the network 
being accessed.  Where these settings do not match, the EAP peer MAY refuse to 
proceed with authentication.  Where the EAP peer does proceed, it SHOULD inform 
the end user (where possible) as to the nature of the changes, and give the 
user the option of proceeding or refusing the authentication.

  The above recommendations have been in wide-spread use in EAP-TLS peer 
implementations for many years.


  Alan DeKok.


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

2021-02-18 Thread John Mattsson
But if I missed something and implementors are fine with “Zero-byte”, I do not 
object. Zero-bytes is allowed by the TLS 1.3 specification and theoreticallty 
better as it is not send normally.

From: Emu  on behalf of John Mattsson 

Date: Friday, 19 February 2021 at 07:09
To: Joseph Salowey , EMU WG 
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

Small nit: Zero-byte application record was removed in -06 as many TLS 
implementations did not support sending a Zero-byte application record. 
Zero-byte was then changes to send 0x00 but accept any application data. Other 
EAP-TLS based method might require longer specific stings like “EAP-Success”.

I think you questions are fine if the word “Zero-byte” is removed everywhere.

Cheers,
John

From: Emu  on behalf of Joseph Salowey 
Date: Friday, 19 February 2021 at 06:26
To: EMU WG 
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

We have had a lot of productive discussion on this topic.  I feel comfortable 
calling consensus that we should add protected result indicators to EAP-TLS 1.3.

There also seems to be consensus to use TLS Failure alert for failure result 
indications.

How to represent success indicators is not as clear.  Fortunately, we have two 
options that seem to have some support.

1. Zero-byte application record.  Multiple implementations already use this 
mechanism and it is clear that the EAP-TLS peer and server "application" can 
receive and send this indicator.  There were additional concerns about the 
ordering of this application data record in the flight, but it seems that this 
should not be a problem as long as the TLS library is fed the entire EAP-TLS 
message containing the flight to process.

2. Close-Notify Alert.  This would use an existing TLS message to signal 
success.  We have had some implementation reports that the EAP-TLS server 
"application" can trigger the close_notify on at least one library.  I have not 
heard any news from implementers if close_notify is accessible to the EAP-TLS 
peer/supplicant "application".  I think it is not clear if the signal would be 
accessible to implementers for both the EAP-TLS peer and server.

I'd like to hear from implementers about their experience with this mechanism:

1. Have you implemented the zero byte application record signa? If not, why 
not?l
a. Is it sent after receiving the client finished?
b. Do you anticipate problems if the application record comes before or after a 
NewSessionTicket message?
c. did you run into any issues with this mechanism?

2. Have you implemented the close notify method? If not, why not?
a. Is it sent after receiving the client finished?
b. Were you able to cause the message to be sent for the server or determine 
that the message was received for the peer/supplicant?
c. Did you run into any issues with this mechanism?

Joe

On Sat, Feb 6, 2021 at 5:22 PM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
There is growing support for mandating result indicators for EAP-TLS 1.3.  The 
result indicators help protect the EAP protocol exchange in the many different 
types of environments EAP-TLS is used and make the integration with the EAP 
state machine clearer.  This has the impact of adding a round trip to EAP-TLS 
1.3 making a total of 4.5 round trips.  It may be possible to optimize this 
exchange, but that would need further study and would be beyond the scope of 
this effort.

This consensus call has two parts:

1. Please respond to the list if you support adding explicit result indications 
of success and failure from the EAP Server to the EAP Peer in EAP-TLS 1.3.  If 
you object please respond to the list indicating why.

2. Please respond to the list if you support using TLS close_notify alert for a 
success indication and TLS error alert for a failure indication.  If you object 
please respond to the list indicating why.

This call will run for 1 week.  Please respond by February 15, 2021.

Thanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

2021-02-18 Thread John Mattsson
Small nit: Zero-byte application record was removed in -06 as many TLS 
implementations did not support sending a Zero-byte application record. 
Zero-byte was then changes to send 0x00 but accept any application data. Other 
EAP-TLS based method might require longer specific stings like “EAP-Success”.

I think you questions are fine if the word “Zero-byte” is removed everywhere.

Cheers,
John

From: Emu  on behalf of Joseph Salowey 
Date: Friday, 19 February 2021 at 06:26
To: EMU WG 
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

We have had a lot of productive discussion on this topic.  I feel comfortable 
calling consensus that we should add protected result indicators to EAP-TLS 1.3.

There also seems to be consensus to use TLS Failure alert for failure result 
indications.

How to represent success indicators is not as clear.  Fortunately, we have two 
options that seem to have some support.

1. Zero-byte application record.  Multiple implementations already use this 
mechanism and it is clear that the EAP-TLS peer and server "application" can 
receive and send this indicator.  There were additional concerns about the 
ordering of this application data record in the flight, but it seems that this 
should not be a problem as long as the TLS library is fed the entire EAP-TLS 
message containing the flight to process.

2. Close-Notify Alert.  This would use an existing TLS message to signal 
success.  We have had some implementation reports that the EAP-TLS server 
"application" can trigger the close_notify on at least one library.  I have not 
heard any news from implementers if close_notify is accessible to the EAP-TLS 
peer/supplicant "application".  I think it is not clear if the signal would be 
accessible to implementers for both the EAP-TLS peer and server.

I'd like to hear from implementers about their experience with this mechanism:

1. Have you implemented the zero byte application record signa? If not, why 
not?l
a. Is it sent after receiving the client finished?
b. Do you anticipate problems if the application record comes before or after a 
NewSessionTicket message?
c. did you run into any issues with this mechanism?

2. Have you implemented the close notify method? If not, why not?
a. Is it sent after receiving the client finished?
b. Were you able to cause the message to be sent for the server or determine 
that the message was received for the peer/supplicant?
c. Did you run into any issues with this mechanism?

Joe

On Sat, Feb 6, 2021 at 5:22 PM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
There is growing support for mandating result indicators for EAP-TLS 1.3.  The 
result indicators help protect the EAP protocol exchange in the many different 
types of environments EAP-TLS is used and make the integration with the EAP 
state machine clearer.  This has the impact of adding a round trip to EAP-TLS 
1.3 making a total of 4.5 round trips.  It may be possible to optimize this 
exchange, but that would need further study and would be beyond the scope of 
this effort.

This consensus call has two parts:

1. Please respond to the list if you support adding explicit result indications 
of success and failure from the EAP Server to the EAP Peer in EAP-TLS 1.3.  If 
you object please respond to the list indicating why.

2. Please respond to the list if you support using TLS close_notify alert for a 
success indication and TLS error alert for a failure indication.  If you object 
please respond to the list indicating why.

This call will run for 1 week.  Please respond by February 15, 2021.

Thanks,

Joe
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Key Derivation for EAP-TLS 1.3

2021-02-18 Thread John Mattsson
Hi,

I don't think any additional information in the key derivation is needed.

I do think that the requirements for server identity verification in RFC 5216 
is a bit vague. 

HTTPS (RFC 2818) for example has much more stricter requirement regarding this:

  "If the hostname is available, the client MUST check it against the
  server's identity as presented in the server's Certificate message,
  in order to prevent man-in-the-middle attacks."

I started an issue regarding this.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/47

My suggestion would be to add something like the following to EAP-TLS 1.3:

  "The EAP-TLS peer MUST check that the identity in the EAP-TLS server's
  Certificate is appropriate and authorized for the link. If a NAI was
  used in the identity response, the EAP-TLS peer MUST check the realm
  in the identity response against the identity in the EAP-TLS server's
  certificate."

I am sure most EAP implementations are secure, but I have recently seen 
prototype usage (not EAP) of TLS where the identity in the certificate was 
never checked, resulting in nothing more than group authentication where any 
cert signed by any of the trust anchors was accepted. I think implementors need 
guidance on that verifying the identity is essential for getting 
authentication. Otherwise implementors might easily miss this, thinking that 
TLS and certificate chain validation alone gives authentication.

Cheers,
John





-Original Message-
From: Emu  on behalf of Alan DeKok 

Date: Monday, 8 February 2021 at 13:42
To: Joseph Salowey 
Cc: EMU WG , Martin Thomson , Benjamin Kaduk 

Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3

On Feb 7, 2021, at 9:27 PM, Joseph Salowey  wrote:
> 
> I'd like to get feedback from the working group on the EAP-TLS 1.3 key 
> derivation.  Does this improve the security of the system?  Are there any 
> implementation barriers?
> 
> The key derivation for TLS 1.3 uses the key exporters defined for TLS 1.3.  A 
> few reviews have pointed out that the exporter master secret for TLS 
> exporters includes server identity information, but does not include 
> information about the peer/client identity.  
> 
> Both Martin and Ben proposed adding the peer identity into the context 
> parameter for the TLS exporter key derivation. This binds the peer identity 
> into the key derivation for EAP-TLS keys that are used in lower layer 
> protocols.   This explicit binding strengthens the resulting authentication 
> implied by the key and should make formal analysis of the system easier.  
> 
> For example, if the EAP-TLS server is requesting a certificate from the peer 
> then the key derivation would look something like:
> 
> Key =  TLS-Exporter(label, peerID/peer certificate, 64) 

  What format is used for then peer certificate?

  The EAP-TLS application doesn't necessarily have access to the "on the wire" 
format of the certificate.  It may only have access to a decoded / high-layer 
representation of the certificate.  For that reason, I would prefer to avoid 
using the certificate in any key derivation.

  The peer ID may be more, if we just a field in a certificate (e.g. 
subjetAltName).  It is simple, and can be exported as an opaque blob.

> Where the label is the label defined for the key and the peer ID is identity 
> information for the peer.  Since the peer ID in EAP-TLS has some potential 
> ordering issues, it may be better to use the end entity certificate of the 
> peer as the peerID.  
> 
> In the case where the peer is not asked for a certificate then the derivation 
> would not include the peerID.  The TLS resumption key derivation is derived 
> using both the peer and server identity from the original exchange so adding 
> the peerID into the EAP-TLS key derivation in the resumption is not 
> necessary.  

  I would prefer to define a consistent key derivation.  The more if / then / 
else cases are defined, the more opportunity for error.

  TBH, just leaving it as draft-13 or -14 is fine.  The main important change 
for me is to mandate the use of TLS alert as a secure altReject indicator, and 
a delayed close_notify / commitment message (after the client cert) was a 
secured altAccept indicator.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Protected Result Indicators in EAP-TLS 1.3

2021-02-11 Thread John Mattsson
Hi,

These three alternatives seem to work for EAP-TLS. (2) seems the simplest from 
a EAP-TLS standpoint.

But how do these work with other EAP methods now that we are taking about a 
protected success. I assume this will be needed in TTLS, PEAP, FAST, TEAP?

The -13 commitment message could be sent as the first application data, the 
protected success would to my understanding be the last application data.

This was discussed in the last months but with unclear definitions of what the 
commitment message was.

Is it only (1a) or (1b) that work?

My understanding is that:

"After sending application data in an EAP-Request the EAP-TLS server MUST send 
only EAP-Success."

would not work for TTLS, PEAP, FAST, TEAP. To make it work the application data 
would have to be something specific like "EAP-SUCCESS".

John


-Original Message-
From: John Mattsson 
Date: Wednesday, 10 February 2021 at 11:48
To: EMU WG , "t...@ietf.org" , Benjamin Kaduk 

Subject: Re: [Emu] Protected Result Indicators in EAP-TLS 1.3

With Alan's comments, I think we are down to 3 alternatives:

(1a). Use close_notify alert as protected success.
  Use error alerts as protected failure.

 - Forbid close_notify except as success indication
 - Mandate Error alert before EAP-Failure
 - Forbid all use of user_cancelled

(1b). Use close_notify alert as protected success.
  Use all other alerts as protected failure.

  - Forbid close_notify except as success indication
  - Mandate Error alert or user_cancelled before EAP-Failure

(2). Use application data as protected success.
 Use all alerts as protected failure.

- After sending application data in an EAP-Request the EAP-TLS server MUST 
send only EAP-Success.
- Mandate alert (closure, error) before EAP-Failure

I think it is important to discuss what the ongoing EMU consensus call will 
mean in practice. Previous discussions was mostly about not sending more 
handshake messages. Protected result indicators are quite different.

It would we very good with early feedback from Ben and the TLS WG if they see 
problems with any of the alternatives.

Cheers,
John

-Original Message-
From: Alan DeKok 
Date: Tuesday, 9 February 2021 at 15:22
To: John Mattsson 
Cc: EMU WG 
Subject: Re: [Emu] Protected Result Indicators in EAP-TLS

On Feb 9, 2021, at 5:00 AM, John Mattsson 
 wrote:
> 
> Below is my summary of the situation:
> 
> - It seems like there will be consensus to have protected result indicators 
> in EAP-TLS 1.3.
> - No one has objected to mandate Error alert on fatal error condition.
> - Optional protected result indicators are different from mandatory result 
> indicators,
>  recent suggestion is that protected failure result indicators shall be 
> mandatory.
> - Success indicators and failure indicators need to be discuss together.

  Yes.

> Below is my summary of the alternatives:

  I think whatever the altAccept notice is used, the altReject needs to be a 
TLS alert.  This alert is secured and authenticated.

> 1. Use close_notify alert as protected success. Use other alerts as protected 
> failure.
> 
>  To make it work I think EAP-TLS 1.3 needs to profile TLS 1.3 as:
> 
>  - Forbid close_notify except as success indication
>  - Mandate Error alert before EAP-Failure
>  - Forbid all use of user_cancelled

  If we use close_notify, yes.

> 2. Use application data for protected result indicators. Mandate alert 
> (closure or error) before EAP-Failure.
>   
>   TLS people has stated that this might be reordered and that it is a 
> layer violation.

  Unlike many other uses of TLS, EAP is *not* handing control of the transport 
protocol over to the TLS layer.  i.e. TLS libraries often implement TCP (or 
even HTTP) wrappers.  None implement EAP.

  This limitation means that there are no ordering issues with use of 
application data.  In packet N, the EAP-TLS server asks the TLS layer for data, 
and encodes it into EAP, and then sends it out.  Some packet M>N, the EAP-TLS 
server has verified the client certificate.  At that point, it can write 
application data to TLS.

  The other benefit of using application data is that it is needed for other 
TLS-based EAP methods.  i.e. there is little reason to have complex code paths 
when a more unified approach will do.  This protocol choice helps to simplify 
implementations.

>   I think the worries can be overcome by writing things as requirements on
>   the EAP-TLS layer, e.g.
> 
>   "After sending application data in a EAP-Request the EAP-TLS server 
> MUST not send
>  any more EAP-Request"

  The EAP-TLS server MUST send only EAP-Success.

> 3. Success and failure indication on the EAP-TLS layer
> 
>   This was never discussed beyond that using an uprotected flag bit was not 
> acceptable.
> 
>

Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt

2021-02-11 Thread John Mattsson
Hi Mohit,



A P-256 ECDH public key does not _require_ 33 bytes. EDHOC uses 32 bytes 
compact representation [RFC 6090] and there are a lot of people arguing that 
HPKE should do the same.



3GPP 5G already uses the 33 bytes compressed format from SECG in SUCI (I wrote 
part of that specification) but I now think it was a mistake.



The change from 32 to 33 bytes encoding affects more than just size. Forcing 
the implementation to calculate a y-coordinate significantly slows down the 
calculations as a x-coordinate only ladder cannot be used. I don’t think this 
change is good.



Also, referring to both 186-4 and SECG for the encoding seems strange. If the 
33 byte encoding is kept, I think SECG only is enough.



John

From: Emu  on behalf of Mohit Sethi M 

Date: Thursday, 9 July 2020 at 08:46
To: Russ Housley 
Cc: "emu@ietf.org" 
Subject: Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-04.txt


Rene, Russ, and I had an offline email exchange about this issue. I think we 
are now in agreement that the public key for the NIST P-256 curve requires at 
least 33 bytes (in the compressed format).

Thus, we should update the draft to reflect the correct key size. Adding a 
reference to 
https://www.secg.org/SEC2-Ver-1.0.pdf
 and explicitly mentioning the use of the compressed format would also be 
beneficial.

--Mohit
On 6/24/20 11:04 PM, Russ Housley wrote:

The ECDH public value in RFC 5480 is an OCTET STRING, which means that the 
value is exactly 32 bytes.  When this gets carried as a subject public key in a 
certificate, there is an extra byte only because the type is 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 

 wrote:



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't it make sense to explicitly say that this is an

octet string in the compressed format while referencing "SEC 1: Elliptic

Curve Cryptography, Version 2.0" for the point to octet string

conversion rules?



--Mohit



On 5/26/20 9:57 AM, 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   : Perfect-Forward Secrecy for the Extensible 
Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' 
PFS)

Authors : Jari Arkko

  Karl Norrman

  Vesa Torvinen

   Filename: draft-ietf-emu-aka-pfs-04.txt

   Pages   : 26

   Date: 2020-05-25



Abstract:

   Many different attacks have been reported as part of revelations

   associated with pervasive surveillance.  Some of the reported attacks

   involved compromising smart cards, such as attacking SIM card

   manufacturers and operators in an effort to compromise shared secrets

   stored on these cards.  Since the publication of those reports,

   manufacturing and provisioning processes have gained much scrutiny

   and have improved.  However, the danger of resourceful attackers for

   these systems is still a concern.



   This specification is an optional extension to the EAP-AKA'

   authentication method which was defined in [I-D.ietf-emu-rfc5448bis].

   The extension, when negotiated, provides Perfect Forward Secrecy for

   the session key generated as a part of the authentication run in EAP-

   AKA'.  This prevents an attacker who has gained access to the long-

   term pre-shared secret in a SIM card from being able to decrypt any

   past communications.  In addition, if the attacker stays merely a

   passive eavesdropper, the extension prevents attacks against future

   sessions.  This forces attackers to use active attacks instead.





The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/



There are also htmlized versions available at:

https://tools.ietf.org/html/draft-ietf-emu-aka-pfs-04

https://datatracker.ietf.org/doc/html/draft-ietf-emu-aka-pfs-04



A diff from the previous version is available at:

https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-aka-pfs-04





Please note that it may take a couple of minutes from the time of submission

until the htmlized version and diff are available at tools.ietf.org.




Re: [Emu] Emu Digest, Vol 145, Issue 37

2021-02-10 Thread John Mattsson
Hi Vadim,

Extending EAP-Failure/EAP-Success has been discussed in the past. People have 
expressed that it would be good to protect EAP-Failure/EAP-Success and to be 
able to send data with them. Changing EAP-Failure/EAP-Success is however not 
seen as possible and was not discussed in any recent discussion.

EAP allows other protected/unprotected result indicatiors in the method or in 
lower layers. The recent discussion was to use the TLS layer for result 
indicatiors or to extend the EAP-TLS request packet format. As Alan think 
extending the EAP-TLS packets is more complex, the only remaining alternatives 
on the table is to rely on the TLS layer.

Cheers,
John


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Protected Result Indicators in EAP-TLS 1.3

2021-02-10 Thread John Mattsson
With Alan's comments, I think we are down to 3 alternatives:

(1a). Use close_notify alert as protected success.
  Use error alerts as protected failure.

 - Forbid close_notify except as success indication
 - Mandate Error alert before EAP-Failure
 - Forbid all use of user_cancelled

(1b). Use close_notify alert as protected success.
  Use all other alerts as protected failure.

  - Forbid close_notify except as success indication
  - Mandate Error alert or user_cancelled before EAP-Failure

(2). Use application data as protected success.
 Use all alerts as protected failure.

- After sending application data in an EAP-Request the EAP-TLS server MUST 
send only EAP-Success.
- Mandate alert (closure, error) before EAP-Failure

I think it is important to discuss what the ongoing EMU consensus call will 
mean in practice. Previous discussions was mostly about not sending more 
handshake messages. Protected result indicators are quite different.

It would we very good with early feedback from Ben and the TLS WG if they see 
problems with any of the alternatives.

Cheers,
John

-Original Message-
From: Alan DeKok 
Date: Tuesday, 9 February 2021 at 15:22
To: John Mattsson 
Cc: EMU WG 
Subject: Re: [Emu] Protected Result Indicators in EAP-TLS

On Feb 9, 2021, at 5:00 AM, John Mattsson 
 wrote:
> 
> Below is my summary of the situation:
> 
> - It seems like there will be consensus to have protected result indicators 
> in EAP-TLS 1.3.
> - No one has objected to mandate Error alert on fatal error condition.
> - Optional protected result indicators are different from mandatory result 
> indicators,
>  recent suggestion is that protected failure result indicators shall be 
> mandatory.
> - Success indicators and failure indicators need to be discuss together.

  Yes.

> Below is my summary of the alternatives:

  I think whatever the altAccept notice is used, the altReject needs to be a 
TLS alert.  This alert is secured and authenticated.

> 1. Use close_notify alert as protected success. Use other alerts as protected 
> failure.
> 
>  To make it work I think EAP-TLS 1.3 needs to profile TLS 1.3 as:
> 
>  - Forbid close_notify except as success indication
>  - Mandate Error alert before EAP-Failure
>  - Forbid all use of user_cancelled

  If we use close_notify, yes.

> 2. Use application data for protected result indicators. Mandate alert 
> (closure or error) before EAP-Failure.
>   
>   TLS people has stated that this might be reordered and that it is a 
> layer violation.

  Unlike many other uses of TLS, EAP is *not* handing control of the transport 
protocol over to the TLS layer.  i.e. TLS libraries often implement TCP (or 
even HTTP) wrappers.  None implement EAP.

  This limitation means that there are no ordering issues with use of 
application data.  In packet N, the EAP-TLS server asks the TLS layer for data, 
and encodes it into EAP, and then sends it out.  Some packet M>N, the EAP-TLS 
server has verified the client certificate.  At that point, it can write 
application data to TLS.

  The other benefit of using application data is that it is needed for other 
TLS-based EAP methods.  i.e. there is little reason to have complex code paths 
when a more unified approach will do.  This protocol choice helps to simplify 
implementations.

>   I think the worries can be overcome by writing things as requirements on
>   the EAP-TLS layer, e.g.
> 
>   "After sending application data in a EAP-Request the EAP-TLS server 
> MUST not send
>  any more EAP-Request"

  The EAP-TLS server MUST send only EAP-Success.

> 3. Success and failure indication on the EAP-TLS layer
> 
>   This was never discussed beyond that using an uprotected flag bit was not 
> acceptable.
> 
>   Things at the EAP-TLS layer can quite easily be made protected.
> 
>   - Use one of the reserved bit in the EAP-TLS pakcet to indicate success.
>   - Append TLS-Exporter("EXPORTER_EAP_TLS_SUCCESS_" + Type-Code, "", 16) 
> to the packet
> 
>   - Use another of the reserved bit in the EAP-TLS pakcet to indicate 
> failure.
>   - Append TLS-Exporter("EXPORTER_EAP_TLS_FAILURE_" + Type-Code, "", 16) 
> to the packet
> 
>   A solution at the EAP-TLS layers would not be dependant on profiling 
> TLS 1.3

  Appending data to the EAP-TLS packets is problematic.  We already have a 
secured tunnel inside of the TLS layer.  Using that is *significantly* easier 
than mangling packets.

> 4. Success on EAP-TLS layer, Mandate alert (closure or error) before 
> EAP-Failure.
> 
> 5. Failure on EAP-TLS layer. Application data for success, 

  I'm not sure what those mean.

> I think 1. seems like the most complicated solution. It is also kind of ugly 
> 

[Emu] Protected Result Indicators in EAP-TLS

2021-02-09 Thread John Mattsson
Below is my summary of the situation:

- It seems like there will be consensus to have protected result indicators in 
EAP-TLS 1.3.
- No one has objected to mandate Error alert on fatal error condition.
- Optional protected result indicators are different from mandatory result 
indicators,
  recent suggestion is that protected failure result indicators shall be 
mandatory.
- Success indicators and failure indicators need to be discuss together.

Below is my summary of the alternatives:

1. Use close_notify alert as protected success. Use other alerts as protected 
failure.

  To make it work I think EAP-TLS 1.3 needs to profile TLS 1.3 as:

  - Forbid close_notify except as success indication
  - Mandate Error alert before EAP-Failure
  - Forbid all use of user_cancelled

  Alternatively

  - Forbid close_notify except as success indication
  - Mandate Error alert or user_cancelled before EAP-Failure

2. Use application data for protected result indicators. Mandate alert (closure 
or error) before EAP-Failure.

TLS people has stated that this might be reordered and that it is a 
layer violation.

I think the worries can be overcome by writing things as requirements on
the EAP-TLS layer, e.g.

"After sending application data in a EAP-Request the EAP-TLS server 
MUST not send
  any more EAP-Request"

3. Success and failure indication on the EAP-TLS layer

   This was never discussed beyond that using an uprotected flag bit was not 
acceptable.

Things at the EAP-TLS layer can quite easily be made protected.

- Use one of the reserved bit in the EAP-TLS pakcet to indicate success.
- Append TLS-Exporter("EXPORTER_EAP_TLS_SUCCESS_" + Type-Code, "", 16) 
to the packet

- Use another of the reserved bit in the EAP-TLS pakcet to indicate 
failure.
- Append TLS-Exporter("EXPORTER_EAP_TLS_FAILURE_" + Type-Code, "", 16) 
to the packet

A solution at the EAP-TLS layers would not be dependant on profiling 
TLS 1.3

4. Success on EAP-TLS layer, Mandate alert (closure or error) before 
EAP-Failure.

5. Failure on EAP-TLS layer. Application data for success, 

I think 1. seems like the most complicated solution. It is also kind of ugly as 
it use an alert as indication for success. That said, I can live with any 
solution that are acceptable for implementors and TLS people.

Cheers,
John


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

2021-02-09 Thread John Mattsson
Michael Richardson wrote:
>is this really 3.5 round trips -> 4.5 round trips, or is it really more like 
>that we are >going from perhaps 5.5 round trips to 6.5 round trips (for 
>example).

Another question is if EAP-Success should even be counted. A protected success 
indication would make EAP-Success a dummy message. It has to be sent according 
to EAP, but would not really be used

John 

-Original Message-----
From: John Mattsson 
Date: Sunday, 7 February 2021 at 11:14
To: EMU WG 
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

Hi,

I think it is important to point out that the discussion has been about 
_protected_ result indications. RFC 3748 discussed protected and non-protected 
result indications. Also worth noting that it is not possible with protected 
failure indication when the server does not accept the ClientHello.

Michael Richardson wrote:
>is this really 3.5 round trips -> 4.5 round trips, or is it really more like 
>that we are >going from perhaps 5.5 round trips to 6.5 round trips (for 
>example).

For a full handshake it is probably more like 10.5 -> 11.5 roundtrips or more. 
Certificate chains are large and EAP-TLS typically sends 2 of them.

For resumption is might 3.5 round trips -> 4.5.

In cases a no-more-handshake indication is needed anyway to ease 
implementation, or in cases where the server wants client finished before 
sending newsessionticket, there is probably no increase at all.

John

-Original Message-
From: Emu  on behalf of Michael Richardson 

Date: Sunday, 7 February 2021 at 03:21
To: EMU WG 
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3


Joseph Salowey  wrote:
> There is growing support for mandating result indicators for EAP-TLS
> 1.3.  The result indicators help protect the EAP protocol exchange in
> the many different types of environments EAP-TLS is used and make the
> integration with the EAP state machine clearer.  This has the impact of
> adding a round trip to EAP-TLS 1.3 making a total of 4.5 round trips.
> It may be possible to optimize this exchange, but that would need
> further study and would be beyond the scope of this effort.

> This consensus call has two parts:

> 1. Please respond to the list if you support adding explicit result
> indications of success and failure from the EAP Server to the EAP Peer
> in EAP-TLS 1.3.  If you object please respond to the list indicating
> why.

I support this.

> 2. Please respond to the list if you support using TLS close_notify
> alert for a success indication and TLS error alert for a failure
> indication.  If you object please respond to the list indicating why.

As I understand it, it is the use of Close_Notify that pushes us to 4.5 round
trips.

Given a client-certificate (or chain) of >1500 bytes more than one packet would 
be
required send that, and I believe that we can't send Close_Notify until the
certificate has been communicated (and verified).

So my question is: is this really 3.5 round trips -> 4.5 round trips, or is
it really more like that we are going from perhaps 5.5 round trips to 6.5
round trips (for example).
I posit this, because I think that the increase in round trip count is
largely irrelevant on non-challenged (RFC7228 term) networks.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide






___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] General EAP discussion of protected alternate indication of success, RFC 4137, and IEEE 802.1X

2021-02-08 Thread John Mattsson
Thanks,

Good to know that RFC 5448 (EAP-AKA’) and aka-pfs have protected result 
indicators. I missed that RFC 5448 gets this from RFC 4187.

John

-Original Message-
From: "jari.ar...@piuha.net" 
Date: Monday, 8 February 2021 at 18:07
To: John Mattsson 
Cc: EMU WG 
Subject: Re: [Emu] General EAP discussion of protected alternate indication of 
success, RFC 4137, and IEEE 802.1X

John,

This may be a side note in the TLS discussion, but just looked at the below 
list:

> Looking at the other active documents in the EMU WG:
> 
> draft-ietf-emu-rfc5448bis
> draft-ietf-emu-aka-pfs
> […]
> None of them has a protected alternate indication of success […]

And it seems to me that RFC 4187 (EAP-AKA) does have protected result 
indicators (see Section 12.8). RFC 5448 (EAP-AKA’) is a diff to EAP-AKA, and it 
doesn’t add or remove of any of that. RFC5448bis even has a table (Section 3.5) 
that shows when AT_RESULT_IND, AT_NOTIFICATION, AT_ENCR_DATA, etc and 
EAP-Request/Response/AKA-Notification can be used. That table matches my 
understanding of RFC 4187 result indicators usage. I also checked an open 
source implementation and it seemed to be doing these functions.

As for the PFS extension, that shouldn’t remove any of the underlying features 
either.

(But I could easily have misunderstood or forgotten something. Happy to learn 
or fix things if so.)

Jari


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

2021-02-08 Thread John Mattsson
>This consensus call has two parts:
>
>1. Please respond to the list if you support adding explicit result
>indications of success and failure from the EAP Server to the EAP Peer in
>EAP-TLS 1.3.  If you object please respond to the list indicating why.

I support this based on that implementors support it. Based on the ongoing 
disucssion
between Mohit and Bernard, the exact security benefits seem a bit uncertain.


>2. Please respond to the list if you support using TLS close_notify alert
>for a success indication and TLS error alert for a failure indication.  If
>you object please respond to the list indicating why.

I support that TLS error alert is a protected failure indication.

But to make a practical difference I think we need to follow Alans suggestion
and mandate a protected failure indication before EAP-Failure.

Looking at RFC 8446 it looks like TLS 1.3 can terminate a connection by:

- Not sending any alert
- Sending an Error alert
- Sending close_notify
- Sending user_cancelled
- Sending user_cancelled followed by close_notify
- (It would also not suprise me if some implementation
sends an Error alert followed by close_notify).

It seems a bit complicated to use alerts as both failure and success 
indications.

To make it work I think EAP-TLS 1.3 needs to:

- Forbid all use of user_cancelled
- Forbid close_notify except as success indication
- Mandate Error alert before EAP-Failure

Do implementors and TLS people agree that is possible?

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Key Derivation for EAP-TLS 1.3

2021-02-07 Thread John Mattsson
Hi,

Martin Thompson wrote:

>What I was concerned about was the information that is exchanged in EAP 
>*before* the TLS handshake
>begins that might affect the choice of certificate to offer.  As this is not 
>authenticated at all,
>there are trivial attacks if a client uses that information to guide its 
>choice of certificate.  For
>that problem, including the certificate as context in the key exporter doesn't 
>help, but including
>any information that might appear outside could, if you get all of it.

That seems more interesting to discuss. I think the only only interesting 
information exchanged before the TLS handshake is the identity in the identity 
response. It will typically be an anonymous NAI 

@realm

but it may be an encrypted username

xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm

and formally it does not even need to be a NAI. EAP-TLS 1.3 mandates a 
"privacy-friendly" identity. An encrypted username may not protect against 
spoofing.

I don't think RFC 5216 states anything about how the client choses it's 
certificate. In some
implementation I have seen the user picks a certificate. The realm does of 
course very much determine the server certificate as the response would be send 
to different servers.

On one hand, the realm could be considered routing information just like the IP 
address. Changing the sever IP address in any use of TLS might change the 
server certificate.

On the other hand the guidance in RFC 5216 on how to verify the server identity 
is very vague.

   Once a TLS session is established, EAP-TLS peer and server
   implementations MUST validate that the identities represented in the
   certificate are appropriate and authorized for use with EAP-TLS.  The
   authorization process makes use of the contents of the certificates
   as well as other contextual information.  While authorization
   requirements will vary from deployment to deployment, it is
   RECOMMENDED that implementations be able to authorize based on the
   EAP-TLS Peer-Id and Server-Id determined as described in Section 5.2.

There are no hard rules like the one in RFC 2818 about comparing hostname with 
subjectAltName.

Not sure that putting the identity response in the exporter context improves 
anything. Might be more useful with guidance/requirements on how to chose 
certificates and which identities to allow.

Cheers,
John

-Original Message-
From: Emu  on behalf of Martin Thomson 

Date: Monday, 8 February 2021 at 04:47
To: Joseph Salowey , EMU WG , 'Benjamin Kaduk' 

Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3

On Mon, Feb 8, 2021, at 13:27, Joseph Salowey wrote:
> Both Martin and Ben proposed adding the peer identity into the context 
> parameter for the TLS exporter key derivation. 

So I wasn't suggesting the client certificate, as that is covered by the client 
key confirmation and (I think) the results we have from the exported 
authenticator work indicates that this isn't necessary for the security of the 
protocol; validating the Finished is what provides the assurances there.

What I was concerned about was the information that is exchanged in EAP 
*before* the TLS handshake begins that might affect the choice of certificate 
to offer.  As this is not authenticated at all, there are trivial attacks if a 
client uses that information to guide its choice of certificate.  For that 
problem, including the certificate as context in the key exporter doesn't help, 
but including any information that might appear outside could, if you get all 
of it.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-07 Thread John Mattsson
Thanks Mohit,

Based on your comments it seems like protected success indication is not needed 
in IEEE 802 for security reasons. Would be good with more feedback on this. 
EAP-TLS 1.3 might get a protected success indication anyway, but the draft 
should have a few sentences about what the alternate success indication is good 
for. Would also be good to conclude that other methods do not need an alternate 
success indication. Seems like e.g. RFC 5448 removed the optional result 
indications from RFC 4187, probably after an agreement that they were not 
needed.

Note that RFC 4137 is informal and not mandatory to follow. Similarly a 
implementation can ignore the alternative success indication unless EAP-TLS 1.3 
makes it mandatory. In RFC 5216 it is to my understanding up to the 
implementation if it wants to use server Finished as a alternate success 
indication.

Cheers,
John

From: Mohit Sethi M 
Date: Monday, 8 February 2021 at 06:33
To: John Mattsson , Bernard Aboba 
, "emu@ietf.org" , "t...@ietf.org" 

Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine


Hi all,

I have now read both the papers. I am not sure the attacks in [2] are anymore 
possible:

- The first attack described in section 4.1.1 shows that an EAP-Success leads 
to an unconditional transition to the Authenticated state irrespective of the 
current state. However, I am not sure this is the case anymore as RFC 4137 
(https://tools.ietf.org/html/rfc4137#appendix-A.1) now says :

 |+--

 |  rxSuccess &&  |

 |  (reqId == lastId) &&  |   SUCCESS

 |   (decision != FAIL)   |

 |+--
The peer cannot simply transition to SUCCESS state as the decision is 
initialized to FAIL. The decision is set to COND_SUCC or UNCOND_SUCC only after 
the peer decides that the server has sufficiently been authenticated (for EAP 
methods with mutual authentication).

- The second attack described in section 4.2 relies on the adversary sending a 
disassociate management frame and then uses the MAC address of the 
authenticated supplicant to gain network access. This again should not work as 
a) 802.11w-2009 protects disassociate management frame, and b) EAP-Success is 
followed by 4-way handshake after which there is per packet authenticity and 
integrity (with Key Confirmation Key). The attacker cannot gain network access 
without knowing the PMK (derived from the MSK) and performing the 4-way 
handshake.

The attacks in [1] are not specific to EAP. The attacks relate to Denial of 
Service (DoS) by injecting spoofed alerts in TLS. John has suggested the 
following text for the draft (which I think is sufficient):
Protected TLS Error alerts are protected failure result indications and enables 
the EAP-TLS peer and EAP-TLS server to determine that the failure result was 
not spoofed by an attacker. Protected failure result indications provide 
integrity protection and replay but MAY be unauthenticated. Protected failure 
result does not significantly improve availability as TLS 1.3 treats most 
malformed data as a fatal error.
--Mohit

[1] Extensible Authentication Protocol Vulnerabilities and Improvements : 
https://scholarworks.sjsu.edu/cgi/viewcontent.cgi?article=1431=etd_projects
[2] An Initial Security Analysis of the IEEE 802.1X Standard : 
http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf
On 2/4/21 2:18 PM, John Mattsson wrote:
Hi Bernard,

I (re-)read the papers you send.

- "Extensible Authentication Protocol Vulnerabilities and Improvements 
Improvements"

  This paper talks attacks on availability by spoofing messages. It looks into 
a small amount of ways where spoofed messages causes the TLS connection to 
fail, especially it focus on alert messages.

  TLS and EAP-TLS is trivial for an on-path attacker to shut down. Basically 
any small error is fatal in TLS. Focusing on alert messages does not seem 
correct. An attacker can e.g. at any time send a small record with length 2^15, 
which causes TLS to terminate the connection. I think the only thing that can 
be achieved without rewriting TLS is that availability attacks does not cause 
long-term damage, i.e. the nodes can retry the handshake.

- "An Initial Security Analysis of the IEEE 802.1X Standard"

  This paper discusses attacks on 801.11. The weaknesses described seems to 
come from 802.11 / EAP interactions.

The discussions around IETF 102 was that the uncertainty (NewSessionTicket or 
not) in TLS 1.3 was "inconvinient" and that it would be convient to get rid of 
the uncertainty. Bernard then pointed out that any message changing the state 
need to be authenticated to that it is not possible to spoof. I think that both 
the application layer commit message as well as clo

Re: [Emu] EAP-TLS and TLS alerts

2021-02-07 Thread John Mattsson
 Alan DeKok wrote:

 >> I personally fine with writing MUST send an Error alert if the WG wants 
 >> that.
>
> This is what all implementations have done for ~15 years.  The TLS Alert 
> satisfies the "altReject" 
> requirements of RFC 4137.  Which means it's a very good iea.

Jorge said offline that he also wanted this behaivior. I will update the draft 
to make TLS Error alerts mandatory to send.

Maybe the draft should summarize the profiling EAP-TLS 1.3 does on TLS 1.3

- OCSP stapling mandatory to support for server
- Only cipher suites with confidentiality
- MUST send Erros alert.



>> I don't if this would be common or expected behavior from the server, but if 
>> EAP-TLS cannot
>> enforce that this to not happen, then we cannot use close_notify as an 
>> alternate success
>> indication, because an alternate success indication cannot be followed by 
>> EAP-Failure.
>
> Perhaps just update the document to say that such use-cases are forbidden?

I already did that when I added text to the GitHub version on alternative 
success indicatiors. If close_notify is to be used as an alternative success 
indicatiors, forbidding and enforcing this is essential, otherwise, 
close_notify cannot be used.


Cheers,
John


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Session tickets in TLS 1.3

2021-02-07 Thread John Mattsson
Alan DeKok wrote:

>The document should explain this in detail, and suggest which message flows 
>are preferred, and which >ones MUST be supported.  It should explain what 
>happens when resumption is negotiated, and 20
>tickets are received by the peer.  What does that mean?  What does the peer do 
>with them?  Why does >the server send them?  Which (if any) ticket is 
>preferred?

>It is not helpful if a specification says "anything can happen".  The purpose 
>of the specification is >to provide a guide for implementors and deployments.  
>This includes not just saying what *can* >happen.  But what *should* happen.  
>Why one thing is preferred over another.  Why certain protocol >choices were 
>made.  So that readers of the document are informed as to what to do, and why 
>they need >to do it.

This seem very much like TLS 1.3 details. I am not sure that EAP-TLS should 
answer these question, or that the EMU WG even has the competence. What you 
want is basically a description of the design choices in TLS 1.3 and guidance 
that TLS 1.3 itself decided to not give.

Have you a conrete example of something this is more important to give guidance 
about in EAP-TLS 1.3 than in TLS 1.3 in genereal?

Several reviewers the last month suggested the opposite, to completely remove 
all TLS 1.3 details and only describe the interactions between TLS 1.3 and 
EAP-TLS 1.3.




>What does it mean to say "will" appear?  SHOULD the conversation look like 
>that?  MUST it?  What >happens when the conversation doesn't appear like that? 
> What does it mean when the conversation >doesn't appear like that?

That is from the old version. Unfortunatly the EMU GitHub does not 
automatically generate txt and html after commits like most other repositories. 
As I do all my commits through the web interface, the only up to date version 
is the xml...

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/blob/master/draft-ietf-emu-eap-tls13.xml

The current text is:

"Figure 2  shows an example message flow where EAP-TLS server authentication is 
unsuccessful and the EAP-TLS peer sends a TLS Error alert."

All sentences talking about the message flow figures have been rewritten in a 
similar way, i.e., "shows an example message flow". TLS 1.3 allows quite a lot 
of flexibility already now with NewSessionTicket, HelloRetryRequest, KeyUpdate, 
option errors, optional to accept resumption, etc. Future extensions might 
allow or restrict the flexibility.




> What does it mean if the NewSessionTicket message is sent later?  Is there an 
> impact on the number > of round trips?  What is the RECOMMENDED approach?

>  Perhaps the NewSessionTicket message SHOULD be sent in the same EAP packet 
> as the TLS Server 
> Finished message.  Sending it later adds additional round trips for no 
> benefit.

I think the only difference would be if the server wants to put the client 
certificate in the ticket.

I am hesitant to add any recommendations for TLS 1.3 not specifically related 
to EAP-TLS. These are also things RFC 8446 leaves completely to the 
implementation.





>Further, there are significantly more variants of TLS 1.3 flows than for TLS 
>1.2.

Yes, for TLS 1.3 there are infinitly many valid message flows


>These variants should be explained, along with suggestions and 
>recommendations.  What does an EAP >peer do if it receives 20 session tickets? 
> Why would a server send 20 session tickets?

>Perhaps simply recommend that if possible, only one session ticket be sent by 
>the EAP server.  And >that if the EAP peer receives multiple session tickets, 
>it should only save one, and discard the >rest.  Which one doesn't matter.  If 
>the EAP server sends multiple session tickets, it's the >responsibility of the 
>EAP server to ensure that all are valid.

These are all things that should be handled by the TLS layer. Not sure EAP-TLS 
should or need to say anything about this. 



>...
>To enable resumption when using EAP-TLS with TLS 1.3, the EAP-TLS server MUST 
>send one or more >Post-Handshake NewSessionTicket messages

>  I suggest limiting this to one. I suggest also saying that session tickets 
> SHOULD NOT be sent >BEFORE the client cert is validated.  But that perhaps 
> this is not always under the control of the >EAP layer.  And, that the EAP 
> peer MUST ignore session tickets until after it has received the 
> >"altSuccess" message from the EAP server.  Further, the EAP server MUST NOT 
> cache or use any session >tickets sent by the TLS layer before the client 
> certificate is validated.

I don't think EAP-TLS should make recommendations about internal TLS 1.3 unless 
necesary. Such recommendations would likely have to be checked with the TLS WG 
so that they make sense. 

Resticting things would make EAP-TLS incompatible with a lot of TLS 
implementation unless the default behaivior can be changed. Both of the 
following 

- I suggest limiting this to one.
- I suggest also saying that session tickets SHOULD NOT 

Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3

2021-02-07 Thread John Mattsson
Hi,

I think it is important to point out that the discussion has been about 
_protected_ result indications. RFC 3748 discussed protected and non-protected 
result indications. Also worth noting that it is not possible with protected 
failure indication when the server does not accept the ClientHello.

Michael Richardson wrote:
>is this really 3.5 round trips -> 4.5 round trips, or is it really more like 
>that we are >going from perhaps 5.5 round trips to 6.5 round trips (for 
>example).

For a full handshake it is probably more like 10.5 -> 11.5 roundtrips or more. 
Certificate chains are large and EAP-TLS typically sends 2 of them.

For resumption is might 3.5 round trips -> 4.5.

In cases a no-more-handshake indication is needed anyway to ease 
implementation, or in cases where the server wants client finished before 
sending newsessionticket, there is probably no increase at all.

John

-Original Message-
From: Emu  on behalf of Michael Richardson 

Date: Sunday, 7 February 2021 at 03:21
To: EMU WG 
Subject: Re: [Emu] Consensus call for result indicators in EAP-TLS 1.3


Joseph Salowey  wrote:
> There is growing support for mandating result indicators for EAP-TLS
> 1.3.  The result indicators help protect the EAP protocol exchange in
> the many different types of environments EAP-TLS is used and make the
> integration with the EAP state machine clearer.  This has the impact of
> adding a round trip to EAP-TLS 1.3 making a total of 4.5 round trips.
> It may be possible to optimize this exchange, but that would need
> further study and would be beyond the scope of this effort.

> This consensus call has two parts:

> 1. Please respond to the list if you support adding explicit result
> indications of success and failure from the EAP Server to the EAP Peer
> in EAP-TLS 1.3.  If you object please respond to the list indicating
> why.

I support this.

> 2. Please respond to the list if you support using TLS close_notify
> alert for a success indication and TLS error alert for a failure
> indication.  If you object please respond to the list indicating why.

As I understand it, it is the use of Close_Notify that pushes us to 4.5 round
trips.

Given a client-certificate (or chain) of >1500 bytes more than one packet would 
be
required send that, and I believe that we can't send Close_Notify until the
certificate has been communicated (and verified).

So my question is: is this really 3.5 round trips -> 4.5 round trips, or is
it really more like that we are going from perhaps 5.5 round trips to 6.5
round trips (for example).
I posit this, because I think that the increase in round trip count is
largely irrelevant on non-challenged (RFC7228 term) networks.

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide





___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] General EAP discussion of protected alternate indication of success, RFC 4137, and IEEE 802.1X

2021-02-06 Thread John Mattsson
Hi,

Bernard brought up compability with RFC 4137 and the need for protected 
alternate indication of success in the context of EAP-TLS 1.3

https://mailarchive.ietf.org/arch/msg/emu/F-LcEX3UbAEX20Amk0xBBqfPQNQ/

I think we need to discuss this in a general EAP setting as this in not EAP-TLS 
specific at all but also related to all other EAP methods including 
draft-ietf-emu-rfc5448bis, draft-ietf-emu-aka-pfs, draft-ietf-emu-eap-noob, and 
draft-ingles-eap-edhoc.

The need for anprotected alternate indication of success in IEEE 802.1X is as 
described in [1]

  "lack of per-packet authenticity and integrity in IEEE 802.11 frames (data 
and management) has been a key contributor in many of the protocol's security 
problems."

  "due to a series of flaws in the composition of protocols that make up RSN".

Regarding solutions [1] states

  "there are currently no plans by the IEEE to add integrity protection to 
management frames"

  "Fortunatly, however, our attacks can easily be prevented through the 
addition of message authenticity to EAP"

To summarize IEEE 802.1X has some design flaws that will not be fixed. Any EAP 
method must have a protected alternate indication of success to be secure in 
IEEE 802.1X.

The attack seems pretty bad. Without a protected alternate indication of 
success an attacker can easily hijack the whole connection. I do not have a 
deep understanding of modern IEEE 802.1X, so I cannot say if anything has 
changed since 2002.

Looking at the other active documents in the EMU WG:

draft-ietf-emu-rfc5448bis
draft-ietf-emu-aka-pfs
draft-ietf-emu-eap-noob
and draft-ingles-eap-edhoc

None of them has a protected alternate indication of success and they would to 
my understanding be completely unsecure to use in IEEE 802.1X as it looked like 
in 2002.

Not having a protected alternate indication of success and pushing out keys 
before success is secure in general, otherwise TLS 1.3 itself would be 
insecure. I think all of these protocols would be secure when used in 3GPP 5G, 
but I think basically all EAP protocols want to function with IEEE 802.1X.

I think EMU need to verify that protected alternate indication of success is 
still needed in IEEE 802.1X. If it is I think draft-ietf-emu-rfc5448bis, 
draft-ietf-emu-aka-pfs, draft-ietf-emu-eap-noob, and draft-ingles-eap-edhoc 
need to be updated, or state that they cannot be used in IEEE 802.1X.

draft-ingles-eap-edhoc would be very easy to fix by just adding EDHOC message_4 
which is desgined for use cases like this. EDHOC exported already derived keys 
from the client's second flight as recently discussed might be good to add to 
TLS 1.3.

[1] http://www.cs.cornell.edu/people/egs/615/mishra-arbaugh.pdf

Cheers,
John


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] EAP-TLS and TLS alerts

2021-02-05 Thread John Mattsson
Hi,

I personally fine with writing MUST send an Error alert if the WG wants that. 
This would maybe help with using close_notify as an alternate success 
indication.

The most pressing question regarding alerts is if EAP-TLS can force the TLS 
implementation to not use close_notify in any situation except for success.

RFC 8446 allow an TLS implementation to send close_notify after receiving 
client finished. The server might send it because of an error in the client 
Finished or because it wants to close the connection for any reason.

EAP-TLS Peer  EAP-TLS Server

 EAP-Request/
 <  Identity
EAP-Response/
Identity (Privacy-Friendly)  >
 EAP-Request/
EAP-Type=EAP-TLS
 <(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS ClientHello) >
 EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
 TLS EncryptedExtensions,
  TLS CertificateRequest,
 TLS Certificate,
   TLS CertificateVerify,
 <  TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS Certificate,
TLS CertificateVerify,
TLS Finished)>

Server 
decides to close connection.

 EAP-Request/
EAP-Type=EAP-TLS
 < (TLS close_notify)
EAP-Response/
EAP-Type=EAP-TLS >
 <   EAP-Failure

I don't if this would be common or expected behavior from the server, but if 
EAP-TLS cannot enforce that this to not happen, then we cannot use close_notify 
as an alternate success indication, because an alternate success indication 
cannot be followed by EAP-Failure.

John



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Session tickets in TLS 1.3

2021-02-05 Thread John Mattsson
Hi,

I made several updates to the text based on your comments.

My earlier comments on the early ticket was wrong, it is not a bug. The ticket 
in OpenSSL is still valid but the server does cannot calculate the PSK before 
it has received the client Finished.

All message flows are correct. There is no single way how TLS 1.3 works. It is 
completely up to the implementation. The server can send 0 or 20 tickets. It 
can send them together with the server Finished, or in one or more separate 
flights.

I updated the draft to make it clear that all the message flows are examples. 
Some of the figure texts appeared like there was only one way the message flow 
could look like, which is basically never the case in TLS 1.3.

I removed the text in the draft on pre-computation of PSK. That is covered in 
RFC 8446. I added text stating that the NewSessionTicket can be sent with the 
server Finished or later so that does not come as a suprise.

I updated the resumption to send the NewSessionTicket together with Finished. 
The draft now gives examples of NewSessionTicket in the first server flight and 
NewSessionTicket in the second server flight.

Cheers,
John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] EAP-TLS and TLS alerts

2021-02-05 Thread John Mattsson
Hi,

I see now that the two paragraphs you send seems to be contradicting each other

https://tools.ietf.org/html/rfc8446#section-2

   A failure of the handshake or other protocol error triggers the
   termination of the connection, optionally preceded by an alert
   message (Section 6).

https://tools.ietf.org/html/rfc8446#section-6.2

   Whenever an implementation encounters a fatal error condition, it
   SHOULD send an appropriate fatal alert and MUST close the connection
   without sending or receiving any additional data.

Unclear if Error alert is optional or SHOULD.

Maybe you should ask the TLS WG.

John


-Original Message-
From: John Mattsson 
Date: Friday, 5 February 2021 at 20:36
To: EMU WG 
Subject: [Emu] EAP-TLS and TLS alerts

Hi,

Alerts are definitly not mandatory in TLS 1.3. Adding a note stating that 
alerts are not mandatory seems like a good idea. But "suggests" seems like the 
wrong word and optional != SHOULD.

I would like more feedback from other people before adding new requirements on 
TLS. Can an application typically enforce Error alerts in TLS?

John



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] EAP-TLS and TLS alerts

2021-02-05 Thread John Mattsson
Hi,

Alerts are definitly not mandatory in TLS 1.3. Adding a note stating that 
alerts are not mandatory seems like a good idea. But "suggests" seems like the 
wrong word and optional != SHOULD.

I would like more feedback from other people before adding new requirements on 
TLS. Can an application typically enforce Error alerts in TLS?

John


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Session tickets in TLS 1.3

2021-02-05 Thread John Mattsson
Not sure that OpenSSL current default behavior is interesting for the draft. 

None of the Tickets in the draft are invalid.

The tickets in Figure 2 are different messages. 

Sending a ticket with Finished after asking for client auth seems like a 
implementaion bug.

As far as I understand, a server can send as many tickets it want in the same 
flight.

That said, sending several ticket in the full authentication does not help 
latency anymore. I will delete the second ticket from the draft.

John


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Session tickets in TLS 1.3

2021-02-05 Thread John Mattsson
Some quick comments below:

Alan DeKok wrote:

>So it's possible for a malicious client to get the ticket, and close the 
>connection without >sending a client cert.  Then, if the EAP server doesn't 
>destroy the ticket, the client can >reconnect.

The resumption_master_secret includes the client finished so the client in your 
handshake with client authentication should not be able to reconnect, if it can 
it is an OpenSSL bug. Alternatively the server did not ask for client 
authentication and it is ok that the client reconnects.

>The packet flows in Figure 2 of draft-14 shows only one exchange of session 
>tickets, not 2.

Looks to me that the Figure 2 of draft-14 provisions two tickets...?

 EAP-Request/
EAP-Type=EAP-TLS
   (TLS NewSessionTicket,
TLS NewSessionTicket,
 <  TLS close_notify)

Cheers,
John


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Planned minor changes for EAP-TLS 1.3 -15

2021-02-05 Thread John Mattsson
Hi,

I re-read all the mails written on the EMU list the last month to see if any 
comments and suggestions had been forgotten. Based on that, the following 
smaller changes were added to the GitHub version and are planned for the next 
version:

- Added references to ietf-emu-tls-eap-types as suggested by Ben
- Made ietf-tls-oldversions-deprecate as suggested by Eric. 
ietf-tls-oldversions-deprecate normatively updated RFC 5216 so it makes sense 
to have it normative.
- Added a summary on packet modification attacks as suggested by Ben and maybe 
more persons.
- Added information on why resumption is important as described by Ben and Alan
- Added som editorial space in the key derivation and used "" to indicate an 
empty context.
- Significantly expanded EAP state machine section as suggested by Bernard.
  Since the discussion yesterday I have made the following changes:
  - Changed authenticated to protected to align with RFC 3748
  - Used RFC 4147 variables as examples in all of the paragraphs.
  - Differentiated derivation and making keys available to lower layers.
  - Complied with RFC 3748 by specifying which alternative failure indications 
are protected and which are not. 

Diff:

https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13-14.txt=https://raw.githubusercontent.com/emu-wg/draft-ietf-emu-eap-tls13/gh-pages/draft-ietf-emu-eap-tls13.txt

Comments welcome as always. 

The current plan is to submit a new version after the consensus calls which 
might lead to more major changes.

(Success and failure operators are already added in the GitHub version based on 
Bernards suggestions).

Cheers,
John


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Way Forward for EAP-TLS 1.3

2021-02-05 Thread John Mattsson
Hi Joe,

Good initiative.

1. To have an alternate success indication is new. The requirement needs to be 
the possibility to have an _protected_ success indication. This is requires in 
at least IEEE 802. It seems to be a weakness in the IEEE 802 spec, but EAP-TLS 
simply has to align with this. I don't think a 3.5. round-trip needs any 
security analysis, but I don't think it is worth specifying such a mode without 
resumption. A 3.5 mode not suitable for IEEE 802 with resumption would require 
significant TLS work. This might be worth doing in the future, but should not 
be done now.

I think 4.5 roundtrip with a mandatory protected success indication is the only 
thing we should specify now.


2. TLS Error alert are perfect matches for alternative failure alerts. Early 
Error alerts are unprotected. Later Error alerts are protected.

Martin and Ben both indicated that they think using application data is 
problematic. First because of reordering done by the TLS implementation and 
secondly as they they seem to disslike the use of applicaiton data to signal 
what the TLS implementation should do. close_notify in a separate flight 
mitigates any reordering issues and automatically implies that no more 
handshake messages are sent.

As long as the implementors can live with it I would suggest that we use 
close_notify as a success indication and move forward, but I don't have a 
strong opinion.

As Bernard suggested I think we should write that TLS Error messages are 
alternate failure indicators.


3. While I agree that TLS should have specified the exporter that way, it does 
not provide any significant value to EAP-TLS. I do not think EAP-TLS should use 
anything else that a standardized TLS exported, and waiting for a new 
standardized TLS exporter takes far too long time.

I think the separate labels for MSK and EMSK are good.
Have we aligned on using context or not? Using contect seemed like a simpler 
solution, but not all TLS implementations support context.
I do not think we should include anything form client finished at this point.

Cheers,
John

From: Emu  on behalf of Joseph Salowey 
Date: Thursday, 4 February 2021 at 17:24
To: EMU WG 
Subject: [Emu] Way Forward for EAP-TLS 1.3

Based on John's email [1] and a few other discussions I've had offline I'm 
proposing the following series of consensus calls to find a path forward:

1.  Consensus on requiring result indicators using a 4.5 roundtrip protocol.  I 
think this is a conservative approach that could move forward quicker then 
alternatives.  It may be possible to securely use an abbreviated protocol in 
some environments or with some additions to TLS, but the security analysis for 
this would take more time and may lead nowhere.  An abbreviated protocol could 
be covered in an update.

2. Consensus on what signal to use for result indicators, such as Close_Notify 
and fatal alerts.

3. Consensus on whether to enhance the key derivation to include certificates 
or other information from that includes the client and server identity.  This 
would help ensure that keys were not passed down to the lower layer prematurely.

I think we can run 1 and 3 in parallel.  We will also need to take resumption 
into account. Please respond to this thread, either privately or on the list, 
with your concerns.  I'd like to start these calls before next week.

Cheers,

Joe

[1] https://mailarchive.ietf.org/arch/msg/emu/hawPjEH2RRin4MlzqJe57Yrf0bQ/

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-04 Thread John Mattsson
Hi Bernard,

802.11 is a very important use case for EAP-TLS so if an authenticated 
alternate success indication is needed there, it absolutely needs to be 
supported by EAP-TLS 1.3

I updated the EAP state machine chapter based on your comments.

---
2.5.  EAP State Machines

   This is a new section when compared to [RFC5216] and only applies to
   TLS 1.3 (or higher).  [RFC4137] offers a proposed state machine for
   EAP

   TLS 1.3 [RFC8446] introduces Post-Handshake messages.  These Post-
   Handshake messages use the handshake content type and can be sent
   after the main handshake.  Examples of Post-Handshake messages are
   NewSessionTicket, which is used for resumption and KeyUpdate, which
   is not useful and not expected in EAP-TLS.  After sending TLS
   Finished, the EAP-TLS server may send any number of Post-Handshake
   messages in separate EAP-Requests.

   To provide an authenticated success result indication and to decrease
   the uncertainty for the EAP-TLS peer, the following procedure MUST be
   followed:

   When an EAP-TLS server has successfully processed the TLS client
   Finished and sent its last handshake message (Finished or a Post-
   Handshake), it commits to not sending any more handshake messages by
   sending a TLS close_notify alert.  The TLS close_notify alert is an
   authenticated success result indication, as defined in [RFC3748].
   After sending the TLS close_notify alert, the EAP-TLS server may only
   send an EAP-Success.  The EAP-TLS server MUST NOT send an TLS
   close_notify alert before it has successfully processed the client
   finished and sent its last handshake message.

   Receipt of any TLS Error alert SHOULD be considered a failure result
   indication, as defined in [RFC3748].  After sending or receiving a
   TLS Error alert, the EAP-TLS server may only send an EAP-Failure.

   The keying material becomes available in the EAP-TLS server after the
   server Finished has been sent.  The keying material becomes available
   in the EAP-TLS peer after the server Finished has been received.
---

I used RFC 3748 terminology as RFC 4237 is an informal draft.

close_notify is now an authenticated success result indication (close_notify 
could be replaced by TLS application data).

My undertstanding from RFC 4137 is that eapKeyAvailable and aaaEapKeyAvailable 
seems
to be automatically set at success if eapKeyData and aaaEapKeyData are set.

if (eapKeyData != NONE)
  eapKeyAvailable = TRUE

if (aaaEapKeyData != NONE)
  aaaEapKeyAvailable = TRUE

I therefore only described when the "keying material becomes available" which 
is the words used by RFC 4137 for eapKeyData and aaaEapKeyData.

Open question if Section 2.5 should say something about TLS 1.2.

Cheers,
John

From: John Mattsson 
Date: Thursday, 4 February 2021 at 15:22
To: Bernard Aboba , "emu@ietf.org" , 
"t...@ietf.org" 
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine


I think the major decision for the EMU WG to make going forward is to agree if 
EAP-TLS 1.3 MUST have an alternative success indication. RFC 5216 does not 
discuss the EAP state machine at all, but in TLS 1.2 the server finished can be 
used as an alternative success indication.

close_notify might be possible to turn into an alternative success indication 
if the TLS implementation can be profiled to not send any close_notify by 
itself. I don't know if there are any cases where an implementation would send 
close_notify without the application telling it to.

If the wg agrees that an authenticated alternative success indication is needed 
(this is to my understanding needed in e.g. 802.11) then the process would be 
that the EAP-TLS server first process the second flight from the client, if 
that verifies correctly, the server send application data commit message / 
close_notify.

Introducing an authenticated alternative success indication would not require 
any changes to the -14 message flows. In -13 the commitment message would have 
to be sent in a later flight than server finished.

If a mandatory authenticated alternative success indication is introduced in 
EAP-TLS 1.3, I do not think any future additions to TLS 1.3 would be needed for 
EAP-TLS 1.3.


From: John Mattsson 
Date: Thursday, 4 February 2021 at 13:18
To: Bernard Aboba , "emu@ietf.org" , 
"t...@ietf.org" 
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

Hi Bernard,

I (re-)read the papers you send.

- "Extensible Authentication Protocol Vulnerabilities and Improvements 
Improvements"

  This paper talks attacks on availability by spoofing messages. It looks into 
a small amount of ways where spoofed messages causes the TLS connection to 
fail, especially it focus on alert messages.

  TLS and EAP-TLS is trivial for an on-pat

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-02-04 Thread John Mattsson


From: Eric Rescorla 
Date: Thursday, 4 February 2021 at 15:32
To: John Mattsson 
Cc: EMU WG , Benjamin Kaduk , "t...@ietf.org" 

Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)



On Thu, Feb 4, 2021 at 6:29 AM Eric Rescorla 
mailto:e...@rtfm.com>> wrote:


On Thu, Feb 4, 2021 at 12:57 AM John Mattsson 
mailto:john.matts...@ericsson.com>> wrote:
Hi,

I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS interact 
better is a very promising idea. This would probably take some time to get 
specified and implemented so it is probably a future 
optimization/simplification rather that something EAP-TLS 1.3 should wait for.

An extension that "I do not send any post-handshake messages" would work and 
remove the need for a commitment message.


NoPostHandShake Extension


Clients MAY send this extension in ClientHello. It contains no data.

Servers MAY send this extension in EncryptedExtentions. It contains no data.

When the "NoPostHandShake" extension is negotiated, the server MUST NOT send 
any post handshake messages.

-

However, this would also stop the client from doing resumption which is also 
very important. EAP-TLS fragments TLS into a large number of round-trips, and 
database lookup to authorize clients is often slow, so resumption is essential 
to get good performance.

The current Post-Handshake NewSessionTicket is not well-suited for EAP-TLS as 
is introduces the demand for the commitment message as well as introducing an 
extra round-trip.

I don't really understand what EAP needs here, but it seems to me that the 
commitment message (or the close_notify) is serving two purposes:

1. Saying that the handshake completed successfully

Though note that this is an external semantic to TLS for close_notify. It's not 
specified with that reqt.

[John] Yes. It would also be on external semantic if an application data commit 
message is used.


2. Saying that there will be no more messages

I understand from the discussion that knowing that there will be no more 
messages is useful. Do you think that the client knowing that the handshake 
completed is unnecessary?

-Ekr

[John] Before this last explosion of discussion, the only publicly discussed 
purpose of the commitment message was to my knowledge 2. All versions of the 
EAP-TLS 1.3 drafts from -01 to -14 was written with only 2. in mind.

Recently people has also been brought up that also 1. is needed. My 
understanding is that this is not required by EAP in general, but it is 
required for secure interaction with 802.11.

After writing this mail suggesting extensions, I invested more time to read the 
mail Bernard recently sent and all the references in detail.

https://mailarchive.ietf.org/arch/msg/emu/hawPjEH2RRin4MlzqJe57Yrf0bQ/

After reading up on the 802.11 interaction, it seems to me that the possibility 
to do 1. is required in at least some deployments. I think the EMU WG need to 
discuss and agree on this. If 1. is always needed, any TLS extensions would not 
be needed.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-04 Thread John Mattsson

I think the major decision for the EMU WG to make going forward is to agree if 
EAP-TLS 1.3 MUST have an alternative success indication. RFC 5216 does not 
discuss the EAP state machine at all, but in TLS 1.2 the server finished can be 
used as an alternative success indication.

close_notify might be possible to turn into an alternative success indication 
if the TLS implementation can be profiled to not send any close_notify by 
itself. I don't know if there are any cases where an implementation would send 
close_notify without the application telling it to.

If the wg agrees that an authenticated alternative success indication is needed 
(this is to my understanding needed in e.g. 802.11) then the process would be 
that the EAP-TLS server first process the second flight from the client, if 
that verifies correctly, the server send application data commit message / 
close_notify.

Introducing an authenticated alternative success indication would not require 
any changes to the -14 message flows. In -13 the commitment message would have 
to be sent in a later flight than server finished.

If a mandatory authenticated alternative success indication is introduced in 
EAP-TLS 1.3, I do not think any future additions to TLS 1.3 would be needed for 
EAP-TLS 1.3.


From: John Mattsson 
Date: Thursday, 4 February 2021 at 13:18
To: Bernard Aboba , "emu@ietf.org" , 
"t...@ietf.org" 
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

Hi Bernard,

I (re-)read the papers you send.

- "Extensible Authentication Protocol Vulnerabilities and Improvements 
Improvements"

  This paper talks attacks on availability by spoofing messages. It looks into 
a small amount of ways where spoofed messages causes the TLS connection to 
fail, especially it focus on alert messages.

  TLS and EAP-TLS is trivial for an on-path attacker to shut down. Basically 
any small error is fatal in TLS. Focusing on alert messages does not seem 
correct. An attacker can e.g. at any time send a small record with length 2^15, 
which causes TLS to terminate the connection. I think the only thing that can 
be achieved without rewriting TLS is that availability attacks does not cause 
long-term damage, i.e. the nodes can retry the handshake.

- "An Initial Security Analysis of the IEEE 802.1X Standard"

  This paper discusses attacks on 801.11. The weaknesses described seems to 
come from 802.11 / EAP interactions.

The discussions around IETF 102 was that the uncertainty (NewSessionTicket or 
not) in TLS 1.3 was "inconvinient" and that it would be convient to get rid of 
the uncertainty. Bernard then pointed out that any message changing the state 
need to be authenticated to that it is not possible to spoof. I think that both 
the application layer commit message as well as close_notify fulfill these old 
requirements.


I think your analysis is correct.

1. What constitutes an "alternative success" indication in the EAP-TLS 1.3 
protocol?

The -13 commitment message verifies that both sides are in possession of a 
derived key. But the server finished already does that. As you state, the -13 
commitment message is not an alternative success indication. I think it would 
be easy to make it an alternative success indication be mandating that the 
EAP-TLS server must only send it after verifying the client finished. I do not 
think defining a new exporter is needed.

The -14 close_notify is also not an alternative success indication and can not 
be made into one either.

If the requirement is that an alternative authenticated success indication is 
needed. Then I think:

- We need to have an extra roundtrip.
- close_notify does not work and cannot be made to work
- Application data commit message could work as an alternative success 
indication. TLS would have to be profiled so the alternative success is only 
send be EAP-TLS server after client finished processed successfully.

2. At what point should keys be pushed down to the lower layer?

What is the exact requirement for eapKeyAvailable = TRUE to be set?

My understanding reading RFC 4137 (correct me if I am wrong) is that it is not 
enough that the other party is authenticated, but that an alternative success 
indication has been sent/received. If that is correct the EAP-TLS server would 
set eapKeyAvailable = TRUE after sendign the alternative success indication and 
the EAP-TLS client would set eapKeyAvailable = TRUE after receiving the 
alternative success indication.

3. What constitutes an "alternative failure" indication in EAP-TLS 1.3?

Yes, I agree, receipt of TLS Alert messages should be considered an alternative 
failure mechanism.

4. What is the purpose of the commitment message?

The -01 to -13 purpose was to indicate in an authenticated way that the EAP-TLS 
method would not continue and that only success or failure could follow.

If an alternative success indication is required. Which i

Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-04 Thread John Mattsson
Hi Bernard,

I (re-)read the papers you send.

- "Extensible Authentication Protocol Vulnerabilities and Improvements 
Improvements"

  This paper talks attacks on availability by spoofing messages. It looks into 
a small amount of ways where spoofed messages causes the TLS connection to 
fail, especially it focus on alert messages.

  TLS and EAP-TLS is trivial for an on-path attacker to shut down. Basically 
any small error is fatal in TLS. Focusing on alert messages does not seem 
correct. An attacker can e.g. at any time send a small record with length 2^15, 
which causes TLS to terminate the connection. I think the only thing that can 
be achieved without rewriting TLS is that availability attacks does not cause 
long-term damage, i.e. the nodes can retry the handshake.

- "An Initial Security Analysis of the IEEE 802.1X Standard"

  This paper discusses attacks on 801.11. The weaknesses described seems to 
come from 802.11 / EAP interactions.

The discussions around IETF 102 was that the uncertainty (NewSessionTicket or 
not) in TLS 1.3 was "inconvinient" and that it would be convient to get rid of 
the uncertainty. Bernard then pointed out that any message changing the state 
need to be authenticated to that it is not possible to spoof. I think that both 
the application layer commit message as well as close_notify fulfill these old 
requirements.


I think your analysis is correct.

1. What constitutes an "alternative success" indication in the EAP-TLS 1.3 
protocol?

The -13 commitment message verifies that both sides are in possession of a 
derived key. But the server finished already does that. As you state, the -13 
commitment message is not an alternative success indication. I think it would 
be easy to make it an alternative success indication be mandating that the 
EAP-TLS server must only send it after verifying the client finished. I do not 
think defining a new exporter is needed.

The -14 close_notify is also not an alternative success indication and can not 
be made into one either.

If the requirement is that an alternative authenticated success indication is 
needed. Then I think:

- We need to have an extra roundtrip.
- close_notify does not work and cannot be made to work
- Application data commit message could work as an alternative success 
indication. TLS would have to be profiled so the alternative success is only 
send be EAP-TLS server after client finished processed successfully.

2. At what point should keys be pushed down to the lower layer?

What is the exact requirement for eapKeyAvailable = TRUE to be set?

My understanding reading RFC 4137 (correct me if I am wrong) is that it is not 
enough that the other party is authenticated, but that an alternative success 
indication has been sent/received. If that is correct the EAP-TLS server would 
set eapKeyAvailable = TRUE after sendign the alternative success indication and 
the EAP-TLS client would set eapKeyAvailable = TRUE after receiving the 
alternative success indication.

3. What constitutes an "alternative failure" indication in EAP-TLS 1.3?

Yes, I agree, receipt of TLS Alert messages should be considered an alternative 
failure mechanism.

4. What is the purpose of the commitment message?

The -01 to -13 purpose was to indicate in an authenticated way that the EAP-TLS 
method would not continue and that only success or failure could follow.

If an alternative success indication is required. Which it seems to be 
according to your mail. I think the alternative success indication would 
replace the old commitment message.

I think

Cheers,
John

From: Emu  on behalf of Bernard Aboba 

Date: Tuesday, 2 February 2021 at 16:25
To: "emu@ietf.org" 
Subject: [Emu] Underspecification of EAP-TLS 1.3 State Machine

The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3 
interacts with the EAP state machine as specified in RFC 4137.  It appears to 
me that this under-specification is at the root of the questions about the 
commitment message.

Historically, under-specification of the EAP-TLS state machine has been a 
source of potential security vulnerabilities by enabling packet injection 
attacks [1][2], including attacks involving the injection of EAP-Success and 
EAP-Failure mechanisms.

RFC 4137 Sections 4.1.1 and 4.1.2 define several variables:


   altAccept (boolean)



  Alternate indication of success, as described in 
[RFC3748].



   altReject (boolean)



  Alternate indication of failure, as described in 
[RFC3748].



   eapKeyData (EAP key)



  Set in peer state machine when keying material becomes available.

  Set during the METHOD state.  Note that this document does not

  define the structure of the type "EAP key".  We expect that it

  will be defined in 
[Keying].



   eapKeyAvailable (boolean)



  Set to TRUE in the SUCCESS state if 

Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-02-04 Thread John Mattsson
Hi,

I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS interact 
better is a very promising idea. This would probably take some time to get 
specified and implemented so it is probably a future 
optimization/simplification rather that something EAP-TLS 1.3 should wait for.

An extension that "I do not send any post-handshake messages" would work and 
remove the need for a commitment message.


NoPostHandShake Extension


Clients MAY send this extension in ClientHello. It contains no data.

Servers MAY send this extension in EncryptedExtentions. It contains no data.

When the "NoPostHandShake" extension is negotiated, the server MUST NOT send 
any post handshake messages.

-

However, this would also stop the client from doing resumption which is also 
very important. EAP-TLS fragments TLS into a large number of round-trips, and 
database lookup to authorize clients is often slow, so resumption is essential 
to get good performance.

The current Post-Handshake NewSessionTicket is not well-suited for EAP-TLS as 
is introduces the demand for the commitment message as well as introducing an 
extra round-trip. The NewSessionTicket mechanism is both complex and 
inefficient for EAP-TLS. Could a new ticket extension be designed that fits 
EAP-TLS better? Looking quickly it seems like it would be possible. It looks 
like the current NewSessionTicket mechanism was designed with a requirements to 
only use symmetric crypto. This would not be important for EAP-TLS.

The below quickly written suggestion use the same PSK derivation as 
NewSessionTicket, but makes the ticket_nonce a sequence, and use asymmetric 
HPKE encryption for client privacy.


ImplicitTicket Extension


Clients MAY send this extension in ClientHello. It contains the following 
structure:

struct {
uint16 ticket_count_request;
} ImplicitTicketRequest;

With the ImplicitTicketRequest, the client requests ticket_count_request 
implicit tickets.

A server MAY send this extension in EncryptedExtentions. It contains the 
following structure:

struct {
uint16 ticket_count;
opaque hpke_pk<1..2^16-1>;
uint32 ticket_lifetime;
opaque ticket<1..2^16-1>;
   Extension extensions<0..2^16-2>;
} ImplicitTicketResponse;

When the "ImplicitTicket" extension is negotiated, it provisions ticket_count 
number of tickets. The tickets all have the same lifetime and extensions.

When doing resumption based on an implicit ticket, the identity is constructed 
as follows:

  identity = ENC(hpke_pk, ticket || ticket_seq || ticket_age_add )

  The uint16 ticket_seq is a that sequence that increases for each ticket the 
client uses. Valid values are 0..ticket_count-1.

  ticket_age_add in the identity replaces the ticket_age_add normally sent in 
the in the NewSessionTicket message.

  ticket_nonce is set to ticket_seq and the PSK associated with the ticket is 
computed as defined in RFC 8446.

-

Used together, two such extentions would effectively solve all the EAP - TLS 
1.3 related issues as they were known a month ago. There has since been 
discussion if EAP-TLS 1.3 needs keys derived from the client second flight, but 
I think more analysis before determining if that is the case or not.

Cheers,
John


From: TLS  on behalf of Eric Rescorla 
Date: Monday, 1 February 2021 at 15:56
To: Alan DeKok 
Cc: EMU WG , Benjamin Kaduk , "t...@ietf.org" 

Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)



On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
  This is a new message to summarize history, requirements, etc. for EAP-TLS 
and TLS 1.3.  The focus here is the requirements for EAP-TLS, and how the 0x00 
commitment message versus CloseNotify meets those.  I'll ignore the exporter 
changes here, as those are less controversial.

  The original proposal in the EAP-TLS draft was to send a zero-length 
application data message in order to signal that no more post-handshake 
messages were needed.  From the -05 version:

   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type = application_data and
   TLSPlaintext.length = 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

  However, the OpenSSL APIs (among others) do not allow for sending zero octets 
of application data.  The proposal was then changed to send a 0x00 octet.

 There was discussion that 

[Emu] Encourage people to make issues on GitHub for EAP-TLS 1.3

2021-02-03 Thread John Mattsson
Hi,

I would strongly encourage people to make concrete and well-defined issues on 
GitHub for any major issues that you think need to be addresses before -13, -14 
or -xx progress.

Mailing issues to the list is of course also accepted but tend to get dragged 
into long conversations and are not as visible. Issues on GitHub are much more 
visible.

Cheers,
John


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-03 Thread John Mattsson
 Alan DeKok wrote:

>Does that mean all open issues have been addressed and resolved?
>
>The current suggestion from Eric is to *not* use application data, but to use 
>>CloseNotify instead.  Does this mean the earlier discussion was wrong, or is 
>the >current suggestion wrong?  Are we allowed to dig into reasons *why* we're 
>doing >this?
>
>I'm a little taken aback at the appeal to authority, and the opinion that the 
>>"best way forward" is to just publish a document we don't understand.
>
>I'll also note that you're defending the *process*.  You're not defending the 
>>*content* of the draft.  So do you stand behind it?  i.e. do *you* have 
>reasons >why this behaviour is necessary?  The above summary from 2.5 years 
>ago discusses >*what* was decided.  The draft (and the summary) still makes no 
>mention of *why* >it's done, or why it's useful.
>
>The purpose of the draft is not to just publish "something".  The purpose of 
>the >draft is to publish a clear, secure, spec for EAP-TLS 1.3.  The current 
>discussion >does not give me confidence that we're making progress.


I seriously don't know where you got all of the above from. I only summarized 
the earlier discussion. I did not state any opinions.

I think the group needs to discuss if -13 or -14 can be a basis for publishing 
or if we need substantial changes. The version the working group wants to 
publish also needs to pass IESG, that is a fact. The suggestion that EAP-TLS 
1.3 should document detailed interaction with the informal EAP state machine is 
very new. This is something RFC 5216 leaves completely to the implementor, but 
as it is important to security I think it might be good idea to do.

Regarding the EAP/EAP-TLS/TLS 1.3 interaction I don't think there are any 
really good short term solution. The chosen mechanism will likely have 
significant drawbacks and tradeoffs. My personal opinion is that the 
application data commitment message seems to be a bit less problematic then 
close_notify. None of them are an "alternative success", if that is what is 
needed, I don't think any of them work.

The current objective status (without defending or offending anybody) is that 
if the WG cannot agree on adding clarifications and smaller updated to -14, 
EAP-TLS 1.3 will likely be significantly delayed. The comments on -14 in the WG 
so far is that it should not progress and that decisions need to wait until 
IETF 110 hackaton and EMU meeting. Delaying may be the right option, but the WG 
should be aware of this. A couple of weeks ago, I understood you position as 
moving forward with either version was the most important goal. 

Cheers,
John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-03 Thread John Mattsson
Hi,

Maybe not so important to figure out who suggested what, but I think the whole 
discussion took place at IETF 102. 

https://datatracker.ietf.org/meeting/102/materials/slides-102-emu-eap-tls-with-tls-13-00.pdf

https://datatracker.ietf.org/meeting/102/materials/minutes-102-emu-00

https://www.youtube.com/watch?v=Ez2Y4wK94Sk

At the same meeting it was also ruled out to use the Reserved bits in EAP-TLS 
header and to make EAP-Success carry payload. Latency and security was 
discussed a lot with Bernard keeping the security high and Jouni expressing on 
the mailing list before the meeting that he wanted to cut even more roundtrips 
from the message flow.

According to the minutes it seems like Jim suggested the use of application 
data and Eric suggested the interpretation to make this mean no more handshake 
messages. This was added to the draft and everybody was happy with that for 2.5 
years. While individual persons cannot represent the TLS WG, there was a large 
amount of senior TLS people present and active in the discussion.

-

John: Jouni implemented this draft and found the NewSessionTicket was 
inconvenient 

Darshak:  Point is well taken. We should not restrict NewSessionTicket. The 
server could signal with EAP that it will send other things.


Bernard: You are not changing EAP. EAP-Success can be spoofed. Understand 
exactly which state it is, not an EAP task but method specific. Reception of 
properly encrypted message should take precedence over EAP-Success. At every 
point, important to know if you are in continuing, success or failed state. It 
has nothing to do with EAP.

Jim Schaad: Have the server send an encrypted content message. Will add 
latency. 

Bernard: That's how EAP-TLS does currently with Finish message.

Darshak: Does sending this encrypted content message indicate that no more TLS 
messages will be sent. 

Jim: TLS content message (a record) to know when you are done and make 
transition. That takes the place of the TLS Finish message.

Hannes: Differenced to other EAP messages. Before there were clear definitions. 
What is finished actually? NewSessionTicket is still a handshake. Cram it in 
earlier in the exchange.

Darshak: Isn't the TLS server allowed to send NewSessionTicket later. Are you 
restricting it in EAP?

Eric: You want to know that there will be no more TLS messages? Profile TLS to 
say don't do this. None of the Post-Handshake messages are needed. 

John: Need more discussion on the mailing list. Could we use FLAG in EAP-TLS.
Bernard: If you use this and it determines cryptographic state, then you have 
just introduced a vulnerability. Don't do that. 

John: Piggyback Newsessionticket on the EAP-SUCCESS 
Bernard: Not a good idea.

-

Do close_notify even fulfill the requirements here. It cannot be spoofed, but 
it is a very strange alternative success message. It can also be sent by the 
server earlier to indicate failure for any reason

Cheers,
John

-Original Message-
From: John Mattsson 
Date: Wednesday, 3 February 2021 at 00:48
To: "emu@ietf.org" 
Subject: Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

Alan wrote:

> wrote:
>> 4. was something I thought was clear. The -13 version states that “The 
>> EAP->TLS server commits to not send any more handshake messages”. This was 
>> >according to my memory exactly what was requested from the implementors.
>
>  The text is in draft-mattsson-eap-tls13-02, but not in 
> draft-ietf-emu-eap->tls13-00.  The announcement message is here:
>
>https://mailarchive.ietf.org/arch/msg/emu/8Axkmgh_ZPCTwhvmRjVMvXGTKko/
>
>  Which doesn't mention the commitment message.  I can't find any other 
> >discussion about the commitment message on the archive.  That doesn't 
> >necessarily mean much, as the archive is difficult to search.
>
>  So it's not clear where that came from.

I Agree. The initial problem was brought up by Jouni who identified both the 
problem with the extra round-trip as well as the uncertainty in the EAP state 
machine.

https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/

The idea with the commitment message was suggested by Jim Schaad during IETF 
102 and then added in -01. The meaning of the commitment message was likely 
also discussed during that EMU session. I do not remember the exact 
discussions. It was likely not an implementor that suggested this definition. I 
mixed it up with Jouni raising the problem.

> In the last weeks discussion, the commitment message has been given a lot of 
> >different interpretations that are not coming from the draft. The meaning of 
> >and requirements for the -13 commitment message now seems quite unclear.
>
> An in-progress draft is not an authoritative source of information.  The WG 
> >is discussing what the commitment message means, with an eye to making 

Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-14.txt

2021-02-03 Thread John Mattsson
Hi,

There was several recent comments on close_notify and the ability to send alert 
messages. My understanding is that the message flow in -14 allows the important 
alert messages to be sent. The server can always send an alert explaining why 
client authentication failed. This should be a hard requirement. The only alert 
that cannot be sent in the -14 message flows is an alert from the client 
describing that the NewSessionTicket is wrong. That requires splitting 
NewSessionTicket and close_notify in different EAP requests, this is something 
that -14 does not forbid but does not describe either. 

My understanding is that TLS 1.3 MUST ignore all data after close_notify is 
sent. But this section is RFC8446 is contradicting itself and will be fixed in 
RFC8446bis. 

The cost for allowing alert messages with close_notify might be an extra 
round-trip. It seems unclear how many implementations that allow/will allow 
application data to be send directly after the server's first flight.

My earlier comments on the list close_notify did not work with alert concerned 
the message flows that had been added to the GitHub version of the draft which 
I think did not work. At that point there was also no stated motivation for 
change expect "EKR said close_notify could be used"

John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] EAP-TLS protected result indications

2021-02-03 Thread John Mattsson
Hi,

Thanks, that is good information. Note that RFC 4137 is informative examples of 
how EAP can be implemented and not even mentioned in RFC 5216. Given this 
discussion it feels like RFC 5216 also needs to follow RFC 4137 or do something 
similar to be secure. RFC 5216 do not say anything about the EAP state machine.

On a high level I think the group need to decide if the EAP-TLS 1.3 
specification should:

a) Have normative state machine text for TLS 1.3 only
b) Have normative state machine text for both TLS 1.2 and 1.3
c) Have informative state machine guidance for TLS 1.3 only
d) Have informative state machine guidance for  both TLS 1.2 and 1.3
e) Leave state machine to the implementaion just like RFC 5216.

The current assumption has been e). Given that this is important for security 
a), b), c), and d) would have been better. TLS 1.3 likely increases the need to 
specify this. Adding this would however undoubtely delay the specification.

Cheers,
John

From: Emu  on behalf of Bernard Aboba 

Date: Wednesday, 3 February 2021 at 02:14
To: "j...@salowey.net" 
Cc: EMU WG 
Subject: Re: [Emu] EAP-TLS protected result indications

The discussion largely happened in 802.11 since that was where the 
vulnerability vulnerability was discovered (by Bill Arbaugh at UMD). 
Documentation of the required signals was in RFC 4137, tests on the fixed 
implementations were done by UMD and subsequent analysis and security proofs 
were done by the Mitchell group at Stanford.

On Tue, Feb 2, 2021 at 15:53 Joseph Salowey 
mailto:j...@salowey.net>> wrote:

[Joe] Aha, It's coming back to me now and it does seem that implementations do 
this.  Do you know if the implementation requirements were documented anywhere?


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-02 Thread John Mattsson
Alan wrote:

> wrote:
>> 4. was something I thought was clear. The -13 version states that “The 
>> EAP->TLS server commits to not send any more handshake messages”. This was 
>> >according to my memory exactly what was requested from the implementors.
>
>  The text is in draft-mattsson-eap-tls13-02, but not in 
> draft-ietf-emu-eap->tls13-00.  The announcement message is here:
>
>https://mailarchive.ietf.org/arch/msg/emu/8Axkmgh_ZPCTwhvmRjVMvXGTKko/
>
>  Which doesn't mention the commitment message.  I can't find any other 
> >discussion about the commitment message on the archive.  That doesn't 
> >necessarily mean much, as the archive is difficult to search.
>
>  So it's not clear where that came from.

I Agree. The initial problem was brought up by Jouni who identified both the 
problem with the extra round-trip as well as the uncertainty in the EAP state 
machine.
 
https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/

The idea with the commitment message was suggested by Jim Schaad during IETF 
102 and then added in -01. The meaning of the commitment message was likely 
also discussed during that EMU session. I do not remember the exact 
discussions. It was likely not an implementor that suggested this definition. I 
mixed it up with Jouni raising the problem.

> In the last weeks discussion, the commitment message has been given a lot of 
> >different interpretations that are not coming from the draft. The meaning of 
> >and requirements for the -13 commitment message now seems quite unclear.
>
> An in-progress draft is not an authoritative source of information.  The WG 
> >is discussing what the commitment message means, with an eye to making 
> >recommendations for the draft, and implementors.

Of course not, but the exact same definition has been in the draft since -01 
without anybody question it before now. This made me think it was clear and 
widely accepted. That does not make it right and I have never said it is wrong 
to question that definition. I think we can agree that the meaning of the 
commitment message now seems unclear.

/John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Underspecification of EAP-TLS 1.3 State Machine

2021-02-02 Thread John Mattsson
Hi,

Bernard Aboba wrote:

> The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3 
> interacts with the EAP state machine as specified in RFC 4137
> The issue in the EAP-TLS 1.3 specification is that the interlock with these 
> variables is not defined

It is definitely true that the EAP TLS 1.3 specification does not at all define 
how EAP-TLS 1.3 interlock with these variables, neither does RFC 5216. Might be 
that this is needed for TLS 1.3 but was not needed for earlier versions of TLS. 
I think this has not been discussed at all before. I will make new issue on 
GitHub.


> 1. What constitutes an "alternative success" indication in the EAP-TLS 1.3 
> protocol?

> 2. At what point should keys be pushed down to the lower layer?

> 3. What constitutes an "alternative failure" indication in EAP-TLS 1.3?



These are things that to my knowledge are not in RFC 5216. If they are they 
would apply to EAP-TLS 1.3 as well. It would be good if you could further 
explain if these are things that:



-   Where missing from RFC 5216 and should be added now for all versions of TLS

-   Are in RFC 5216 but are not applicable to TLS 1.3 due to massive changes in 
the protocol and therefor need to be rewritten in the draft.

-   Where not needed in RFC 5216 for earlier versions of TLS but are needed for 
TLS 1.3 due to the changes in the protocol.



> 4. What is the purpose of the commitment message?


4. was something I thought was clear. The -13 version states that “The EAP-TLS 
server commits to not send any more handshake messages”. This was according to 
my memory exactly what was requested from the implementors. In the last weeks 
discussion, the commitment message has been given a lot of different 
interpretations that are not coming from the draft. The meaning of and 
requirements for the -13 commitment message now seems quite unclear.

Cheers,
John

From: Emu  on behalf of Bernard Aboba 

Date: Tuesday, 2 February 2021 at 16:25
To: "emu@ietf.org" 
Subject: [Emu] Underspecification of EAP-TLS 1.3 State Machine

The EAP TLS 1.3 specification does not currently specify how EAP TLS 1.3 
interacts with the EAP state machine as specified in RFC 4137.  It appears to 
me that this under-specification is at the root of the questions about the 
commitment message.

Historically, under-specification of the EAP-TLS state machine has been a 
source of potential security vulnerabilities by enabling packet injection 
attacks [1][2], including attacks involving the injection of EAP-Success and 
EAP-Failure mechanisms.

RFC 4137 Sections 4.1.1 and 4.1.2 define several variables:


   altAccept (boolean)



  Alternate indication of success, as described in 
[RFC3748].



   altReject (boolean)



  Alternate indication of failure, as described in 
[RFC3748].



   eapKeyData (EAP key)



  Set in peer state machine when keying material becomes available.

  Set during the METHOD state.  Note that this document does not

  define the structure of the type "EAP key".  We expect that it

  will be defined in 
[Keying].



   eapKeyAvailable (boolean)



  Set to TRUE in the SUCCESS state if keying material is available.

  The actual key is stored in eapKeyData.



The issue in the EAP-TLS 1.3 specification is that the interlock with these 
variables is not defined.



For example, it appears to me that the commitment message verifies that both 
sides are in possession of a derived key,

allowing the eapKeyData variables to be set.  However, it does not appear to me 
that the successful validation of the commitment message is

sufficient to allow keys to be pushed down to the lower layer, allowing data to 
flow.

Therefore the eapKeyAvailable variable should not yet be set to TRUE.



Also, the commitment message does not constitute an alternative success 
indication because it is possible for an

alternative failure indication (e.g. a TLS alert) to be sent after the 
commitment message.

If the commitment message did constitute an alternative success mechanism, then 
an attacker injecting an

EAP-Success message would be able to cause the peer to believe that 
authentication

had succeeded even though it had actually failed (e.g. TLS alert sent after the 
commitment message).



Given these issues, I believe the specification needs to answer several 
questions:



1. What constitutes an "alternative success" indication in the EAP-TLS 1.3 
protocol?

2. At what point should keys be pushed down to the lower layer?

3. What constitutes an "alternative failure" indication in EAP-TLS 1.3?

4. What is the purpose of the commitment message?



Only question 3 looks straight forward to me: receipt of TLS Alert messages 
should be considered an alternative failure mechanism,

although perhaps some caveats need to be applied to address the injection 
attacks 

Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-14.txt

2021-02-02 Thread John Mattsson
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 clear that this >separation can be 
>enforced by the application.

John: It is impossible to not separate them when client authentication is used. 
The only time it is possible to send them together is when there is no client 
authentication. The message flows are just examples of how a TLS 1.3 message 
flow might look like. In Figure 8: EAP-TLS without peer authentication, the TLS 
implementation may send NewSessionTicket together with server Finished, as 
explained in RFC 8446. Future extension might also change things. I don't think 
the draft can or should explain all the corner cases of TLS 1.3.

I made an issue on this on GitHub.

Cheers,
John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] New Version Notification for draft-ietf-emu-eap-tls13-14.txt

2021-02-02 Thread John Mattsson
Hi,

Our understanding is that draft-ietf-emu-eap-tls13-13 currently has no 
possibility to progress to the RFC editor’s que. To secure a place in the RFC 
editors’ que we have submitted version -14 that addresses all the comments in 
the IESG Discuss. -14 uses close_notify instead of a application data 
commitment message and slightly changes the exporter calls. We hope this 
version will clear the remaining Discuss. The only way forward at the moment is 
to publish and implement -14.

Implementors have expressed a preference for draft-13, but an even stronger 
preference to finalize and publish the draft. I hope the discussions will 
continue during the coming weeks and at the EMU WG meeting at IETF 110 meeting, 
but -14 looks like the only thing that can reach agreement to be published at 
this point.

John & Mohit

-Original Message-
From: "internet-dra...@ietf.org" 
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 repository.

Name:   draft-ietf-emu-eap-tls13
Revision:   14
Title:  Using EAP-TLS with TLS 1.3
Document date:  2021-02-02
Group:  emu
Pages:  32
URL:https://www.ietf.org/archive/id/draft-ietf-emu-eap-tls13-14.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13
Htmlized:   https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-14
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-14

Abstract:
   The Extensible Authentication Protocol (EAP), defined in RFC 3748,
   provides a standard mechanism for support of multiple authentication
   methods.  This document specifies the use of EAP-Transport Layer
   Security (EAP-TLS) with TLS 1.3 while remaining backwards compatible
   with existing implementations of EAP-TLS.  TLS 1.3 provides
   significantly improved security, privacy, and reduced latency when
   compared to earlier versions of TLS.  EAP-TLS with TLS 1.3 further
   improves security and privacy by always providing forward secrecy,
   never disclosing the peer identity, and by mandating use of
   revocation checking.  This document also provides guidance on
   authorization and resumption for EAP-TLS in general (regardless of
   the underlying TLS version used).  This document updates RFC 5216.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

2021-01-29 Thread John Mattsson
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.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/tree/master

Text format:

https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

The diff can be found here:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

This would be ready for submission but I think the Implementors, WGs, Chairs, 
Shepard, ADs need to agree on the direction before we do that. The two 
important technical changes from -13 are

(1) Changing key derivation
(2) Changing Commitment message to close_notify

The key derivation changes are good and more modern. I personally like the 
change but the change but I don't think it is essential and was not done for 
security reasons.

The close_notity changes are not only positive as it sometimes introduce an 
additional roundtrip. The Commitment message can according to specification be 
sent with the server Finish even if some/most/all implementation does not seem 
to allow this. If the commitment message cannot be send with Finished in 
practice there is no difference in latency. Still a bit sad how poorly TLS 1.3 
and EAP interacts. I am not sure I fully agree with the layer violation 
argument, my interpretation was that this was information for the EAP state 
machine which is the application using TLS. Maybe the text regarding the 
commitment message was badly written and should have talked about the EAP state 
machine more instead of TLS

We need to get agreement on how to proceed here asap. I would like implementors 
and security AD to agree on the way forward before submitting -14. Four ways 
forward:

A. Add (1) and (2)
B. Only add (1)
C. Only add (2)
D. Do not add (1) or (2)

I assume implementors (Alan, Jorge) are fine with all other changes since -13.

Do we need to have a telephone meeting to discuss these things? We cannot have 
a formal interim meeting as that formally takes weeks to setup. This can also 
not wait until the next IETF. As soon as we agree on a way forward we can 
update and submit a new version within 24 h.

Cheers,
John

-Original Message-
From: TLS  on behalf of Jorge Vergara 

Date: Friday, 29 January 2021 at 00:57
To: Alan DeKok , Martin Thomson 
Cc: "t...@ietf.org" , EMU WG 
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

I am in favor of sticking to draft-13. There was some discussion about whether 
draft-13 contained a TLS layering violation, but I believe that discussion 
concluded that it does not. As noted, discussion has mostly stalled since then 
with a few additional ideas surfacing that have added round trips. Other 
threads are now popping up expressing dissatisfaction with the extra round trip.

Alan mentions that betas may be months out for his product line - for Microsoft 
and Windows, the situation is much tighter. If we cannot reach consensus 
quickly we will need to push this out of our 2021 release cycle. Seeing as 
we're sitting on draft-13 with multiple implementations available, I would 
really prefer to reach consensus to finalize draft-13 and get this into the 
hands of customers this calendar year.

Jorge Vergara

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Saturday, January 23, 2021 2:28 PM
To: Martin Thomson 
Cc:  ; EMU WG 
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

  We're approaching 2 weeks since the last discussion of this topic.  This 
document has been in development for 3 years.  We desperately need to finish 
it.  IMHO waiting another 6 months is not an option.  Even 3 would be worrying.

  We have multiple inter-operable implementations which have implemented 
draft-13.  That work over the last few months have resulted in implementors 
making plans to do beta testing in the next few weeks.  Those plans have been 
put on indefinite hold, due to the recent request for changes.

  I understand getting feedback from the TLS WG is useful.  But I would prefer 
to have consensus on a *solution*. Right now, we just have a series of proposed 
changes, with little to no discussion.

  We're getting to the point where we have to ship code as promised to 
customers soon (weeks, not months).  We therefore need consensus, as soon as 
possible.

  My preference is to implement draft-13.  We know the code works.  People are 
ready to ship it.  Any changes will add not just more months of standard 
discussion, but more months of interoperability testing.

  If there is no progress in EMU, we're looking at September for first 

Re: [Emu] NewSessionTicket, Resumption, close_notify, and number of round-trips

2021-01-28 Thread John Mattsson
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 worse than EAP-TLS 1.2 when it comes 
to latency. They have the same number of roundtrips for full handshake, but 
EAP-TLS 1.3 has one more for resumption. In practice, with a typical 1500 MTU, 
EAP-TLS 1.3 is probably faster as long as certificate compression (RFC8879, 
draft-mattsson-cose-cbor-cert-compress-06) are used.

The suggestion from Jim to use application data was adopted as it did not 
introduce extra round-trips and allowed alerts. Is the principle of not using 
application data really worth introducing a mandatory extra round-trip? And is 
a mandatory extra dummy roundtrip really the best solution we can come up with?

  EAP-Request/
 EAP-Type=EAP-TLS
  < (TLS close_notify)
EAP-Response/
EAP-Type=EAP-TLS >

It looks kind of stupid 

After Jim suggested to use application data, the commitment issue was not 
discussed much more. Would e.g. using the reserved bits in the EAP-TLS packet 
be possible or would that cause problems? I think an extra round-trip is a sad 
conclusion to the EAP-TLS 1.3 work.

John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] NewSessionTicket, Resumption, close_notify, and number of round-trips

2021-01-27 Thread John Mattsson
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 handshake could as far as I understand always be 
done in 3.5 round-trips. This would cut a large amount of complexity from the 
draft and implementations and make the protocol much faster.

Trading a few asymmetric operations for an additional round-trip does not make 
sense to me. Optimizing away a few asymmetric operation is not important. 
Optimizing the number of round-trips is very important.

My conclusion from the discussion regarding the Commitment message is not that 
is should be replaced by the close_notify, but that EAP-TLS should probably 
remove Commitment message, NewSessionTicket, and resumption...

EAP-TLS 1.3 could then be done in 3.5 round-trips as shown below:


EAP-TLS Peer  EAP-TLS Server

  EAP-Request/
  <  Identity
 EAP-Response/
 Identity (Privacy-Friendly)  >
  EAP-Request/
 EAP-Type=EAP-TLS
  <(TLS Start)
 EAP-Response/
 EAP-Type=EAP-TLS
(TLS ClientHello) >
  EAP-Request/
 EAP-Type=EAP-TLS
 (TLS ServerHello,
  TLS EncryptedExtensions,
   TLS CertificateRequest,
  TLS Certificate,
TLS CertificateVerify,
  <  TLS Finished)
 EAP-Response/
 EAP-Type=EAP-TLS
(TLS Certificate,
 TLS CertificateVerify,
 TLS Finished)>
  <   EAP-Success

/John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] EAP-TLS 1.3 and KeyUpdate

2021-01-26 Thread John Mattsson
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 message or even forbid its 
use?

Cheers,
John


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] I-D Action: draft-ietf-emu-eaptlscert-07.txt

2020-11-20 Thread John Mattsson
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:
> 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 replaced by something else.
> https://tools.ietf.org/html/draft-thomson-tls-sic-00
Since this is a non-blocking informational reference, I prefer having it 
in the document (among the list of many other techniques to avoid large 
messages).
>
>
> "CBOR Certificate Algorithm for TLS Certificate Compression" has been 
> replaced by "CBOR Encoding of X.509 Certificates (CBOR Certificates)". This 
> draft does now register a new TLS certificate type instead of a certificate 
> compression. It will be brought up (list or presentation) in the TLS working 
> group when COSE has approved its new charter and adopted the draft.
> https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00
> https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/

I have updated the reference and slightly altered the corresponding text 
in version (-08): 
https://www.ietf.org/archive/id/draft-ietf-emu-eaptlscert-08.txt.

I believe we are now ready to ship this to the RFC editor.

--Mohit

>
> Cheers,
> John
>
>
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] I-D Action: draft-ietf-emu-eaptlscert-07.txt

2020-11-19 Thread John Mattsson
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 replaced by something else.
https://tools.ietf.org/html/draft-thomson-tls-sic-00


"CBOR Certificate Algorithm for TLS Certificate Compression" has been replaced 
by "CBOR Encoding of X.509 Certificates (CBOR Certificates)". This draft does 
now register a new TLS certificate type instead of a certificate compression. 
It will be brought up (list or presentation) in the TLS working group when COSE 
has approved its new charter and adopted the draft. 
https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00
https://datatracker.ietf.org/doc/draft-mattsson-cose-cbor-cert-compress/

Cheers,
John



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-26 Thread John Mattsson
Hi Eliot,

The EAP server is expected to frequently request a OCSP response from the OCSP 
responder (a server typically run by the certificate issuer). The OCSP response 
is then added to the Servers Certificate message as long as it is valid. Before 
the OCSP response is close to expiring, the EAP server requests a new OCSP 
response from the OCSP responder.

I assume you mean the client is offline? If use cases where none of the 
entities can contact the OCSP responder is in scope, OCSP stapling does not 
work.

OCSP Nonce does not work with OCSP stapling. If you want you revocation data 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 John,

My question is one of pragmatics.  In an offline industrial environment, what 
is expected of the server to accomplish the stapling?  Especially if the 
request is nonced.

Eliot

> On 26 Oct 2020, at 13:08, John Mattsson 
>  wrote:
> 
> Hi,
> 
> When this was discussed in the group, it 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 
> mandate stapling in the draft instead of waiting for support of the X.509 
> must-staple extension. OCSP and OCSP stapling are quite well supported 
> already and should be even more well-supported in a few years:
> 
> 1. Basically all TLS implementations support OSCP, and a majority support 
> OSCP stapling (Certificate Status Request). Mbed is an exception rather than 
> the rule.
> 
> https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations
> 
> 2. All browsers (desktop and mobile) support OCSP stapling.
> 
> https://blog.apnic.net/2019/01/15/is-the-web-ready-for-ocsp-must-staple/#:~:text=OCSP%20Must%2DStaple%20is%20a,Certificate%20Status%20Protocol%20(OCSP).
> 
> 3. NIST SP 800-52 Rev 2 mandates that the server shall support use of the 
> Certificate Status Request extension (i.e. OCSP stapling).
> 
> 
> - I do not think there is any wiggle room at all in the current version of 
> the draft:
> 
>  "When EAP-TLS is used with TLS 1.3, the peer and server MUST use Certificate 
> Status Requests [RFC6066]
>for the server's certificate chain"
> 
>  Note that in the current draft it is unspecified how the server checks the 
> revocation status of the client's certificate:
> 
>  "When EAP-TLS is used with TLS 1.3, the server MUST check the revocation 
> status of the certificates in the
>client's certificate chain."
> 
> 
> - The X.509 must-staple extension 
> (https://tools.ietf.org/html/draft-hallambaker-muststaple-00) is not relevant 
> for server certificates in the current EAP-TLS 1.3 draft as stapling is 
> already a must. OSCP stapling is not very useful for client certs. I do not 
> know if the X.509 must-staple extension is well supported or not. It could 
> become relevant for server certs if the requirements are softened.
> 
> 
> - My view is that OSCP stapling is a very good fit for EAP in particular and 
> is well-supported enough to be mandated. Mandating stapling for EAP-TLS 1.3 
> from the start avoids having to rely on the X.509 must-staple extension. Any 
> implementation not supporting OCSP stapling should implement it together with 
> TLS 1.3. I do not think the requirent should be softened, but if it is, my 
> view is that is should be softened as little as possible.
> 
> Cheers,
> John
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-26 Thread John Mattsson
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 mandate 
stapling in the draft instead of waiting for support of the X.509 must-staple 
extension. OCSP and OCSP stapling are quite well supported already and should 
be even more well-supported in a few years:

1. Basically all TLS implementations support OSCP, and a majority support OSCP 
stapling (Certificate Status Request). Mbed is an exception rather than the 
rule.

https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations

2. All browsers (desktop and mobile) support OCSP stapling.

https://blog.apnic.net/2019/01/15/is-the-web-ready-for-ocsp-must-staple/#:~:text=OCSP%20Must%2DStaple%20is%20a,Certificate%20Status%20Protocol%20(OCSP).

3. NIST SP 800-52 Rev 2 mandates that the server shall support use of the 
Certificate Status Request extension (i.e. OCSP stapling).


- I do not think there is any wiggle room at all in the current version of the 
draft:

  "When EAP-TLS is used with TLS 1.3, the peer and server MUST use Certificate 
Status Requests [RFC6066]
for the server's certificate chain"

  Note that in the current draft it is unspecified how the server checks the 
revocation status of the client's certificate:
  
  "When EAP-TLS is used with TLS 1.3, the server MUST check the revocation 
status of the certificates in the
client's certificate chain."


- The X.509 must-staple extension 
(https://tools.ietf.org/html/draft-hallambaker-muststaple-00) is not relevant 
for server certificates in the current EAP-TLS 1.3 draft as stapling is already 
a must. OSCP stapling is not very useful for client certs. I do not know if the 
X.509 must-staple extension is well supported or not. It could become relevant 
for server certs if the requirements are softened.


- My view is that OSCP stapling is a very good fit for EAP in particular and is 
well-supported enough to be mandated. Mandating stapling for EAP-TLS 1.3 from 
the start avoids having to rely on the X.509 must-staple extension. Any 
implementation not supporting OCSP stapling should implement it together with 
TLS 1.3. I do not think the requirent should be softened, but if it is, my view 
is that is should be softened as little as possible.

Cheers,
John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Commitment Message handling in EAP-TLS 1.3

2020-09-22 Thread John Mattsson
If we are going back to an encrypted application message with 0x00, how do we 
update the draft to make it clear that the commitment message is encrypted? 
Several people understood that 0x00 was supposed to not be encrypted. Is 
something incorrect in draft-ietf-emu-eap-tls13-10, or it there just 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 Mattsson , Mohit Sethi M 
, Benjamin Kaduk , EMU WG 

Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

On Sep 17, 2020, at 12:44 PM, Jorge Vergara  wrote:
> 
> Does anyone else have any other thoughts on this? I'm not a TLS expert but 
> similarly value the TLS Fatal Alerts over using close_notify. If we will be 
> losing alerts then I would favor switching back to 0x00.

  In the absence of further discussion, I would suggest staying with 0x00.

  I'll go poke some code. :)

  Alan DeKok.


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

2020-09-02 Thread John Mattsson


>>> This raises the question what TEAP TLS 1.2 implementations do today? Are 
>>> they only using outdated and non-secure cipher suites or are they doing 
>>> something unspecified to derive Compound-MAC with an AEAD cipher suite?

>>  It's not clear.  I'd have to double-check hostap, which is the only 
>> publicly available TEAP implementation I know of.

> I can tell you what Windows is doing for TLS 1.2; and Windows interops with 
> all the TEAP implementations that I know of, so others are likely doing the 
> same. We're using the MAC function in the case of a CBC block cipher suite, 
> or PRF hash function in the case of an AEAD cipher suite. Yes, it's 
> unspecified, but I believe most TLS libraries abstracts the difference away, 
> so it went unnoticed. I imagine it may have gone unnoticed by other 
> implementations as well.

Should we document this behavior for TLS 1.2 in the draft? I.e. the PRF hash 
function in HMAC mode for AEAD cipher suites and the MAC function for non-AEAD 
cipher suites.

>>  Realistically, PEAP is a vendor-defined protocol.  It is not under the 
>> change control of the IETF.  If the vendor agrees to this change, then it's 
>> possible.  Otherwise we're stuck with what we have.

> We agree to changes in this area to the extent that WG feels they are 
> necessary. I don't have the cryptanalysis background to weight heavily in on 
> what the right thing to do is, but have no objection to moving away from SHA1.

> Rather than locking in another dependency such as SHA256, I wonder if this 
> calculation should also use a hash function derived from the TLS handshake?

That is a much better idea! It is not necessary 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: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

On Sep 1, 2020, at 12:05 PM, John Mattsson 
 wrote:
> 
> 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 
> use an AEAD. There is however a cipher suite hash algorithms that is used in 
> HMAC mode. Maybe something like
> 
>   "Compound-MAC = HMAC( CMK, BUFFER )
> 
>   Where HMAC uses the Hash algorithm for the handshake."
> 
>   or
> 
>   "Compound-MAC = HMAC( CMK, BUFFER )
> 
>   Where the Hash function used by HKDF is the cipher suite hash algorithm"

  OK.

> This raises the question what TEAP TLS 1.2 implementations do today? Are they 
> only using outdated and non-secure cipher suites or are they doing something 
> unspecified to derive Compound-MAC with an AEAD cipher suite?

  It's not clear.  I'd have to double-check hostap, which is the only publicly 
available TEAP implementation I know of.

> Anyway, how to calculate Compound-MAC with an AEAD algorithm needs to be 
> specified for TLS 1.2 as well. I think the scope of the document need to be 
> expanded slightly.

  Or punt on TEAP entirely, and leave it to a TEAP-bis document.

> - "For PEAP, some derivation use HMAC-SHA1 [PEAP-MPPE].  There are no
>   known security issues with HMAC-SHA1.  In the interests of
>   interoperability and minimal changes, we do not change that
>   definition here."
> 
> While it is true that there are no known practical attacks against HMAC-SHA1, 
> most modern protocols like TLS 1.3 forbid all uses of SHA-1, governments are 
> recommending phasing out use of HMAC-SHA1 in e.g. IKEv2, and many buyers of 
> security equipment thinks that everything with SHA-1 is very weak. To me it 
> feels strange to force future implementations to continue support of SHA-1 
> when it is completely removed from TLS 1.3. Enforcing SHA-256 when TLS 1.3 is 
> used seems like the easy way forward. It is probably much harder to do at a 
> later stage. 

  Realistically, PEAP is a vendor-defined protocol.  It is not under the change 
control of the IETF.  If the vendor agrees to this change, then it's possible.  
Otherwise we're stuck with what we have.

> Editorials:
> 
> - "in Section Those"
> - formatting of the list in section 5

  I'll fix that, thanks.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://protect2.fireeye.com/v1/url?k=1e1c2e57-40bcec12-1e1c6ecc-8692dc8284cb-890ef1f2fc081407=1=b42cb8cd-b2ad-4018-b532-f8328271bffc=https%3A%2F%2Fnam06.safelinks.protection.outl

Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

2020-09-01 Thread John Mattsson
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 use 
an AEAD. There is however a cipher suite hash algorithms that is used in HMAC 
mode. Maybe something like

   "Compound-MAC = HMAC( CMK, BUFFER )

   Where HMAC uses the Hash algorithm for the handshake."
   
   or

   "Compound-MAC = HMAC( CMK, BUFFER )

   Where the Hash function used by HKDF is the cipher suite hash algorithm"

This raises the question what TEAP TLS 1.2 implementations do today? Are they 
only using outdated and non-secure cipher suites or are they doing something 
unspecified to derive Compound-MAC with an AEAD cipher suite?

Anyway, how to calculate Compound-MAC with an AEAD algorithm needs to be 
specified for TLS 1.2 as well. I think the scope of the document need to be 
expanded slightly.


- "For PEAP, some derivation use HMAC-SHA1 [PEAP-MPPE].  There are no
   known security issues with HMAC-SHA1.  In the interests of
   interoperability and minimal changes, we do not change that
   definition here."

While it is true that there are no known practical attacks against HMAC-SHA1, 
most modern protocols like TLS 1.3 forbid all uses of SHA-1, governments are 
recommending phasing out use of HMAC-SHA1 in e.g. IKEv2, and many buyers of 
security equipment thinks that everything with SHA-1 is very weak. To me it 
feels strange to force future implementations to continue support of SHA-1 when 
it is completely removed from TLS 1.3. Enforcing SHA-256 when TLS 1.3 is used 
seems like the easy way forward. It is probably much harder to do at a later 
stage. 

Editorials:

- "in Section Those"
- formatting of the list in section 5

Cheers,
John

-Original Message-
From: Emu  on behalf of "internet-dra...@ietf.org" 

Reply to: "emu@ietf.org" 
Date: Wednesday, 29 July 2020 at 23:04
To: "i-d-annou...@ietf.org" 
Cc: "emu@ietf.org" 
Subject: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt


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  : Alan DeKok
Filename: draft-ietf-emu-tls-eap-types-01.txt
Pages   : 12
Date: 2020-07-29

Abstract:
   EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS].  Many
   other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as
   FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many
   vendor specific EAP methods.  This document updates those methods in
   order to use the new key derivation methods available in TLS 1.3.
   Additional changes necessitated by TLS 1.3 are also discussed.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01
https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-tls-eap-types-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Commitment Message handling in EAP-TLS 1.3

2020-09-01 Thread John Mattsson
Hi,

If the ability to send a descriptive TLS Fatal Alert back to the peer is a 
requirement, changing to close_notify seems like a bad idea. My understanding 
is that is would add an extra roundtrip without any clear benefits compared to 
sending an encrypted 0x00 application data.

EAP Peer  EAP Server

 EAP-Request/
 <  Identity
EAP-Response/
Identity (Privacy-Friendly)  >
 EAP-Request/
EAP-Type=EAP-TLS
 <(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS ClientHello) >
 EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
 TLS EncryptedExtensions,
  TLS CertificateRequest,
 TLS Certificate,
   TLS CertificateVerify,
TLS Finished,
 <Commitment Message)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS Certificate,
TLS CertificateVerify,
TLS Finished)>
 <   EAP-Success

  Figure 1: EAP-TLS mutual authentication

vs.

EAP Peer  EAP Server

 EAP-Request/
 <  Identity
EAP-Response/
Identity (Privacy-Friendly)  >
 EAP-Request/
EAP-Type=EAP-TLS
 <(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS ClientHello) >
 EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
 TLS EncryptedExtensions,
  TLS CertificateRequest,
 TLS Certificate,
   TLS CertificateVerify,
TLS Finished)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS Certificate,
TLS CertificateVerify,
TLS Finished)>
 EAP-Request/
EAP-Type=EAP-TLS
 <  TLS close_notify)
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 
, Jorge Vergara 
, Mohit Sethi M , Benjamin 
Kaduk , EMU WG 
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

On Sep 1, 2020, at 8:24 AM, John Mattsson  
wrote:
> Reading up on the mail discussion more (I have been on parental leave), I 
don't see any real motivation for this late technical change suggestion...

  My $0.02 is that it's philosophical.  EAP-TLS does authentication using 
TLS.  Adding an extra zero byte seems weird.  It's a hack to get around 
limitations of protocol and/or implementations.

> If we change the specification to use close_notify:
> 
> - we need to also update Figure 6 
> 
> - do we still want to have the flexibilty that "The close_notify alert 
may be sent in the same EAP-Request as the last handshake record or in a 
separate EAP-Request."? The flexibility was added to be compatible with OpenSSL 
that where not compatible with RFC8446. But keeping the flexibility with 
close_notify allows the server to chose between an extra round-trip and the 
ability to send a TLS Fatal Alert as a result of unsuccessful client 
authentication.

  In my experience, the TLS Fatal Alert is incredibly useful.  It would be 
very, very, bad to remove that from the spec.  Doing so would mean that failed 
authentications get an error of "failed", instead of something descriptive.  
And IMHO t

Re: [Emu] Commitment Message handling in EAP-TLS 1.3

2020-09-01 Thread John Mattsson
Hi,

Reading up on the mail discussion more (I have been on parental leave), I don't 
see any real motivation for this late technical change suggestion...

Hannes wrote that the draft-ietf-emu-eap-tls13 does not work with Mbed because 
it introduces a new message and requires unencrypted data. One of Hannes 
suggestions for change was that:

"Use the Commitment Message as an application layer payload (encrypted as it 
should be)."

This suggestion is exactly my understanding of how draft-ietf-emu-eap-tls13-10 
works. At least it is exactly what I intended when I wrote the sections in 
question. 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.

To summarize, I don't see that there is a real motivation for late technical 
change. That Hannes misunderstood the draft seems like a reason to add some 
clarification text. 

If we change the specification to use close_notify:

- we need to also update Figure 6 

- do we still want to have the flexibilty that "The close_notify alert may be 
sent in the same EAP-Request as the last handshake record or in a separate 
EAP-Request."? The flexibility was added to be compatible with OpenSSL that 
where not compatible with RFC8446. But keeping the flexibility with 
close_notify allows the server to chose between an extra round-trip and the 
ability to send a TLS Fatal Alert as a result of unsuccessful client 
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

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  EAP Server

 EAP-Request/
 <  Identity
EAP-Response/
Identity (Privacy-Friendly)  >

 EAP-Request/
EAP-Type=EAP-TLS
 <(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS ClientHello) >
 EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
 TLS EncryptedExtensions,
  TLS CertificateRequest,
 TLS Certificate,
   TLS CertificateVerify,
TLS Finished,
 <Commitment Message)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS Certificate,
TLS CertificateVerify,
TLS Finished)>
 EAP-Request/
EAP-Type=EAP-TLS
 <  (TLS Fatal Alert)
EAP-Response/
EAP-Type=EAP-TLS >
 <   EAP-Failure

   Figure 6: EAP-TLS unsuccessful client authentication

If the Commitment Message is changed to close_notify, the TLS Fatal Alert 
would have to be changed to an EAP-Failure instead. The difference is that The 
TLS Fatal Alert can contain information such as 

   bad_certificate,  unsupported_certificate,  certificate_revoked,  
certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca, 
access_denied, etc. while EAP-Failure must not contain any additional data.

I don't have any strong preferences but if we change to close_notify, then 
Figure 6 needs to be updated.

Cheers,
John

-Original Message-
From: Emu  on behalf of Mohit Sethi M 

Date: Wednesday, 5 August 2020 at 11:31
To: Alan DeKok , Jorge Vergara 

Cc: Mohit Sethi M , Benjamin Kaduk 
, EMU WG 
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

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 sp

Re: [Emu] Commitment Message handling in EAP-TLS 1.3

2020-09-01 Thread John Mattsson
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  EAP Server

 EAP-Request/
 <  Identity
EAP-Response/
Identity (Privacy-Friendly)  >

 EAP-Request/
EAP-Type=EAP-TLS
 <(TLS Start)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS ClientHello) >
 EAP-Request/
EAP-Type=EAP-TLS
(TLS ServerHello,
 TLS EncryptedExtensions,
  TLS CertificateRequest,
 TLS Certificate,
   TLS CertificateVerify,
TLS Finished,
 
 EAP-Request/
EAP-Type=EAP-TLS
 <  (TLS Fatal Alert)
EAP-Response/
EAP-Type=EAP-TLS >
 <   EAP-Failure

   Figure 6: EAP-TLS unsuccessful client authentication

If the Commitment Message is changed to close_notify, the TLS Fatal Alert would 
have to be changed to an EAP-Failure instead. The difference is that The TLS 
Fatal Alert can contain information such as 

   bad_certificate,  unsupported_certificate,  certificate_revoked,  
certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca, 
access_denied, etc. while EAP-Failure must not contain any additional data.

I don't have any strong preferences but if we change to close_notify, then 
Figure 6 needs to be updated.

Cheers,
John

-Original Message-
From: Emu  on behalf of Mohit Sethi M 

Date: Wednesday, 5 August 2020 at 11:31
To: Alan DeKok , Jorge Vergara 

Cc: Mohit Sethi M , Benjamin Kaduk , 
EMU WG 
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

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://protect2.fireeye.com/v1/url?k=6a599c40-34f9328d-6a59dcdb-866132fe445e-b8526f21b1021465=1=bf6ddc28-bb64-4bb0-bea7-defe210b15fd=https%3A%2F%2Fgithub.com%2Femu-wg%2Fdraft-ietf-emu-eap-tls13

Here is the diff for your convenience:


https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

This edit probably still requires some sanity checking. I will wait 
until we have confirmation from the different implementations before 
cleaning up and publishing a new version.

--Mohit

On 8/4/20 8:15 PM, Alan DeKok wrote:
> On Aug 3, 2020, at 2:23 PM, Jorge Vergara  wrote:
>> ACK that EAP-TLS does not need to keep the connection open.
>I agree.  I'm happy to change the implementations to send "close 
notify".
>
>> Question: should some consideration be given to consistency with other 
EAP methods that do need to keep the connection open? i.e. PEAP/EAP-TTLS/TEAP
>When those methods send application data, they don't need to do 
anything else.
>
>When those methods use fast reconnect, they don't send application 
data.  So the other EAP methods should also send "close notify" in that case.
>
>Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Status of draft-dekok-emu-tls-eap-types?

2020-03-11 Thread John Mattsson
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 in its -00 version and it has not 
been updated in 13 months...

https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00

/John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

2020-03-11 Thread John Mattsson
Alan DeKok wrote:

>That being said, I'm OK with having one EAP type code for EAP-TLS (certs), and 
>another for EAP-TLS (everything else)

>I would avoid having multiple EAP types.  That would bloat implementations.  
>It's better to just let implementors / admins configure TLS parameters for one 
>EAP type, instead of multiple  EAP types.

What does "avoid having multiple EAP types" refer to?

Does this mean you would like to avoid "EAP-TLS (certs), and another for 
EAP-TLS (everything else)", even If you can accept it

Or are you saying that 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

    On Mar 11, 2020, at 4:01 AM, John Mattsson 
 wrote:
> 
> If I remember correctly, Bernard stated that the indroduction of PSK 
could weaken the implementation and violate the security proofs of EAP-TLS. I 
don't really agree with Bernard, but I am fine with resticting the type code 
0x0D to certificates only. I am not sure any proofs with TLS 1.1 would apply to 
TLS 1.3 anyway as TLS 1.3 is basically a new protocol, reusing encoding and 
IANA registers from the old version. 

  For what it's worth, RFC 5216 doesn't make any statement about PSK.  So 
on a first reading, there are currently no restrictions on using PSK with 
EAP-TLS, and TLS <= 1.2.

  There are multiple client / server implementations which support PSK for 
EAP-TLS.

  That being said, I'm OK with having one EAP type code for EAP-TLS 
(certs), and another for EAP-TLS (everything else)

  I would avoid having multiple EAP types.  That would bloat 
implementations.  It's better to just let implementors / admins configure TLS 
parameters for one EAP type, instead of multiple  EAP types.

  Alan DeKok.



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

2020-03-11 Thread John Mattsson
Hi,

Russ Housley wrote:
 >> I do not understand the reason for Bernard's objection.  I looked at the 
 >> minutes, and I do not find any rationale there.  Can you help?

If I remember correctly, Bernard stated that the indroduction of PSK could 
weaken the implementation and violate the security proofs of EAP-TLS. I don't 
really agree with Bernard, but I am fine with resticting the type code 0x0D to 
certificates only. I am not sure any proofs with TLS 1.1 would apply to TLS 1.3 
anyway as TLS 1.3 is basically a new protocol, reusing encoding and IANA 
registers from the old version. 

Given that the EAP-TLS Type-Code 0x0D is decicated to Certificates, I am not 
sure the approach to dedicate a new type code for PSK authentication is the 
correct choice.

psk_ke
psk_dhe_ke
tls_cert_with_extern_psk+psk_dhe_ke

are just three of many authentication methods that may not fit in type code 
0x0D. Earlier versions of TLS have supported many more authentication methods 

KRB5
anon
SRP
ECCPWD

And just looking at the TLS WG documents, there are several future 
authentication methods for TLS 1.3 likely in the future.

https://datatracker.ietf.org/doc/draft-wang-tls-raw-public-key-with-ibc/
https://datatracker.ietf.org/doc/draft-tschofenig-tls-cwt/
https://datatracker.ietf.org/doc/draft-vanrein-tls-kdh/

I do not think the EAP group should forbid any TLS 1.3 authentication method 
unless there is valid reasons to do so. Instead of the current suggestion:

0x0D EAP-TLS (cert and nothing else)
0xTBDEAP-TLS-PSK (psk and psk+something else)

I think a better way to structure things would be:

0x0D EAP-TLS (cert and nothing else)
0xTBDEAP-TLS-FULL (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 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 WGLC Comment on draft-ietf-emu-eap-tls13

Thanks for the pointer.

I am fine with the proposed way forward.

Russ


> On Mar 10, 2020, at 12:43 PM, Mohit Sethi M  
wrote:
> 
> 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 external PSK any ways requires 
> ironing out some issues like what is the relationship between NAI and 
> the PSK identity? And do we allow user-configured PSK identities/PSKs 
etc.?
> 
> Would it be reasonable if we specify the usage of 
> draft-ietf-tls-tls13-cert-with-extern-psk in EAP-TLS-PSK instead?
> 
> --Mohit
> 
> On 3/10/20 6:30 PM, Russ Housley wrote:
>> I do not understand the reason for Bernard's objection.  I looked at the 
minutes, and I do not find any rationale there.  Can you help?
    >> 
>> Russ
>> 
>> 
>>> On Mar 9, 2020, at 5:59 AM, John Mattsson  
wrote:
>>> 
>>> Hi Russ,
>>> 
>>> Sorry for the late reply. I actually brought up your draft 
[ID-ietf-tls-tls13-cert-with-extern-psk] during my EMU presentation at IETF 106 
as something that should probably be in EAP-TLS. Bernard Aboba then expressed a 
very strong opinion that [ID-ietf-tls-tls13-cert-with-extern-psk] should 
absolutely not be included in the EAP-TLS Type-Code 0x0D. After this the WG 
decided as a way forward to specify EAP-TLS with PSK authentication in a new 
draft.
>>> 
>>> Given these strong opinions from Bernard Aboba, and the wish to publish 
draft-ietf-emu-eap-tls13 soon. I think the best way 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 
>>> Cc: EMU WG 
>>> Subject: Late WGLC Comment on draft-ietf-emu-eap-tls13
>>> 
>>>John:
>>> 
>>>Section 2.1.1 says:
>>> 
>>>   Pre-Shared Key (PSK) authentication SHALL NOT be used except
>>>   for resumption.
>>> 
>>>I would rather this say:
>>> 
>>>   Pre-Shared Key (PSK) au

Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-09.txt

2020-03-10 Thread John Mattsson
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 identities are prefered over other 
(routing)
  - More guidance on how to contruct a NAI to use use in EAP-TLS

- I did not include draft-ietf-tls-tls13-cert-with-extern-psk as there at this 
point is no consencus to do so with Russ suggesting to include it and Bernard 
previous being stongly against such inclusion.

Cheers,
John

-Original Message-
From: Emu  on behalf of "internet-dra...@ietf.org" 

Reply to: "emu@ietf.org" 
Date: Monday, 9 March 2020 at 18:55
To: "i-d-annou...@ietf.org" 
Cc: "emu@ietf.org" 
Subject: [Emu] I-D Action: draft-ietf-emu-eap-tls13-09.txt


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   : Using EAP-TLS with TLS 1.3
Authors : John Preuß Mattsson
  Mohit Sethi
Filename: draft-ietf-emu-eap-tls13-09.txt
Pages   : 29
Date: 2020-03-09

Abstract:
   This document specifies the use of EAP-TLS with TLS 1.3 while
   remaining backwards compatible with existing implementations of EAP-
   TLS.  TLS 1.3 provides significantly improved security, privacy, and
   reduced latency when compared to earlier versions of TLS.  EAP-TLS
   with TLS 1.3 further improves security and privacy by mandating use
   of privacy and revocation checking.  This document updates RFC 5216.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-09
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-08.txt

2020-03-09 Thread 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 the 
identity sections in the resumption and privacy sections and added a new 
paragraph on identity in Section 2.1. This aligns well with RFC 5216.
- The text on encrypted usernames (like 3GPP SUCI) where updated to illustrate 
that they are intended to be NAIs, not opaque blobs.
- I added an explanation on how to derive a anonymous NAI from a NAI in the 
certificate subject name. I did not want to talk about common name as the 
certificate may contain a subjectAltName which is not common name (I think).

The new suggested paragraphs on identities are shown below. The resumption and 
privacy section only talks about details specific for resumption and privacy.

Cheers,
John

--

2.1.  Overview of the EAP-TLS Conversation

   ...

   It is RECOMMENDED to use a NAIs in the Identity Response [RFC7542] as
   such identities are routable.  While opaque blobs are allowed by
   [RFC3748] such identities are NOT RECOMMENDED as they are not
   routable and should only be considered in local deployments where the
   EAP Peer, EAP authenticator, and EAP Server all belong to the same
   network.  An anonymous NAIs MAY be derived from the subject name in
   the TLS client certificate by removing the username from a NAI.  The
   subject name in client certificates typically contains an identity
   with a routable domain such as an email address.

2.1.6.  Resumption

   ...

   It is RECOMMENDED to use a NAIs with the same realm in the resumption
   and the original full authentication.  This requirement allows EAP
   packets to be routable to the same destination as the original full
   authentication.  The TLS PSK identity is typically derived be the TLS
   implementation and may be an opaque blob without a routable realm.
   The TLS PSK identity is therefore in general unsuitable for deriving
   a NAI to use in the Identity Response.

2.1.7.  Privacy

   ...

   EAP-TLS peer and server implementations supporting TLS 1.3 or higher
   MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4
   in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its
   username in cleartext in the Identity Response.  Following [RFC7542],
   it is RECOMMENDED to omit the username (i.e. the NAI is @realm), but
   other constructions such as a fixed username (e.g. anonymous@realm)
   or an encrypted username (e.g.  YmVuZGVy@realm) are allowed.  Note
   that the NAI MUST be a UTF-8 string as defined by the grammar in
   Section 2.2 of [RFC7542].

--
 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

2020-03-09 Thread John Mattsson
Hi Russ,

Sorry for the late reply. I actually brought up your draft 
[ID-ietf-tls-tls13-cert-with-extern-psk] during my EMU presentation at IETF 106 
as something that should probably be in EAP-TLS. Bernard Aboba then expressed a 
very strong opinion that [ID-ietf-tls-tls13-cert-with-extern-psk] should 
absolutely not be included in the EAP-TLS Type-Code 0x0D. After this the WG 
decided as a way forward to specify EAP-TLS with PSK authentication in a new 
draft.

Given these strong opinions from Bernard Aboba, and the wish to publish 
draft-ietf-emu-eap-tls13 soon. I think the best way 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 
Cc: EMU WG 
Subject: Late WGLC Comment on draft-ietf-emu-eap-tls13

John:

Section 2.1.1 says:

   Pre-Shared Key (PSK) authentication SHALL NOT be used except
   for resumption.

I would rather this say:

   Pre-Shared Key (PSK) authentication SHALL NOT be used except
   for resumption or in conjunction with the "tls_cert_with_extern_psk"
   extension [ID-ietf-tls-tls13-cert-with-extern-psk].

Russ



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] 3GPP mandates Rel-16 EAP-TLS implementations to support TLS 1.3

2020-03-09 Thread John Mattsson
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, forbids support of TLS 1.1, MD5, 
SHA-1, non-AEAD, non-PFS, and  mandates minimum key lengths of 2048 for 
RSA/FFDH and 255 for ECC.

Cheers,
John

[1] http://www.3gpp.org/ftp/TSG_SA/WG3_Security/TSGS3_98e/Docs/S3-200318.zip

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-10 Thread John Mattsson
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 working that was patched 12 
months ago. 
https://github.com/openssl/openssl/issues/7433


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-10 Thread John Mattsson
Mohit Sethi M mohit.m.se...@ericsson.com wrote:

I think these are mostly TLS questions that would not be specific for 
EAP-TLS-PSK

> For example: the current TLS 1.3 spec requires external PSKs to be 
> provisioned for a specific hash function.

Yes, but if there is no specific hash function, SHA-256 is used as a default.

>Then there is also the discussion on how does a server handle external PSK vs. 
>PSK for resumption? They will clearly be >in different parts of the stack: 
>external PSKs with the EAP server and resumptions PSKs with the TLS server 
>library.
>Also, should a server issue resumption PSKs when the original authentication 
>is based on an external PSK. The only >benefit would be that it would make 
>tracking of peers/clients much harder.

Yes, but I do not see how EAP would differ from any other TLS deployment with 
external PSK.

>There is ongoing work in the TLS working group but the question is how long 
>should we wait: 
>https://tools.ietf.org/html/>draft-ietf-tls-external-psk-importer-01

I see no reason to wait for that draft. What 
draft-ietf-tls-external-psk-importer does is to allow a single external PSK to 
be used to negotiate both TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. 
Most IoT would not want to negotiate AES-256 and SHA-384, and those who want 
(like e.g. US government devices using the CSNA suite) would probably not want 
to negotiate AES-128 and SHA-256. draft-ietf-tls-external-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 Comments draft-ietf-emu-eap-tls13


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. PSK for 
resumption? They will clearly be in different parts of the stack: external PSKs 
with the EAP server and resumptions PSKs with the TLS server library. Also, 
should a server issue resumption PSKs when the original authentication is based 
on an external PSK. The only benefit would be that it would make tracking of 
peers/clients much harder.

There is ongoing work in the TLS working group but the question is how long 
should we wait: 
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01

--Mohit
On 10/10/19 10:51 AM, Eliot Lear wrote:
I do think this is where we can make TEAP’s sweet spot.  But we should avoid 
differences in TLS implementations between TEAP and EAP-TLS.  That just 
complicates libraries.  And it’s for that same reason that I’m just a bit 
nervous about us constraining TLS 1.3.  Put another way: before we do so we 
have to answer this question: what is so different about EAP than other TLS 
applications?  If the answer is “nothing” for a particular case, then either we 
have it wrong or TLS 1.3 has it wrong, and we should sort that.

Eliot


On 10 Oct 2019, at 09:44, John Mattsson 
mailto:john.matts...@ericsson.com>> wrote:

Hi Eliot,

I agree that the question boils down to IoT. There are currently a lot of IoT 
systems using PSK, and many of them will likely want to stay on PSK, rather 
than migrating to RPK. Using a protocol with PFS is nowadays recommended 
practice. EAP-PSK does not provide PFS, and EAP-PWD is 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 mailto:l...@cisco.com>>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey mailto:j...@salowey.net>>
Cc: John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
 "draft-ietf-emu-eap-tl...@ietf.org<mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 
mailto:john.matts...@ericsson.com>>, 
mailto:mo...@piuha.net>>
Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,



On 7 Oct 2019, at 02:42, Joseph Salowey 
mailto:j...@salowey.net>> wrote:

There is a TLS working group draft on importing external PSKs for use with TLS 
- https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01.  This 
draft can mitigate some of the issues with using external PSKs.

My suggesting is to leave the draft as is and deal with external PSKs as an 
update to EAP-TLS 1.3 or as a separate method.


Before we nail this down, it seems like we need to have a discussion about how 
best to onboard wired IoT 

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-10 Thread John Mattsson
Mohit Sethi M mohit.m.se...@ericsson.com wrote:

> @Elliot: I understand your discomfort with constraining TLS 1.3. But there is 
> clearl precedent. The original EAP-TLS specification in RFC 5216 
> (https://tools.ietf.org/html/rfc5216) has no mention of PSKs.

That was quite different. When EAP-TLS (RFC 2716) was first published, there 
was no PSK mode in TLS at all. When RFC 5216 was published, TLS-PSK was a quite 
recent and not so well-supported extension. Also TLS 1.2 (RFC 5246) has no 
mention of PSKs. TLS 1.3 embraces PSK because the demand from IoT and makes it 
part of 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 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 constraining TLS 1.3. But there is 
clearl precedent. The original EAP-TLS specification in RFC 5216 
(https://tools.ietf.org/html/rfc5216) has no mention of PSKs.

--Mohit
On 10/10/19 10:44 AM, John Mattsson wrote:
Hi Eliot,

I agree that the question boils down to IoT. There are currently a lot of IoT 
systems using PSK, and many of them will likely want to stay on PSK, rather 
than migrating to RPK. Using a protocol with PFS is nowadays recommended 
practice. EAP-PSK does not provide PFS, and EAP-PWD is 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 <mailto:l...@cisco.com>
Date: Thursday, 10 October 2019 at 09:14
To: Joseph Salowey <mailto:j...@salowey.net>
Cc: John Mattsson 
<mailto:john.mattsson=40ericsson@dmarc.ietf.org>,
 "draft-ietf-emu-eap-tl...@ietf.org"<mailto:draft-ietf-emu-eap-tl...@ietf.org> 
<mailto:draft-ietf-emu-eap-tl...@ietf.org>, 
EMU WG <mailto:emu@ietf.org>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <mailto:alias-boun...@ietf.org>
Resent to: John Mattsson 
<mailto:john.matts...@ericsson.com>, 
<mailto:mo...@piuha.net>
Resent date: Thu, 10 Oct 2019 00:14:49 -0700 (PDT)

Hi Joe,



On 7 Oct 2019, at 02:42, Joseph Salowey 
mailto:j...@salowey.net>> wrote:

There is a TLS working group draft on importing external PSKs for use with TLS 
- https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01.  This 
draft can mitigate some of the issues with using external PSKs.

My suggesting is to leave the draft as is and deal with external PSKs as an 
update to EAP-TLS 1.3 or as a separate method.


Before we nail this down, it seems like we need to have a discussion about how 
best to onboard wired IoT devices in particular from an on-prem view.  The 
issue here is that EAP-TLS-PSK is useful for that purpose, as we discussed.  
Now there is nothing particularly special about PSK and we could run with a 
naked public key pair as well in 1.3, but we have to choose something.  The 
fundamental question is what does a manufacturer stamp into the device and what 
is placed on a label.  We have a running example of DPP doing this for wireless 
with public key code, but that doesn’t get us to proper onboarding for wired – 
the signaling just isn’t there.

Also, maybe it’s me, but I remain uncomfortable about this group constraining 
TLS 1.3.

Eliot




Is the current published version up to date with the rest of the comments?

Thanks,

Joe

On Fri, Sep 20, 2019 at 3:42 AM John Mattsson 
mailto:40ericsson@dmarc.ietf.org>>
 wrote:
Hi Alan,

I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that 
they are good to point out.

I am not sure about the other suggestions, I am hesitant to discuss anything 
detailed about TLS 1.3 that does not have a specific connection to EAP-TLS or 
are useful for users of EAP-TLS. My feeling is that adding some extension, but 
not other would be even more confusing. The diagrams are there to show the 
message flows, which have a strong connection to the EAP state machine. For 
other details I think implementors have to read RFC 8466.

/John

-Original Message-
From: Alan DeKok mailto:al...@deployingradius.com>>
Date: Wednesday, 18 September 2019 at 15:21
To: 
"draft-ietf-emu-eap-tl...@ietf.org<mailto:draft-ietf-emu-eap-tl...@ietf.org>" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: mailto:alias-boun...@ietf.org>>
Resent to: John Mattsson 
mailto:john.matts...@ericsson.com>>, 
mailto:mo...@piuha.n

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-10-07 Thread John Mattsson
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 forward in the publication process.

Cheers,
John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-07.txt

2019-09-21 Thread John Mattsson
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 instead of TLS Application Data 
- Some additional clarifications and rewordings in sections 2 and 5.7
- References to Sections 4.2.11, 8.1, 8.2, and C.4 of RFC 8446
- Reference to draft-ietf-emu-eaptlscert

The only remaining discussion is about the TLS PSK mode. I made an issue for 
this on Github:
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/10

Right now there seems to be disagreement about technical things like the 
security properties of the different EAP methods. Right now I think we need a 
better understanding regarding the security offered by the different method and 
what the use cases we would like to solve (PSK and/or password) (tunnelled 
and/or non-tunnelled).

Cheers,
John

-Original Message-
From: Emu  on behalf of "internet-dra...@ietf.org" 

Reply to: "emu@ietf.org" 
Date: Saturday, 21 September 2019 at 10:39
To: "i-d-annou...@ietf.org" 
Cc: "emu@ietf.org" 
Subject: [Emu] I-D Action: draft-ietf-emu-eap-tls13-07.txt


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   : Using EAP-TLS with TLS 1.3
Authors : John Preuß Mattsson
  Mohit Sethi
Filename: draft-ietf-emu-eap-tls13-07.txt
Pages   : 28
Date: 2019-09-21

Abstract:
   This document specifies the use of EAP-TLS with TLS 1.3 while
   remaining backwards compatible with existing implementations of EAP-
   TLS.  TLS 1.3 provides significantly improved security, privacy, and
   reduced latency when compared to earlier versions of TLS.  EAP-TLS
   with TLS 1.3 further improves security and privacy by mandating use
   of privacy and revocation checking.  This document updates RFC 5216.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-07
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-09-19 Thread John Mattsson
I am starting to come down on the side the EAP-TLS PSK should be specified.

- I think EAP-PSK should be phased out like all other methods not giving PFS.
- The security of the Dragonfly handshake used in EAP-PWD (and WPA3) seems 
quite shaky ( https://eprint.iacr.org/2019/383 ), but I have not looked into 
the details.

- An EAP password method for the future should likely use the PAKE that CFRG 
will soon standardize.
- EAP methods should in the future support some PQC key exchange.

TLS will very likely get support for both the CFRG PAKE and PQC key exchange 
algorithms. I am not sure the EAP group want to spend time updating either 
EAP-PSK or ESP-PWD. Unless there are other benefits with EAP-PSK or EAP-PWD, I 
think standardizing EAP-TLS PSK makes a lot of sense.

I also note that, EAP-PSK is experimental and EAP-PWD is informal. Unless IETF 
thinks PSK and passwords should not be used (which does certainly not seem to 
be the case as TLS 1.3 is including PSK and CFRG is standardizing password 
based AKE) I think that EMU should make some PSK and password based method 
Standards Track. At the moment EAP-TLS 1.3 looks like the best choice.

Jim wrote:
> and more to do with the security properties of the EAP method.

If that is seen as a problem, standardizing a separate Type-Code for EAP-TLS 
with PSK authentication would solve the problem.

/John

-Original Message-
From: "Owen Friel (ofriel)" 
Date: Thursday, 19 September 2019 at 11:17
To: Jim Schaad , '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 Message-
> From: Jim Schaad 
> Sent: 19 September 2019 07:28
> To: 'Alan DeKok' ; Owen Friel (ofriel)
> 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' 
> Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> I am going to come down on the side of no PSK should not be supported.
> However my issues have nothing to do with how things are implemented
> and more to do with the security properties of the EAP method.
> 
> When you use certificates, there is no leakage of who the client is as 
this is
> encrypted by TLS.  When you use a restore session ticket, it is possible 
to limit
> the number of times that the ticket can be used (for example once).
> The PSK identity is public and unprotected so it can be used to track.  
If one is
> using PSK for the purpose of authentication then that value will always be
> visible to intermediate parties for the purpose of tracking.
> This can be slightly mitigated by using restore session tickets with PSK, 
but
> you are going to send that PSK identifier over the wire many times.

The IoT use case is to use the PSK one time for authentication during 
bootstrapping, then get credentialed, and thereafter use a certificate for 
subsequent EAP authentications. The bootstrap PSK enables proof of possession 
i.e. the thing will only bootstrap against a network that knows its PSK.

> 
> 
> This is just informational and can be ignored:
> 
> My current favorite way to deal with PSK/ticket identifiers is with
> encryption:
> 
> 32 bytes of index into table
> 32 bytes of date information
> 32 bytes of SIV (synthetic IV)
> 
> Encrypt the first two items using the SIV.  You can then have multiple 
keys for
> decryption.  One for PSKs and a resolving one for session tickets.  If the
> identifier does not decrypt then you reject.  Otherwise you look at the 
date
> information and the index in the table for the secret information.
> 
> It is even possible to play games with AAD to do things like scope the 
tickets
> up front - if you put in the name/address of the NAS then you have a
> prescreen on where the ticket can be used.
> 
> Jim
> 
> 
> 
> 
> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: Wednesday, September 18, 2019 2:59 PM
> To: Owen Friel (ofriel) 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel)  wrote:
> > Giving some implementation guidance seems appropriate here. Naively,
> > one
> could envisage the implementation simply having a DB table for extern PSKs
> and a table that holds NewSessionTickets. An implementation could simply
> check the extern PSK table using the PskIdentity.identity, and if no 
match is
> found then check the NewSessionTickets tab

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-09-18 Thread John Mattsson
If I understand you correctly Alan, your implementation would have different 
databases (one resumption DB and one external PSK DB) and you do not want to do 
two database lookups. The format of the PSKidentities is free for the 
deployment to decide upon and the resumption PSKs can be completely be 
determined by the EAP-TLS implementation. Your implementation could for example 
put a message authentication code inside the PSK identity. The MAC would be 
calculated with a symmetric key the EAP server has randomly generated by 
itself. I think that would solve your problem.

I do not see how an attacker could do anything. an attacker can definitely 
reuse any PSK identity, but would not have the corresponding PSK and the 
ClientHello would therefore not be accepted. The worst thing an attacker could 
do is to replay a ClientHello, then the handshake would fail then the EAP 
server 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 Mattsson , 
"draft-ietf-emu-eap-tl...@ietf.org" , EMU WG 

Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

On Sep 18, 2019, at 8:45 AM, Owen Friel (ofriel)  wrote:
> 
>> 
>>  Which means that if PSK was allowed, the server can't look at the 
packets to
>> distinguish resumption from "raw" PSK.  Instead, the server has to look 
at it's
>> resumption cache which may be in a DB.
> 
> The server can use the PskIdentity in the PreSharedKeyExtension to 
differentiate between an offline PSK used for authentication vs. a PSK 
established via NewSessionTicket.

  Please define "use".  As an implementor, I can't implement "my code USES 
a field".  I need to know what the code *does* with it.

  How does the code differentiate between PSK identities?  Are the identity 
formats different?  If so, how and why?

  What prevents a malicious attacker from "using" a format which matches an 
identity coming from NewSessionTicket?

  My understanding is that the code *cannot* make any decisions simply by 
looking at the PSK identity field.  Instead, it has to look at the resumption 
cache to see if a given PSK matches a cached one.  Or maybe the code looks in a 
DB to see if the given PSK is a real "end-user" PSK in the DB.

  Simply waving your hands and saying it "uses" a field is unhelpful.  
Please give substantive feedback and/or advice about what the code *does*.

  Alan DeKok.



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

2019-09-12 Thread John Mattsson
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 , 
Resent date: Thursday, 12 September 2019 at 15:56

>Alan DeKok wrote:
>On Sep 12, 2019, at 9:53 AM, Aura Tuomas  wrote:
>   > 
>> I was looking at the EAP-TLS with TLS 1.3 draft and noticed that it 
> forbids PSK >authentication. Why is that?

There was discussion regarding this on the list some years ago. The conclusion 
was to use the EAP-TLS Type-Code should be exclusively for certificate 
authentication. At that point, nobody expressed wish to use EAP-TLS with PSK 
authentication. If someone wants to use EAP-TLS with symmetric keys that should 
probably be a  new code point.

>  See Section 2.1.2.  TLS 1.3 uses PSK for resumption.  As a result, we 
> *cannot* use PSK for >authentication in EAP-TLS.

I don't understand why this could not be done. My view is that allowing PSK 
authentication would be quite easy.

>> While there is the EAP-PSK method, I would much rather use EAP-TLS with 
> PSK because it >provides identity protection and perfect forward secrecy, 
> unlike EAP-PSK. 
>
>  Use EAP-PWD for that.

Standardizing EAP-TLS should only be done if it has some significant advantages 
over EAP-PWD, and there are people wanting to implement and use it. 3GPP is 
e.g. adding  identity protection and perfect forward secrecy to EAP-AKA instead.

>
>> In fact, I think EAP-TLS with PSK should become the standard 
> authentication method for >networks that rely on shared secrets, e.g. 
> WPA-Personal. Unifying the Wi-Fi authentication >around EAP would greatly 
> simplify the Wi-Fi protocol stack. Not that I expect it to happen 
> >immediately, but we should not close sensible paths forward.
>
>  The time to fix that was before TLS 1.3 was standardized.
>
>  Alan DeKok.



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Re-charter text

2019-08-21 Thread John Mattsson
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 involved 
and part of EAP-AKA like SUCI encryption may be done by the ME.

I suggest something like "TLS and Mobile Network AKA"

- "pdate" -> "update"

- "document the implications of using new vs. old TLS versions"

The current document only docuemnt implications of using TLS 1.2 as  
draft-ietf-tls-oldversions-deprecate formally forbids use of TLS 1.0 and TLS 
1.1 everywhere (including EAP).

- "erratas" -> "errata" (errata is plural of eratum)

- "Define session identifiers for fast re-authentication for EAP-SIM, EAP-AKA, 
and EAP-AKA’. The lack of this definition is a recently discovered bug in the 
original RFCs."

Should mention PEAP as well.

"in the context of EAP-TLS (all versions)" -> "in the context of TLS based EAP 
methods"

- "TLS working group (for EAP-TLS work)" -> "TLS working group (for work on TLS 
based EAP methods)"

Cheers,
John

From: Emu  on behalf of Mohit Sethi M 

Date: Wednesday, 21 August 2019 at 10:14
To: "emu@ietf.org" 
Subject: [Emu] Re-charter text


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/rfc2418#section-2.2 says the 
following about a working group charter:

   2. Specifies the direction or objectives of the working group and

  describes the approach that will be taken to achieve the goals;

Please keep this in mind when suggesting changes. Once the text is ready, we 
will send it to the IESG for review.

Joe and Mohit



The Extensible Authentication Protocol (EAP) [RFC 3748] is a network access 
authentication framework used, for instance, in VPN and mobile networks. EAP 
itself is a simple protocol and actual authentication happens in EAP methods. 
Several EAP methods have been developed at the IETF and support for EAP exists 
in a broad set of devices. Previous larger EAP-related efforts at the IETF 
included rewriting the base EAP protocol specification and the development of 
several standards track EAP methods.

EAP methods are generally based on existing security technologies such as TLS 
and SIM cards. Our understanding of security threats is continuously evolving. 
This has driven the evolution of several of these underlying technologies. As 
an example, IETF has standardized a new and improved version of TLS in RFC 
8446. The group will therefore provide guidance and update EAP method 
specifications where necessary to enable the use of new versions of these 
underlying technologies.

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 update existing 
EAP methods such as EAP-AKA' to stay in sync with updates to the referenced 
3GPP specifications. RFC 7258 notes that pervasive monitoring is an attack. 
Perfect Forward Secrecy (PFS) is an important security property for modern 
protocols to thwart pervasive monitoring. The group will therefore work on an 
extension to EAP-AKA' for providing Perfect Forward Secrecy (PFS).

Out-of-band (OOB) refers to a separate communication channel independent of the 
primary in-band channel over which the actual network communication takes 
place. OOB channels are now used for authentication in a variety of protocols 
and devices (draft-ietf-oauth-device-flow-13, WhatsApp Web, etc.). Many users 
are accustomed to tapping NFC or scanning QR codes. However, EAP currently does 
not have any standard methods that support authentication based on OOB 
channels. The group will therefore work on an EAP method where authentication 
is based on an out-of-band channel between the peer and the server.

EAP authentication is based on credentials available on the peer and the 
server. However, some EAP methods use credentials that are time or domain 
limited (such as EAP-POTP), and there may be a need for creating long term 
credentials for re-authenticating the peer in a more general context. The group 
will investigate minimal mechanisms with which limited-use EAP authentication 
credentials can be used for creating general-use long-term credentials.

In summary, the working group shall produce the following documents:

 - An update to enable the use of TLS 1.3 in the context of EAP-TLS (RFC 5216). 
This document will pdate the security considerations relating to EAP-TLS, 
document the implications of using new vs. old TLS versions, add any recently 
gained new knowledge on vulnerabilities, and discuss the possible implications 
of pervasive surveillance.

 - Several EAP 

Re: [Emu] I-D Action: draft-ietf-emu-aka-pfs-00.txt

2019-08-03 Thread John Mattsson
Hi,

I read the whole document again. I think it is in a good shape. Some quick high 
level comments. I will do a more detailed review(s) later

- I think this should formally update rfc5448bis

- "This specification is an optional extension to the EAP-AKA'"

  While the extension is not mandatory, I think the draft should somewhere say 
that use of the
  extension is strongly recommended instead of just stating that it is optional.
 
 - "This specification is an optional extension to the EAP-AKA'
   authentication method which was defined in RFC 5448 (to be superseded
   by draft-ietf-emu-rfc5448bis)."

   With RFC5448bis almost done, I think this could be changed to

 - "This specification is an optional extension to the EAP-AKA'
   authentication method defined in draft-ietf-emu-rfc5448bis."

- "from being able to decrypt all past communications."

  True, but this could be more specificly described as

  "from being able to decrypt any past communications."

- " 3rd generation AKA "

  I don't think it is third gen AKA, rather 3G aka in the sense of AKA for 3G

- "When AKA (and AKA')"

  AKA' is not explained anywhere

- "Perfect Forward Secrecy" vs. "Perfect Forward Security"
  
  Draft uses both. PFS is stated to stand for the Security version.
  I suggest only using one of them.

- Whould be good to say something small about active vs. passive attacks early.
  Just a few sentences that active attacks are much more resource demanding and
  can be detected.

- "This method is referred to as ECDHE"

  Could say "This method is referred to as ECDHE or ECDH-EE"
  TLS calls it ECDHE while some other IETF protocols call it ECDH-EE

- "i.e., using temporary keys"
  I suggest "using only temporary keys" to differentiate from ECDH-ES that use
  one static key pair and one ephemeral key pair.

-  "Curve25519 group specified in [RFC8031]."

  I think the group is specified in RFC 7748

- 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 say a little about detecting
  active attackers.

- "I-D.mattsson-eap-tls13" -> "I-D.ietf-emu-eap-tls13"

- "John Mattson" -> "John Mattsson"

- "SIM" vs. "USIM" vs. "(U)SIM"
 
  The document uses all three. Could maybe cut down to one or two.

Cheers,
John

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-06.txt

2019-08-03 Thread John Mattsson
The did not get any feedback on the suggested changes I send out on Thu, 25 
July 2019 so I submitted that version as -06 that addresses all the comments 
made during the WGLC.

Cheers,
John

-Original Message-
From: Emu  on behalf of "internet-dra...@ietf.org" 

Reply to: "emu@ietf.org" 
Date: Saturday, 3 August 2019 at 10:25
To: "i-d-annou...@ietf.org" 
Cc: "emu@ietf.org" 
Subject: [Emu] I-D Action: draft-ietf-emu-eap-tls13-06.txt


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   : Using EAP-TLS with TLS 1.3
    Authors : John Mattsson
  Mohit Sethi
Filename: draft-ietf-emu-eap-tls13-06.txt
Pages   : 28
Date: 2019-08-03

Abstract:
   This document specifies the use of EAP-TLS with TLS 1.3 while
   remaining backwards compatible with existing implementations of EAP-
   TLS.  TLS 1.3 provides significantly improved security, privacy, and
   reduced latency when compared to earlier versions of TLS.  EAP-TLS
   with TLS 1.3 further improves security and privacy by mandating use
   of privacy and revocation checking.  This document updates RFC 5216.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-06
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

2019-08-03 Thread John Mattsson
Then draft-dekok-emu-tls-eap-types will have to describe how TLS-based EAP 
types do or not do the commit with application data.

As far as I understand, 0x00 will work for these other EAP types as well, so 
not need to change any thing in draft-ietf-emu-eap-tls13.

Cheers,
John

-Original 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 would seem that TEAP might need this 
feature
> as, at least on resumption, it is totally optional for both sides to use 
any
> TLVs an thus the same issue might be present.  TTLS seems to always 
require
> that the client send a AVP, but I am not sure that it is required for the
> server based on a really fast read.

  For initial authentication, TTLS requires TLVs inside of the TLS tunnel.  
For resumption, the inner tunnel isn't used.

  So it looks like the other TLS-based EAP methods will have the same 
issue, when resumption is used.

  Alan DeKok.



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] I-D Action: draft-dekok-emu-eap-session-id-01.txt

2019-07-25 Thread John Mattsson
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 
removed.

- The following sentences in the abstract and intro will have to change
  before publishing.

  "EAP Session-Id derivation has not been defined for EAP-SIM, EAP-AKA,
  and EAP-AKA' when using the fast re-authentication exchange instead
  of full authentication."

  I suggest to just remove EAP-AKA' (The document already talks about 
RFC5448bis). 

  "EAP Session-Id derivation has not been defined for EAP-SIM and EAP-AKA,
   when using the fast re-authentication exchange instead
   of full authentication."

- The sentence in the abstract about EAP-AKA' should be in the document body as 
well.

  "Since [AKAP] defines the Session-ID for EAP-AKA', the definition for
  EAP-AKA' is not included here."

- "TLS 1.2 or earlier is used" -> "TLS 1.2 is used"

   The TLS wg document draft-ietf-tls-oldversions-deprecate (Submitted to IESG
for Publication) formally prohibits negotiation and use of TLS 1.0
and TLS 1.1. It also updates all RFCs that use TLS.

- "deriviation" -> "derivation"

- "EAP-SIM, and EAP-AKA" -> "EAP-SIM and EAP-AKA"

Cheers,
John

-Original Message-
From: Emu  on behalf of "internet-dra...@ietf.org" 

Reply to: "emu@ietf.org" 
Date: Wednesday, 24 July 2019 at 01:47
To: "i-d-annou...@ietf.org" 
Cc: "emu@ietf.org" 
Subject: [Emu] I-D Action: draft-dekok-emu-eap-session-id-01.txt


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   : EAP Session-Id Derivation
Author  : Alan DeKok
Filename: draft-dekok-emu-eap-session-id-01.txt
Pages   : 9
Date: 2019-07-23

Abstract:
   EAP Session-Id derivation has not been defined for EAP-SIM, EAP-AKA,
   and EAP-AKA' when using the fast re-authentication exchange instead
   of full authentication.  This document updates [RFC5247] to define
   those derivations for EAP-SIM, and EAP-AKA.  Since [AKAP] defines the
   Session-ID for EAP-AKA', the definition for EAP-AKA' is not included
   here.  [RFC5247] also does not define Session-Id derivation for PEAP.
   A definition is given here which follows the definition for other
   TLS-based EAP methods.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-dekok-emu-eap-session-id/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-dekok-emu-eap-session-id-01
https://datatracker.ietf.org/doc/html/draft-dekok-emu-eap-session-id-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-dekok-emu-eap-session-id-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

2019-07-25 Thread John Mattsson
I made a few smaller changes, added a figure, and committed to GitHub. 

A diff can be found here:

http://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13-05.txt=https://raw.githubusercontent.com/emu-wg/draft-ietf-emu-eap-tls13/master/draft-ietf-emu-eap-tls13.txt

The GitHub commit can be found here:

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/b6529d49b129a0796715ab320df18003ceb4a964#diff-f0254f10e4339e650834528e3c398a26

Question: How will the use of Application data with TLSPlaintext.fragment = 
0x00 work with EAP-TTLS, PEAP, and TEAP when they start using TLS 1.3? I assume 
they will need to send the same 0x00 to commit to not sending any more 
handshake messages as well as using application data for other purposes. I do 
not know exactly how the TLSPlaintext fragments look like in EAP-TTLS, PEAP, 
and TEAP. The TLSPlaintext 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 for draft-ietf-emu-eap-tls13-05

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 
NewSessionTicket. Do we need a figure to illustrate the "or in a separate 
EAP-Request" part of " The TLS record with application data may be sent in the 
same EAP-Request as the last handshake record or in a separate EAP-Request."

Cheers,
John

Section 2.1:
---

OLD
   The EAP server commits to not send any more handshake messages by
   sending an empty TLS record, see Section 2.5.


NEW
   The EAP server commits to not send any more handshake messages by
   sending a TLS record with the application data 0x00, see Section 2.5.


Section 2.5 EAP State Machines
---

OLD
   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type = application_data and
   TLSPlaintext.length = 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

NEW
   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by sending a TLS record with application data 0x00 (i.e. a
   TLS record with TLSPlaintext.type = application_data,
   TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00).  EAP
   server implementations MUST set TLSPlaintext.fragment to 0x00, but
   EAP peer implementations MUST accept any application data as a commit
   from the EAP server to not send any more handshake messages.  The TLS
   record with application data may be sent in the same EAP-Request as
   the last handshake record or in a separate EAP-Request.  After
   sending the application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

Figures:
---

OLD
 <  TLS empty record)

NEW
 <  TLS Application Data)
 



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] WGLC completed for for draft-ietf-emu-eap-tls13-05

2019-07-24 Thread John Mattsson
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 
NewSessionTicket. Do we need a figure to illustrate the "or in a separate 
EAP-Request" part of " The TLS record with application data may be sent in the 
same EAP-Request as the last handshake record or in a separate EAP-Request."

Cheers,
John

Section 2.1:
---

OLD
   The EAP server commits to not send any more handshake messages by
   sending an empty TLS record, see Section 2.5.


NEW
   The EAP server commits to not send any more handshake messages by
   sending a TLS record with the application data 0x00, see Section 2.5.


Section 2.5 EAP State Machines
---

OLD
   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by appending an empty application data record (i.e. a TLS
   record with TLSPlaintext.type = application_data and
   TLSPlaintext.length = 0) to the last handshake record.  After sending
   an empty application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

NEW
   When an EAP server has sent its last handshake message (Finished or a
   Post-Handshake), it commits to not sending any more handshake
   messages by sending a TLS record with application data 0x00 (i.e. a
   TLS record with TLSPlaintext.type = application_data,
   TLSPlaintext.length = 1, and TLSPlaintext.fragment = 0x00).  EAP
   server implementations MUST set TLSPlaintext.fragment to 0x00, but
   EAP peer implementations MUST accept any application data as a commit
   from the EAP server to not send any more handshake messages.  The TLS
   record with application data may be sent in the same EAP-Request as
   the last handshake record or in a separate EAP-Request.  After
   sending the application data record, the EAP server may only send an
   EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
   Message.

Figures:
---

OLD
 <  TLS empty record)

NEW
 <  TLS Application Data)
 

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] The EMU WG has placed draft-dekok-emu-eap-session-id in state "Call For Adoption By WG Issued"

2019-07-03 Thread John Mattsson
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-based EAP types:

https://tools.ietf.org/html/draft-ms-emu-eaptlscert
https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types

and move them forward. I think draft-ms-emu-eaptlscert is ready for a working 
group adoption call. draft-dekok-emu-tls-eap-types should be given presentation 
and discussion time in Montreal.

Cheers,
John

From: Emu  on behalf of Mohit Sethi M 

Date: Wednesday, 3 July 2019 at 13:38
To: IETF Secretariat , 
"draft-dekok-emu-eap-session...@ietf.org" 
, "emu-cha...@ietf.org" 
, "emu@ietf.org" 
Subject: Re: [Emu] The EMU WG has placed draft-dekok-emu-eap-session-id in 
state "Call For Adoption By WG Issued"


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 Secretariat wrote:

The EMU WG has placed draft-dekok-emu-eap-session-id in state

Call For Adoption By WG Issued (entered by Mohit Sethi)



The document is available at

https://datatracker.ietf.org/doc/draft-dekok-emu-eap-session-id/



Comment:

This is a relatively straight-forward document that addresses an important

charter item. There have been a couple of reviews from John and Mohit.

Implementations have already been updated.



Please let us know if you object to the adoption of this document as a

working group item.



We intend to move forward with this document rather quickly after adoption.

Please provide reviews/feedback as early as possible.



Joe and Mohit



___

Emu mailing list

Emu@ietf.org

https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Can we get a WG last call for draft-dekok-emu-eap-session-id-00 ?

2019-06-11 Thread John Mattsson
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 of Alan DeKok 

Date: Thursday, 6 June 2019 at 17:59
To: Mohit Sethi M 
Cc: EMU WG 
Subject: Re: [Emu] Can we get a WG last call for 
draft-dekok-emu-eap-session-id-00 ?

On Jun 5, 2019, at 3:17 AM, Mohit Sethi M  
wrote:
> 
> Chair hat on: 
> 
> The draft needs to be formally adopted as a working group item before 
moving to last call.

  It would be nice, but I don't think that's strictly necessary for the 
process.

  The subject is already a WG charter item, so there should be no issues.

> 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 in the wpa_supplicant and hostapd:
> 
https://protect2.fireeye.com/url?k=d57338aa-89f9f214-d5737831-869a17b5b21b-1ed8c39152cccb96=1=https%3A%2F%2Fw1.fi%2Fcgit%2Fhostap%2Fcommit%2F%3Fid%3D1c16b257a081e810caf2ca0926ff4f9e2bb9557c
> 
> 
https://protect2.fireeye.com/url?k=20285d34-7ca2978a-20281daf-869a17b5b21b-7a8f16a9731f4e17=1=https%3A%2F%2Fw1.fi%2Fcgit%2Fhostap%2Fcommit%2F%3Fid%3D5eefa8115b884f8ab45ac6521f66dc68f555dcd0
> 
> John provided a review here: 
https://mailarchive.ietf.org/arch/msg/emu/fHopSdLqMY37odPGvwn7M5ZksIw
> 
> and Jouni made a comment here: 
https://mailarchive.ietf.org/arch/msg/emu/MX7P367g4j2c3yuyqch3W-I3u_o
> 
> I have a couple of comments:
> 
> I think it would really help to document the fact that the Session-Id 
length for EAP-SIM is different for full authentication and fast 
re-authentication. That's because for full authentication, the Session-Id is:

  Sure.

> 
>> Session-Id = 0x12 || RAND || NONCE_MT
> and RFC 4186 says that EAP server should obtain n GSM triplets where n = 
2 or n = 3. So the length is either:
> 
> 1 (Method-Id) + 32 (RAND*2) +16 (NONCE_MT) = 49 or 
> 
> 1 (Method-Id) + 48 (RAND*3) + 16 (NONCE_MT) =65. 
> 
> However, in fast-reauthentication, the Session-Id is:
> 
> 
>> Session-Id = 0x12 || NONCE_S || MAC
> So the length is:
> 
> 1 (Method-Id) + 16 (NONCE_S) + 16 (MAC) = 33 
> 
> I found it surprising while implementing that the Session-Ids were 
different in lengths. 
> 
> My next question is about Session-Id for PEAP. The draft currently 
defines Session-Id for EAP-PEAP as:
> 
> 
>>   Session-Id = 0x19 || client.random || server.random).

  Which is for TLS 1.2 and below.

> Do you plan to update this for TLS 1.3 and use TLS-Exporter in your other 
draft:  draft-dekok-emu-tls-eap-types? Do we need to do this twice in separate 
drafts?

  draft-dekok-emu-tls-eap-types already updates the Session-ID for all 
TLS-based EAP types, including PEAP.

  The issues are (a) update missing derivations for TLS <1.2, and (b) 
define new derivations for TLS 1.3.  So yes, we update PEAP twice.
 
  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] FW: I-D Action: draft-ietf-emu-eap-tls13-05.txt

2019-05-26 Thread John Mattsson
Hi,

The changes in the 05 version are:

- Added new subsection for Hello Retry Request
- Changed the order of some subsubsection in section 2.1
- Removed all text on other TLS-based EAP methods as agreed at IETF 104
- Added a reference to draft-ietf-tls-oldversions-deprecate (which updates RFC 
5216) and made changes based on this.
- Added clarification on how to treat the fragmentation L bit.
- Several changes ("early_data", empty certificate_list, other authorization 
information, force a full TLS handshake) based on the review by Jim Schaad.

Cheers,
John

-Original Message-
From: Emu  on behalf of "internet-dra...@ietf.org" 

Reply-To: "emu@ietf.org" 
Date: Sunday, 26 May 2019 at 13:29
To: "i-d-annou...@ietf.org" 
Cc: "emu@ietf.org" 
Subject: [Emu] I-D Action: draft-ietf-emu-eap-tls13-05.txt


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   : Using EAP-TLS with TLS 1.3
Authors : John Mattsson
  Mohit Sethi
Filename: draft-ietf-emu-eap-tls13-05.txt
Pages   : 26
Date: 2019-05-26

Abstract:
   This document specifies the use of EAP-TLS with TLS 1.3 while
   remaining backwards compatible with existing implementations of EAP-
   TLS.  TLS 1.3 provides significantly improved security, privacy, and
   reduced latency when compared to earlier versions of TLS.  EAP-TLS
   with TLS 1.3 further improves security and privacy by mandating use
   of privacy and revocation checking.  This document updates RFC 5216.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-05
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] FW: New Version Notification for draft-ms-emu-eaptlscert-03.txt

2019-05-26 Thread John Mattsson
Hi,

The changes in -03 are:

- Added text to the "Update Authenticator" section based on the discussions on 
the mailing list.
- Added text describing the Suppressing Intermediate Certificates draft 
draft-thomson-tls-sic
- Added references to other TLS-based EAP methods.

Cheers,
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
has been successfully submitted by John Mattsson and posted to the
IETF repository.

Name:   draft-ms-emu-eaptlscert
Revision:   03
Title:  Handling Large Certificates and Long Certificate Chains 
in TLS-based EAP Methods
Document date:  2019-05-26
Group:  Individual Submission
Pages:  10
URL:
https://www.ietf.org/internet-drafts/draft-ms-emu-eaptlscert-03.txt
Status: https://datatracker.ietf.org/doc/draft-ms-emu-eaptlscert/
Htmlized:   https://tools.ietf.org/html/draft-ms-emu-eaptlscert-03
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ms-emu-eaptlscert
Diff:   https://www.ietf.org/rfcdiff?url2=draft-ms-emu-eaptlscert-03

Abstract:
   EAP-TLS and other TLS-based EAP methods are widely deployed and used
   for network access authentication.  Large certificates and long
   certificate chains combined with authenticators that drop an EAP
   session after only 40 - 50 round-trips is a major deployment problem.
   This memo looks at the this problem in detail and describes the
   potential solutions available.


  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

2019-04-06 Thread John Mattsson
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 compromised, 
enabling pervasive monitoring on a global scale. The heist did not only enable 
tracking of users, but also passive eavesdropping of communication from these 
devices as well as installation of malware.

https://www.kaspersky.com/blog/gemalto-sim-hack/7774/
https://theintercept.com/2015/02/19/great-sim-heist/
https://motherboard.vice.com/en_us/article/4x354b/worlds-largest-sim-card-maker-has-no-clue-whether-it-was-hacked-by-the-nsa

Even if AKA is primarily a 3GPP technology, IETF has a very important role to 
play as a driving force and guardian of security and privacy for all Internet 
users. IETF took an early stance in fighting pervasive monitoring everywhere 
and BCP 188 requires IETF work to mitigate pervasive monitoring when possible. 
Providing perfect forward secrecy for session keys has been identified as one 
of the easiest and most efficient ways to fight pervasive monitoring.

John

On Apr 3, 2019, at 1:37 AM, Joseph Salowey ; wrote:
> 
> Thanks for reviving this thread.  I agree this is important work, but we need 
> to have consensus to bring the item into the working group.  I think the IPR 
> issue is the main sticking point. 
> 
> I'll note that RFC 5448 has a similar IPR declaration and both documents are 
> targeted as informational.   Some possible ways forward:
> 
> 1. Come up with an alternative proposal.  Since no one has already stepped 
> forward I don't think this is realistic. 
> 2. Accept the document into the working group.
> 3. Reject the document, which will force the work to go through the 
> independent submission process, which will probably result in less broad and 
> thorough review.  
> 4. Amendment to the license terms of the IPR - I have received no indication 
> that this will happen
> 
> The document will likely get published in either case 2 or 3 above.  I'd like 
> to work through this discussion over the next few weeks so please voice your 
> views on this thread.  
>
>Thanks,
>Joe

___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] EAP-AKA' and Re: WG adoption call for draft-arkko-eap-aka-pfs

2019-04-03 Thread John Mattsson
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 or did it mutate into
>AKA?  I never quite knew.
>
>I was always very sad that AKA did not get more uptake as it authenticates
>the network to the phone, and therefore would have (as I understand things)
>defended against "Stingray" like equipment used without judicial review,
>requiring interceptors to significantly involve telco in such things, and
>limiting who they would actually "catch".  ... I've heard other claims too.

Several independent things here, first there are 4 different form factors for 
removable UICCs (aka "SIM cards")
1FF ("Full-size") = ID-1
2FF ("Mini-SIM") = ID-000
3FF ("Micro-SIM") = Mini-UICC
4FF ("Nano-SIM")

On the UICC, there are either a SIM application (2G), an USIM application (3G) 
or both. If you live in a country that have 4G and do not use a very old 
SIM-card, your SIM-card have USIM and can do AKA with network authentication. 
Authentication to a 4G/LTE network requires a USIM and always use AKA with 
network authentication.

Two main types of "Stingray like equipment"

- one is passive IMSI catchers. They just passively eavesdrop to catch 
identities. These will be mitigated in 5G with ECIES encryption of the 
identities as long as your operator provisions its public key on the UICC.

- the other is active false base stations. Many operators around the world has 
already turned off their 2G/GSM networks. The only reason this attack still 
works is that your phone happily connects to false 2G network is offers the 
best signal. Neither iOS (Apple) nor Android (Google) allows you to even 
manually turn off 2G. They both allow you to turn off 4G for battery savings 
but not 2G for security reasons. Ask the company that made your phone ;)

Cheers,
John


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] FW: Comment on draft-thomson-tls-sic-00

2019-03-29 Thread John Mattsson
I think draft-thomson-tls-sic-00 solves all the problems that the EMU wg have 
identified. The draft only works with EAP-TLS 1.3 but I think that is fine. Any 
implementation willing to update the TLS code, should update to TLS 1.3. I 
agree with Martin Thompson that the TLS WG should not spend 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 only talks about the ClientHello use case. 
Should shortly mention the CertificateRequest use case as well.

- I notice that the draft does not have any requirement on how the client 
gets access to the intermediary certificates. I think this is the right 
approach.

The problem discussed in EMU is that that many access points drops EAP 
connections after 40 - 50 packets and that EAP-TLS connections with large 
certificate chains may therefore be unable to complete.

One approach discussed in EMU is that the client could take intermediate 
certificates from an earlier EAP-TLS connection that was dropped by the access 
point. This drafts currently allows that. I think that is correct. I cannot see 
that the distribution of intermediary certificates need any security 
requirements as the client can verify them with the help of one of its trust 
anchors.

Cheers,
John

-Original Message-
From: John Mattsson 
Date: Friday, 29 March 2019 at 10:29
To: "t...@ietf.org" 
Subject: Comment on draft-thomson-tls-sic-00

Hi,

I am strongly supporting of solving the problem this draft is trying to 
solve. This is a problem that the EMU WG has identified and discussed in the 
past.

https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02

I will add text discussing draft-thomson-tls-sic-00 to 
draft-ms-emu-eaptlscert-03 and ask for agenda time in EMU at IETF 105 to 
discuss if draft-thomson-tls-sic-00 solves the problems of the EMU WG.

The EMU WG actually shortly discussed this Monday if the WG thought 
there was any updates to TLS that needed to be driven in the TLS WG.

Cheers,
John





___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] FW: [TLS] Comment on draft-thomson-tls-sic-00

2019-03-29 Thread John Mattsson
Hi EMU,

This new draft from Martin Thomson is solving a lot of the problems with large 
certificate chains in TLS, at least for EAP-TLS 1.3. I think the EMU working 
group should discuss if this draft solves the problems of the EMU working 
group, if not we should try to influence the draft so it 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 am strongly supporting of solving the problem this draft is trying to 
solve. This is a problem that the EMU WG has identified and discussed in the 
past.

https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02

I will add text discussing draft-thomson-tls-sic-00 to 
draft-ms-emu-eaptlscert-03 and ask for agenda time in EMU at IETF 105 to 
discuss if draft-thomson-tls-sic-00 solves the problems of the EMU WG.

The EMU WG actually shortly discussed this Monday if the WG thought there 
was any updates to TLS that needed to be driven in the TLS WG.

Cheers,
John

___
TLS mailing list
t...@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] TLS Resumption across Server Name Indications for TLS 1.3

2019-03-25 Thread John Mattsson
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 list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


  1   2   >