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

2021-05-11 Thread Jorge Vergara
I am in favor of the switch back to draft-13 key derivations.

Jorge Vergara

From: Emu  On Behalf Of Joseph Salowey
Sent: Sunday, May 9, 2021 10:54 AM
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] WG Last Call for Using EAP-TLS with TLS 1.3

2021-05-07 Thread Jorge Vergara
>[Joe] I think the one issue that was raised during TLS review was that using 
>the same label for MSK and EMSK could make it more difficult to separate out 
>the derivations of these keys at the TLS level.  For example, example, perhaps 
>the TLS implementation could restrict access to the MSK and EMSK independently 
>depending upon hte caller.  In practice, it is EAP-TLS that is the caller and 
>the use cases that require the separate derivation of these two keys of these 
>two keys is few to none.  I'll start a short consensus call on this issue.

I reviewed all of the concerns I was able to find in the group archives, and 
the concerns mostly seemed to express that the combined derivation (draft-13) 
was a bit "clumsy" with potential to clean it up a bit, but I didn't find any 
strong objections. Looking forward to more input from the group as to whether 
the draft-13 exporter is livable.

Jorge Vergara

From: Joseph Salowey 
Sent: Friday, May 7, 2021 2:19 PM
To: Jorge Vergara 
Cc: Alan DeKok ; EMU WG 
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3



On Fri, May 7, 2021 at 1:09 PM Jorge Vergara 
mailto:jover...@microsoft.com>> wrote:
>   When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and
>   Method-Id SHALL be derived from the exporter_secret using the TLS
>   exporter interface [RFC5705] (for TLS 1.3 this is defined in
>   Section 7.5 of [RFC8446]).
>
>   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
>
> All this is nice, but it might be too late.  I'd check with major 
> implementations which have frozen their code, and are shipping.

The Windows implementation is using draft-13 exporters; it is not possible to 
change at this point unless a critical technical issue that prevents 
functionality or impacts security were to be discovered. I don't think this is 
such an issue. The preference to keep draft-13 exporters was discussed at IETF 
110 and I do not recall any objection. The draft-15 exporter is problematic for 
Windows at this point.

[Joe] I think the one issue that was raised during TLS review was that using 
the same label for MSK and EMSK could make it more difficult to separate out 
the derivations of these keys at the TLS level.  For example, example, perhaps 
the TLS implementation could restrict access to the MSK and EMSK independently 
depending upon hte caller.  In practice, it is EAP-TLS that is the caller and 
the use cases that require the separate derivation of these two keys of these 
two keys is few to none.  I'll start a short consensus call on this issue.

I have fewer opinions on the less-technical areas of the draft. One of my flaws 
as an implementor of several EAP methods is that I can parse the current draft 
and assume enough intent to complete my implementation. I do call out questions 
I have - but I sometimes make assumptions without realizing due to prior 
experience in the area. This may be true of several others in the working group 
as well. Non-implementors don't have the luxury of this experience and I think 
it is extremely difficult to create a secure and robust EAP method 
implementation from scratch. The more guidance toward this goal that can be 
included in the document the better, in my opinion.

[Joe] Thanks, having a more voices chime in on issues can help resolve them 
more quickly and satisfactorily.

Jorge

-Original Message-
From: Emu mailto:emu-boun...@ietf.org>> On Behalf Of Alan 
DeKok
Sent: Thursday, May 6, 2021 12:12 PM
To: Joseph Salowey mailto:j...@salowey.net>>
Cc: EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3



> On May 5, 2021, at 11:33 AM, Joseph Salowey 
> mailto:j...@salowey.net>> wrote:
>
> 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.


Section 1 says:

  While this document updates EAP-TLS [RFC5216], it
  remains backwards compatible with it and existing implementations of
  EAP-TLS.

Other than the abstract, this is the only reference to EAP-TLS 1.3 being 
backwards compatible with older versions of EAP-TLS.  This compatibility is 
simply asserted, with no further explanation given.

Q: What does "backwards compatible" mean?  How is it achieved?

Suggestion: add text explaining how it is backwards compatible.  How will 
EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps update Section 2.1 
with text indicating that TLS version negotiation is handled by the TLS layer, 
and thus outside of the scope of EAP-TLS.
Therefore so long

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

2021-05-07 Thread Jorge Vergara
>   When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and
>   Method-Id SHALL be derived from the exporter_secret using the TLS
>   exporter interface [RFC5705] (for TLS 1.3 this is defined in
>   Section 7.5 of [RFC8446]).
>
>   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
>
> All this is nice, but it might be too late.  I'd check with major 
> implementations which have frozen their code, and are shipping.

The Windows implementation is using draft-13 exporters; it is not possible to 
change at this point unless a critical technical issue that prevents 
functionality or impacts security were to be discovered. I don't think this is 
such an issue. The preference to keep draft-13 exporters was discussed at IETF 
110 and I do not recall any objection. The draft-15 exporter is problematic for 
Windows at this point.

I have fewer opinions on the less-technical areas of the draft. One of my flaws 
as an implementor of several EAP methods is that I can parse the current draft 
and assume enough intent to complete my implementation. I do call out questions 
I have - but I sometimes make assumptions without realizing due to prior 
experience in the area. This may be true of several others in the working group 
as well. Non-implementors don't have the luxury of this experience and I think 
it is extremely difficult to create a secure and robust EAP method 
implementation from scratch. The more guidance toward this goal that can be 
included in the document the better, in my opinion.

Jorge

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Thursday, May 6, 2021 12:12 PM
To: Joseph Salowey 
Cc: EMU WG 
Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3



> On May 5, 2021, at 11:33 AM, Joseph Salowey  wrote:
> 
> 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.   


Section 1 says:

  While this document updates EAP-TLS [RFC5216], it
  remains backwards compatible with it and existing implementations of
  EAP-TLS. 

Other than the abstract, this is the only reference to EAP-TLS 1.3 being 
backwards compatible with older versions of EAP-TLS.  This compatibility is 
simply asserted, with no further explanation given.

Q: What does "backwards compatible" mean?  How is it achieved?

Suggestion: add text explaining how it is backwards compatible.  How will 
EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps update Section 2.1 
with text indicating that 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.


Section 2.1.1 says:

  TLS 1.3 introduced the Post-Handshake KeyUpdate
  message which is not useful and not expected in EAP-TLS. 

Q: What does it mean that the message is "not expected"?  This seems like a 
source of implementation-defined behavior, which experience shows has been a 
source of interoperability and security issues.

Suggestion: If there is no use for KeyUpdate messages, then mandate that it 
SHOULD be ignored, or perhaps connections which use KeyUpdate MUST be closed 
without updating the keys.  OpenSSL as APIs to determine the status of key 
updates, so this suggestion is implementable.


Section 2.1.3 says this about the session ticket:

  ... If the EAP-TLS server
  accepts it, then the security context of the new connection is tied
  to the original connection and the key derived from the initial
  handshake is used to bootstrap the cryptographic state instead of a
  full handshake. 

Nit: This the the only reference to "bootstrap the cryptographic state" in this 
document.  This text seems like an unnecessary repetition of RFC 8446 Section 
2.2.

Suggestion: Perhaps say instead

  ... If the EAP-TLS server
  accepts it, then the resumed session has been deemed to be
  authenticated, and securely associated with the prior authentication
  or resumption.


Section 2.1.4

   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. 

NIT: strengthenS this requirement.

Section 2.1.5 is essentially empty.

 Is there guidance as to when no peer authentication should / should not be 
used?  Is it possible for an EAP peer to present a client certificate, but have 
the EAP server ignore it?  What kind of network access should an EAP peer have 
if it does not use peer authentication?

  Perhaps some of the text from 

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

2021-02-19 Thread Jorge Vergara
Here are my answers as a client implementor. You'll see our implementation has 
had more time to bake with the application data, but I don't think either is 
technically problematic. I do favor the application data because I believe it 
is better suited for the semantic purpose as a protected result indicator for 
EAP-TLS. When close_notify was floated in the group and put in draft-14, the 
group was very specifically discussing the semantic of "no more messages will 
be sent" - for which close_notify carries that intent very clearly. The group 
has now realized that a protected result indicator is needed instead, and this 
is very different from "no more messages will be sent." It's my opinion that 
close_notify is less suited for this new purpose.

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

>a. Is it sent after receiving the client finished?
Observably in server implementations we are testing against, yes.

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

>c. did you run into any issues with this mechanism?
No.
>2. Have you implemented the close notify method? If not, why not?
Yes, but testing isn't finished.

>a. Is it sent after receiving the client finished?
We're ironing out a few implementation issues.

>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?
We're ironing out a few implementation issues.

>c. Did you run into any issues with this mechanism?
Yes, as above - but theoretically I don't see a technical issue once the kinks 
are ironed out. We believe the signal should be accessible to our client 
implementation.

Jorge Vergara
___
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-02-01 Thread Jorge Vergara
There has been a lot of discussion on the ending of the handshake that I hope I 
have parsed. Here is my perspective as an client implementor (not an author):



1. I don't see a strict requirement for an authenticated signal at the end of 
the handshake. No prior version of EAP-TLS needed this and I don't necessarily 
see the need now. An EAP-TLS client should wait until it has satisfied all of 
its server validation policies and completes TLS before accepting a connection 
to the server, even if a "rogue" server starts sending EAP-Success all the 
time. Any client which blindly connects in this case is a broken client.



2. Although I don't see any security benefit, such a signal *may* be convenient 
to help EAP-TLS implementations update their state machines to support TLS 1.3. 
For example, if an EAP-TLS state machine previously used to assume that a "TLS 
complete" signal from its TLS library was sufficient to advance to a new state 
where it will no longer accept TLS payload might break when TLS 1.3 is used. 
Such a state machine would not necessarily know when to advance to this state 
with some similar sort of signal that the server is done.



A different state machine which simply will always process TLS payload even 
after a "TLS complete" signal from its TLS library may not need any updates at 
all to work with TLS 1.3. I believe such a state machine would be able to 
handle a NewSessionTicket after TLS completion without issues even without a 
signal.



Windows currently happens to fall into the first camp, where a signal is 
convenient. It seems to me that using close_notify is more semantically 
correct, but has some tradeoffs.



A. In some cases, where the commitment message may be able to allow for a 
shorter handshake, using close_notify doesn't allow the client to send an 
alert, which is a non-starter in my opinion.

B. If we settle for an extra round trip, we can use close_notify and make sure 
the client always has at least 1 chance to send an alert.



This seems to me to be roughly where we started the discussion. Perhaps I have 
some of the theoretical details regarding the authenticated end signal 
incorrect as my perception is definitely colored by being mainly a client 
implementor. I happen to prefer the draft-13 commitment message because it 
seems to allow one less round trip in some cases. I'm happy to see discussion 
occurring either way and hope my perspective as an implementor is useful in 
driving toward a resolution.



Jorge Vergara


From: Emu  On Behalf Of Joseph Salowey
Sent: Monday, February 1, 2021 11:32 AM
To: Alan DeKok 
Cc:  ; EMU WG ; Benjamin Kaduk 

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



On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On Feb 1, 2021, at 11:26 AM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
> Yes, this is what I have in mind. So, maybe there's never any need for the 
> server to say "I won't say anything more" after just one round trip?

  I think so, yes.

  That means of course EAP-TLS will always require 4.5 round trips.

[Joe] I don't follow why this means 4.5 round trips would be required.

  Alan DeKok.

___
TLS mailing list
t...@ietf.org<mailto:t...@ietf.org>
https://www.ietf.org/mailman/listinfo/tls<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls=04%7C01%7Cjovergar%40microsoft.com%7Cd91c71b48e0c4b698fbc08d8c6e850bb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637478048391997828%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=y8w56%2BgJwrxEOi%2B%2FgFCeQpZnA8%2FjPqslXFEngbk8dKE%3D=0>
___
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 Jorge Vergara
>>DISCUSS: We have interoperable implementations of -13.  Does this mean that 
>>the EAP state machines *implicitly* work with the TLS state machines?  There 
>>is no *explicit* requirement in the draft about ordering, and no discussion 
>>thereof.  I suspect that this means the implementations work in part by 
>>accident, instead of by design.  So updates to TLS libraries *may* break 
>>EAP-TLS.  It would be best to make any assumptions explicit.  And / or to 
>>recommend to implementors that they be flexible with respect to changing 
>>order of the 0x00 octet vs session tickets.
>[Joe] Yes we should be clear about this.
[Jorge] My only recommendation would be to wordsmith this part of draft-13 
found in section 2.5. I am not a good wordsmith but I see potential confusion 
here:
>After sending the Commitment Message, the EAP-TLS
>   server may only send an EAP-Success, an EAP-Failure, or an EAP-
>   Request with a TLS Alert Message.

[Jorge] The diagrams in the draft mostly imply that the commitment message 
being the last thing sent, after any NewSessionTicket. As stated, this is 
problematic since the TLS stack may re-order these, and the NewSessionTicket 
may have to come in another EAP-TLS fragment entirely if the combined message 
ends up crossing a fragment boundary.

In my mind, it is obvious that the rest of the EAP-TLS packet should be 
processed so that the EAP-TLS client can correctly receive the NewSessionTicket 
and any other handshake data that may have been in this final message. However, 
once that complete EAP-TLS packet is processed, the next message from the 
server should indeed be an EAP-Success, EAP-Failure, or EAP-Request with a TLS 
Alert Message as draft-13 indicates.

This is currently how the Windows client implementation operates, but it is 
mostly by chance. If we made the full processing of the EAP-TLS packet 
explicit, then I think this would resolve the concerns around ordering here.

Jorge Vergara

From: Emu  On Behalf Of Joseph Salowey
Sent: Friday, January 29, 2021 2:00 PM
To: Alan DeKok 
Cc: EMU WG ; Benjamin Kaduk ; Martin Thomson 
;  
Subject: Re: [Emu] [TLS] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

HI Alan,

THanks for this message, comments inline below:

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 CloseNotify could achieve the same goals.  But 
CloseNotify requires an additional round trip.  There are strong opinions that 
additional round trips are bad.

  In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal 
Alert:  
https://www.mail-archive.com/emu@ietf.org/msg03092.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.mail-archive.com%2Femu%40ietf.org%2Fmsg03092.html=04%7C01%7Cjovergar%40microsoft.com%7C56726123402f4c09052908d8c4a16915%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637475544836111592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=mvsTA5W4KMdnLyFin4tzW185JUB%2FuxP%2FyNjI2Mh2Mkg%3D=0>

  i.e. there would be no TLS layer signalling for the following situations:

   bad_certificate,  unsupported_certificate,  certificate_revoked,
certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca,
access_denied, etc

  This limitation would be an unmitigated disaster for EAP-TLS.  Those messages 
are required by people deploying EAP-TLS.  Without those messages, it will be 
near impossible to debug configuration issues.

  As a result, we cannot use CloseNotify to signal "no more handshake messages" 
from the server.

  There is a related issue, in that TLS 1.3 separates Session Tickets from TLS 
handshakes.  So it's still possible for the EAP state machine to

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

2021-01-29 Thread Jorge Vergara
> 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)

My preference is D.

> 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.

Totally open to this.

Jorge Vergara

-Original Message-
From: Alan DeKok  
Sent: Friday, January 29, 2021 5:10 AM
To: John Mattsson 
Cc: Jorge Vergara ; Martin Thomson 
; Benjamin Kaduk ; Roman Danyliw 
;  ; EMU WG 
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

On Jan 29, 2021, at 5:31 AM, John Mattsson  wrote:
> 
> 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.

  Then our choices are:

a) draft-13 in February.  There are multiple interoperable implementations, 
including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.

b) ??? in 2021.

> 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.

  The TLS implementations largely assume that TLS is being used (a) over TCP, 
and (b) to exchange application data.  These assumptions *severely* limit the 
choices available for implementors of EAP-TLS.

  We can verify these assumptions by simply noting that many TLS 
implementations include native support for TLS over TCP.  While there have been 
assertions that TLS libraries also implement EAP, those assertions seem to be 
firmly outside of the bounds of reality.

> 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)

  My strong preference is (D).

> I assume implementors (Alan, Jorge) are fine with all other changes since -13.

  Yes,

> 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.

  TBH, implementors have already had multiple informal discussions and calls.  
One more wouldn't make much difference.

  Alan DeKok

___
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-28 Thread Jorge Vergara
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 betas.  
With no guarantee that there won't be further changes made after that.

  So the question is:

* are the draft-13 0x00 byte and exporter *terrible* enough to delay the 
standard another 6 months?

* if the answer is "no", then we can ship now.

* if the answer is 'yes", then the next question is "when can we get this 
finalized?"  "March" would be late.  "July" is a major problem.

> On Jan 12, 2021, at 10:22 AM, Alan DeKok  wrote:
> 
> On Jan 11, 2021, at 7:08 PM, Martin Thomson  wrote:
>> I was not exactly.  I was thinking that EAP-TLS uses the unadorned string 
>> and other usages (that need a different MSK) define their own string as 
>> needed.
> 
>  Which is largely what was done for <= TLS 1.2.
> 
>  That choice made implementations more difficult.  Not impossible, but 
> annoying.  The other TLS-based EAP types are generally implemented as 
> variants of EAP-TLS.  They re-use much of the EAP-TLS code.  So every 
> difference is more code, and more things to test.
> 
>> Though what you describe would scale more, if the ordinality of that scale 
>> is bounded by RFC numbers, defining the extra strings would not be that 
>> hard.  You could provide some sort of infrastructure in the form of a 
>> recommended label prefix if you are concerned about misuse.
> 
>  I'm not sure EAP-TLS is the place to make recommendations for other EAP 
> types.  There is a draft to deal with other EAP types:
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-00data=04%7C01%7Cjovergar%40microsoft.com%7Cb558b067ea62444150d008d8bfee5b6a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637470377753309597%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=eTBptf92iMhYupJv9kRLl%2FzAV75fZXSbDjTI9sKu%2Bvs%3Dreserved=0
> 
>  It's pretty trivial.  Adding more complexity is annoying, but not much worse 
> than that.
> 
>  My preference is to remain with the EAP type as the context.  The code is 
> simple, and it's easy to understand.  But if it causes issues with TLS 
> review, we can change it.
> 
>  Alan DeKok.
> 

___
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=04%7C01%7Cjovergar%40microsoft.com%7Cb558b067ea62444150d008d8bfee5b6a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637470377753319592%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX

Re: [Emu] Proposed Resolution for TEAP errata 5768

2020-12-10 Thread Jorge Vergara
This change looks good to me. Would appreciate a sanity check of another 
implementation by Oleg to make sure I have my facts straight here.

From: Joseph Salowey 
Sent: Sunday, November 22, 2020 9:24 PM
To: Jorge Vergara 
Cc: Oleg Pekar ; EMU WG ; Jouni 
Malinen 
Subject: Re: Proposed Resolution for TEAP errata 5768



On Thu, Nov 19, 2020 at 8:53 PM Jorge Vergara 
mailto:jover...@microsoft.com>> wrote:
Sorry for the last minute comment on this one before the meeting. I would like 
to mark this as a “discuss” - I have some compat concern about making the TLV 
length variable. Current implementations truncate the MAC field at 20 octets. 
Although I agree in spirit with the direction of this change, I think it would 
require changing the version of the Crypto-Binding TLV.

I recognize that most probably won’t have time to review this concern before 
the meeting and so the discussion may not be able to occur there. Apologies 
again as I only realized this concern as I was giving everything a final 
pass-over.


[Joe] Thanks for catching this.  If this is the case then we should have the 
errata resolution reflect what implementations do and leave the rest of the 
change for a document update.

For this I suggest that we leave section 4.2.13 unchanged and make changes to 
5.3.

Section 5.3 Says:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in the following
   order:

   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message.

It Should say:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is HMAC [RFC2104] using the hash function negotiated in
   TLS [RFC5246].  If the output of the HMAC is greater than 20 bytes then
   it is truncated to 20 bytes.  The BUFFER is created after concatenating
   these fields in the following order:

   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message. This
   is a single octet encoded as (0x37)

Jorge Vergara

From: Oleg Pekar mailto:oleg.pekar.2...@gmail.com>>
Sent: Saturday, October 24, 2020 4:30 PM
To: Joseph Salowey mailto:j...@salowey.net>>
Cc: EMU WG mailto:emu@ietf.org>>; Jouni Malinen 
mailto:j...@w1.fi>>; Jorge Vergara 
mailto:jover...@microsoft.com>>
Subject: Re: Proposed Resolution for TEAP errata 5768

> 2  The EAP Type sent by the other party in the first TEAP message. This is a 
> single octet encoded as (0x37)

Shouldn't we clarify the motivation for placing the octet with TEAP type 0x37 
into the BUFFER? Joe, I remember you explained that it is for protection 
against cross protocol attacks if Crypto-Binding TLV was reused (e.g. from 
PEAP).

On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
Errata 5768:  
https://www.rfc-editor.org/errata/eid5768<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5768=04%7C01%7Cjovergar%40microsoft.com%7C7011142d26864049db1808d88f6ffe5c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637417058458652454%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=J2HkST0fETP%2Fu5CJ789InRFFiI9OtX1awuKUhhDfBSQ%3D=0>
Proposed State: Verified
Revision:

Section 4.2.13. Says:

Length

76

It should say:

Length

 36 plus the length of the 2 MAC fields

Section 4.2.13. Says:

   EMSK Compound MAC

  The EMSK Compound MAC field is 20 octets.  This can be the Server
  MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
  MAC is described in Section 5.3.

   MSK Compound MAC

  The MSK Compound MAC field is 20 octets.  This can be the Server
  MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
  MAC is described in Section 5.3.

It Should Say:

   EMSK Compound MAC

  The computation of the MAC is described in Section 5.3.  This can be
  the Server MAC (B1_MAC) or the Client MAC (B2_MAC).

   MSK Compound MAC

  The computation of the MAC is described in Section 5.3.  This can be
  the Server MAC (B1_MAC) or the Client MAC (B2_MAC).

Section 5.3 Says:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in th

Re: [Emu] Proposed Resolution for TEAP errata 5768

2020-11-19 Thread Jorge Vergara
Sorry for the last minute comment on this one before the meeting. I would like 
to mark this as a “discuss” - I have some compat concern about making the TLV 
length variable. Current implementations truncate the MAC field at 20 octets. 
Although I agree in spirit with the direction of this change, I think it would 
require changing the version of the Crypto-Binding TLV.

I recognize that most probably won’t have time to review this concern before 
the meeting and so the discussion may not be able to occur there. Apologies 
again as I only realized this concern as I was giving everything a final 
pass-over.

Jorge Vergara

From: Oleg Pekar 
Sent: Saturday, October 24, 2020 4:30 PM
To: Joseph Salowey 
Cc: EMU WG ; Jouni Malinen ; Jorge Vergara 

Subject: Re: Proposed Resolution for TEAP errata 5768

> 2  The EAP Type sent by the other party in the first TEAP message. This is a 
> single octet encoded as (0x37)

Shouldn't we clarify the motivation for placing the octet with TEAP type 0x37 
into the BUFFER? Joe, I remember you explained that it is for protection 
against cross protocol attacks if Crypto-Binding TLV was reused (e.g. from 
PEAP).

On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
Errata 5768:  
https://www.rfc-editor.org/errata/eid5768<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5768=04%7C01%7Cjovergar%40microsoft.com%7C100b027d04c14dc5f59b08d87874b568%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637391789943190120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=jn7e%2FfR9O%2Fa%2B%2F1gPWuUcUaXKKyf%2F8cTAR0qTXXx6MRM%3D=0>
Proposed State: Verified
Revision:

Section 4.2.13. Says:

Length

76

It should say:

Length

 36 plus the length of the 2 MAC fields

Section 4.2.13. Says:

   EMSK Compound MAC

  The EMSK Compound MAC field is 20 octets.  This can be the Server
  MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
  MAC is described in Section 5.3.

   MSK Compound MAC

  The MSK Compound MAC field is 20 octets.  This can be the Server
  MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
  MAC is described in Section 5.3.

It Should Say:

   EMSK Compound MAC

  The computation of the MAC is described in Section 5.3.  This can be
  the Server MAC (B1_MAC) or the Client MAC (B2_MAC).

   MSK Compound MAC

  The computation of the MAC is described in Section 5.3.  This can be
  the Server MAC (B1_MAC) or the Client MAC (B2_MAC).

Section 5.3 Says:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
   BUFFER is created after concatenating these fields in the following
   order:

   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message.

It Should say:

 The Compound MAC computation is as follows:

  CMK = CMK[j]
  Compound-MAC = MAC( CMK, BUFFER )

   where j is the number of the last successfully executed inner EAP
   method, MAC is HMAC [RFC2104] using the hash function negotiated in
   TLS [RFC5246].  The output length is the length of the output of the HMAC
   function.  The BUFFER is created after concatenating these fields in
   the following order:

   1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
  Compound MAC fields zeroed out.

   2  The EAP Type sent by the other party in the first TEAP message. This
   is a single octet encoded as (0x37)

Notes:

This corrects the problem that the MAC output will vary depending upon the TLS 
hash function. It clarifies that HMAC is used with the hash function negotiated 
in TLS.   It also clarifies that the  EAP Type used in the TLS message is the 
TEAP EAP type encoded as a single byte.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Proposed Resolution to TEAP Errata 5770

2020-10-26 Thread Jorge Vergara
This is a detailed one so I’ve tried to go over it carefully. Most of it looks 
good but I’m unsure about this part:

> If an inner method fails or MAC verification
fails then S-IMCK is not used in further calculation.

It is a valid scenario that multiple authentication methods run and some fail, 
but the overall TEAP authentication succeeds. For example, if two inner EAP 
Authentication methods run and the first fails but the seconds succeeds, the 
calculation needs to be valid. Based on the old text, that authentication 
method is omitted from calculations. This is what current implementations do.

My editorial comment based on some other errata would be to that text needs to 
specify “authentication” methods (per Jouni’s other errata) since the Identity 
method doesn’t factor in here. I think it would also be beneficial to be 
specific about the behavior of basic username and password authentication here. 
Oleg made some comments to this effect on another email. Our implementation 
doesn’t support basic username and password authentication so I don’t have any 
prior experience here.

Jorge Vergara

From: Joseph Salowey 
Sent: Saturday, October 24, 2020 5:18 PM
To: EMU WG 
Cc: Oleg Pekar ; Jouni Malinen ; Jorge 
Vergara 
Subject: Proposed Resolution to TEAP Errata 5770

Errata 5770: 
https://www.rfc-editor.org/errata/eid5770<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5770=04%7C01%7Cjovergar%40microsoft.com%7C728ceb6af6694e40e08e08d8787b669d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637391818689781723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=RuRrXZ5c70r43Rmyl4s%2BVUKAA22nGtoenLElbCeUkmE%3D=0>
Proposed Status: Verified
Revision:

Section 5.2 Says:

On the sender of the Crypto-Binding TLV side:

 If the EMSK is not available, then the sender computes the Compound
 MAC using the MSK of the inner method.

 If the EMSK is available and the sender's policy accepts MSK-based
 MAC, then the sender computes two Compound MAC values.  The first
 is computed with the EMSK.  The second one is computed using the
 MSK.  Both MACs are then sent to the other side.

 If the EMSK is available but the sender's policy does not allow
 downgrading to MSK-generated MAC, then the sender SHOULD only send
 EMSK-based MAC.

   On the receiver of the Crypto-Binding TLV side:

 If the EMSK is not available and an MSK-based Compound MAC was
 sent, then the receiver validates the Compound MAC and sends back
 an MSK-based Compound MAC response.

 If the EMSK is not available and no MSK-based Compound MAC was
 sent, then the receiver handles like an invalid Crypto-Binding TLV
 with a fatal error.

 If the EMSK is available and an EMSK-based Compound MAC was sent,
 then the receiver validates it and creates a response Compound MAC
 using the EMSK.

 If the EMSK is available but no EMSK-based Compound MAC was sent
 and its policy accepts MSK-based MAC, then the receiver validates
 it using the MSK and, if successful, generates and returns an MSK-
 based Compound MAC.

 If the EMSK is available but no EMSK Compound MAC was sent and its
 policy does not accept MSK-based MAC, then the receiver handles
 like an invalid Crypto-Binding TLV with a fatal error.

If the ith inner method does not generate an EMSK or MSK, then IMSKi
is set to zero (e.g., MSKi = 32 octets of 0x00s).  If an inner method
fails, then it is not included in this calculation.

It Should Say:

On the sender of the Crypto-Binding TLV side:

 If the EMSK is not available, then the sender computes the Compound
 MAC using the CMK generated from MSK (CMK-MSK) of the inner method.

 If the EMSK is available and the sender's policy accepts MSK-based
 MAC, then the sender computes two Compound MAC values.  The first
 is computed with the CMK generated from the EMSK (CMK-EMSK).  The
 second one is computed using the CMK-MSK.  Both MACs are
 then sent to the other side.  This also means the sender must generate
 both EMSK and MSK based S-IMCKs.

 If the EMSK is available but the sender's policy does not allow
 downgrading to CMK-MSK MAC, then the sender SHOULD only send
 a MAC computed from the CMK-EMSK.

   On the receiver of the Crypto-Binding TLV side:

 If the EMSK is not available and an CMK-MSK Compound MAC was
 sent, then the receiver validates the Compound MAC and sends back
 an CMK-MSK Compound MAC response.

 If the EMSK is not available and no CMK-MSK Compound MAC was
 sent, then the receiver handles like an invalid Crypto-Binding TLV
 with a fatal error.

 If the EMSK is available and a CMK-EMSK Compound MAC was sent,
 then the receiver validates it and creates a response Compound MAC
 using the CMK-EMSK.

 If the EMSK is available but no CMK-EMSK Compound MAC

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-22 Thread Jorge Vergara
>[Joe] This is the one we have not discussed yet.  This derivation is also 
>ambiguous.  THis section does not reference 5295.  It's not clear if the 
>original intent was to include the length in the hash or not.  I think there 
>are a few interpretations:
>
>1. TLS-PRF(S-IMCK[j], "Session Key Generating Function")  iterated to generate 
>64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
>2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated to 
>generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 
>| 0x40)
>3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating 
>Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | 
>0x00 | 0x00 | 0x40)
>
>I think 1 or 2 is what was probably originally intended, however it seems that 
>3 is what has been implemented.  Do we have agreement on this is what current 
>implementations do?

No, Microsoft implements number 1 of Joe’s presented options. That is - 
P_(S-IMCK[j], "Session Key Generating Function").

This follows the same pattern as the errata we are discussion. I am very 
surprised to hear that Cisco’s implementation may be different. Oleg, could you 
please double check? I have just double checked our implementation. Since our 
implementations interop, I assume we must have the same implementation.

Jorge Vergara


From: Joseph Salowey 
Sent: Thursday, October 22, 2020 9:53 AM
To: Oleg Pekar 
Cc: EMU WG ; Jorge Vergara ; Jouni 
Malinen 
Subject: Re: Proposed resolution for TEAP errata for 5128



On Thu, Oct 22, 2020 at 9:29 AM Oleg Pekar 
mailto:oleg.pekar.2...@gmail.com>> wrote:
I agree that changing the KDF is harmful to existing implementations. However, 
if I understood correctly, Joe's suggestion for IMCK[j] also breaks the 
existing implementation. I still see that we can define a unified KDF by 
changing the API in the RFC but with the same harm to the existing 
implementation in IMCK[j] as in both proposals:

TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key label 
| 0x00 | optional data, length)
Joe, thanks for pointing out that RFC 5295 doesn't specify that a 0x00 is used 
to represent no optional data, that was just my mistake.

IMSK:
Current Microsoft and Cisco implementation: P_hash(EMSK, 
"teapbind...@ietf.org<mailto:teapbind...@ietf.org>" | 0x00 | 0x00 | 0x40)
Joe's proposal: P_hash(EMSK, 
"teapbind...@ietf.org<mailto:teapbind...@ietf.org>" | 0x00 | 0x00 | 0x40), the 
same, just the API correction
Unified KDF proposal: TEAP-PRF(EMSK, 
"teapbind...@ietf.org<mailto:teapbind...@ietf.org>", , 64) = 
P_hash(EMSK, "teapbind...@ietf.org<mailto:teapbind...@ietf.org>" | 0x00 | 0x00 
| 0x40)
--- no implementation change

IMCK[j]:
Current Microsoft and Cisco implementation: P_hash(S-IMCK[j-1], "Inner Methods 
Compound Keys” | IMSK[j])
Joe's proposal: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 
0x00 | 0x3C)
Unified KDF proposal: TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", 
IMSK[j], 60) = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 
0x00 | 0x3C)
--- implementation change

[Joe] That was my initial proposal, but based on Jorge's comment it is modified 
to:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])  to 
generate a length of 60 bytes
IMCK[j] = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys” | IMSK[j])


MSK:
Current Microsoft and Cisco implementation: P_hash(S-IMCK[j], "Session Key 
Generating Function” | 0x00 | 0x00 | 0x40)
Unified KDF proposal: TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 
, 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | 
0x00 | 0x00 | 0x40)
--- no implementation change

[Joe] This is the one we have not discussed yet.  This derivation is also 
ambiguous.  THis section does not reference 5295.  It's not clear if the 
original intent was to include the length in the hash or not.  I think there 
are a few interpretations:

1. TLS-PRF(S-IMCK[j], "Session Key Generating Function")  iterated to generate 
64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated to 
generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function” | 0x00 
| 0x40)
3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating 
Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating Function” | 
0x00 | 0x00 | 0x40)

I think 1 or 2 is what was probably originally intended, however it seems that 
3 is what has been implemented.  Do we have agreement on this is what current 
implementations do?




Jorge, please correct me if I misinterpret the Mi

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-22 Thread Jorge Vergara
My concern with this proposal of defining a new KDF is that it is a clear 
breaking change to any implementation that may exist.

In my opinion such a change would be fine if we want to bump some version 
numbers - maybe the TEAP version number has to be bumped, or maybe this can be 
achieved solely with the TLV version fields some of the TLVs contain. I haven’t 
thought about this aspect of too much. But redefining the KDF entirely with no 
version changes would be disruptive to multiple products.

This leads to a follow-up concern is - if an entirely new KDF were to be 
defined, I believe it should avoid using the TLS 1.2 PRF since it is already 
obsoleted in TLS 1.3.

Jorge Vergara

From: Oleg Pekar 
Sent: Thursday, October 22, 2020 6:59 AM
To: Joseph Salowey 
Cc: EMU WG ; Jorge Vergara ; Jouni 
Malinen 
Subject: Re: Proposed resolution for TEAP errata for 5128

Hi all,
Speaking about both errata 5127 and 5128, I think we need to align all key 
derivation calls in TEAP RFC with the same rule/format to make the RFC easier 
to understand. This can be achieved by introducing a unified single PRF 
function that will be called from all the relevant RFC locations. For me it 
sounds better than if we align just part of KDF calls with RFC 5295 (where the 
output length is included into seed). Also: in some KDF calls we do have 
optional data and in some no. This could be also unified.

So I would suggest introducing:
TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key label 
| 0x00 | optional data, length)
where a single byte 0x00 is used for no optional data, length is a 2-octet 
unsigned integer in network byte order.

Then:
IMSK = First 32 octets of TEAP-PRF(EMSK, 
"teapbind...@ietf.org<mailto:teapbind...@ietf.org>", 64) = TLS-PRF(EMSK, 
"teapbind...@ietf.org<mailto:teapbind...@ietf.org>" | 0x00 | 0x00 | 0x00 | 0x40)
IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60) = 
TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] | 0x00 | 
0x3C)
MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 64) = 
TLS-PRF(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 | 0x00 | 
0x40)
EMSK = TEAP-PRF(S-IMCK[j], ”Extended Session Key Generating Function”, 64) = 
TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function" | 0x00 | 0x00 | 
0x00 | 0x40)

This may change the existing implementation but will make it more clear - need 
to create and call just one KDF function.

We can remove 0x00 that comes after the key label - while it is required by RFC 
5295. But there the key label is also ASCII printable string. Joe, do you 
remember what was the motivation to put 0x00 after the key label parameter?

Oleg


On Thu, Oct 22, 2020 at 2:54 AM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
(I accidentally dropped this list from the conversation)

On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara 
mailto:jover...@microsoft.com>> wrote:
>[Joe] Yes this is a concern and I think your interpretation of the current 
>document is also valid.  There may be more than one implementation.  So what 
>you implemented was:
>
>IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) = 
>P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])

Yes, this is what I implemented. As you mentioned, there are multiple possible 
interpretations of this since the TEAP usage is incorrect. However, my 
implementation does interop with at least 2 large vendor implementations. If 
the implementations were using different calculations here, the Wi-Fi/Ethernet 
connections that depend on the MSK would fail. But since connections work, I 
can assume we are all using the same implementation and arriving at the same 
MSK. Cisco is one of the implementations that I have tested against which is 
why I was hoping Oleg may offer more context as to what he has seen.

[Joe] I can hope Jouni can chime in on this as well.  I think the original 
intent was to not include the length as is your suggestion.


>[Joe] Does the revision in 5167 match you implementation ( I don't think 
>Jouni's comment changes the underly calculation, just its representation)?

I have not implemented this portion of the RFC as I found it too unclear to 
work with. Thus I can’t comment on what implementations may be doing. However, 
I agree with the current revision in 5167 as the most natural interpretation. 
If others have implemented this portion of the RFC then certainly their 
comments would be welcome.

By the way, we’ve dropped the EMU group on our replies here – not sure if 
intentional or not.

Jorge Vergara

From: Joseph Salowey mailto:j...@salowey.net>>
Sent: Wednesday, October 21, 2020 4:36 PM
To: Jorge Vergara mailto:jover...@microsoft.com>>
Subject: Re: Proposed resolution for TEAP errata for 5128



On Wed, Oct 21, 2020 at 3:20 PM Jorge Verg

Re: [Emu] Resolution of TEAP Errata 5767

2020-10-21 Thread Jorge Vergara
I agree with all the proposed resolutions. For context, there was some prior 
discussion of this errata here: 
https://mailarchive.ietf.org/arch/msg/emu/K_XWBMevKNdxdWskK8RkBt1ZpSQ/

Jorge Vergara

From: Joseph Salowey 
Sent: Wednesday, October 21, 2020 5:13 PM
To: EMU WG ; Jouni Malinen ; Jorge Vergara 
; Oleg Pekar 
Subject: Resolution of TEAP Errata 5767

Errata 5767: 
https://www.rfc-editor.org/errata/eid5767<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5767=04%7C01%7Cjovergar%40microsoft.com%7C50b56afadcf34732d50708d8761f45d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389223977410444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=24y%2BkrsBw1mdGuNMMgqmqiRz%2BqeFt9jVX4qUHtlUJwY%3D=0>
Status: Verified
Revision:

Section 3.3.1 says:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  If more than one method is going to be executed in
   the tunnel, then upon method completion, the server MUST send an
   Intermediate-Result TLV indicating the result.

It should say:

   EAP method messages are carried within EAP-Payload TLVs defined in
   Section 4.2.10.  Upon completion of each EAP authentication method in
   the tunnel, the server MUST send an Intermediate-Result TLV
   indicating the result.

Section 3.3.3 says:

  The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
  to perform cryptographic binding after each successful EAP method in a
  sequence of one or more EAP methods.

It should say:

  The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
  to perform cryptographic binding after each successful EAP authentication
  method in a sequence of one or more EAP methods.

Section 3.8.3 says:

   Upon successful completion of the EAP method in Phase 2, the peer and
   server exchange a Crypto-Binding TLV to bind the inner method with
   the outer tunnel and ensure that a man-in-the-middle attack has not
   been attempted.

It should say:

   Upon successful completion of the EAP authentication method in Phase 2,
   the peer and server exchange a Crypto-Binding TLV to bind the inner
   method with the outer tunnel and ensure that a man-in-the-middle attack
   has not been attempted.

Section 4.2.11 says:

   The Intermediate-Result TLV provides support for acknowledged
   intermediate Success and Failure messages between multiple
   inner EAP methods within EAP.

It should say:

  The Intermediate-Result TLV provides support for acknowledged
  intermediate Success and Failure messages after each inner EAP
  authentication method.

Section 4.2.13 says:

 It MUST be included with the Intermediate-Result TLV to perform
 cryptographic binding after each successful EAP method in a
 sequence of EAP methods, before proceeding with another inner
 EAP method.

It should say:

 It MUST be included with the Intermediate-Result TLV to perform
 cryptographic binding after each successful EAP authentication
 method in a sequence of EAP methods, before proceeding with
 another inner EAP method.

Notes:

TEAP description is somewhat vague in discussion about "EAP methods" vs. "EAP 
authentication methods" as it comes to the EAP methods performed in Phase 2 
within the TLS tunnel. RFC 3748 defines Identity request/response as an EAP 
method. However, this method is not an "authentication method" which is a 
special case of an method where the Type is 4 or greater.

RFC 7170 uses correct terminology in the first paragraph of Section 3.3.1 when 
talking about multiple authentication methods not being allowed by RFC 3748 in 
a single EAP conversation. However, many, but not all, of the following "[EAP] 
method" instances are actually referring to "[EAP] authentication method". This 
results in incorrect claims on when the Intermediate-Result TLV and 
Crypto-Binding TLV are used. They are not used after an EAP non-authentication 
method like Identity (e.g., see the example in C.3); they are used after each 
EAP authentication method like EAP-pwd.

Furthermore, the comment about "more than one method is going to be executed in 
the tunnel" does not sound accurate. This applies even if only a single EAP 
authentication method is executed in the tunnel (Identity method is not 
required to be executed). The proposed text in this errata entry addresses 
these two issues in Section 3.3.1. The following additional changes would be 
needed to make rest of the specification use the terms more accurately:

3.3.3: "after each successful EAP method" --> "after each successful EAP 
authentication method"
3.8.3: "completion of the EAP method" --> "completion of the EAP authentication 
method"
4.2.11: "between multiple inner EAP methods within EAP" --> "after each inner 
EAP authentication method"
4.2.13: "after each succes

Re: [Emu] Proposed resolution for TEAP errata for 5128

2020-10-21 Thread Jorge Vergara
In theory I agree this is a possible resolution. However, this doesn’t match 
any of the current TEAP implementations that I am aware of. Perhaps Oleg can 
weigh in as well in terms of what he’s seen.

I believe all current implementations treat 60 as the desired output length 
without treating as a seed. In terms of P_, this means implementations 
are performing the calculation without a seed.

RFC 5246 defines the TLS 1.2 PRF as:
PRF(secret, label, seed) = P_(secret, label + seed)

So the calculation implementations are currently performing with an empty seed 
ends up as:
P_(secret, label)

Note that in RFC 5295, the length *is* explicitly mentioned as being 
concatenated with the label
USRK = KDF(EMSK, key label | "\0" | optional data | length)

RFC 5295 is mentioned earlier in the TEAP RFC, in the section covered by errata 
5127. *However* it is not mentioned in this portion of the RFC. Since this 
calculation is not on an EMSK, I do not believe RFC 2395 applies and this is 
likely why implementations went with the seedless P_(secret, label) 
calculation instead.

Is there concern about updating the RFC in a way that breaks existing 
implementations?

Jorge Vergara

From: Joseph Salowey 
Sent: Wednesday, October 21, 2020 2:34 PM
To: EMU WG ; Jouni Malinen ; Jorge Vergara 
; Oleg Pekar (olpekar) 
Subject: Proposed resolution for TEAP errata for 5128

Errata 5128: 
https://www.rfc-editor.org/errata/eid5128<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5128=04%7C01%7Cjovergar%40microsoft.com%7Ca85c718a3fd14ab5d88f08d87609209d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389128860921409%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=GXwU4tO1%2BlJg9aYY%2Bc%2BNKGdRAMlWy3I%2BqElyb%2BNd7ck%3D=0>
Proposed State: Verified
Revision:

Section 5.2. says

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK[j], 60)

It should say:

IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j] | 60)

Note:
According to

RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2

5. HMAC and the Pseudorandom Function

"TLS's PRF is created by applying P_hash to the secret as:

PRF(secret, label, seed) = P_(secret, label + seed)"

In terms of P_ this would look like the following with the length 
represented as a 2 byte value in network byte order:

IMCK[j] = P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j] | 0x00 
| 0x3C)


___
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-17 Thread Jorge Vergara
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.

Jorge Vergara

-Original Message-
From: Alan DeKok  
Sent: Wednesday, September 2, 2020 10:33 AM
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 10:23 AM, John Mattsson  wrote:
> 
> 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.

  It's fine for EAP Success.  But having two different code paths is a little 
surprising.

> My understanding is that is would add an extra roundtrip without any clear 
> benefits compared to sending an encrypted 0x00 application data.

  That's a reason to stick with sending 0x00, then.

  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 Jorge Vergara
>>[Joe] Moving away from SHA-1 is a good idea as it will only raise questions 
>>moving forward.  For TLS 1.3 I think you could use the same text, but I would 
>>look to Jorge to make sure we get it correct for PEAP.   TEAP should also use 
>>the Hash from HKDF in TLS 1.3.

>I am not a TLS terminology expert so please go with whatever the group thinks 
>is best. If for TEAP we are using "For TLS 1.3 the hash function used is the 
>same as the ciphersuite hash function negotiated for HKDF in the key 
>schedule.", then I’d be fine with something similar for PEAP.

After some more thought a concern came to me about reaching into TLS 1.3 and 
using the HKDF. These dependencies on TLS versions are why all the EAP methods 
are currently needing updates. Would using the HKDF directly create a similar 
situation for the future? Would it be better to define these calculation in 
terms of the TLS-Exporter instead?

Jorge

From: Emu  On Behalf Of Jorge Vergara
Sent: Wednesday, September 2, 2020 9:48 AM
To: Joseph Salowey ; Alan DeKok 
Cc: emu@ietf.org
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt

>[Joe] Moving away from SHA-1 is a good idea as it will only raise questions 
>moving forward.  For TLS 1.3 I think you could use the same text, but I would 
>look to Jorge to make sure we get it correct for PEAP.   TEAP should also use 
>the Hash from HKDF in TLS 1.3.

I am not a TLS terminology expert so please go with whatever the group thinks 
is best. If for TEAP we are using "For TLS 1.3 the hash function used is the 
same as the ciphersuite hash function negotiated for HKDF in the key 
schedule.", then I’d be fine with something similar for PEAP.

Jorge

From: Joseph Salowey mailto:j...@salowey.net>>
Sent: Wednesday, September 2, 2020 8:53 AM
To: Alan DeKok mailto:al...@deployingradius.com>>
Cc: John Mattsson 
mailto:john.matts...@ericsson.com>>; Jorge Vergara 
mailto:jover...@microsoft.com>>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt



On Wed, Sep 2, 2020 at 7:54 AM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On Sep 2, 2020, at 3:30 AM, John Mattsson 
mailto:john.matts...@ericsson.com>> wrote:
>> 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.

  Yes.  Any suggested text?  I'm not overly familiar with TLS 1.3, so I don't 
want to suggest the wrong thing.

[Joe]  I think you should treat them as 3 distinct cases to make sure it is 
clear.  For TLS 1.3 I like John's second phrasing better as it aligns better 
with TLS 1.3 terminology:

"For TLS 1.3 the hash function used is the same as the ciphersuite hash 
function negotiated for HKDF in the key schedule."  (section 7.1 of 8446)

>> 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.

  Can we use the same hash functions as above?  If so, what would the text look 
like?

[Joe] Moving away from SHA-1 is a good idea as it will only raise questions 
moving forward.  For TLS 1.3 I think you could use the same text, but I would 
look to Jorge to make sure we get it correct for PEAP.   TEAP should also use 
the Hash from HKDF in TLS 1.3.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org<mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu=02%7C01%7Cjovergar%40microsoft.com%7Cb048c31e4ebd4573320308d84f5ff56e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346620851549851=jLdzGHqKrWNlsjKbBiscOzWRWmXd8pvgkBg6KgEWHmA%3D=0>
___
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 Jorge Vergara
>[Joe] Moving away from SHA-1 is a good idea as it will only raise questions 
>moving forward.  For TLS 1.3 I think you could use the same text, but I would 
>look to Jorge to make sure we get it correct for PEAP.   TEAP should also use 
>the Hash from HKDF in TLS 1.3.

I am not a TLS terminology expert so please go with whatever the group thinks 
is best. If for TEAP we are using "For TLS 1.3 the hash function used is the 
same as the ciphersuite hash function negotiated for HKDF in the key 
schedule.", then I’d be fine with something similar for PEAP.

Jorge

From: Joseph Salowey 
Sent: Wednesday, September 2, 2020 8:53 AM
To: Alan DeKok 
Cc: John Mattsson ; Jorge Vergara 
; emu@ietf.org
Subject: Re: [Emu] I-D Action: draft-ietf-emu-tls-eap-types-01.txt



On Wed, Sep 2, 2020 at 7:54 AM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On Sep 2, 2020, at 3:30 AM, John Mattsson 
mailto:john.matts...@ericsson.com>> wrote:
>> 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.

  Yes.  Any suggested text?  I'm not overly familiar with TLS 1.3, so I don't 
want to suggest the wrong thing.

[Joe]  I think you should treat them as 3 distinct cases to make sure it is 
clear.  For TLS 1.3 I like John's second phrasing better as it aligns better 
with TLS 1.3 terminology:

"For TLS 1.3 the hash function used is the same as the ciphersuite hash 
function negotiated for HKDF in the key schedule."  (section 7.1 of 8446)

>> 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.

  Can we use the same hash functions as above?  If so, what would the text look 
like?

[Joe] Moving away from SHA-1 is a good idea as it will only raise questions 
moving forward.  For TLS 1.3 I think you could use the same text, but I would 
look to Jorge to make sure we get it correct for PEAP.   TEAP should also use 
the Hash from HKDF in TLS 1.3.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org<mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu=02%7C01%7Cjovergar%40microsoft.com%7Ce9ca671b636744277cb408d84f58487c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637346587886062328=l8ieJEByAeR%2F4Nvmhs0heTW900Gx9Q1i%2BvoF1rDUPII%3D=0>
___
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-01 Thread Jorge Vergara
>> 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.

>  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?

Jorge Vergara

-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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7C3beed6d0ea854ee4414c08d84eb9eec0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637345907781097079sdata=%2Bs%2FarBWgPHSNgKG8rbLN0kB2hbr77aYRP35L9O2rgZc%3Dreserved=0

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


Re: [Emu] Commitment Message handling in EAP-TLS 1.3

2020-08-03 Thread Jorge Vergara
ACK that EAP-TLS does not need to keep the connection open.

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

Jorge

-Original Message-
From: Emu  On Behalf Of Jim Schaad
Sent: Saturday, August 1, 2020 8:23 AM
To: 'Alan DeKok' 
Cc: 'Mohit Sethi M' ; 'EMU WG' ; 
'Benjamin Kaduk' 
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3



-Original Message-
From: Alan DeKok  
Sent: Saturday, August 1, 2020 6:53 AM
To: Jim Schaad 
Cc: Mohit Sethi M ; EMU WG ; Benjamin 
Kaduk 
Subject: Re: [Emu] Commitment Message handling in EAP-TLS 1.3

On Jul 31, 2020, at 12:30 PM, Jim Schaad  wrote:
> 
> Ok – so this issue was raised at IETF 102.  (presentation 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F102%2Fslides%2Fslides-102-emu-eap-tls-with-tls-13-00data=02%7C01%7Cjovergar%40microsoft.com%7C79f98e3e6f7f49971c4608d8362ed351%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318922028443984sdata=nExLYi6p0JNNeZ8TZsfXkRIm53%2BHuUidEhU2GrrioA4%3Dreserved=0)
>  
> Just reading the slides is not telling me what was the problem.  I think I am 
> going to need to hear the audio of the presentation.  I have an extremely 
> vague memory that there was an OpenSSL problem involved here but I would not 
> swear to that.  You might be a better description either from John Mattsson 
> or Jouni.

  IIRC it's that OpenSSL doesn't have an API to send a zero bytes of 
application data.  I think other TLS implementations have similar limitations.

  Regardless of what solution is implemented, the requirement is to have a 
positive acknowledgement that TLS setup is finished.  This step seems to be 
missing by default in TLS 1.3.

  I suspect that most uses of TLS will *always* send application data.  Which 
makes EAP-TLS an outlier.  Hence the need for hacks like "send application data 
as one octet of zero".

[JLS]  Cobwebs are slowly being shaken out of my brain.  
*  I made an incorrect statement yesterday because I got EAP-TEAP and EAP-TLS 
confused.  Not surprising because I only ever spent any time on EAP-TEAP .  In 
EAP-TLS, once the handshake has been completed the tunnel does not need to be 
kept open.  This is the opposite of the case for EAP-TEAP where the tunnel is 
used for application EAP data.

* Based on that I agree with EKR that the close notification could be used 
instead of sending the one byte of application data.   Sending the close 
notification means that the server will no longer be sending any data and thus 
would not send any new session tickets.

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
 <(close_notify)
EAP-Response/
EAP-Type=EAP-TLS >
 <   EAP-Success

Jim



  Alan DeKok.


___
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7C79f98e3e6f7f49971c4608d8362ed351%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637318922028448974sdata=c40nE5bUpT69CYY9qDNx7dRyVWzFRqgoKcUvgV0p9yE%3Dreserved=0
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message handling

2020-07-13 Thread Jorge Vergara
Windows expects an encrypted octet. My brain had automatically translated the 
plaintext -> encrypted based on the timing of the commitment message - which 
was apparently an incorrect translation at the time. Interop has been tested 
with FreeRADIUS and hostapd.

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Monday, July 13, 2020 10:52 AM
To: Mohit Sethi M 
Cc: Roman Danyliw ; emu@ietf.org
Subject: Re: [Emu] Finishing draft-ietf-emu-eap-tls13 - Commitment Message 
handling

On Jul 13, 2020, at 1:44 PM, Mohit Sethi M  wrote:
> 
> Dear all,
> 
> draft-ietf-emu-eap-tls13 is currently in the state "AD Evaluation::AD 
> Followup". Our AD (Roman) had done an excellent review 
> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2Fk6K98OhuOQmbzSAgGWCtSIVv3Qk%2Fdata=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944sdata=mfYGmzLt9zC%2BDBmqGzeFmx%2Bq8XdZG%2Bd0JefKvwSSQ%2Bw%3Dreserved=0),
>  which I addressed in version 10 
> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FIopJTjefyVVKpObzyFc0CAJ-Pig%2Fdata=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380970944sdata=%2FWzCNaXEnxX9adDHjLHKHmH0aYyG3CV4cqpyRSP7yF4%3Dreserved=0).
>  
> ...
> Hannes says that this is not ideal and cannot be achieved with mbed TLS 1.3 
> implementation. He made 3 alternative suggestions for achieving the 
> functionality of the commitment message 
> (https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Femu%2FeM-14QdDQjg7DvhAVJMzpvPz5wg%2Fdata=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941sdata=umbXQTG0%2FLJN6IrXI%2BjgrQME6mE3UtmI7nOTAdghl7M%3Dreserved=0).
>  
> 
> I would like to close this issue and would like to receive feedback from 
> others who have commented before or are working on implementations: Jim, 
> Alan, Jouni; please let us know what do you think about the change?

  hostap sends an encrypted octet.  See 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw1.fi%2Fcgit%2Fhostap%2Fcommit%2F%3Fid%3D36ec5881657157752dced741256441c230e42fe6data=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941sdata=R1R8rq0d0MyG36iSVeJwcP3UYRSb%2F4MafyW9Ir%2BNx2A%3Dreserved=0

EAP-TLS server: Add application data to indicate end of v1.3 handshake This 
adds an encrypted version of a one octet application data payload to the end of 
the handshake when TLS v1.3 is used to indicate explicit termination of the 
handshake (either after Finished message or after the optional NewSessionTicket 
message). The current
draft-ietf-emu-eap-tls13-05 defines this to be a zero length payload, but since 
that is not allowed by OpenSSL, use a one octet payload instead for now with 
hopes of getting the draft specification updated instead of having to modify 
OpenSSL for this.

Signed-off-by: Jouni Malinen 

  FreeRADIUS does the same, as of recent commits in the v3.0.x branch.  We've 
successfully tested interoperability.

  So I think it's fine to send the one octet as *encrypted* data, and not 
*plaintext*.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7C435cd35863dd44a5aba708d82755b6b4%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637302596380980941sdata=1xjqVMXOl1D62KRGdzAggBjEIuBVMoIU6AisOnJEroo%3Dreserved=0

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


Re: [Emu] draft-dekok-emu-tls-eap-types discussion

2020-06-22 Thread Jorge Vergara
>[Joe] (catching up) With respect to the case that the method is an MSK 
>generating mechanism and and MSK is not generated/used.  I think the original 
>intention was that this case would be a protocol violation, ie if a method 
>generates an MSK it should be available for crypto-binding.   I'm concerned 
>that allowing the fallback to 0 MSK actually will cause a security 
>vulnerability in compound binding.  Do we know if this method mismatch is a 
>problem in practice?

[jovergar] I agree that if a method generates an MSK it should generally be 
used for crypto-binding. But this does not eliminate the need for a mechanism 
for each party (client/server) to communicate what kind of crypto-binding they 
are sending. The client/server is free to reject the crypto-binding if the peer 
is unable to produce a crypto-binding that satisfies the minimum policy of the 
implementation.

For example, if EAP-TLS is used as an inner method, and a client sends a 
zero-MSK, I would fully expect the server to reject the connection – not 
fallback to zero-MSK. I would expect a client to have similar minimum security 
policies it would accept for each method.

As to whether method mismatch is a problem in practice – yes, to an extent. 
Windows does not generate EMSK for EAP-TLS despite it being specified in the 
RFC, so the crypto-binding sent to the server is MSK based. If a server’s 
policy requires EMSK, then Windows can’t connect. This is certainly a Windows 
feature gap – but servers are free to decline the connection if they do not 
want to downgrade to an MSK based crypto binding.

From: Joseph Salowey 
Sent: Monday, June 22, 2020 8:53 PM
To: Oleg Pekar 
Cc: Jorge Vergara ; Jouni Malinen ; EMU WG 

Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion



On Tue, Apr 21, 2020 at 11:02 AM Oleg Pekar 
mailto:oleg.pekar.2...@gmail.com>> wrote:
>And focusing on that "what to do here.." part and the unused IMCK-zero[j] in 
>the previous paragraph..
>How is this supposed to work when an inner EAP authentication method does not 
>derive either MSK or EMSK?
>Intermediate result indication of success needs to be done and that implies 
>there needs to be Crypto-Binding TLV.
>But that TLV does not have option of indicating that neither EMSK Compound MAC 
>nor MSK Compound MAC are present (Flags field has no value 0 defined to do so).
I agree the 0 value should be explicitly listed for this purpose. Given the 
design of the flags I think it is clear this was the intended usage and its 
omission was likely an oversight.
>So what are those fields (or one of them) supposed to be set to?
>And how is that selected for an inner EAP authentication method j?
>Does this depends on what happened with method j-1 (if one was present)?
>How would the correct IMCK[j] be determined by the peer and the server if one 
>of them derived MSK/EMSK but the other one did not derive either for inner EAP 
>method j?
Assuming we use the value 0 to indicate the state where one of the peers did 
not derive either MSK or EMSK, then I believe the RFC addresses this as MSKi = 
32 octets of 0x00s. So if one side calculated neither MSK nor EMSK, and both 
sides decided to continue the conversion, then both sides would use the 
zero-MSK for that IMSK[j],

Jorge, Jouni, agree with the approach.

Jorge, please note that the same problem exists in PEAP Crypto-Binding TLV as 
specified in its 
documentation<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.microsoft.com%2Fen-us%2Fopenspecs%2Fwindows_protocols%2Fms-peap%2Febb2b12b-cd53-4f3a-afed-36588566c7c2=02%7C01%7Cjovergar%40microsoft.com%7Cf691061f596040be882d08d81728fe5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637284812133625099=9B%2BrGF9AduXXuERXbDh4tTTT4I%2BnVjOI1GrLwWJNPkY%3D=0>
 - when one side has an inner method that provided MSK and another side has 
this inner method that didn't provide MSK.

[Joe] (catching up) With respect to the case that the method is an MSK 
generating mechanism and and MSK is not generated/used.  I think the original 
intention was that this case would be a protocol violation, ie if a method 
generates an MSK it should be available for crypto-binding.   I'm concerned 
that allowing the fallback to 0 MSK actually will cause a security 
vulnerability in compound binding.  Do we know if this method mismatch is a 
problem in practice?

There is also a case where no inner method is executed. For example, when 
client certificate was received during TEAP outer tunnel establishment. In this 
case we also need to use zero-MSK. For such case both values of the flag work - 
"0 for zero-MSK" and "2 for MSK". This creates unnecessary ambiguity and thus 
would be better to request using flag's value "0" for zero MSK in such case 
(today we use value "2" and it doesn't create ambiguity). However there's a 
question here: in case of TEAP

Re: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02

2020-06-02 Thread Jorge Vergara


-Original Message-
From: Alan DeKok  
Sent: Tuesday, June 2, 2020 6:09 AM
To: Jorge Vergara 
Cc: EMU WG 
Subject: Re: [Emu] jovergar review of draft-dekok-emu-tls-eap-types-02

On Jun 2, 2020, at 3:29 AM, Jorge Vergara 
 wrote:
>>  
>> I’ve attempted/completed a prototype implementation of EAP-TLS, PEAP, 
>> EAP-TTLS, and TEAP clients using TLS 1.3. EAP-TLS went smoothly so this 
>> boils down to a review of the subject line document which addresses the rest 
>> of the EAP types. I am not necessarily an expert on all of TLS 1.3 so some 
>> of my issues may just be a lack of understanding – please point this out if 
>> so.

>  Thanks.  Is the source available somewhere?  It would be good to have 
> multiple implementations for interoperability testing.

Unfortunately I use code from the Windows operating system and so am not able 
to share my source at this time. I understand an open source implementation 
would be better but am happy to test against any server implementations that 
become available. I'm currently testing against hostapd.

>> I had the following questions/issues that may need to be addressed in this 
>> document:
>>  
>>  • PEAP Key Material when crypto binding is used. When PEAP uses crypto 
>> binding, it uses a different key material calculation that consumes inner 
>> method key material. This is not addressed in this document. If we fallback 
>> to what is currently defined, we end up with PEAP’s definition of PRF+, 
>> which despite the name is hardcoded to SHA1. Since it’s hard-coded to SHA1 
>> and doesn’t technically depend on the TLS-PRF, it technically could continue 
>> to be used. But, is there a desire to update this key material calculation 
>> as well to use the TLS-Exporter as with the rest of the calculations?  If 
>> not, I believe it’s still worth a mention, since I see it being a point of 
>> confusion.

>  I'm happy to leave the PRF+ calculation alone.  It uses HMAC-SHA1, which 
> seems fine.

Works for me, I just wanted to raise the question.

>>  
>>  • TTLS Implicit Challenge. The TLS-PRF is currently used to calculate 
>> the implicit challenge for CHAP, MS-CHAP, and MS-CHAP-V2 (non-EAP). This 
>> isn’t currently covered in the document. In TTLS, differing amounts of 
>> challenge material are needed based on whether CHAP, MS-CHAP, or MS-CHAP-V2 
>> is being used. It’s probably sufficient to define one exporter of a suitable 
>> length for all three and truncate to the amount needed.

>  I don't see that this needs to change, but it is worth a mention in the 
> document.
>
>  i.e. TTLS uses the TLS-PRF with a label of "ttls challenge".  The length of 
> the challenge material can simply be taken from the requirements.  So we 
> don't need to define multiple exporters.

Sure, this works too, as long as TLS-Exporter replaces the TLS-PRF.

>>  • TEAP Compound MAC. The TEAP Compound MAC is currently defined in 
>> terms of the “MAC function negotiated in TLS 1.2.” If TEAP is to remain in 
>> this document, I believe this should be clarified. Here my familiarity with 
>> TLS 1.3 becomes an issue as I am not sure whether this is a simple wording 
>> update or if the calculation needs to be re-defined. (as an aside, I am in 
>> favor of TEAP in this document but understand if the consensus is to 
>> separate it)

>  I'm not sure here.

I reached out to a colleague on the Windows TLS team. He mentioned that the 
HKDF also has a hash function that is similar to the TLS 1.2 PRF function. So 
at first glance, he did not see a need to redefine this entirely; just reword 
the text. He suggested something like "hash function associated with the cipher 
suite negotiated for the TLS session." e.g., for TLS_AES_128_GCM_SHA256, EAP 
uses SHA256.

Hoping others with more TLS experience can chime in here or spend more time on 
the wording, but a first pass would seem to indicate this is mostly okay.

>>  • TEAP Inner Method Session Key. When an inner authentication method 
>> supports exporting an EMSK, the definition of the IMSK relies on the TLS-PRF 
>> and so needs to be adjusted. 

>  OK.  I'm less sure of what should be done here.  I'll take a look.

>>  • Section 5 of this document is out of date with the EAP-TLS document. 
>> It mentions that an empty application record is used to indicate negotiation 
>> has finished – this is now a size 1 0x00 application record.

>  Good point.  I'll update the doc.

>>  • Section 5 further mentions that methods which use inner tunnel 
>> methods should instead begin their inner tunnel negotiation by sending type 
>> specific application data. The inner tunnel is optional for PEAP, EAP-TT

[Emu] jovergar review of draft-dekok-emu-tls-eap-types-02

2020-06-02 Thread Jorge Vergara
Hi all,

I've attempted/completed a prototype implementation of EAP-TLS, PEAP, EAP-TTLS, 
and TEAP clients using TLS 1.3. EAP-TLS went smoothly so this boils down to a 
review of the subject line document which addresses the rest of the EAP types. 
I am not necessarily an expert on all of TLS 1.3 so some of my issues may just 
be a lack of understanding - please point this out if so.

I had the following questions/issues that may need to be addressed in this 
document:


  1.  PEAP Key Material when crypto binding is used. When PEAP uses crypto 
binding, it uses a different key material 
calculation<https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-PEAP/e75b0385-915a-4fc3-a549-fd3d06b995b0>
 that consumes inner method key material. This is not addressed in this 
document. If we fallback to what is currently defined, we end up with PEAP's 
definition of 
PRF+<https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-PEAP/0de54161-0bd3-424a-9b1a-854b4040a6df>,
 which despite the name is hardcoded to SHA1. Since it's hard-coded to SHA1 and 
doesn't technically depend on the TLS-PRF, it technically could continue to be 
used. But, is there a desire to update this key material calculation as well to 
use the TLS-Exporter as with the rest of the calculations?  If not, I believe 
it's still worth a mention, since I see it being a point of confusion.



  1.  TTLS Implicit Challenge. The TLS-PRF is currently used to calculate the 
implicit challenge<https://tools.ietf.org/html/rfc5281#section-11.1> for CHAP, 
MS-CHAP, and MS-CHAP-V2 (non-EAP). This isn't currently covered in the 
document. In TTLS, differing amounts of challenge material are needed based on 
whether CHAP, MS-CHAP, or MS-CHAP-V2 is being used. It's probably sufficient to 
define one exporter of a suitable length for all three and truncate to the 
amount needed.

  2.  TEAP Compound MAC. The TEAP Compound 
MAC<https://tools.ietf.org/html/rfc7170#section-5.3> is currently defined in 
terms of the "MAC function negotiated in TLS 1.2." If TEAP is to remain in this 
document, I believe this should be clarified. Here my familiarity with TLS 1.3 
becomes an issue as I am not sure whether this is a simple wording update or if 
the calculation needs to be re-defined. (as an aside, I am in favor of TEAP in 
this document but understand if the consensus is to separate it)

  3.  TEAP Inner Method Session Key. When an inner authentication method 
supports exporting an EMSK, the definition of the 
IMSK<https://tools.ietf.org/html/rfc7170#section-5.2> relies on the TLS-PRF and 
so needs to be adjusted.

  4.  Section 5 of this document is out of date with the EAP-TLS document. It 
mentions that an empty application record is used to indicate negotiation has 
finished - this is now a size 1 0x00 application record.

  5.  Section 5 further mentions that methods which use inner tunnel methods 
should instead begin their inner tunnel negotiation by sending type specific 
application data. The inner tunnel is optional for PEAP, EAP-TTLS, and TEAP, 
especially if resumption is used. So it's not clear to me how to indicate 
negotiation has finished in these methods. I believe the 0x00 octet from 
EAP-TLS is needed here as well.

I appreciate the effort gone into this thus far. I believe the adjustments 
needed are fairly simple and after the above issues are solved I could complete 
my prototypes.

Thanks,
Jorge Vergara
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] TEAP - RFC 7170 - Errata ID 5768

2020-05-26 Thread Jorge Vergara

From: Joseph Salowey 
Sent: Monday, May 25, 2020 9:27 PM
To: Jorge Vergara 
Cc: Oleg Pekar ; Jouni Malinen ; EMU WG 

Subject: Re: [Emu] TEAP - RFC 7170 - Errata ID 5768



On Fri, May 22, 2020 at 1:18 PM Jorge Vergara 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
My review of this errata and the current responses from Oleg:


  1.  I agree with this proposed resolution. I do think this is an important 
omission that needs to be clarified in the RFC. Otherwise it is somewhat 
guesswork that truncation is the right action. I think the current wording 
leans toward truncation, but I definitely asked this question myself while 
implementing.
[Joe]  Why not just change the TLV to be variable length?  It seems if we 
hardcode the length to 100 we risk having the same problem in the future?

[Jorge] I have to admit that in my original response my brain skipped over the 
TLV length adjustment and focused only on the truncation. If the TLV length is 
going to be adjusted at all, I am in favor of making the TLV variable length. A 
minimum length could also be added (32 bits seems to be the current 
recommendation). However, I do believe this is a breaking change to any TEAP 
implementation – would the TEAP version need to be bumped?

  1.
  2.  This bleeds into Alan’s TLS 1.3 document somewhat, but I agree with Jouni 
that this will need to change when the rest of the document is eventually 
updated to TLS 1.3.. There are enough TLS 1.3 related things to address in TEAP 
that I don’t exactly view this as an errata. I view it as a needed update, 
whether in this document, Alan’s document, or both.
[Joe]  I tend to agree that this is not an errata.  However an update to TEAP 
should address these.


  1.
  2.  Agree with Jouni that I don’t see the point of the 0x37 octet, but 
regardless this clarification of how it is encoded is positive (minor) change.
[Joe] I think the original reason to include the TEAP method ID in the 
specification was to make sure that we differentiated between similar crypto 
binding implementations in other protocols such as EAP-FAST.   I don't think 
there is much ambiguity here, but I am OK with including 0x37 in the 
description.


Thanks,
Jorge

From: Emu mailto:emu-boun...@ietf.org>> On Behalf Of Oleg 
Pekar
Sent: Tuesday, May 5, 2020 6:27 AM
To: Jouni Malinen mailto:j...@w1.fi>>; EMU WG 
mailto:emu@ietf.org>>
Subject: [Emu] TEAP - RFC 7170 - Errata ID 5768

Hi Jouni,
I propose the following fix for the issues described in this errata id:
1) In Section "4.2.13.  Crypto-Binding TLV" make "EMSK Compound MAC" and "MSK 
Compound MAC" fields 32 octets long (currently 20 octets). The MAC value is 
truncated at 32 octets if it is longer than 32 octets or padded to a length of 
32 octets with zeros to the right if it is less than 32 octets. The length of 
the TLV should be changed to 100 bytes (currently 76).

The motivation is to keep collision-resistance strength of MAC on 128 bit. Hash 
value truncation is described in "NIST Special Publication 800-107 Revision 1: 
Recommendation for Applications Using Approved Hash 
Algorithms"<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnvlpubs.nist.gov%2Fnistpubs%2FLegacy%2FSP%2Fnistspecialpublication800-107r1.pdf=02%7C01%7Cjovergar%40microsoft.com%7C6102b418ffd64be20f0b08d8012d1ade%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637260640995993815=MIOfT9tSEHTmbuP2oTjAxlgJdBOke3V4uAqQq7YDzN0%3D=0>

2) In Section "5.3.  Computing the Compound MAC" specify that "MAC is the MAC 
function negotiated in TLS of TEAP Phase 1" (currently it says TLS 1.2)

The motivation is to support TLS 1.2, 1.3 and possibly later TLS versions.

3) In Section "5.3.  Computing the Compound MAC" when specifying the list of 
field to be placed in the BUFFER" should say "...2  A single octet contains 
TEAP EAP method type 0x37". Alternatively it could be "...2  A single octet 
contains EAP Type of the inner EAP method related to the calculation or 0 if no 
inner EAP method was executed" (currently "...2  The EAP Type sent by the other 
party in the first TEAP message")

Please note that there's still a discussion on sending Crypto-Binding TLV on 
"Authentication inner EAP method" or "Inner EAP method that exports MSK" only.

Thanks
Oleg
___
Emu mailing list
Emu@ietf.org<mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femu=02%7C01%7Cjovergar%40microsoft.com%7C6102b418ffd64be20f0b08d8012d1ade%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637260640996003807=kBRkWM2GADS2iZP%2F6A9Ygr61JO6hcEe8cNK2Z6p9Pg0%3D=0>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] TEAP - RFC 7170 - Errata

2020-05-22 Thread Jorge Vergara
I am going to consider these 3 errata separately as I think it is clearest:

Errata ID 5767:

I believe Jouni’s differentiation of an “EAP authentication method” vs “EAP 
method” is that an “EAP authentication method” has a type >= 4. Jouni mentions 
this in his errata filing and it is also mentioned in RFC 3748 Section 
2.1 (possibly other places 
also). Jouni, I apologize if I have misinterpreted – please correct me if so.

So, an EAP-Identity (type 1) request is an “EAP method”, but there is obviously 
no intermediate result TLV or crypto binding TLV exchanged after an 
EAP-Identity exchange.

Jouni has done an excellent job in this errata of identifying where the 
terminology should be updated, and I agree with Jouni’s changes. I think the 
intent of the RFC in the four instances Jouni identified was fairly clear.

Errata ID 5844:

Oleg, your final proposal seems to indicate that an Intermediate-Result TLV 
should NOT be sent after Basic Password Authentication – I’m not sure I follow 
this. Section 3.3.2 outlines that an Intermediate-Result TLV SHOULD be sent 
after Basic Password Authentication.

So I find this errata valid and agree with Jouni that section C.1 and C.2 
should be updated to include the Intermediate-Result TLV in the diagrams.

I agree with the rest of the proposals Jouni has made as well that this should 
be made clearer throughout the document. Most of the time where the 
Intermediate-Result TLV is mentioned, only EAP is discussed and the Basic 
Password Authentication is forgotten. I don’t believe Jouni’s proposals change 
any timings – just clarify the language.

Errata ID 5845:

I find the errata valid and agree with Jouni. The direction in the rest of the 
document seems to be that an Intermediate-Result TLV is always exchanged (after 
both EAP authentication methods and Basic Password Authentications) and the 
text in 3.3.1 is confusing.

*

In summary – I find all of these errata valid and appreciate Jouni’s 
suggestions for clarifications. I find them all to be language clarifications 
and don’t believe any exchanges need to be altered.

Oleg, your final proposal seems to be removing the exchange of 
Intermediate-Result TLVs in the Basic Password Authentication case – I am not 
sure I follow this but if you believe this is needed for the resolution of this 
errata I would like to better understand why.

Thanks,
Jorge

From: Emu  On Behalf Of Oleg Pekar
Sent: Sunday, May 3, 2020 10:02 AM
To: Jouni Malinen ; EMU WG 
Subject: [Emu] TEAP - RFC 7170 - Errata

Hi Jouni,
You filed Errata ID: 5767, 5844, 5845 regarding sending of Intermediate-Result 
TLV. Can we clarify a general scheme of sending Intermediate-Result TLV and 
Crypto-Binding TLV in all cases? It is not exactly clear what is "EAP 
authentication method" and what is its different from "EAP method" (you 
referred to appendix C.3 as an example of "EAP Method" but it is not clear why 
it is not an "EAP authentication method" - could you please clarify).

Here's the list of cases with the current RFC instructions (please add if 
something is missing):

1. A single inner EAP method is executed inside the tunnel.
*** RFC says ***
Section 4.2.11 "An Intermediate-Result TLV indicating success MUST be 
accompanied by a Crypto-Binding TLV". Section 3.3 "Phase 2 MUST always end with 
a Crypto-Binding TLV exchange"

2. Multiple inner EAP methods are executed inside the tunnel.
*** RFC says ***
Send Intermediate-Result TLV if more than one method is going to be executed in 
the tunnel. Send Crypto-Binding TLV if Intermediate-Result TLV indicates 
success.
Section 3.3.1 "If more than one method is going to be executed in the tunnel, 
then upon method completion, the server MUST send an Intermediate-Result TLV 
indicating the result" - wrong
Section 3.3.3 "The Crypto-Binding TLV and Intermediate-Result TLV MUST be 
included to perform cryptographic binding after each successful EAP method in a 
sequence of one or more EAP methods" - correct

3. Basic Password Authentication (using Basic-Password-Auth-Req/Response) is 
executed inside the tunnel
*** RFC says ***
Send Intermediate-Result TLV.
Section 3.3.2 "Upon receiving the response, the server indicates the success or 
failure of the exchange using an Intermediate-Result TLV" - thus Crypto-Binding 
TLV MUST be also sent as quoted in #1.

4. No inner EAP method is executed inside the tunnel.
*** RFC says ***
Section 3.3.3 "A successful TEAP Phase 2 conversation MUST always end in a 
successful Crypto-Binding TLV and Result TLV exchange.  A TEAP server may 
initiate the Crypto-Binding TLV and Result TLV exchange without initiating any 
EAP conversation in TEAP Phase 2"
Section 4.2.13 "The Crypto-Binding TLV MUST be exchanged and verified before 
the final Result TLV exchange, regardless of whether there is an inner EAP 
method authentication or not"

**
Jouni, you provided multiple suggestions for fixing this. Incorporating you 

Re: [Emu] TEAP - RFC 7170 - Errata ID 5768

2020-05-22 Thread Jorge Vergara
My review of this errata and the current responses from Oleg:


  1.  I agree with this proposed resolution. I do think this is an important 
omission that needs to be clarified in the RFC. Otherwise it is somewhat 
guesswork that truncation is the right action. I think the current wording 
leans toward truncation, but I definitely asked this question myself while 
implementing.
  2.  This bleeds into Alan’s TLS 1.3 document somewhat, but I agree with Jouni 
that this will need to change when the rest of the document is eventually 
updated to TLS 1.3. There are enough TLS 1.3 related things to address in TEAP 
that I don’t exactly view this as an errata. I view it as a needed update, 
whether in this document, Alan’s document, or both.
  3.  Agree with Jouni that I don’t see the point of the 0x37 octet, but 
regardless this clarification of how it is encoded is positive (minor) change.

Thanks,
Jorge

From: Emu  On Behalf Of Oleg Pekar
Sent: Tuesday, May 5, 2020 6:27 AM
To: Jouni Malinen ; EMU WG 
Subject: [Emu] TEAP - RFC 7170 - Errata ID 5768

Hi Jouni,
I propose the following fix for the issues described in this errata id:
1) In Section "4.2.13.  Crypto-Binding TLV" make "EMSK Compound MAC" and "MSK 
Compound MAC" fields 32 octets long (currently 20 octets). The MAC value is 
truncated at 32 octets if it is longer than 32 octets or padded to a length of 
32 octets with zeros to the right if it is less than 32 octets. The length of 
the TLV should be changed to 100 bytes (currently 76).

The motivation is to keep collision-resistance strength of MAC on 128 bit. Hash 
value truncation is described in "NIST Special Publication 800-107 Revision 1: 
Recommendation for Applications Using Approved Hash 
Algorithms"

2) In Section "5.3.  Computing the Compound MAC" specify that "MAC is the MAC 
function negotiated in TLS of TEAP Phase 1" (currently it says TLS 1.2)

The motivation is to support TLS 1.2, 1.3 and possibly later TLS versions.

3) In Section "5.3.  Computing the Compound MAC" when specifying the list of 
field to be placed in the BUFFER" should say "...2  A single octet contains 
TEAP EAP method type 0x37". Alternatively it could be "...2  A single octet 
contains EAP Type of the inner EAP method related to the calculation or 0 if no 
inner EAP method was executed" (currently "...2  The EAP Type sent by the other 
party in the first TEAP message")

Please note that there's still a discussion on sending Crypto-Binding TLV on 
"Authentication inner EAP method" or "Inner EAP method that exports MSK" only.

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


Re: [Emu] draft-dekok-emu-tls-eap-types discussion

2020-04-19 Thread Jorge Vergara
>And focusing on that "what to do here.." part and the unused IMCK-zero[j] in 
>the previous paragraph..
>How is this supposed to work when an inner EAP authentication method does not 
>derive either MSK or EMSK?
>Intermediate result indication of success needs to be done and that implies 
>there needs to be Crypto-Binding TLV.
>But that TLV does not have option of indicating that neither EMSK Compound MAC 
>nor MSK Compound MAC are present (Flags field has no value 0 defined to do so).

I agree the 0 value should be explicitly listed for this purpose. Given the 
design of the flags I think it is clear this was the intended usage and its 
omission was likely an oversight.

>So what are those fields (or one of them) supposed to be set to?
>And how is that selected for an inner EAP authentication method j?
>Does this depends on what happened with method j-1 (if one was present)?
>How would the correct IMCK[j] be determined by the peer and the server if one 
>of them derived MSK/EMSK but the other one did not derive either for inner EAP 
>method j?

Assuming we use the value 0 to indicate the state where one of the peers did 
not derive either MSK or EMSK, then I believe the RFC addresses this as MSKi = 
32 octets of 0x00s. So if one side calculated neither MSK nor EMSK, and both 
sides decided to continue the conversion, then both sides would use the 
zero-MSK for that IMSK[j], 

Jorge Vergara

-Original Message-
From: Jouni Malinen  
Sent: Thursday, April 16, 2020 3:25 AM
To: Oleg Pekar 
Cc: Jorge Vergara ; EMU WG 
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion

On Wed, Apr 15, 2020 at 07:25:08PM +0300, Oleg Pekar wrote:
> For TEAP errata 5770:
> Technically TEAP RFC suggests the implicit method of taking the 
> correct IMSK[j] and all the subsequent keys after each inner method 
> via negotiation taking place in Crypto-Binding TLV exchange.

What is "the correct IMSK[j]" and where is this defined?

> Let's say we are on the inner method number j that supports both MSK 
> and EMSK and we are server which implementation generates both MSK and 
> EMSK for this inner method. We generated keys according to the rules 
> below - two sets, for IMSK[j] derived from inner method EMSK and for 
> IMSK[j] equal to inner method MSK. Because we don't know whether 
> client implementation supports both MSK and EMSK.
> 
> S-IMCK[0] = session_key_seed
>   For j = 1 to n-1 do
>IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
> IMSK[j], 60)
>S-IMCK[j] = first 40 octets of IMCK[j]
>CMK[j] = last 20 octets of IMCK[j]
> 
> 
> So we have two CMK[j] and we create Crypto-Binding TLV with both 
> Compound MAC for MSK and EMSK. The client sends Crypto-Binding TLV in 
> response and we can understand from it whether it supports EMSK for 
> this inner method or not. And here we can decide which version of 
> IMCK[j] to take for this inner method - derived from EMSK or MSK. This 
> is just not explicitly specified in the RFC.

Is this the proposed definition of "the correct IMSK[J]"? In other words, is 
this to be understood to have two (or three since we have the no MSK/EMSK case 
as well) variants of IMSK[j] during an execution of an internal AP 
authentication method and a single one of those variants is selected as _the 
correct_ IMSK[j] at the successful conclusion of this inner authentication 
method?

Would this single "correct IMSK[j]" then be used for deriving the different 
variants of IMSK[j+1] instead of using EMSK-based-IMSK[j] when deriving 
EMSK-based-IMSK[j+1]? In other words, is this to work by having all following 
inner authentication rounds and MSK/EMSK derivation to behave as if the other 
variants of IMSK[j] never really existed?

> Could this method work? Should we make it more clearly specified? Or 
> should we change the protocol to arrive explicitly to the 
> understanding which type
> (MSK/EMSK) of IMSK[j] to use?

Regardless of what is done for the design, it will absolutely need to be 
specified more clearly.

If I understood the proposed design correctly, this should be defined with 
something like following:

For each successful inner EAP authentication method, derive IMCK-MSK[j] (if MSK 
was derived by the inner method), derive IMCK-EMSK[j] (if EMSK was derived by 
the inner method), derive IMSK-zero[j] (for all cases). Derive CMK-MSK[j] from 
IMCK-MSK[j] and CMK-EMSK[j] from IMCK-EMSK[j] (both: if available). Generate 
Crypto-Binding TLV with all available Compound MAC values. Also verify 
Crypto-Binding TLV with all available Compound MAC values. After both ends have 
transmitted and received Crypto-Binding TLV, set IMSK[j] to be IMCK-EMSK[j] if 
both ends included EMSK Compound MAC, or set IMSK[j] to be IMCK-MSK[j] if both 
ends inclu

Re: [Emu] draft-dekok-emu-tls-eap-types discussion

2020-04-19 Thread Jorge Vergara
Apologies for a second round of feedback after some more time reviewing the 
document contents.

Section 3 of the document describes how tunneled methods should the possibility 
of Post-Handshake messages in TLS 1.3. As discussed on this mail thread:
https://mailarchive.ietf.org/arch/msg/emu/0MeocWZQLCv1pST5_2jW_ABlpMo/
it is possible for the methods in this discussion to skip the phase 2 "tunnel" 
completely. Thus it seems that a similar approach as is being taken for EAP-TLS 
would be needed here, since there may be no application data exchanged after 
the TLS handshake completes.

Jorge Vergara

-Original Message-
From: Alan DeKok  
Sent: Sunday, April 19, 2020 9:17 AM
To: Jorge Vergara 
Cc: EMU WG 
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion

On Apr 7, 2020, at 5:09 PM, Jorge Vergara  wrote:
> On the document contents themselves, I have this review: The key derivation 
> proposed for TEAP/FAST uses the definition from FAST, which is not identical 
> to the TEAP derivation. Namely, FAST used MSK[j] in the derivation, but TEAP 
> uses IMSK[j], which may be equivalent in some cases, but may not in others 
> where the inner method exports an EMSK.
> 
> Specifically, I believe this line of section 2.2 should change from
>  IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound 
> Keys", S-IMCK[j-1] | MSK[j], 60) To
>  IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound 
> Keys", S-IMCK[j-1] | IMSK[j], 60) For TEAP.

  I've made the change, thanks.

  Alan DeKok.

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


Re: [Emu] draft-dekok-emu-tls-eap-types discussion

2020-04-15 Thread Jorge Vergara
> For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning to 
> find the common method of TLS 1.3 support for all three or you just want to 
> release TLS 1.3 support at the same time for all three?

It’s not our intention to try to force the same solution for every method. We 
plan to update our implementations at the same time, since we anticipate the 
updates will be similar (though not necessarily identical).

>Could this method work? Should we make it more clearly specified? Or should we 
>change the protocol to arrive explicitly to the understanding which type 
>(MSK/EMSK) of IMSK[j] to use?

You clarification is what I understood the intention of the RFC to be as well, 
and makes sense to me. I don’t think there needs to be a protocol update if 
this clarification sounds good to all parties. I would welcome Jouni’s thoughts 
as the filer of the errata.

Jorge

From: Emu  On Behalf Of Oleg Pekar
Sent: Wednesday, April 15, 2020 9:25 AM
To: Jorge Vergara 
Cc: EMU WG 
Subject: Re: [Emu] draft-dekok-emu-tls-eap-types discussion

Hi Jorge,
For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning to 
find the common method of TLS 1.3 support for all three or you just want to 
release TLS 1.3 support at the same time for all three?

For TEAP errata 5770:
Technically TEAP RFC suggests the implicit method of taking the correct IMSK[j] 
and all the subsequent keys after each inner method via negotiation taking 
place in Crypto-Binding TLV exchange.

Let's say we are on the inner method number j that supports both MSK and EMSK 
and we are server which implementation generates both MSK and EMSK for this 
inner method. We generated keys according to the rules below - two sets, for 
IMSK[j] derived from inner method EMSK and for IMSK[j] equal to inner method 
MSK. Because we don't know whether client implementation supports both MSK and 
EMSK.


S-IMCK[0] = session_key_seed

  For j = 1 to n-1 do

   IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",

IMSK[j], 60)

   S-IMCK[j] = first 40 octets of IMCK[j]

   CMK[j] = last 20 octets of IMCK[j]

So we have two CMK[j] and we create Crypto-Binding TLV with both Compound MAC 
for MSK and EMSK. The client sends Crypto-Binding TLV in response and we can 
understand from it whether it supports EMSK for this inner method or not. And 
here we can decide which version of IMCK[j] to take for this inner method - 
derived from EMSK or MSK. This is just not explicitly specified in the RFC.

Could this method work? Should we make it more clearly specified? Or should we 
change the protocol to arrive explicitly to the understanding which type 
(MSK/EMSK) of IMSK[j] to use?

Thanks
Oleg


On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara 
mailto:40microsoft@dmarc.ietf.org>>
 wrote:
>Microsoft has already said that they won't rev their EAP-TLS implementation 
>until they can also rev PEAP.

PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the same 
time and will postpone TLS 1.3 support until such a time as we are able to make 
the updates together.

>* should the document drop references to TEAP?
> Given Jouni Malinen's comments on implementing TEAP, it may be worth simply 
> noting that we're waiting for a TEAP update document

I've reviewed the current errata, and acknowledge their validity, but am not 
sure that any of them would impact this document.

The most relevant errata to this document seems to be 
https://www.rfc-editor.org/errata/eid5770<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5770=02%7C01%7Cjovergar%40microsoft.com%7C5d8493e9a66549355c6508d7e1599c5f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637225647341455297=VWIJTVrYLPWmg6JOPrWbiwtUJGHktaFoxGusqldLHrg%3D=0>.
 As noted in the errata, the calculation of keys becomes confusing when methods 
export both MSK and EMSK because it is not clearly specified which value 
IMCK[j] should take on during the calculation of S-IMCK[j]. The addition of 
clarifying information is welcome, but I don't believe this ambiguity currently 
prevents a compliant implementation - for example, an implementation could 
avoid this ambiguity by choosing to use either the MSK/EMSK exclusively, and 
communicating that to the server via the Compound MAC TLV. The server can then 
make a policy decision on whether it is accepting of this decision by the 
client and follow suit, or reject the client.

The specifics of resolving this particular errata is a digression from my main 
point - I believe a clarification can be added to the main TEAP document at a 
future time without impacting the contents of this document. Ambiguity about 
which IMCK to use in S-IMCK calculation should not impact the definition of the 
cryptographic calculations.

On the document contents themselves, I have this review: The key derivation 
prop

Re: [Emu] draft-dekok-emu-tls-eap-types discussion

2020-04-07 Thread Jorge Vergara
>Microsoft has already said that they won't rev their EAP-TLS implementation 
>until they can also rev PEAP.

PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the same 
time and will postpone TLS 1.3 support until such a time as we are able to make 
the updates together.

>* should the document drop references to TEAP?
> Given Jouni Malinen's comments on implementing TEAP, it may be worth simply 
> noting that we're waiting for a TEAP update document

I've reviewed the current errata, and acknowledge their validity, but am not 
sure that any of them would impact this document.

The most relevant errata to this document seems to be 
https://www.rfc-editor.org/errata/eid5770. As noted in the errata, the 
calculation of keys becomes confusing when methods export both MSK and EMSK 
because it is not clearly specified which value IMCK[j] should take on during 
the calculation of S-IMCK[j]. The addition of clarifying information is 
welcome, but I don't believe this ambiguity currently prevents a compliant 
implementation - for example, an implementation could avoid this ambiguity by 
choosing to use either the MSK/EMSK exclusively, and communicating that to the 
server via the Compound MAC TLV. The server can then make a policy decision on 
whether it is accepting of this decision by the client and follow suit, or 
reject the client.

The specifics of resolving this particular errata is a digression from my main 
point - I believe a clarification can be added to the main TEAP document at a 
future time without impacting the contents of this document. Ambiguity about 
which IMCK to use in S-IMCK calculation should not impact the definition of the 
cryptographic calculations.

On the document contents themselves, I have this review: The key derivation 
proposed for TEAP/FAST uses the definition from FAST, which is not identical to 
the TEAP derivation. Namely, FAST used MSK[j] in the derivation, but TEAP uses 
IMSK[j], which may be equivalent in some cases, but may not in others where the 
inner method exports an EMSK.

Specifically, I believe this line of section 2.2 should change from
  IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys", 
S-IMCK[j-1] | MSK[j], 60)
To
  IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys", 
S-IMCK[j-1] | IMSK[j], 60)
For TEAP.

Jorge

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Friday, April 3, 2020 1:48 PM
To: EMU WG 
Subject: [Emu] draft-dekok-emu-tls-eap-types discussion

https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-01data=02%7C01%7Cjovergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215437188744711sdata=ndLp%2FSzsDlX%2FKYx0UR0uf77rHgCjGej4kdZPpywuD9Q%3Dreserved=0

  I haven't seen much discussion on the document.  There are still some open 
questions:

* should it be published simultaneously with draft-ietf-emu-eap-tls13?
   If so, we need some consensus on this document, and quick.

   If not, when do we publish this draft?  Microsoft has already said that they 
won't rev their EAP-TLS implementation until they can also rev PEAP.

* Should the document simply drop references to FAST?
  It looks like the effort has moved to TEAP.
  Perhaps we should note that FAST cannot be used with TLS 1.3, and that TEAP 
should be used instead

* should the document drop references to TEAP?
 Given Jouni Malinen's comments on implementing TEAP, it may be worth simply 
noting that we're waiting for a TEAP update document

* Without FAST / TEAP, the document is about 4 pages of text.  Is there 
anything controversial, missing, etc?

* What are the barriers to adoption and publication?

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215437188744711sdata=lkoHzd0fgN4z1oalqV2jW9pewUGSnlRLeKpiFew4Yw8%3Dreserved=0

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


Re: [Emu] TLS1.3 and TEAP (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

2019-11-08 Thread Jorge Vergara
> Since it looks like TEAP hasn't actually been implemented much, it's probably 
> best to move the TLS 1.3 fixes into a general "oops, we need to fix TEAP" 
> document.

I can understand the reasoning here, but it's my opinion that we should default 
to including TEAP changes for TLS1.3 in draft-dekok-emu-tls-eap-types. If the 
changes become lengthy or complex then I would understand moving them to a 
different document. But it's my belief that the currently proposed updates in 
draft-dekok-emu-tls-eap-types are sufficient. Are there further TEAP specific 
changes that are thought to be needed?

The latest Windows insider builds contain a TEAP implementation if you would 
like to play with another supplicant implementation.

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Thursday, November 7, 2019 9:50 AM
To: Owen Friel (ofriel) 
Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG ; John Mattsson 
; Michael Richardson 

Subject: Re: [Emu] TLS1.3 and TEAP (RE: POST WGLC Comments 
draft-ietf-emu-eap-tls13)

On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel)  wrote:
> 
> 
> [ofriel] Question to the WG: should the TEAP changes for TLS1.3 be included 
> in draft-dekok-emu-tls-eap-types?

  If they're minor, it may be OK.

> Or in draft-lear-eap-teap-brski - and note that the title is changed to " 
> TEAP Update and Extensions for Bootstrapping "? Or potentially both? Eliot, 
> Nancy and I had planned on adding TLS1.3 updates to 
> draft-lear-eap-teap-brski, but haven't got it done yet.

  Since it looks like TEAP hasn't actually been implemented much, it's probably 
best to move the TLS 1.3 fixes into a general "oops, we need to fix TEAP" 
document.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7Cff6d16a2debe42fe552608d763aade1d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637087458127841459sdata=uNLeQQn%2BPI2BAi1FweVNdKNG9MhBzxIu8oozlp%2F774s%3Dreserved=0

___
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-30 Thread Jorge Vergara
Hello - I am the primary maintainer of Microsoft's EAP implementation. I am 
sorry for joining late to this conversation, but hope our input is welcome.

On the topic of draft-dekok-emu-tls-eap-types:

I agree that it is necessary to standardize other TLS based EAP methods at the 
same time as EAP-TLS. The alternatives if this doesn't happen were discussed 
here previously at 
https://mailarchive.ietf.org/arch/msg/emu/J9Afcza1gOBQ_jww8E0yxSKPYeo - namely, 
either implementations will forge ahead with non-standard updates anyways, or 
they will be forced to wait to update EAP-TLS until the other methods are 
updated.

We are taking the second approach - we do not plan to update our EAP-TLS 
implementation until it is clear what the updates to other EAP methods will 
look like. We do not want to see non-standard vendor implementations to become 
difficult to implement de-facto standards. We would also like to see TEAP 
covered in this update.

A brief review on the material contained in the draft-dekok-emu-tls-eap-types:

I believe the 0x00 "Commitment message" not to send anymore TLS handshake data 
should be mentioned in this document, since it was established during 
https://mailarchive.ietf.org/arch/msg/emu/0MeocWZQLCv1pST5_2jW_ABlpMo that even 
tunnel based methods will need this.

The key derivation proposed for TEAP/FAST uses the definition from FAST, which 
is not identical to the TEAP derivation. Namely, FAST used MSK[j] in the 
derivation, but TEAP uses IMSK[j], which may be equivalent in some cases, but 
may not in others where the inner method exports an EMSK. I understand there 
may be a TEAP errata related to this and I may not be fully up to date on the 
errata discussion, so perhaps this is already taken into consideration.

Jorge Vergara

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Wednesday, October 30, 2019 4:12 AM
To: Eliot Lear 
Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson 
; Michael Richardson 
; EMU WG 
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

On Oct 30, 2019, at 5:02 AM, Eliot Lear  wrote:
> A fair argument, if it can be made, and I am not convinced it has been fully 
> expressed, is the idea that there is no context by which one can separate 
> fast restart and initial authentication.  This is Alan’s concern.  I’m not 
> saying it’s without merit, but what I cannot yet see is whether it is an 
> implementation or a protocol matter.

  I believe it's a protocol matter.  In TLS 1.3, PSK handshakes are the same as 
resumption handshakes.

  It's not clear to me how this issue was addressed when using TLS 1.3 with 
HTTPS.  But I do believe it's an issue there, too.

  As an additional note, I believe it's also important that 
draft-dekok-emu-tls-eap-types be published at the same time as the EAP-TLS 
document.  The only unknown there is FAST and TEAP.  I'm happy to remove them 
from the document.

  But at this point it's not even a WG document.  There's not even consensus 
that the document necessary, which surprises me rather a lot.  Because 
password-based EAP methods are *much* more wide-spread than EAP-TLS.

  If the IETF publishes EAP-TLS without simultaneously rev'ing TTLS and PEAP, 
it will not only look bad, it will *be* bad.  And the industry press will 
(rightfully) lambast the standards process.

  Alan DeKok.

___
Emu mailing list
Emu@ietf.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Femudata=02%7C01%7Cjovergar%40microsoft.com%7C68e3a65a1c3441c857cb08d75d2a038b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637080308161040037sdata=zrPr0rRh1bkV8rrF23SaAJYz6aFfuO3lTX9e6U1fOXw%3Dreserved=0
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu