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

[John Mattsson]

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

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



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


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

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

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


NoPostHandShake Extension


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

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

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

-

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

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

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

1. Saying that the handshake completed successfully

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

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


2. Saying that there will be no more messages

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

-Ekr

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

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

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

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

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

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

[Eric Rescorla]

On Thu, Feb 4, 2021 at 6:29 AM Eric Rescorla  wrote:

>
>
> On Thu, Feb 4, 2021 at 12:57 AM John Mattsson 
> wrote:
>
>> Hi,
>>
>>
>>
>> I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS
>> interact better is a very promising idea. This would probably take some
>> time to get specified and implemented so it is probably a future
>> optimization/simplification rather that something EAP-TLS 1.3 should wait
>> for.
>>
>>
>>
>> An extension that "I do not send any post-handshake messages" would work
>> and remove the need for a commitment message.
>>
>>
>>
>> 
>>
>> NoPostHandShake Extension
>>
>> 
>>
>>
>>
>> Clients MAY send this extension in ClientHello. It contains no data.
>>
>>
>>
>> Servers MAY send this extension in EncryptedExtentions. It contains no
>> data.
>>
>>
>>
>> When the "NoPostHandShake" extension is negotiated, the server MUST NOT
>> send any post handshake messages.
>>
>>
>>
>> -
>>
>>
>>
>> However, this would also stop the client from doing resumption which is
>> also very important. EAP-TLS fragments TLS into a large number of
>> round-trips, and database lookup to authorize clients is often slow, so
>> resumption is essential to get good performance.
>>
>>
>>
>> The current Post-Handshake NewSessionTicket is not well-suited for
>> EAP-TLS as is introduces the demand for the commitment message as well as
>> introducing an extra round-trip.
>>
>
> I don't really understand what EAP needs here, but it seems to me that the
> commitment message (or the close_notify) is serving two purposes:
>

> 1. Saying that the handshake completed successfully
>

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

-Ekr

2. Saying that there will be no more messages
>
> I understand from the discussion that knowing that there will be no more
> messages is useful. Do you think that the client knowing that the handshake
> completed is unnecessary?
>
> -Ekr
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Thu, Feb 4, 2021 at 12:57 AM John Mattsson 
wrote:

> Hi,
>
>
>
> I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS
> interact better is a very promising idea. This would probably take some
> time to get specified and implemented so it is probably a future
> optimization/simplification rather that something EAP-TLS 1.3 should wait
> for.
>
>
>
> An extension that "I do not send any post-handshake messages" would work
> and remove the need for a commitment message.
>
>
>
> 
>
> NoPostHandShake Extension
>
> 
>
>
>
> Clients MAY send this extension in ClientHello. It contains no data.
>
>
>
> Servers MAY send this extension in EncryptedExtentions. It contains no
> data.
>
>
>
> When the "NoPostHandShake" extension is negotiated, the server MUST NOT
> send any post handshake messages.
>
>
>
> -
>
>
>
> However, this would also stop the client from doing resumption which is
> also very important. EAP-TLS fragments TLS into a large number of
> round-trips, and database lookup to authorize clients is often slow, so
> resumption is essential to get good performance.
>
>
>
> The current Post-Handshake NewSessionTicket is not well-suited for EAP-TLS
> as is introduces the demand for the commitment message as well as
> introducing an extra round-trip.
>

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

1. Saying that the handshake completed successfully
2. Saying that there will be no more messages

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

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[John Mattsson]

Hi,

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

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


NoPostHandShake Extension


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

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

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

-

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

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

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


ImplicitTicket Extension


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

struct {
uint16 ticket_count_request;
} ImplicitTicketRequest;

With the ImplicitTicketRequest, the client requests ticket_count_request 
implicit tickets.

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

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

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

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

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

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

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

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

-

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

Cheers,
John


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

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



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

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

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

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

 There was discussion that 

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

[Joseph Salowey]

On Mon, Feb 1, 2021 at 8:23 PM Benjamin Kaduk  wrote:

> On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote:
> > On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk  wrote:
> > > That's a scenario that I was starting to puzzle over this weekend as
> well
> > > -- with EAP-Success "completely unauthenticated", it would be fairly
> easy
> > > for an on-path attacker to send the EAP-Success the EAP peer was
> expecting
> > > and make the EAP peer think things succeeded even if the server had
> > > rejected the client cert.
> >
> >   Yes.
> >
> > >  Now, a server that has rejected the client cert
> > > is hopefully not going to be exporting the keys and continuing to run
> the
> > > next steps of protocol operation, but to some extent it seems that the
> > > security of the system as a whole relies on the server operating
> correctly
> > > in this regard.
> >
> >   The TLS exporter keys are used for 802.1X / MacSec.  But they're not
> always used.
>
> Somehow I had convinced myself that the EMSK was only sometimes used, but
> MSK was always used.  If MSK is always used, then key confirmation of the
> MSK can play the role of handshake (and client authentication)
> confirmation, but otherwise I seem to be coming around to your "4.5 round
> trips is unavoidable" conclusion.  I'm not sure how clear-cut a distinction
> there is between cases that use the keys and those that don't, such that
> the last round trip could be shaved off when the exported key is used for
> key confirmation...
>
> > > ... it
> > > seems like a lot of what is being described as desired here ends up
> relying
> > > on ordering between application data and handshake messages.
> >
> >   I think there's no implementation issue here.  The draft should be
> clearer that there's no guaranteed ordering.
>
> I was going to stick this in a reply to Joe (at
> https://mailarchive.ietf.org/arch/browse/emu/), but maybe I can sneak it
> in
> here and save a message in everybody's inbox.
>
> My understanding (based on
> https://tools.ietf.org/html/rfc5216#section-2.1.5) is that EAP-TLS
> fragments TLS records, or in some cases, groups of records, and the first
> fragment includes a four-byte length field for the total message being
> fragmented.  Recalling that a given TLS record can only have payload of a
> single content type, in the scenario with a 0x00 confirmation message and a
> NewSessionTicket, that means one record with inner type application data
> and another record with inner type handshake.  If they are both grouped
> together to the EAP-TLS fragmentation engine, then I agree that there is no
> issue and a proper implementation should be waiting to reassemble the whole
> fragmented bundle, including both records, before finalizing processing.
> But is it also allowed to fragment the two records separately?  I didn't
> see anything that required the entire TLS flight of messages to be
> a single fragmentation input, and it's in the case that the 0x00 and
> NewSessionTicket are fragmented separately that the ordering becomes
> relevant -- if the 0x00 is fragmented first then the peer gets the complete
> fragmented message, sees the commitment message, and prepares its
> authentication flight in the EAP-Response, and based on the supposed
> commitment semantics would then somehow be expected to reject an
> EAP-Request with NewSessionTicket as breaking the commitment.  (Assuming it
> had a way to tell it was a handshake message at all, that is...)
>
> I'd love to hear what I am missing that makes the above incorrect, and/or
> that we have a way to require the NewSessionTicket and commitment message
> to be part of the same fragmentation unit.
>
>
[Joe] I would interpret the commitment message to mean that there are no
more handshake messages coming after completing the processing of this
entire EAP message.  An implementation should not stop processing the
packet in the middle of an EAP-TLS message, even if it is fragmented.  The
whole message should be consumed.


> > > (A lot of my hedging in messages on this thread is because I also don't
> > > really understand why the message is there.)
> > > I believe I read somewhere that it stemmed from the change in who
> speaks
> > > last in the TLS handshake, but am a bit hazy on how that implies it is
> > > needed.
> >
> >   I would like clarification on just what that message *means*.  If we
> want an explicit EAP layer signal that the server saw the client cert and
> authenticated it, then we MUST NOT send any such signal until after the
> server has seen the client cert.  And because the EAP-Success is sent all
> alone, we MUST then have another full round of TLS exchange, before the
> final EAP-Success.   i.e.
> >
> >
> > EAP-TLS Peer  EAP-TLS Server
> >
> >  EAP-Request/
> >  <  Identity
> > EAP-Response/
> > Identity (Privacy-Friendly)  

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

[Benjamin Kaduk]

On Mon, Feb 01, 2021 at 07:09:14AM -0500, Alan DeKok wrote:
> On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk  wrote:
> > That's a scenario that I was starting to puzzle over this weekend as well
> > -- with EAP-Success "completely unauthenticated", it would be fairly easy
> > for an on-path attacker to send the EAP-Success the EAP peer was expecting
> > and make the EAP peer think things succeeded even if the server had
> > rejected the client cert.
> 
>   Yes.
> 
> >  Now, a server that has rejected the client cert
> > is hopefully not going to be exporting the keys and continuing to run the
> > next steps of protocol operation, but to some extent it seems that the
> > security of the system as a whole relies on the server operating correctly
> > in this regard.
> 
>   The TLS exporter keys are used for 802.1X / MacSec.  But they're not always 
> used.

Somehow I had convinced myself that the EMSK was only sometimes used, but
MSK was always used.  If MSK is always used, then key confirmation of the
MSK can play the role of handshake (and client authentication)
confirmation, but otherwise I seem to be coming around to your "4.5 round
trips is unavoidable" conclusion.  I'm not sure how clear-cut a distinction
there is between cases that use the keys and those that don't, such that
the last round trip could be shaved off when the exported key is used for
key confirmation...

> > ... it
> > seems like a lot of what is being described as desired here ends up relying
> > on ordering between application data and handshake messages.
> 
>   I think there's no implementation issue here.  The draft should be clearer 
> that there's no guaranteed ordering.

I was going to stick this in a reply to Joe (at
https://mailarchive.ietf.org/arch/browse/emu/), but maybe I can sneak it in
here and save a message in everybody's inbox.

My understanding (based on
https://tools.ietf.org/html/rfc5216#section-2.1.5) is that EAP-TLS
fragments TLS records, or in some cases, groups of records, and the first
fragment includes a four-byte length field for the total message being
fragmented.  Recalling that a given TLS record can only have payload of a
single content type, in the scenario with a 0x00 confirmation message and a
NewSessionTicket, that means one record with inner type application data
and another record with inner type handshake.  If they are both grouped
together to the EAP-TLS fragmentation engine, then I agree that there is no
issue and a proper implementation should be waiting to reassemble the whole
fragmented bundle, including both records, before finalizing processing.
But is it also allowed to fragment the two records separately?  I didn't
see anything that required the entire TLS flight of messages to be
a single fragmentation input, and it's in the case that the 0x00 and
NewSessionTicket are fragmented separately that the ordering becomes
relevant -- if the 0x00 is fragmented first then the peer gets the complete
fragmented message, sees the commitment message, and prepares its
authentication flight in the EAP-Response, and based on the supposed
commitment semantics would then somehow be expected to reject an
EAP-Request with NewSessionTicket as breaking the commitment.  (Assuming it
had a way to tell it was a handshake message at all, that is...)

I'd love to hear what I am missing that makes the above incorrect, and/or
that we have a way to require the NewSessionTicket and commitment message
to be part of the same fragmentation unit.

> > (A lot of my hedging in messages on this thread is because I also don't
> > really understand why the message is there.)
> > I believe I read somewhere that it stemmed from the change in who speaks
> > last in the TLS handshake, but am a bit hazy on how that implies it is
> > needed.
> 
>   I would like clarification on just what that message *means*.  If we want 
> an explicit EAP layer signal that the server saw the client cert and 
> authenticated it, then we MUST NOT send any such signal until after the 
> server has seen the client cert.  And because the EAP-Success is sent all 
> alone, we MUST then have another full round of TLS exchange, before the final 
> EAP-Success.   i.e.
> 
> 
> EAP-TLS Peer  EAP-TLS Server
> 
>  EAP-Request/
>  <  Identity
> EAP-Response/
> Identity (Privacy-Friendly)  >
>  EAP-Request/
> EAP-Type=EAP-TLS
>  <(TLS Start)
> EAP-Response/
> EAP-Type=EAP-TLS
>(TLS ClientHello) >
>  EAP-Request/
> EAP-Type=EAP-TLS
> (TLS ServerHello,
>

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

[Benjamin Kaduk]

On Mon, Feb 01, 2021 at 02:52:58PM -0500, Alan DeKok wrote:
> On Feb 1, 2021, at 1:30 PM, Joseph Salowey  wrote:
> > [Joe] This could also address the early export of keys before the peer is 
> > authenticated. RFC 5216 provides a canonical way to create these IDs, but 
> > I'm not sure anyone follows it today
> 
>   FreeRADIUS does not officially expose Peer-Id or Server-Id.  But the 
> certificate subjectAltNames are available via the policy engine.  The greater 
> difficulty is *which* Id to use.
> 
>   RFC 5216 Section 5.2 says:
> 
>It is possible for more than one subjectAltName field to be present
>in a peer or server certificate in addition to an empty or non-empty
>subject distinguished name.  EAP-TLS implementations supporting
>export of the Peer-Id and Server-Id SHOULD export all the
>subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also
>export a non-empty subject distinguished name field within the Peer-
>Ids or Server-Ids.  All of the exported Peer-Ids and Server-Ids are
>considered valid.

I had missed that part of 5216 before.
While you're mostly stuck doing that sort of "all names in the cert are
deemed valid" for the TLS client certificate, since the server just asks
for *some* cert and has to handle what it gets back, that's not the normal
pattern for authenticating the server.  Consider, e.g., the RFC 6125
procedure, which takes as input to validation the name that the TLS client
was attempting to initiate communication towards.  Depending on the
application protocol that might be a DNS-ID or URI-ID or whatever, but
there's still a clear "I initiated communication towards this specific
named entity; can the server prove that it is that entity" which is very
much not "they proved possession of the private key; all names are
verified".  Even for the same server and same certificate, the answer can
be different for different names in the certificate.  (I am about to clear
a DISCUSS position on draft-ietf-quic-http for just this topic; the
historical HTTP semantics are in line with RFC 6125.  It is perhaps not
strictly required that the EAP usage do the same, but it is surprising, at
least.)

> > and it may be difficult to implement in practice due to ordering.  It might 
> > be simpler to just specify that the end entity peer and client certificates 
> > are used in the key derivation.  Most libraries provide APIs to get the raw 
> > certs.
> 
>   Yes.  We expose the certs to the policy engine, along with various fields.  
> Having the TLS exporter use more data should just be about updating some code.

I think that you get better security properties if you include the entire
certificates, but even just identities are better than nothing (provided
there is a clear unique ordering/encoding, as you note).

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

On Mon, Feb 1, 2021 at 12:04 PM Alan DeKok 
wrote:

> On Feb 1, 2021, at 3:00 PM, Joseph Salowey  wrote:
> > [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require
> CloseNotify.
>
>   With TLS 1.2, the server sends TLS Finished to the client *after* it
> sees the client cert.
>
>   With TLS 1.3, the server sends TLS Finished to the client *before* it
> sees the client cert.
>
>   So the question is: when the client sees EAP-Success, has it's
> certificate been verified?  If there's no more TLS exchange server ->
> client, then malicious parties can forge an EAP-Success, and the client
> doesn't know any better.
>
>   This attack isn't possible in TLS 1.2, because the client receives the
> TLS Finished from the server, as a *positive* acknowledgement that the
> server has authenticated the client.  In addition, the TLS exporter keys
> are not available until after the server sends TLS Finished.
>
>
[Joe]   There are some cases the finished will fail (math and path
problems), but  5216 allows for a different flow which is vulnerable to an
early EAP Success:

 In the case where the server authenticates to the peer successfully,
   but the peer fails to authenticate to the server, the conversation
   will appear as follows:

   Authenticating Peer Authenticator
   --- -
   <- EAP-Request/
   Identity
   EAP-Response/
   Identity (MyID) ->
   <- EAP-Request/
   EAP-Type=EAP-TLS
   (TLS Start)
   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS client_hello)->
   <- EAP-Request/
   EAP-Type=EAP-TLS
   (TLS server_hello,
 TLS certificate,
[TLS server_key_exchange,]
   TLS certificate_request,
 TLS server_hello_done)

   EAP-Response/
   EAP-Type=EAP-TLS
   (TLS certificate,
TLS client_key_exchange,
TLS certificate_verify,
TLS change_cipher_spec,
TLS finished) ->

   <- EAP-Request/
   EAP-Type=EAP-TLS
   (TLS change_cipher_spec,
   TLS finished)
   EAP-Response/
   EAP-Type=EAP-TLS ->
   <- EAP-Request
   EAP-Type=EAP-TLS
   (TLS Alert message)
   EAP-Response/
   EAP-Type=EAP-TLS ->
   <- EAP-Failure
   (User Disconnected)




>   With TLS 1.3, the exporter keys are available *before* the client cert
> has been validated.  This "fast path" helps with non-EAP protocols.  But
> makes life more difficult for EAP.
>
>
[Joe] We can use Ben's suggestion and make the exported keys depend on the
Peer and server's identities or certificates.  But if you are going to want
a protected result indication in EAP-TLS then you cannot end the early.
 5216 does not support protected result indicators, it's not clear to me if
implementations do or not.


>   Alan DeKok.
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Feb 1, 2021, at 2:48 PM, Jorge Vergara  wrote:
> 
> 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

  Prior versions *implicitly* relied on the server sending "TLS Finished" after 
the client certificate had been validated.

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

  We should ideally make the protocol robust to broken implementations.  RFC 
4137 was written to deal with implementations having these sort of issues in 
broken EAP state machines.

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

  Yes.

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

  True, but that's a bit of a separate issue.

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

  I agree.

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

  Presuming that we *do* need an explicit signal, which I think is true.  If we 
do need it, then the extra round trip is unavoidable.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Feb 1, 2021, at 3:00 PM, Joseph Salowey  wrote:
> [Joe] What purpose is the CloseNotify serving? RFC 5216 does not require 
> CloseNotify. 

  With TLS 1.2, the server sends TLS Finished to the client *after* it sees the 
client cert.

  With TLS 1.3, the server sends TLS Finished to the client *before* it sees 
the client cert.

  So the question is: when the client sees EAP-Success, has it's certificate 
been verified?  If there's no more TLS exchange server -> client, then 
malicious parties can forge an EAP-Success, and the client doesn't know any 
better.

  This attack isn't possible in TLS 1.2, because the client receives the TLS 
Finished from the server, as a *positive* acknowledgement that the server has 
authenticated the client.  In addition, the TLS exporter keys are not available 
until after the server sends TLS Finished.

  With TLS 1.3, the exporter keys are available *before* the client cert has 
been validated.  This "fast path" helps with non-EAP protocols.  But makes life 
more difficult for EAP.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

On Mon, Feb 1, 2021 at 11:55 AM Alan DeKok 
wrote:

> On Feb 1, 2021, at 2:32 PM, Joseph Salowey  wrote:
> >
> >
> >
> > On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok 
> wrote:
> > On Feb 1, 2021, at 11:26 AM, Eric Rescorla  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.
>
>   If the CloseNotify signal is sent by the server *after* it receives the
> client certs, then another round trip is required.  At least, according to
> Figure 1 of draft-13.
>
>   The CloseNotify can't be sent with the EAP-Success, because the
> EAP-Success can't carry data.  So the packet flow looks something like this:
>
>
[Joe] What purpose is the CloseNotify serving? RFC 5216 does not require
CloseNotify.


>EAP-TLS Peer  EAP-TLS Server
>
> EAP-Request/
> <  Identity
>EAP-Response/
>Identity (Privacy-Friendly)  >
> EAP-Request/
>EAP-Type=EAP-TLS
> <(TLS Start)
>EAP-Response/
>EAP-Type=EAP-TLS
>   (TLS ClientHello) >
> EAP-Request/
>EAP-Type=EAP-TLS
>(TLS ServerHello,
> TLS EncryptedExtensions,
>  TLS CertificateRequest,
> TLS Certificate,
>   TLS CertificateVerify,
> <---TLS Finished)
>EAP-Response/
>EAP-Type=EAP-TLS
>   (TLS Certificate,
>TLS CertificateVerify,
>TLS Finished)>
>
> EAP-Request/
>EAP-Type=EAP-TLS
> <(TLS CloseNotify)
>
>EAP-Response/
>EAP-Type=EAP-TLS
> (TLS Ack) >
> <   EAP-Success
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Feb 1, 2021, at 2:32 PM, Joseph Salowey  wrote:
> 
> 
> 
> On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok  wrote:
> On Feb 1, 2021, at 11:26 AM, Eric Rescorla  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.  

  If the CloseNotify signal is sent by the server *after* it receives the 
client certs, then another round trip is required.  At least, according to 
Figure 1 of draft-13.

  The CloseNotify can't be sent with the EAP-Success, because the EAP-Success 
can't carry data.  So the packet flow looks something like this:

   EAP-TLS Peer  EAP-TLS Server

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

EAP-Request/
   EAP-Type=EAP-TLS
<(TLS CloseNotify)

   EAP-Response/
   EAP-Type=EAP-TLS
(TLS Ack) >
<   EAP-Success
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Feb 1, 2021, at 1:30 PM, Joseph Salowey  wrote:
> [Joe] This could also address the early export of keys before the peer is 
> authenticated. RFC 5216 provides a canonical way to create these IDs, but I'm 
> not sure anyone follows it today

  FreeRADIUS does not officially expose Peer-Id or Server-Id.  But the 
certificate subjectAltNames are available via the policy engine.  The greater 
difficulty is *which* Id to use.

  RFC 5216 Section 5.2 says:

   It is possible for more than one subjectAltName field to be present
   in a peer or server certificate in addition to an empty or non-empty
   subject distinguished name.  EAP-TLS implementations supporting
   export of the Peer-Id and Server-Id SHOULD export all the
   subjectAltName fields within Peer-Ids or Server-Ids, and SHOULD also
   export a non-empty subject distinguished name field within the Peer-
   Ids or Server-Ids.  All of the exported Peer-Ids and Server-Ids are
   considered valid.

> and it may be difficult to implement in practice due to ordering.  It might 
> be simpler to just specify that the end entity peer and client certificates 
> are used in the key derivation.  Most libraries provide APIs to get the raw 
> certs.

  Yes.  We expose the certs to the policy engine, along with various fields.  
Having the TLS exporter use more data should just be about updating some code.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[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
TLS@ietf.org<mailto:TLS@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>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok 
wrote:

> On Feb 1, 2021, at 11:26 AM, Eric Rescorla  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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Feb 1, 2021, at 11:26 AM, Eric Rescorla  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.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

On Mon, Feb 1, 2021 at 9:12 AM Benjamin Kaduk  wrote:

> Hi Alan,
>
> I'll second the thanks for putting this together; I think it covers the
> important open points.
>
> I did belatedly remember one more thing that is perhaps not critical, but
> would also be good to get an answer for:
>
> On Fri, Jan 29, 2021 at 03:00:51PM -0500, Alan DeKok wrote:
> [...]
> >
> > DISCUSS: other than word-smithing the above points, are there serious
> objections to the behaviour documented in -13?  i.e. does the IETF want to
> recommend that EAP-TLS alpha testing begins *now*, or should it wait until
> 2022?
>
> I think that an exchange between Martin and Mohit raised the question of
> whether the EAP server-id and peer-id would be available for use in the
> 'context' argument of the TLS Exporter, as that would help strengthen the
> binding between keys and the authentication exchange.
> I do recall a mention that WolfSSL doesn't support a context argument for
> the exporter, but I don't know how prohibitive that limitation would be in
> practice.
>
>
[Joe] This could also address the early export of keys before the peer is
authenticated. RFC 5216 provides a canonical way to create these IDs, but
I'm not sure anyone follows it today and it may be difficult to implement
in practice due to ordering.  It might be simpler to just specify that the
end entity peer and client certificates are used in the key derivation.
Most libraries provide APIs to get the raw certs.
It looks like the WolfSSL API that Mohit linked is specifically for RFC5216
EAP keys and not a general exporter API.  I'm not sure if they have a
general exporter API.


> -Ben
>
> ___
> Emu mailing list
> e...@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

Hi Alan,

I'll second the thanks for putting this together; I think it covers the
important open points.

I did belatedly remember one more thing that is perhaps not critical, but
would also be good to get an answer for:

On Fri, Jan 29, 2021 at 03:00:51PM -0500, Alan DeKok wrote:
[...]
> 
> DISCUSS: other than word-smithing the above points, are there serious 
> objections to the behaviour documented in -13?  i.e. does the IETF want to 
> recommend that EAP-TLS alpha testing begins *now*, or should it wait until 
> 2022?

I think that an exchange between Martin and Mohit raised the question of
whether the EAP server-id and peer-id would be available for use in the
'context' argument of the TLS Exporter, as that would help strengthen the
binding between keys and the authentication exchange.
I do recall a mention that WolfSSL doesn't support a context argument for
the exporter, but I don't know how prohibitive that limitation would be in
practice.

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Mon, Feb 1, 2021 at 8:22 AM Alan DeKok  wrote:

> On Feb 1, 2021, at 11:09 AM, Eric Rescorla  wrote:
> > That's not what I'm proposing. I'm only talking about the case where the
> server says this after flight (2).
>
>   OK, my misreading of the text.
>
> > Right. But close_notify is the message that more matches the TLS
> semantics.
>
>   I agree.
>
> > Ignoring the protocol mechanics, let's just talk about what signals you
> think the client ought to want to receive. The two I am aware of are:
> >
> > 1. From the server's perspective, the TLS handshake is complete.
> > 2. The server will not be sending any more handshake messages to the
> client.
> >
> > When client authentication is being used, then for obvious reasons (1)
> cannot be delivered prior to the server receiving and processing the
> client's certificate. Agreed?
>
>   Yes.
>
> > Indeed, this seems like a problem with the flow shown in Figure 1,
> because the server sends Commitment prior to reading the client's cert.
>
>   Yes.
>
> > ISTM that the relevant question is when one might want to receive (2).
> In particular, when would the client want to learn that the server will not
> send any more handshake messages when the client has second flight
> handshake messages still outstanding? Can you explain to me how this is
> useful?
>
>   I'm just trying to summarize the discussion so far, and get
> clarification on exactly what we're trying to do. So take what I say with a
> grain of salt... I didn't write the text in the current draft.
>
>   The main issue I can see where (2) might be useful is to deal with TLS
> 1.3's separation of "TLS finished" from other handshake messages.  If the
> SessionTicket message comes *after* "TLS finished", then it might be in a
> separate EAP packet.  The client doesn't know that there's an additional
> handshake until it receives that message.
>
>   So an explicit CloseNotify sent by the server *after* receiving the
> client certificate would seem useful.  It's an authenticated message saying
> "yes, I agree we're done".
>
>   If the client cert has issues, the server can send TLS alerts *before*
> the CloseNotify.  So the client has to either wait for those, OR an
> explicit CloseNotify, to see if it's (a) rejected, or (b) authenticated
>

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?

-Ekr

  Alan DeKok.
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Feb 1, 2021, at 11:09 AM, Eric Rescorla  wrote:
> That's not what I'm proposing. I'm only talking about the case where the 
> server says this after flight (2).

  OK, my misreading of the text.

> Right. But close_notify is the message that more matches the TLS semantics.

  I agree.

> Ignoring the protocol mechanics, let's just talk about what signals you think 
> the client ought to want to receive. The two I am aware of are:
> 
> 1. From the server's perspective, the TLS handshake is complete.
> 2. The server will not be sending any more handshake messages to the client.
> 
> When client authentication is being used, then for obvious reasons (1) cannot 
> be delivered prior to the server receiving and processing the client's 
> certificate. Agreed?

  Yes.

> Indeed, this seems like a problem with the flow shown in Figure 1, because 
> the server sends Commitment prior to reading the client's cert.

  Yes.

> ISTM that the relevant question is when one might want to receive (2).  In 
> particular, when would the client want to learn that the server will not send 
> any more handshake messages when the client has second flight handshake 
> messages still outstanding? Can you explain to me how this is useful?

  I'm just trying to summarize the discussion so far, and get clarification on 
exactly what we're trying to do. So take what I say with a grain of salt... I 
didn't write the text in the current draft.

  The main issue I can see where (2) might be useful is to deal with TLS 1.3's 
separation of "TLS finished" from other handshake messages.  If the 
SessionTicket message comes *after* "TLS finished", then it might be in a 
separate EAP packet.  The client doesn't know that there's an additional 
handshake until it receives that message.

  So an explicit CloseNotify sent by the server *after* receiving the client 
certificate would seem useful.  It's an authenticated message saying "yes, I 
agree we're done".

  If the client cert has issues, the server can send TLS alerts *before* the 
CloseNotify.  So the client has to either wait for those, OR an explicit 
CloseNotify, to see if it's (a) rejected, or (b) authenticated

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Mon, Feb 1, 2021 at 7:42 AM Alan DeKok  wrote:

> On Feb 1, 2021, at 9:55 AM, Eric Rescorla  wrote:
> > Let's take the second case first. If the server is sending (or
> > potentially sending) post-handshake messages after the client's second
> > flight (e.g., after reading its certificate), then it can easily send
> > a close_notify after sending all of them. This will appear in the same
> > flight as the commitment message would have (because you can't send it
> > before the post-handshake messages) and avoid the need for an extra
> > round trip.
>
>   That use of CloseNotify would be before the server receives the client
> certificates.  It prevents the server from sending TLS alerts for
> certificate errors (expired, unknown CA, etc).  That would be an
> unmitigated disaster for deployments.
>

That's not what I'm proposing. I'm only talking about the case where the
server says this after flight (2).


  The CloseNotify *could* be sent after the server receives the client
> certs.  But that still means another full round of EAP, before the final
> EAP-Success.  So from that view, there's no difference between CloseNotify
> and an explicit commitment message.
>

Right. But close_notify is the message that more matches the TLS semantics.


> > The first case, where the commitment message is sent in 0.5-RTT,
> > is the interesting one. However, the server has no more information
> > after sending SFIN than it does sending EE, so I believe that the
> > easiest way to deal with this is with a TLS extension that says
> > "I do not send any post-handshake messages". This would still
> > leave the server free to send any relevant alerts in response to
> > the client's second flight.
>
>   Except that if the server likes the client cert, Figure 1 of draft-13
> shows the next packet is EAP-Success.  So the client has no *authenticated*
> way of telling that it has been authenticated.  Any party to the
> conversation could send a blank EAP-Success (which is 4 bytes of
> unauthenticated data).  And thus break EAP-TLS.
>

I fear we are talking past each other.

Ignoring the protocol mechanics, let's just talk about what signals you
think the client ought to want to receive. The two I am aware of are:

1. From the server's perspective, the TLS handshake is complete.
2. The server will not be sending any more handshake messages to the client.

When client authentication is being used, then for obvious reasons (1)
cannot be delivered prior to the server receiving and processing the
client's certificate. Agreed? Indeed, this seems like a problem with the
flow shown in Figure 1, because the server sends Commitment prior to
reading the client's cert.

ISTM that the relevant question is when one might want to receive (2).  In
particular, when would the client want to learn that the server will not
send any more handshake messages when the client has second flight
handshake messages still outstanding? Can you explain to me how this is
useful?

-Ekr


>   Alan DeKok.
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Feb 1, 2021, at 9:55 AM, Eric Rescorla  wrote:
> Let's take the second case first. If the server is sending (or
> potentially sending) post-handshake messages after the client's second
> flight (e.g., after reading its certificate), then it can easily send
> a close_notify after sending all of them. This will appear in the same
> flight as the commitment message would have (because you can't send it
> before the post-handshake messages) and avoid the need for an extra
> round trip.

  That use of CloseNotify would be before the server receives the client 
certificates.  It prevents the server from sending TLS alerts for certificate 
errors (expired, unknown CA, etc).  That would be an unmitigated disaster for 
deployments.

  The CloseNotify *could* be sent after the server receives the client certs.  
But that still means another full round of EAP, before the final EAP-Success.  
So from that view, there's no difference between CloseNotify and an explicit 
commitment message.

> The first case, where the commitment message is sent in 0.5-RTT,
> is the interesting one. However, the server has no more information
> after sending SFIN than it does sending EE, so I believe that the
> easiest way to deal with this is with a TLS extension that says
> "I do not send any post-handshake messages". This would still
> leave the server free to send any relevant alerts in response to
> the client's second flight.

  Except that if the server likes the client cert, Figure 1 of draft-13 shows 
the next packet is EAP-Success.  So the client has no *authenticated* way of 
telling that it has been authenticated.  Any party to the conversation could 
send a blank EAP-Success (which is 4 bytes of unauthenticated data).  And thus 
break EAP-TLS.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

>Asking as the author of a TLS library that has always done this, why would 
> you
stop immediately after the Finished and leave metadata messages sitting 
unread
in the input stream?  Was it just some arbitrary implementation decision, or
is there a technical reason for it?

The mistaken belief that applications really wanted to control all the knobs 
and flow of control of the protocol.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok 
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


I agree that extra round trips are bad, I'd like to take a step back
here and think about what this message is trying to do. Here's
the relevant text:

   TLS 1.3 [RFC8446] introduces Post-Handshake messages.  These Post-
   Handshake messages use the handshake content type and can be sent
   after the main handshake.  One such Post-Handshake message is
   NewSessionTicket.  The NewSessionTicket can be used for resumption.
   After sending TLS Finished, the EAP-TLS server may send any number of
   Post-Handshake messages in separate EAP-Requests.

The relevant question is when the server knows what post-handshake
messages it will send. There are two points at which the server might
wish to send post-handshake messages:

1. After the server's first flight.
2. After the client's second flight.

Let's take the second case first. If the server is sending (or
potentially sending) post-handshake messages after the client's second
flight (e.g., after reading its certificate), then it can easily send
a close_notify after sending all of them. This will appear in the same
flight as the commitment message would have (because you can't send it
before the post-handshake messages) and avoid the need for an extra
round trip.

The first case, where the commitment message is sent in 0.5-RTT,
is the interesting one. However, the server has no more information
after sending SFIN than it does sending EE, so I believe that the
easiest way to deal with this is with a TLS extension that says
"I do not send any post-handshake messages". This would still
leave the server free to send any relevant alerts in response to
the client's second flight.

-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Jan 31, 2021, at 9:16 PM, Benjamin Kaduk  wrote:
> That's a scenario that I was starting to puzzle over this weekend as well
> -- with EAP-Success "completely unauthenticated", it would be fairly easy
> for an on-path attacker to send the EAP-Success the EAP peer was expecting
> and make the EAP peer think things succeeded even if the server had
> rejected the client cert.

  Yes.

>  Now, a server that has rejected the client cert
> is hopefully not going to be exporting the keys and continuing to run the
> next steps of protocol operation, but to some extent it seems that the
> security of the system as a whole relies on the server operating correctly
> in this regard.

  The TLS exporter keys are used for 802.1X / MacSec.  But they're not always 
used.

> ... it
> seems like a lot of what is being described as desired here ends up relying
> on ordering between application data and handshake messages.

  I think there's no implementation issue here.  The draft should be clearer 
that there's no guaranteed ordering.

> (A lot of my hedging in messages on this thread is because I also don't
> really understand why the message is there.)
> I believe I read somewhere that it stemmed from the change in who speaks
> last in the TLS handshake, but am a bit hazy on how that implies it is
> needed.

  I would like clarification on just what that message *means*.  If we want an 
explicit EAP layer signal that the server saw the client cert and authenticated 
it, then we MUST NOT send any such signal until after the server has seen the 
client cert.  And because the EAP-Success is sent all alone, we MUST then have 
another full round of TLS exchange, before the final EAP-Success.   i.e.


EAP-TLS Peer  EAP-TLS Server

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

 EAP-Request/
EAP-Type=EAP-TLS
 <(TLS Commitment Message)

EAP-Response/
EAP-Type=EAP-TLS
 (TLS Ack) >
 <   EAP-Success

  In that scenario, the commitment message *does* have a purpose:

*  It was not needed in TLS 1.2, because the "TLS Finished" message from the 
server came after the server saw the client cert. 
*  In TLS 1.3, that behaviour has changed
* so the *implicit* meaning of "server sends TLS finished" is no longer "server 
has seen client cert"
*  Since EAP-TLS wishes to authenticate the client cert, it MUST have an EAP 
state after the "TLS Finished" message
*  Since EAP-TLS does not provide for any data exchanged in the EAP layer, any 
data MUST be mangled into TLS
* and the only possibility is TLS application data.

  I'd like to know if any of these assumptions are false.

  If all this is true, then the 3.5 round EAP-TLS goal is impossible.

> I don't disagree with what you say, but I will note that if we are seeing a
> conflict between a desire to ship something ASAP and uncertainty that the
> current specification is fully correct, it's easy process-wise to allocate
> a new type code for people to ship "now" without locking in behavior for
> 0x0d.  Whether we call it an early allocation, an experimental usage, or a
> normal allocation via specification required doesn't seem terribly
> important (and given that Joe is the expert and he basically suggested it,
> I suspect that allocation would occur quite quickly after a request).
> How easy it would be to get things back onto 0x0d in the future is less
> clear, though.

  As an implementor, I fervently hope to *not* support an "ad hoc" EAP type for 
the next 10 years.

  My preference is to get this right, even it means more delays.

  Alan DeKok.

___

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

[Alan DeKok]

On Feb 1, 2021, at 1:00 AM, Joseph Salowey  wrote:
[ re: commitment message ]

> [Joe]  I'm not sure why it's needed. It's not clear to me why the peer can't 
> hold the TLS session open until it receives more TLS messages (handshake or 
> alert) or an EAP failure or EAP Success.  

  I suspect that it can.

  The larger issue for me is that in EAP + TLS 1.2, the "TLS Finished" message 
comes after the client certificate has been validated.  See Page 6 of 
https://tools.ietf.org/html/rfc5216

  In EAP + TLS 1.3, the proposal is that the "TLS Finished" message comes 
before the client certificate has been validated.

  To me, this means that the client has absolutely no idea whether or not it's 
certificate has been verified.  Any malicious actor could forge an EAP-Success 
(as it is entirely unauthenticated).  This seems to be a major difference from 
TLS 1.2, and potentially a major problem.

  There is a goal to get EAP-TLS working in 3.5 rounds.  That's a good goal, 
but I'd like to be sure that it doesn't come at the expense of security.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

On Mon, Feb 01, 2021 at 06:21:16AM +, Peter Gutmann wrote:
> Alan DeKok  writes:
> 
> >OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages
> >*after* the Finished message. i.e. the Session Ticket, etc. When an
> >application calls SSL_Read(), all of the TLS data is processed, instead of
> >just the "TLS finished" message. They've made this the default, because most
> >applications get it wrong.
> 
> Asking as the author of a TLS library that has always done this, why would you
> stop immediately after the Finished and leave metadata messages sitting unread
> in the input stream?  Was it just some arbitrary implementation decision, or
> is there a technical reason for it?

I expect (but did not attempt to validate) that this was SSLeay-vintage logic
involving only reading a single record from the wire per call to
SSL_read().  If that record was a handshake record and not application
data, well, then the SSL_read() didn't do something useful and so the
special "try again" code was returned and the application was supposed to
call SSL_read() again.

There's no technical reason that I'm aware of.

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Peter Gutmann]

Alan DeKok  writes:

>OpenSSL has a feature SSL_MODE_AUTO_RETRY which makes it process TLS messages
>*after* the Finished message. i.e. the Session Ticket, etc. When an
>application calls SSL_Read(), all of the TLS data is processed, instead of
>just the "TLS finished" message. They've made this the default, because most
>applications get it wrong.

Asking as the author of a TLS library that has always done this, why would you
stop immediately after the Finished and leave metadata messages sitting unread
in the input stream?  Was it just some arbitrary implementation decision, or
is there a technical reason for it?

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

On Sun, Jan 31, 2021 at 6:17 PM Benjamin Kaduk  wrote:

> On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote:
> > On Jan 29, 2021, at 5:00 PM, Joseph Salowey  wrote:
> > > DISCUSS: the EAP-TLS draft should also explain that session tickets
> may be sent either before or after the 0x00 octet.  Does the packet flow
> look any different for the two cases?  If so, what does that mean?
> > >
> > > [Joe] I believe the flow of the message flights would be the same, but
> the on-the-wire format of those flights could be reversed.  I don't think
> this will necessarily cause a problem since the application data is
> consumed by the EAP TLS and the NewSessionTicket is consumed by TLS,
> However I think the draft should be clear that this can happen.
> >
> >   I think so, too.
>
> I think we should talk about that, yes.
> But I haven't managed to convince myself yet that it is 100% safe in the
> face of fragmentation -- can we rule out a case where we end up delivering
> an EAP-TLS message that ends exactly at the end of the application data
> record (say, if bundled along with the tail end of the server handshake
> flight) and there is a NewSessionTicket queued that would get fragmented
> into the next EAP-TLS message?
>
>
[Joe] As Alan points out, the peer should parse all fragments to get the
complete message and pass them all to the TLS layer.  It would be good to
call this out, but I don't think it should be a problem for
implementations.  For example, if the peer is notified that application
data is available before it has finished passing all the data to the TLS
layer it should pass the rest of the data to the TLS layer before
responding.


> > > DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note
> that this examples does not include Session Tickets.  Section 2.1.2 should
> be updated to note that there are more rounds than for the previous section.
> > >
> > > [Joe] Yes.  It might be helpful to say that the commitment message may
> be sent before or after the client authentication is verified, but in the
> case that resumption is used it will always be after.
> >
> >   I think that's a good idea.  The current draft doesn't make this
> explicit.
> >
> >   But... if the commitment message is sent before the client
> certificates have been authenticated, what does that commitment message
> *mean*?
> >
> >   i.e. can the server send the commitment message, ignore the client
> cert information, and send an EAP-Success?  Even if the client certs have
> expired, been revoked, etc.?  Can the client detect a rogue server which
> always answers "yes"?
>
> That's a scenario that I was starting to puzzle over this weekend as well
> -- with EAP-Success "completely unauthenticated", it would be fairly easy
> for an on-path attacker to send the EAP-Success the EAP peer was expecting
> and make the EAP peer think things succeeded even if the server had
> rejected the client cert.  Now, a server that has rejected the client cert
> is hopefully not going to be exporting the keys and continuing to run the
> next steps of protocol operation, but to some extent it seems that the
> security of the system as a whole relies on the server operating correctly
> in this regard.  Strictlys speaking, it need not do so -- we could have
> defined a mechanism where the exported keys depend, cryptographically, on
> the client authentication flight such that the TLS layer will not produce
> the needed keys on failed authentication. [0]
>
> [Joe] This could be also a difference between EAP-TLS 1.2 and EAP-TLS
1.3.  In 1.2, the server's finished came second so, if the server rejected
the peer certificate it could abort before sending the finished and the
client's state machine would not be able to continue.  However, 5216
section 2.1.3, suggests that errors should be sent after the finished which
means they could be removed from the conversation and the peer would be
none the wiser.   It seems the behavior between 1.2 and 1.3 would be
similar in this regard.

I'm assuming that people will not be terribly keen on switching to such a
> scheme given that (AFAIK) it would require defining a new TLS 1.3 Exporter
> variant that includes the full transcript hash, [1] not just up to Server
> Finished, which would incur at a minimum several months' delay.  It might
> be worth asking the teams that did formal analysis work on TLS 1.3 how they
> modelled client authentication and what assumptions on server behavior they
> made.
>
> So, if we do not wait for a cryptographic method to assure successful
> client authentication, and thus are going to be stuck requiring some amount
> of trust that the server is doing the right thing with the keys, how is it
> different to say that the server is going to not export the keys if the
> client authentication fails vs saying that the server is going to not
> export the keys if it is not done sending handshake messages?  There is
> perhaps some detail in terms of how EAP-TLS interacts with 

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

[Benjamin Kaduk]

Hi Alan,

With my apologies to everyone on the thread for so many mails in
succession...

On Fri, Jan 29, 2021 at 02:09:09PM -0500, Alan DeKok wrote:
> On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk  wrote:
> > With respect to the exporter usage, I do see you had asked about using the
> > type-code as the exporter context value that Martin didn't see much value
> > in, but I am willing to accept that as a boon for safety of portability to
> > other TLS-using EAP mechanisms.
> 
>   OK. 
> 
> >  (I do note that the current editor's copy
> > shows calls to TLS-Exporter() with only two arguments, but three are
> > required; the construction there also seems to include a propspect for
> > violation of the requirement that "one label is not a prefix of any other
> > label" when both regular one-byte and extended type codes are used, but if
> > the type code is meant to be the context argument I believe that risk goes
> > away.)
> 
>   The EAP type codes are one octet: 0x00 through 0xfd.  The "expanded" type 
> codes begin with 0xfe.  So there is no prefix issue, even if the type codes 
> form part of the label.

Ah, of course I should have realized that the 0xfe octet separates them.
You are correct; there is no issue with prefixes, and sorry for the
confusion.

Thanks,

Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

Hi Mohit,

The quoting in your note is not coming across usefully in my MUA, so I'm
trimming to (what I think are) just your remarks without other history.

On Fri, Jan 29, 2021 at 07:34:42PM +, Mohit Sethi M wrote:
> Hi Ben,
> 
> RFC 5705 says:
> 
>If no context is provided, it then computes:
> 
>PRF(SecurityParameters.master_secret, label,
>SecurityParameters.client_random +
>SecurityParameters.server_random
>)[length]
> 
>If context is provided, it computes:
> 
>PRF(SecurityParameters.master_secret, label,
>SecurityParameters.client_random +
>SecurityParameters.server_random +
>context_value_length + context_value
>)[length]
> 
> 
> We use only two arguments and say "No context data is used in the TLS 
> exporter interface.". We could show the context argument as empty in the 
> calls to make things clearer. By the way, this is what is done by TEAP also. 
> RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters defined 
> in [RFC5705] to derive the session_key_seed.  The label used in the 
> derivation is "EXPORTER: teap session key seed".  The length of the session 
> key seed material is 40 octets.  No context data is used in the export 
> process."

We're using the TLS 1.3 exporter, though, so the RFC 8446
(https://www.rfc-editor.org/rfc/rfc8446.html#section-7.5) three-argument
form seems most relevant.  Note that there is no difference in TLS 1.3
between an absent context and a zero-length context.

> The change of moving the type-code from the context to the label was made 
> based on your review (comments from Martin) and the fact that some libraries 
> such as wolfssl don't support passing a context (so far). See: 
> https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996

I'm not going to get super hung-up on label vs context (but it's clearly a bug
if WolfSSL doesn't support contexts).  I guess Martin even wanted the type code
to be in the label part in the first place, so having it in the label is
"better"; we just need to actually show that there's an empty context
argument.

> I think there was a misunderstanding that an authenticated signal of 
> authentication completed was needed. Only a signal of no more post handshake 
> messages was needed. I think Alan's summary might also explain the situation 
> better.

I note that Alan seems to also be a bit unclear about exactly what purpose
the commitment message serves; I look forward to seeing how the questions
he has listed get answered.

Thanks,

Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

On Sun, Jan 31, 2021 at 09:20:57AM -0500, Alan DeKok wrote:
> On Jan 29, 2021, at 5:00 PM, Joseph Salowey  wrote:
> > DISCUSS: the EAP-TLS draft should also explain that session tickets may be 
> > sent either before or after the 0x00 octet.  Does the packet flow look any 
> > different for the two cases?  If so, what does that mean?
> > 
> > [Joe] I believe the flow of the message flights would be the same, but the 
> > on-the-wire format of those flights could be reversed.  I don't think this 
> > will necessarily cause a problem since the application data is consumed by 
> > the EAP TLS and the NewSessionTicket is consumed by TLS,  However I think 
> > the draft should be clear that this can happen.  
> 
>   I think so, too.

I think we should talk about that, yes.
But I haven't managed to convince myself yet that it is 100% safe in the
face of fragmentation -- can we rule out a case where we end up delivering
an EAP-TLS message that ends exactly at the end of the application data
record (say, if bundled along with the tail end of the server handshake
flight) and there is a NewSessionTicket queued that would get fragmented
into the next EAP-TLS message?

> > DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that 
> > this examples does not include Session Tickets.  Section 2.1.2 should be 
> > updated to note that there are more rounds than for the previous section.
> > 
> > [Joe] Yes.  It might be helpful to say that the commitment message may be 
> > sent before or after the client authentication is verified, but in the case 
> > that resumption is used it will always be after.  
> 
>   I think that's a good idea.  The current draft doesn't make this explicit.
> 
>   But... if the commitment message is sent before the client certificates 
> have been authenticated, what does that commitment message *mean*?
> 
>   i.e. can the server send the commitment message, ignore the client cert 
> information, and send an EAP-Success?  Even if the client certs have expired, 
> been revoked, etc.?  Can the client detect a rogue server which always 
> answers "yes"?

That's a scenario that I was starting to puzzle over this weekend as well
-- with EAP-Success "completely unauthenticated", it would be fairly easy
for an on-path attacker to send the EAP-Success the EAP peer was expecting
and make the EAP peer think things succeeded even if the server had
rejected the client cert.  Now, a server that has rejected the client cert
is hopefully not going to be exporting the keys and continuing to run the
next steps of protocol operation, but to some extent it seems that the
security of the system as a whole relies on the server operating correctly
in this regard.  Strictlys speaking, it need not do so -- we could have
defined a mechanism where the exported keys depend, cryptographically, on
the client authentication flight such that the TLS layer will not produce
the needed keys on failed authentication. [0]

I'm assuming that people will not be terribly keen on switching to such a
scheme given that (AFAIK) it would require defining a new TLS 1.3 Exporter
variant that includes the full transcript hash, [1] not just up to Server
Finished, which would incur at a minimum several months' delay.  It might
be worth asking the teams that did formal analysis work on TLS 1.3 how they
modelled client authentication and what assumptions on server behavior they
made.

So, if we do not wait for a cryptographic method to assure successful
client authentication, and thus are going to be stuck requiring some amount
of trust that the server is doing the right thing with the keys, how is it
different to say that the server is going to not export the keys if the
client authentication fails vs saying that the server is going to not
export the keys if it is not done sending handshake messages?  There is
perhaps some detail in terms of how EAP-TLS interacts with the TLS layer
and what information is available when, but it seems that if you have an
interface with TLS of "provide input bytes; get output bytes out" [2] you
could achieve this by not exporting keys until you've sent all those bytes
into EAP-TLS messages.


>   RFC 4137 (https://tools.ietf.org/html/rfc4137) describes a state machine 
> for EAP peer and server.  Does this work follow that?

A good question!

> > [Joe]  If we are going to make a change in the key derivation we should do 
> > it now.  Personally, I think we should update the key derivation to 
> > separate the MSK and EMSK, but it is workable as is.  
> > I think there are potential issues around the ordering of the 0x00 octet 
> > and other messages, but I don't think this will require changes to 
> > implementations in the short term, but the spec needs to clarify this. 
> 
>   I agree.

I wonder if (assuming that 0x00 goes forward instead of "close_notify") we
should also go further and say that this mechanism does not use stock TLS
1.3, but rather a variant of the protocol that imposes an 

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

[Alan DeKok]

On Jan 29, 2021, at 5:00 PM, Joseph Salowey  wrote:
> DISCUSS: the EAP-TLS draft should also explain that session tickets may be 
> sent either before or after the 0x00 octet.  Does the packet flow look any 
> different for the two cases?  If so, what does that mean?
> 
> [Joe] I believe the flow of the message flights would be the same, but the 
> on-the-wire format of those flights could be reversed.  I don't think this 
> will necessarily cause a problem since the application data is consumed by 
> the EAP TLS and the NewSessionTicket is consumed by TLS,  However I think the 
> draft should be clear that this can happen.  

  I think so, too.

> DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that this 
> examples does not include Session Tickets.  Section 2.1.2 should be updated 
> to note that there are more rounds than for the previous section.
> 
> [Joe] Yes.  It might be helpful to say that the commitment message may be 
> sent before or after the client authentication is verified, but in the case 
> that resumption is used it will always be after.  

  I think that's a good idea.  The current draft doesn't make this explicit.

  But... if the commitment message is sent before the client certificates have 
been authenticated, what does that commitment message *mean*?

  i.e. can the server send the commitment message, ignore the client cert 
information, and send an EAP-Success?  Even if the client certs have expired, 
been revoked, etc.?  Can the client detect a rogue server which always answers 
"yes"?

  RFC 4137 (https://tools.ietf.org/html/rfc4137) describes a state machine for 
EAP peer and server.  Does this work follow that?

> [Joe]  If we are going to make a change in the key derivation we should do it 
> now.  Personally, I think we should update the key derivation to separate the 
> MSK and EMSK, but it is workable as is.  
> I think there are potential issues around the ordering of the 0x00 octet and 
> other messages, but I don't think this will require changes to 
> implementations in the short term, but the spec needs to clarify this. 

  I agree.

  There's also the question of *why* the commitment message is there.  It's not 
in EAP-TLS for TLS 1.2.  The draft doesn't explain why it's not needed in TLS 
1.2, but is needed for TLS 1.3.  Such an explanation would go a long way to 
clarifying many issues around the commitment message.

>   So if we later discover that EAP-TLS is flawed, we can only deprecated 
> EAP-TLS, and create a new EAP-TLS "prime", with a new EAP type code.
> 
> [Joe] Perhaps we could use an expanded EAP-Type for the alpha? Or perhaps 
> experimental or a temporary experimental allocation could be made (not sure 
> if that would be possible). 

  I think the issue for MS is less "alpha" code than "shipping" code.  If we 
use an experimental type, it doesn't matter if it's interoperable, because 
people won't deploy it in production.  Implementors are already verifying code 
behind the scenes in builds which aren't shipped to customers.  So the type 
code is less of an issue, because that interoperability is "inter-engineer", 
and not "inter-customer".

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[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: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Joseph Salowey]

HI Alan,

THanks for this message, comments inline below:

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok 
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
>
>   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 send a
> 0x00 octet, and then the TLS state machines sends that *before* a Session
> Ticket.
>
>   In addition, RFC 8446 Figure 1 shows that application data can be sent
> by the server to the client, *before* the client certificate is sent to the
> server.  So sending this octet in EAP-TLS does not prove that the client
> certificate has been validated.
>
> DISCUSS: the EAP-TLS draft should explain that the 0x00 byte is NOT a
> positive signal of either "finished TLS", or "successful authentication".
>
> [Joe] It would be good to be clear about the purpose of the message.


> DISCUSS: the EAP-TLS draft should also explain that session tickets may be
> sent either before or after the 0x00 octet.  Does the packet flow look any
> different for the two cases?  If so, what does that mean?
>
> [Joe] I believe the flow of the message flights would be the same, but the
on-the-wire format of those flights could be reversed.  I don't think this
will necessarily cause a problem since the application data is consumed by
the EAP TLS and the NewSessionTicket is consumed by TLS,  However I think
the draft should be clear that this can happen.


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


>
>   In situations where resumption is not needed, figure 1 of
> https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13 is correct.
> There are 3.5 rounds, which is about as low as possible.  Adding resumption
> here would *increase* there number of rounds to 4.5, which is worse!
>
> DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that
> this examples does not include Session Tickets.  Section 2.1.2 should be
> updated to note that there are more rounds than for the previous section.
>
>
[Joe] Yes.  It might be helpful to say that the commitment message may be
sent before or after the client authentication is verified, but in the case
that resumption is used it will always be after.


>
>   In situations where the certificate chain is longer, the initial
> authentication will be >=4.5 round trips, and session tickets are perhaps
> more useful.
>
> DISCUSS: the EAP-TLS draft 

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

[Joseph Salowey]

On Fri, Jan 29, 2021 at 11:34 AM Mohit Sethi M  wrote:

> Hi Ben,
> On 1/29/21 8:32 PM, Benjamin Kaduk wrote:
>
> Hi Alan,
>
> I see that the thread is continuing and that perhaps my reply will even
> become stale as I write it, but I'm replying to your note instead of the
> tip of the thread because it has good context for making some broader
> points that I would like to make.
>
> On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:
>
>   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.
>
> My understanding of the discussions involving the TLS WG are that we forked
> off into two sub-threads: one about the use of TLS Exporters for key
> derivation (the one this is a reply to), that largely concluded with
> agreement on a simple change to make, and the other sub-thread about the
> protocol element known in -13 as the "commitment message".
>
> With respect to the exporter usage, I do see you had asked about using the
> type-code as the exporter context value that Martin didn't see much value
> in, but I am willing to accept that as a boon for safety of portability to
> other TLS-using EAP mechanisms.  (I do note that the current editor's copy
> shows calls to TLS-Exporter() with only two arguments, but three are
> required; the construction there also seems to include a propspect for
> violation of the requirement that "one label is not a prefix of any other
> label" when both regular one-byte and extended type codes are used, but if
> the type code is meant to be the context argument I believe that risk goes
> away.)
>
> RFC 5705 says:
>
>If no context is provided, it then computes:
>
>PRF(SecurityParameters.master_secret, label,
>SecurityParameters.client_random +
>SecurityParameters.server_random
>)[length]
>
>If context is provided, it computes:
>
>PRF(SecurityParameters.master_secret, label,
>SecurityParameters.client_random +
>SecurityParameters.server_random +
>context_value_length + context_value
>)[length]
>
> We use only two arguments and say "No context data is used in the TLS
> exporter interface.". We could show the context argument as empty in the
> calls to make things clearer. By the way, this is what is done by TEAP
> also. RFC 7170 says "TEAPv1 makes use of the TLS Keying Material Exporters
> defined in [RFC5705] to derive the session_key_seed.  The label used in the
> derivation is "EXPORTER: teap session key seed".  The length of the session
> key seed material is 40 octets.  *No context data is used in the export
> process.*"
>
> The change of moving the type-code from the context to the label was made
> based on your review (comments from Martin) and the fact that some
> libraries such as wolfssl don't support passing a context (so far). See:
> https://w1.fi/cgit/hostap/tree/src/crypto/tls_wolfssl.c#n1996
>
[Joe] If this implements the derivation RFC 5216.  It's not clear that
function will give you the right output with TLS 1.3 since we are now using
exporters.  Perhaps they provide an exporter interface which should be used
instead.

Personally, I think including the method byte in the context is a bit less
error prone and straight forward then including it in the label.


>
> With respect to the "commitment message", I thought we had a discussion
> that revealed that the mechanism in the -13 could not fulfil its stated
> purpose, and that also called into question whether that stated purpose was
> actually the right thing that the protocol needed.  My understanding,
> therefore, was that the TLS WG could not contribute further insight until
> there was a revised proposal from people who understand the needs of the
> EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
> actually be achievable.
>
>
>   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.
>
> I think this is becaues the TLS WG members (in aggregate) do not have a
> clear picture of what property or properties EAP-TLS will require from TLS
> that led to the need for an additional message when using TLS 1.3 as
> opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
> "authenticated signal from TLS to EAP-TLS that the authentication completed
> successfully" was mentioned, but I did not have the sense that there 

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

[Alan DeKok]

  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

  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 send a 0x00 
octet, and then the TLS state machines sends that *before* a Session Ticket.

  In addition, RFC 8446 Figure 1 shows that application data can be sent by the 
server to the client, *before* the client certificate is sent to the server.  
So sending this octet in EAP-TLS does not prove that the client certificate has 
been validated.

DISCUSS: the EAP-TLS draft should explain that the 0x00 byte is NOT a positive 
signal of either "finished TLS", or "successful authentication".

DISCUSS: the EAP-TLS draft should also explain that session tickets may be sent 
either before or after the 0x00 octet.  Does the packet flow look any different 
for the two cases?  If so, what does that mean?

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.


  In situations where resumption is not needed, figure 1 of 
https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-13 is correct.  There are 
3.5 rounds, which is about as low as possible.  Adding resumption here would 
*increase* there number of rounds to 4.5, which is worse!

DISCUSS: the EAP-TLS draft Section 2.1.1 should be updated to note that this 
examples does not include Session Tickets.  Section 2.1.2 should be updated to 
note that there are more rounds than for the previous section.


  In situations where the certificate chain is longer, the initial 
authentication will be >=4.5 round trips, and session tickets are perhaps more 
useful.

DISCUSS: the EAP-TLS draft should be updated to better explain the costs / 
benefits of using resumption


  I hope that this summary clarifies the issues and requirements.  The 0x00 
octet is intended as a promise that no more handshake messages are sent.  I 
leave it to others to discuss whether or not that promise is useful.

  As for what to do, my $0.02 is that the behaviour described in -13 is fine.  
The 0x00 octet is useful.  The key exporters are perhaps odd, but not 
problematic.  We have multiple inter-operable implementations.

  The remaining question is this:

DISCUSS: other than word-smithing the above points, are there serious 
objections to the behaviour documented in -13?  i.e. does the IETF want to 
recommend that EAP-TLS alpha testing begins *now*, or should it wait until 2022?

  The only advice I offer here is that we *cannot* rev EAP-TLS, as there is no 
"version" flag in the EAP-TLS 

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

[Alan DeKok]

On Jan 29, 2021, at 1:32 PM, Benjamin Kaduk  wrote:
> With respect to the exporter usage, I do see you had asked about using the
> type-code as the exporter context value that Martin didn't see much value
> in, but I am willing to accept that as a boon for safety of portability to
> other TLS-using EAP mechanisms.

  OK. 

>  (I do note that the current editor's copy
> shows calls to TLS-Exporter() with only two arguments, but three are
> required; the construction there also seems to include a propspect for
> violation of the requirement that "one label is not a prefix of any other
> label" when both regular one-byte and extended type codes are used, but if
> the type code is meant to be the context argument I believe that risk goes
> away.)

  The EAP type codes are one octet: 0x00 through 0xfd.  The "expanded" type 
codes begin with 0xfe.  So there is no prefix issue, even if the type codes 
form part of the label.

  That being said, using them as the context is preferred, I think.

> With respect to the "commitment message", I thought we had a discussion
> that revealed that the mechanism in the -13 could not fulfil its stated
> purpose, and that also called into question whether that stated purpose was
> actually the right thing that the protocol needed.

  I'm less sure.  There was a lot of discussion around a lot of things.  Part 
of the issue seems to be that bits of the TLS state machine are underspecified 
so far as the EAP needs go.

  i.e. when Z happens, is A guaranteed to have happened before that?  RFC 8446 
is not clear.

> I think this is becaues the TLS WG members (in aggregate) do not have a
> clear picture of what property or properties EAP-TLS will require from TLS
> that led to the need for an additional message when using TLS 1.3 as
> opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
> "authenticated signal from TLS to EAP-TLS that the authentication completed
> successfully" was mentioned, but I did not have the sense that there was
> universal agreement of that as the sole relevant property.

  The issue is in part due to API limitations in OpenSSL.  I will send a 
separate message summarizing the issues.

> Well, the text of the -13 contains a protocol mechanism that cannot deliver
> its stated purpose, so I will continue to hold a Discuss position if that
> remains.  One Discuss ballot does not have to block the work indefinitely
> (the shepherding AD can request a different IESG balloting procedure be
> used), and I leave it between the WG and Roman whether to attempt that
> route.  It is perhaps possible that (as John noted downthread) the text
> about the commitment message was badly written, and that just changing the
> surrounding description could work, but that gets back to the question I
> mentioned above of what properties EAP-TLS actually requires from TLS.

  I've had some further discussions and will send a separate message 
summarizing the issues.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

Hi Alan,

I see that the thread is continuing and that perhaps my reply will even
become stale as I write it, but I'm replying to your note instead of the
tip of the thread because it has good context for making some broader
points that I would like to make.

On Sat, Jan 23, 2021 at 05:28:10PM -0500, Alan DeKok wrote:
>   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.

My understanding of the discussions involving the TLS WG are that we forked
off into two sub-threads: one about the use of TLS Exporters for key
derivation (the one this is a reply to), that largely concluded with
agreement on a simple change to make, and the other sub-thread about the
protocol element known in -13 as the "commitment message".

With respect to the exporter usage, I do see you had asked about using the
type-code as the exporter context value that Martin didn't see much value
in, but I am willing to accept that as a boon for safety of portability to
other TLS-using EAP mechanisms.  (I do note that the current editor's copy
shows calls to TLS-Exporter() with only two arguments, but three are
required; the construction there also seems to include a propspect for
violation of the requirement that "one label is not a prefix of any other
label" when both regular one-byte and extended type codes are used, but if
the type code is meant to be the context argument I believe that risk goes
away.)

With respect to the "commitment message", I thought we had a discussion
that revealed that the mechanism in the -13 could not fulfil its stated
purpose, and that also called into question whether that stated purpose was
actually the right thing that the protocol needed.  My understanding,
therefore, was that the TLS WG could not contribute further insight until
there was a revised proposal from people who understand the needs of the
EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
actually be achievable.

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

I think this is becaues the TLS WG members (in aggregate) do not have a
clear picture of what property or properties EAP-TLS will require from TLS
that led to the need for an additional message when using TLS 1.3 as
opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
"authenticated signal from TLS to EAP-TLS that the authentication completed
successfully" was mentioned, but I did not have the sense that there was
universal agreement of that as the sole relevant property.

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

Well, the text of the -13 contains a protocol mechanism that cannot deliver
its stated purpose, so I will continue to hold a Discuss position if that
remains.  One Discuss ballot does not have to block the work indefinitely
(the shepherding AD can request a different IESG balloting procedure be
used), and I leave it between the WG and Roman whether to attempt that
route.  It is perhaps possible that (as John noted downthread) the text
about the commitment message was badly written, and that just changing the
surrounding description could work, but that gets back to the question I
mentioned above of what properties EAP-TLS actually requires from TLS.

-Ben

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

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

[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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Jan 29, 2021, at 8:10 AM, Alan DeKok  wrote:
>  Then our choices are:
> 
> a) draft-13 in February.  There are multiple interoperable implementations, 
> including Microsoft, FreeRADIUS, and hostap / wpa_supplicant.
> 
> b) ??? in 2021.

  Typo:   2022.  :(
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[John Mattsson]

Hi,

I can live with any version, the important thing is that interoperable 
implementations get shipped ASAP. This is important also for 3GPP as EAP-TLS 
1.3 is mandatory to support in 3GPP Rel-16 if EAP-TLS is supported.

We (the authors) have addressed all the comments from IESG/TLS WG in GitHub.

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

Text format:

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

The diff can be found here:

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-emu-eap-tls13.txt=https://emu-wg.github.io/draft-ietf-emu-eap-tls13/draft-ietf-emu-eap-tls13.txt

This would be ready for submission but I think the Implementors, WGs, Chairs, 
Shepard, ADs need to agree on the direction before we do that. The two 
important technical changes from -13 are

(1) Changing key derivation
(2) Changing Commitment message to close_notify

The key derivation changes are good and more modern. I personally like the 
change but the change but I don't think it is essential and was not done for 
security reasons.

The close_notity changes are not only positive as it sometimes introduce an 
additional roundtrip. The Commitment message can according to specification be 
sent with the server Finish even if some/most/all implementation does not seem 
to allow this. If the commitment message cannot be send with Finished in 
practice there is no difference in latency. Still a bit sad how poorly TLS 1.3 
and EAP interacts. I am not sure I fully agree with the layer violation 
argument, my interpretation was that this was information for the EAP state 
machine which is the application using TLS. Maybe the text regarding the 
commitment message was badly written and should have talked about the EAP state 
machine more instead of TLS

We need to get agreement on how to proceed here asap. I would like implementors 
and security AD to agree on the way forward before submitting -14. Four ways 
forward:

A. Add (1) and (2)
B. Only add (1)
C. Only add (2)
D. Do not add (1) or (2)

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

Do we need to have a telephone meeting to discuss these things? We cannot have 
a formal interim meeting as that formally takes weeks to setup. This can also 
not wait until the next IETF. As soon as we agree on a way forward we can 
update and submit a new version within 24 h.

Cheers,
John

-Original Message-
From: TLS  on behalf of Jorge Vergara 

Date: Friday, 29 January 2021 at 00:57
To: Alan DeKok , Martin Thomson 
Cc: "TLS@ietf.org" , EMU WG 
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on 
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

I am in favor of sticking to draft-13. There was some discussion about whether 
draft-13 contained a TLS layering violation, but I believe that discussion 
concluded that it does not. As noted, discussion has mostly stalled since then 
with a few additional ideas surfacing that have added round trips. Other 
threads are now popping up expressing dissatisfaction with the extra round trip.

Alan mentions that betas may be months out for his product line - for Microsoft 
and Windows, the situation is much tighter. If we cannot reach consensus 
quickly we will need to push this out of our 2021 release cycle. Seeing as 
we're sitting on draft-13 with multiple implementations available, I would 
really prefer to reach consensus to finalize draft-13 and get this into the 
hands of customers this calendar year.

Jorge Vergara

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

  We're approaching 2 weeks since the last discussion of this topic.  This 
document has been in development for 3 years.  We desperately need to finish 
it.  IMHO waiting another 6 months is not an option.  Even 3 would be worrying.

  We have multiple inter-operable implementations which have implemented 
draft-13.  That work over the last few months have resulted in implementors 
making plans to do beta testing in the next few weeks.  Those plans have been 
put on indefinite hold, due to the recent request for changes.

  I understand getting feedback from the TLS WG is useful.  But I would prefer 
to have consensus on a *solution*. Right now, we just have a series of proposed 
changes, with little to no discussion.

  We're getting to the point where we have to ship code as promised to 
customers soon (weeks, not months).  We therefore need consensus, as soon as 
possible.

  My preference is to implement draft-13.  We know the code works.  People are 
ready to ship it.  Any changes will add not just more months of standard 
discussion, but more months of interoperability testing.

  If there is no progress in EMU, we're looking at September

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

[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
e...@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: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

[Alan DeKok]

  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://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00
> 
>  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.
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

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://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00

  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.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On Mon, Jan 11, 2021, at 17:07, Joseph Salowey wrote:
> 
> 
> On Thu, Jan 7, 2021 at 2:42 PM Martin Thomson  wrote:
> > Hi Joe,
> > 
> > Thanks for doing this, I think that this is a distinct improvement (and I 
> > will take your word for the difficulties involved with further splits).
> > 
> > One point that I made poorly perhaps, and was dismissed, might be worth 
> > restating:
> > 
> > MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code, 64) 
> > 
> 
> [Joe] I think you propose something like this instead (eliminating context):
> 
> MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK-" + ASCII-Type-Code, 64) 
> 
> Where + is concatenation and ASCII-Type-Code is "13"

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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Jan 11, 2021, at 1:07 AM, Joseph Salowey  wrote:
> [Joe] I think you propose something like this instead (eliminating context):
> 
> MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK-" + ASCII-Type-Code, 64) 
> 
> Where + is concatenation and ASCII-Type-Code is "13"
> 
> the IANA section would explicitly list: EXPORTER_EAP_TLS_MSK-13

  That's fine, but I have a minor forward-looking comment based on other EAP 
types.  They'll have to do similar things.  This is OK for 8-bit EAP types.  
This is more complex for the "extended" EAP types.

  For simplicity, I would suggest that the ASCII type code is represented as 
hex, instead of decimal.  This makes implementations simpler.  They can just 
hex-ify whatever EAP thing they have (8 bits, or more for extended types), and 
then append that to the "EXPORTER_EAP_TLS_MSK" string.

  Decimal is just ugly for computers to deal with. :)

> [Joe] I see your point that we should eliminate the context and include the 
> type code in the label as it will always be the same for EAP-TLS (which also 
> goes to the point that has been made by several people that this value may be 
> redundant since we would expect another EAP type to use a different label).  
> In the past, people have used TLS in all sorts of innovative and unique ways 
> in different EAP methods all loosely based on EAP-TLS.  I don't see this 
> usage as too far outside the intended use of the context field (the value 
> should match on both sides) and I think including the type value in the 
> context value would help avoid some potential implementation problems if the 
> key derivation is reused for another method.  

  I agree here.  I think it's simpler conceptually, for implementations, and 
there's less for IANA to deal with.

 But maybe the TLS people have a strong opposition to using the context in this 
way.  In that case, it's ugly, more work for everyone, but still possible to 
just append the hexified EAP type code to the label.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

On Thu, Jan 7, 2021 at 2:42 PM Martin Thomson  wrote:

> Hi Joe,
>
> Thanks for doing this, I think that this is a distinct improvement (and I
> will take your word for the difficulties involved with further splits).
>
> One point that I made poorly perhaps, and was dismissed, might be worth
> restating:
>
> MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code, 64)
>
>
[Joe] I think you propose something like this instead (eliminating context):

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

Where + is concatenation and ASCII-Type-Code is "13"

the IANA section would explicitly list: EXPORTER_EAP_TLS_MSK-13


> The inclusion of a type code as context is, I believe, a misuse of the
> field.  As this is a fixed value, the value is being used for domain
> separation.  However, that is the function of the exporter label input.
> The label exists to establish that this is EAP-TLS and the key is (in this
> case) MSK.  If you need different derivations for different type codes, I
> strongly suggest that this be included in the label.
>
> The Context input exists to pull in variables from the context that
> endpoints might need to agree on.  It is not for domain separation.  For
> example, if you thought it necessary to authenticate the Identity values
> that client and server exchange, you might add those to this field.  (As an
> aside, you might want to consider that as their value could be used to
> determine what parameters to feed into the TLS handshake.)
>
> If, however, you have an adjacent usage of EAP that wants its own MSK,
> then that is domain separation.  The right thing to do would be to create
> new labels for that usage.
>
> This might be a fine point in light of the fact that these all just get
> fed into HKDF, but I think that it is important to respect the purpose for
> which these inputs were designed.
>
>
[Joe] I see your point that we should eliminate the context and include the
type code in the label as it will always be the same for EAP-TLS (which
also goes to the point that has been made by several people that this value
may be redundant since we would expect another EAP type to use a different
label).  In the past, people have used TLS in all sorts of innovative and
unique ways in different EAP methods all loosely based on EAP-TLS.  I don't
see this usage as too far outside the intended use of the context field
(the value should match on both sides) and I think including the type value
in the context value would help avoid some potential implementation
problems if the key derivation is reused for another method.




Cheers,
> Martin
>
> On Wed, Jan 6, 2021, at 17:24, Joseph Salowey wrote:
> >
> >
> > On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok 
> wrote:
> > > On Jan 5, 2021, at 11:13 AM, Mohit Sethi M 
> wrote:
> > > >
> > > > Hi Alan,
> > > >
> > > > Cleaning up the email. The current draft says the exporter should be
> called once as:
> > > >
> > > >>Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
> > > >>Type-Code, 128)
> > > >>
> > > > and then split the 128 into MSK (64) and EMSK (64). As said, from
> initial glance, it seems the exporter is called twice (once in
> eap_tls_get_emsk and once in eap_tls_getKey). Both the calls are with
> exactly the same context, context length, and labels. In getKey, the EMSK
> parts are cleared with
> > > >> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
> > > > while in get_emsk, they are read with
> > > >
> > > >
> > > >>  os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
> > > >>
> > > >>
> > > >> EAP_EMSK_LEN);
> > > > Maybe we can live with this. But if exporter is called twice, we
> should use different labels as suggested by Martin?
> > >
> > >   Yes.
> > >
> > >   Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and
> EXPORTER_EAP_TLS_EMSK, which seem simple enough.
> > >
> > [Joe] I created a pull request
> > (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the
> > proposed labels.  Is this change going to cause significant problems
> > for implementation?
> >
> > >   Alan DeKok.
> > >
> > > ___
> > > TLS mailing list
> > > TLS@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tls
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Mohit Sethi M]

Hi Martin,

Thanks for the quick response.

On 1/8/21 10:25 AM, Martin Thomson wrote:
> On Fri, Jan 8, 2021, at 18:54, Mohit Sethi M wrote:
>> Thanks for pointing this out. I think Ben also mentioned this in his
>> review. I am not sure if it is necessary to add the type-code to the
>> label when it is already part of the label string as 'EAP_TLS'. Other
>> TLS based EAP methods should ideally register labels of the form
>> EXPORTER_EAP_TTLS_MSK or EXPORTER_EAP_FAST_MSK (instead of reusing the
>> EAP-TLS label) as is currently done in
>> https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01.
> Sounds good to me.
>
>> I do agree with your point about the incorrect usage of the context.
>> Perhaps the ideal choice here would be Server-Id and Peer-Id (if client
>> certificate is used): https://tools.ietf.org/html/rfc5216#section-5.2.
> Maybe, as I said, it depends.
>
>> However, I checked the wpa_supplicant implementation and currently these
>> values are not available. As far as I can tell, the Server-Id and
>> Peer-Id are not exported for any EAP method. So we'll need to think
>> what's the right thing to do: update implementation/use some other
>> sensible value/or leave the context empty (which is allowed in RFC 5705).
> This suggests that the values aren't critical to any decision making process 
> made by either peer and maybe you don't need to include them.  I would check 
> a little more thoroughly though.  One implementation not using them isn't 
> strong enough evidence that they aren't used at all.  If those identifiers 
> determine what certificate is selected, or anything like that, then it would 
> be good to ensure that peers agree on what they were.  That might mean making 
> them available in implementations that did not previously use them.  On the 
> other hand, if they are always going to be anonymous identifiers that have no 
> bearing on the TLS operation, don't worry about it and use the empty string.

These values are critical for making authorization decisions about 
network access. It is more a question of where these values are 
available, exported, and used for decision making in implementations. 
Thank you for nudging us in the right direction. :)

--Mohit

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On Fri, Jan 8, 2021, at 18:54, Mohit Sethi M wrote:
> Thanks for pointing this out. I think Ben also mentioned this in his 
> review. I am not sure if it is necessary to add the type-code to the 
> label when it is already part of the label string as 'EAP_TLS'. Other 
> TLS based EAP methods should ideally register labels of the form 
> EXPORTER_EAP_TTLS_MSK or EXPORTER_EAP_FAST_MSK (instead of reusing the 
> EAP-TLS label) as is currently done in 
> https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01.

Sounds good to me.

> I do agree with your point about the incorrect usage of the context. 
> Perhaps the ideal choice here would be Server-Id and Peer-Id (if client 
> certificate is used): https://tools.ietf.org/html/rfc5216#section-5.2. 

Maybe, as I said, it depends.

> However, I checked the wpa_supplicant implementation and currently these 
> values are not available. As far as I can tell, the Server-Id and 
> Peer-Id are not exported for any EAP method. So we'll need to think 
> what's the right thing to do: update implementation/use some other 
> sensible value/or leave the context empty (which is allowed in RFC 5705).

This suggests that the values aren't critical to any decision making process 
made by either peer and maybe you don't need to include them.  I would check a 
little more thoroughly though.  One implementation not using them isn't strong 
enough evidence that they aren't used at all.  If those identifiers determine 
what certificate is selected, or anything like that, then it would be good to 
ensure that peers agree on what they were.  That might mean making them 
available in implementations that did not previously use them.  On the other 
hand, if they are always going to be anonymous identifiers that have no bearing 
on the TLS operation, don't worry about it and use the empty string.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Mohit Sethi M]

Hi Ben,

On 1/7/21 9:21 AM, Benjamin Kaduk wrote:
> On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote:
>> On Jan 5, 2021, at 4:47 AM, Mohit Sethi M  wrote:
>>> What I am gathering is that this commitment message should instead be
>>> made into a confirmation message, i.e. it should only be sent after
>>> receiving TLS Finished from the client? This would result in one extra
> I forget if it has been explicitly mentioned in the thread so far, but
> https://tools.ietf.org/html/rfc8446#section-4.4.4 is pretty clear that
> "Servers MAY send data after sending their first flight, but because the
> handshake is not yet complete, they have no assurance of either the peer's
> identity or its liveness (i.e., the ClientHello might have been replayed)."
> In particular, "no assurance of the peer's identity" means that the server
> is at this point sending to an unauthenticated client.  If the goal of
> EAP-TLS is to ascertain that there is in fact an authenticated client, it
> may be ill-advised to send indications of overall success to an
> unauthenticated client.  Part of what Martin alluded to with the situation
> being lousy overall is that there are basically two things that can
> cryptographically confirm that the client has authenticated: successful
> processing of the client Finished, and values derived from the resumption
> master secret.  In "normal" TLS usage the server will bail out if the
> client Finished doesn't validate, so continued receipt of application data,
> including application data bearing application-protocol responses to data
> the client sent in 1-RTT after client Finished, effectively implies that
> the server validated the client Finished, but the EAP-TLS usage is quite
> different from that.  There's not a cryptographic way to tell whether 0x00
> application data was generated before or after the client Finished was
> processed.
Yes, this was discussed. See email from Hannes 
(https://mailarchive.ietf.org/arch/msg/emu/Vf4Zor-xIDVZLQB-BE9mPvlDZMM/) 
where we did look at the text from RFC 8446 about the peer being 
unauthenticated. It was (at that time) accepted since the server was 
only committing to not sending more post-handshake messages (rather than 
indicating successful completion of handshake).
>
>>> round trip to both figure 1 and 3 in the current draft. So we would end
>>> up with the same number of messages as RFC 5216 for full authentication
>>> (https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do
>>> worse than RFC 5216 (one extra round trip) in case resumption
>>> (https://tools.ietf.org/html/rfc5216#section-2.1.2).
>>That sounds right.
> While counting arrows in the diagram like this is definitely useful, part
> of my concerns related to the need (in non-resumption flows) to convey the
> entire (enlarged) server Certificate chain in individual 1020-byte
> EAP-Requests.  My understanding was that the server had to send a single
> 1020-byte EAP-Request and wait for the corresponding EAP-Response before
> sending the next chunk of the certificate chain.  It was in that scenario
> that I expected a substantial difference between resumption and
> non-resumption.
>
>>> Maybe this is acceptable? The draft anyway notes that "Sending the
>>> Commitment Message in a separate EAP-Request adds an additional
>>> round-trip, but may be necessary in TLS implementations that only
>>> implement a subset of TLS 1.3.". In which case, I am not sure if the
>>> reasons against using close_notify apply anymore.
>>I won't offer opinions on TLS internals, as I'm out of my depth there.
>>
>>As an implementor, the priority is getting TLS alerts (expired cert, 
>> etc.) back from the EAP server to the EAP peer.  Those messages can then be 
>> used to debug deployment issues.
>>
>>The exact method of doing this is less important.  The "0x00" octet works 
>> now, so I'm happy with it.  But if TLS review decides that should change, 
>> that's fine, too.
> It's pretty much guaranteed that we can get the TLS alerts if we always
> wait for client Finished to be processed (whatever signal we end up
> choosing to send after that occurs).  Have we reached agreement on whether
> we should always wait for client Finished?

I hope so. I'll try to submit an update next week.

--Mohit

>
> -Ben
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Mohit Sethi M]

Hi Martin,

Thanks for pointing this out. I think Ben also mentioned this in his 
review. I am not sure if it is necessary to add the type-code to the 
label when it is already part of the label string as 'EAP_TLS'. Other 
TLS based EAP methods should ideally register labels of the form 
EXPORTER_EAP_TTLS_MSK or EXPORTER_EAP_FAST_MSK (instead of reusing the 
EAP-TLS label) as is currently done in 
https://tools.ietf.org/html/draft-ietf-emu-tls-eap-types-01.

I do agree with your point about the incorrect usage of the context. 
Perhaps the ideal choice here would be Server-Id and Peer-Id (if client 
certificate is used): https://tools.ietf.org/html/rfc5216#section-5.2. 
However, I checked the wpa_supplicant implementation and currently these 
values are not available. As far as I can tell, the Server-Id and 
Peer-Id are not exported for any EAP method. So we'll need to think 
what's the right thing to do: update implementation/use some other 
sensible value/or leave the context empty (which is allowed in RFC 5705).

--Mohit

On 1/8/21 12:41 AM, Martin Thomson wrote:
> Hi Joe,
>
> Thanks for doing this, I think that this is a distinct improvement (and I 
> will take your word for the difficulties involved with further splits).
>
> One point that I made poorly perhaps, and was dismissed, might be worth 
> restating:
>
> MSK = TLS-Exporter("EXPORTER_EAP_TLS_MSK", Type-Code, 64)
>
> The inclusion of a type code as context is, I believe, a misuse of the field. 
>  As this is a fixed value, the value is being used for domain separation.  
> However, that is the function of the exporter label input.  The label exists 
> to establish that this is EAP-TLS and the key is (in this case) MSK.  If you 
> need different derivations for different type codes, I strongly suggest that 
> this be included in the label.
>
> The Context input exists to pull in variables from the context that endpoints 
> might need to agree on.  It is not for domain separation.  For example, if 
> you thought it necessary to authenticate the Identity values that client and 
> server exchange, you might add those to this field.  (As an aside, you might 
> want to consider that as their value could be used to determine what 
> parameters to feed into the TLS handshake.)
>
> If, however, you have an adjacent usage of EAP that wants its own MSK, then 
> that is domain separation.  The right thing to do would be to create new 
> labels for that usage.
>
> This might be a fine point in light of the fact that these all just get fed 
> into HKDF, but I think that it is important to respect the purpose for which 
> these inputs were designed.
>
> Cheers,
> Martin
>
> On Wed, Jan 6, 2021, at 17:24, Joseph Salowey wrote:
>>
>> On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok  wrote:
>>> On Jan 5, 2021, at 11:13 AM, Mohit Sethi M  
>>> wrote:
 Hi Alan,

 Cleaning up the email. The current draft says the exporter should be 
 called once as:

> Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
> Type-Code, 128)
>
 and then split the 128 into MSK (64) and EMSK (64). As said, from initial 
 glance, it seems the exporter is called twice (once in eap_tls_get_emsk 
 and once in eap_tls_getKey). Both the calls are with exactly the same 
 context, context length, and labels. In getKey, the EMSK parts are cleared 
 with
> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
 while in get_emsk, they are read with


>   os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
>
> 
> EAP_EMSK_LEN);
 Maybe we can live with this. But if exporter is called twice, we should 
 use different labels as suggested by Martin?
>>>Yes.
>>>
>>>Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and 
>>> EXPORTER_EAP_TLS_EMSK, which seem simple enough.
>>>
>> [Joe] I created a pull request
>> (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the
>> proposed labels.  Is this change going to cause significant problems
>> for implementation?
>>   
>>>Alan DeKok.
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

Hi Joe,

Thanks for doing this, I think that this is a distinct improvement (and I will 
take your word for the difficulties involved with further splits).

One point that I made poorly perhaps, and was dismissed, might be worth 
restating:

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

The inclusion of a type code as context is, I believe, a misuse of the field.  
As this is a fixed value, the value is being used for domain separation.  
However, that is the function of the exporter label input.  The label exists to 
establish that this is EAP-TLS and the key is (in this case) MSK.  If you need 
different derivations for different type codes, I strongly suggest that this be 
included in the label.

The Context input exists to pull in variables from the context that endpoints 
might need to agree on.  It is not for domain separation.  For example, if you 
thought it necessary to authenticate the Identity values that client and server 
exchange, you might add those to this field.  (As an aside, you might want to 
consider that as their value could be used to determine what parameters to feed 
into the TLS handshake.)

If, however, you have an adjacent usage of EAP that wants its own MSK, then 
that is domain separation.  The right thing to do would be to create new labels 
for that usage.

This might be a fine point in light of the fact that these all just get fed 
into HKDF, but I think that it is important to respect the purpose for which 
these inputs were designed.

Cheers,
Martin

On Wed, Jan 6, 2021, at 17:24, Joseph Salowey wrote:
> 
> 
> On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok  wrote:
> > On Jan 5, 2021, at 11:13 AM, Mohit Sethi M  
> > wrote:
> > > 
> > > Hi Alan,
> > > 
> > > Cleaning up the email. The current draft says the exporter should be 
> > > called once as:
> > > 
> > >>Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
> > >>Type-Code, 128)
> > >> 
> > > and then split the 128 into MSK (64) and EMSK (64). As said, from initial 
> > > glance, it seems the exporter is called twice (once in eap_tls_get_emsk 
> > > and once in eap_tls_getKey). Both the calls are with exactly the same 
> > > context, context length, and labels. In getKey, the EMSK parts are 
> > > cleared with
> > >> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
> > > while in get_emsk, they are read with
> > > 
> > > 
> > >>  os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
> > >> 
> > >>
> > >> EAP_EMSK_LEN);
> > > Maybe we can live with this. But if exporter is called twice, we should 
> > > use different labels as suggested by Martin?
> > 
> >   Yes.
> > 
> >   Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and EXPORTER_EAP_TLS_EMSK, 
> > which seem simple enough.
> > 
> [Joe] I created a pull request 
> (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the 
> proposed labels.  Is this change going to cause significant problems 
> for implementation? 
>  
> >   Alan DeKok.
> > 
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

On Tue, Jan 05, 2021 at 10:41:50AM -0500, Alan DeKok wrote:
> On Jan 5, 2021, at 4:47 AM, Mohit Sethi M  wrote:
> > What I am gathering is that this commitment message should instead be 
> > made into a confirmation message, i.e. it should only be sent after 
> > receiving TLS Finished from the client? This would result in one extra 

I forget if it has been explicitly mentioned in the thread so far, but
https://tools.ietf.org/html/rfc8446#section-4.4.4 is pretty clear that
"Servers MAY send data after sending their first flight, but because the
handshake is not yet complete, they have no assurance of either the peer's
identity or its liveness (i.e., the ClientHello might have been replayed)."
In particular, "no assurance of the peer's identity" means that the server
is at this point sending to an unauthenticated client.  If the goal of
EAP-TLS is to ascertain that there is in fact an authenticated client, it
may be ill-advised to send indications of overall success to an
unauthenticated client.  Part of what Martin alluded to with the situation
being lousy overall is that there are basically two things that can
cryptographically confirm that the client has authenticated: successful
processing of the client Finished, and values derived from the resumption
master secret.  In "normal" TLS usage the server will bail out if the
client Finished doesn't validate, so continued receipt of application data,
including application data bearing application-protocol responses to data
the client sent in 1-RTT after client Finished, effectively implies that
the server validated the client Finished, but the EAP-TLS usage is quite
different from that.  There's not a cryptographic way to tell whether 0x00
application data was generated before or after the client Finished was
processed.

> > round trip to both figure 1 and 3 in the current draft. So we would end 
> > up with the same number of messages as RFC 5216 for full authentication 
> > (https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do 
> > worse than RFC 5216 (one extra round trip) in case resumption 
> > (https://tools.ietf.org/html/rfc5216#section-2.1.2).
> 
>   That sounds right.

While counting arrows in the diagram like this is definitely useful, part
of my concerns related to the need (in non-resumption flows) to convey the
entire (enlarged) server Certificate chain in individual 1020-byte
EAP-Requests.  My understanding was that the server had to send a single
1020-byte EAP-Request and wait for the corresponding EAP-Response before
sending the next chunk of the certificate chain.  It was in that scenario
that I expected a substantial difference between resumption and
non-resumption.

> > Maybe this is acceptable? The draft anyway notes that "Sending the 
> > Commitment Message in a separate EAP-Request adds an additional 
> > round-trip, but may be necessary in TLS implementations that only 
> > implement a subset of TLS 1.3.". In which case, I am not sure if the 
> > reasons against using close_notify apply anymore.
> 
>   I won't offer opinions on TLS internals, as I'm out of my depth there.
> 
>   As an implementor, the priority is getting TLS alerts (expired cert, etc.) 
> back from the EAP server to the EAP peer.  Those messages can then be used to 
> debug deployment issues.
> 
>   The exact method of doing this is less important.  The "0x00" octet works 
> now, so I'm happy with it.  But if TLS review decides that should change, 
> that's fine, too.

It's pretty much guaranteed that we can get the TLS alerts if we always
wait for client Finished to be processed (whatever signal we end up
choosing to send after that occurs).  Have we reached agreement on whether
we should always wait for client Finished?

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Jan 6, 2021, at 1:24 AM, Joseph Salowey  wrote:
> [Joe] I created a pull request 
> (https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the 
> proposed labels.  Is this change going to cause significant problems for 
> implementation? 

  After making this change:

$ git diff src/modules/rlm_eap/ | wc -l
  89

  It's fine.

   Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok  wrote:

> On Jan 5, 2021, at 11:13 AM, Mohit Sethi M 
> wrote:
> >
> > Hi Alan,
> >
> > Cleaning up the email. The current draft says the exporter should be
> called once as:
> >
> >>Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
> >>Type-Code, 128)
> >>
> > and then split the 128 into MSK (64) and EMSK (64). As said, from
> initial glance, it seems the exporter is called twice (once in
> eap_tls_get_emsk and once in eap_tls_getKey). Both the calls are with
> exactly the same context, context length, and labels. In getKey, the EMSK
> parts are cleared with
> >> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
> > while in get_emsk, they are read with
> >
> >
> >>  os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
> >>
> >>
> >> EAP_EMSK_LEN);
> > Maybe we can live with this. But if exporter is called twice, we should
> use different labels as suggested by Martin?
>
>   Yes.
>
>   Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and
> EXPORTER_EAP_TLS_EMSK, which seem simple enough.
>
> [Joe] I created a pull request (
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/17)  with the
proposed labels.  Is this change going to cause significant problems for
implementation?


>   Alan DeKok.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Michael Richardson]

pedantically, because I think that there is much confusion here.
Let me go back to the whole sentence:

Alan>  Therefore, we need an explicit signal to the EAP-TLS layer that the
Alan>  EAP-TLS method has finished.  Discussion on the list went back and
Alan>  forth between CloseNotify and sending one octet of application data.
Alan>  Implementations have done both.  The conclusion was that the one octet
Alan>  of application data was slightly easier to implement.

Alan DeKok  wrote:
>> Alan DeKok  wrote:
>>> Therefore, we need an explicit signal to the EAP-TLS layer that the
>>
>> Do you mean, "to the EAP layer"?
>> s/EAP-TLS layer/EAP/ ??

> If the EAP-TLS layer allows TLS negotiation OR EAP-Success, then it's
> possible to bypass TLS by spoofing an EAP-Success.  So the EAP-TLS
> layer needs to have a way to say "we're done, EAP-Success is now OK".

> It's really nested:  EAP ( EAP-TLS ( TLS ) )

Okay, so I think that we need:
  1) signal from the TLS layer to EAP-TLS layer
  2) signal from the EAP-TLS layer to the EAP layer

But, you said, above:

 "to the EAP-TLS layer that the EAP-TLS method has finished"

so I still think that there might be a typo :-)

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


signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

On Tue, Jan 05, 2021 at 11:12:21AM -0500, Alan DeKok wrote:
> On Jan 5, 2021, at 11:05 AM, Michael Richardson  wrote:
> > 
> > Alan DeKok  wrote:
> >> Therefore, we need an explicit signal to the EAP-TLS layer that the
> > 
> > Do you mean, "to the EAP layer"?
> > s/EAP-TLS layer/EAP/ ??
> 
>   If the EAP-TLS layer allows TLS negotiation OR EAP-Success, then it's 
> possible to bypass TLS by spoofing an EAP-Success.  So the EAP-TLS layer 
> needs to have a way to say "we're done, EAP-Success is now OK".
> 
>   It's really nested:  EAP ( EAP-TLS ( TLS ) ) 
> 
>   We can't finish EAP until we know that EAP-TLS is finished.  We can't 
> finish EAP-TLS until we know that TLS is finished.

Okay.  What step suffices to determine that "TLS is finished" for your use
case.  The natural definition is "the handshake is complete", which would
be incompatible with the text currently in the draft (and with 0.5-RTT
entirely).

-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

On Tue, Jan 5, 2021 at 8:14 AM Mohit Sethi M  wrote:

> Hi Alan,
> Cleaning up the email. The current draft says the exporter should be
> called once as:
>
>Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
>Type-Code, 128)
>
> and then split the 128 into MSK (64) and EMSK (64). As said, from initial
> glance, it seems the exporter is called twice (once in eap_tls_get_emsk and
> once in eap_tls_getKey). Both the calls are with exactly the same context,
> context length, and labels. In getKey, the EMSK parts are cleared with
>
> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
>
> while in get_emsk, they are read with
>
>   os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
> EAP_EMSK_LEN);
>
> Maybe we can live with this. But if exporter is called twice, we should
> use different labels as suggested by Martin?
>
> Regarding the Enc-Recv-Key and Enc-Send-Key, you obviously know more. I
> was thrown off by Joe's comment "The mechanism for splitting the MSK into
> Enc-RECV-Key and Enc-SNED-Key I believe is only used in specific legacy
> cases (WEP, MPPE?)" and the fact that other EAP methods only export MSK.
> Other EAP methods leave it to the AAA architecture for splitting up the
> MSK. Why should EAP-TLS be different?
>
[Joe] EAP TLS was defined before the keying framework so it
explicitly called out those keys.  Originally, there were RADIUS attributes
for carrying send key and receive key material defined for MPPE.  These
were reused to carry key material when WEP was integrated with 802.1x/EAP.
 With 802.11i and the EAP revision things were made more formal and the MSK
was defined, but the same RADIUS attributes were used for key transport.
Essentially, 802.11i takes the First half of the MSK and uses it as the PMK
for the 4-way handshake, this is transported to the authenticator in the
ms-mppe-recv-key attribute.   The second half of the key is sent in the
ms-mppe-send-key attribute and may be used by some other IEEE
specifications.   Newer attributes have been developed for key transport in
RADIUS over the years.  I don't know their adoption rate at this
point.  THe EMSK was developed as a key that was shared between the AAA
(EAP Server) and supplicant (EAP-Peer) that is not known to the
EAP-Authenticator.   We could leave the definition of how to derive the
receive and send keys from the MSK in the EAP-TLS spec and reference it
from this one.  Or we could just include it.



> --Mohit
> ___
> Emu mailing list
> e...@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Jan 5, 2021, at 11:13 AM, Mohit Sethi M  wrote:
> 
> Hi Alan,
> 
> Cleaning up the email. The current draft says the exporter should be called 
> once as:
> 
>>Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
>>Type-Code, 128)
>> 
> and then split the 128 into MSK (64) and EMSK (64). As said, from initial 
> glance, it seems the exporter is called twice (once in eap_tls_get_emsk and 
> once in eap_tls_getKey). Both the calls are with exactly the same context, 
> context length, and labels. In getKey, the EMSK parts are cleared with
>> os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);
> while in get_emsk, they are read with
> 
> 
>>  os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
>> 
>>
>> EAP_EMSK_LEN);
> Maybe we can live with this. But if exporter is called twice, we should use 
> different labels as suggested by Martin?

  Yes.

  Perhaps as Joe suggested: EXPORTER_EAP_TLS_MSK and EXPORTER_EAP_TLS_EMSK, 
which seem simple enough.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Mohit Sethi M]

Hi Alan,

Cleaning up the email. The current draft says the exporter should be called 
once as:

   Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
   Type-Code, 128)

and then split the 128 into MSK (64) and EMSK (64). As said, from initial 
glance, it seems the exporter is called twice (once in eap_tls_get_emsk and 
once in eap_tls_getKey). Both the calls are with exactly the same context, 
context length, and labels. In getKey, the EMSK parts are cleared with

os_memset(eapKeyData + EAP_TLS_KEY_LEN, 0, EAP_EMSK_LEN);

while in get_emsk, they are read with

os_memcpy(emsk, eapKeyData + EAP_TLS_KEY_LEN,
  EAP_EMSK_LEN);

Maybe we can live with this. But if exporter is called twice, we should use 
different labels as suggested by Martin?

Regarding the Enc-Recv-Key and Enc-Send-Key, you obviously know more. I was 
thrown off by Joe's comment "The mechanism for splitting the MSK into 
Enc-RECV-Key and Enc-SNED-Key I believe is only used in specific legacy cases 
(WEP, MPPE?)" and the fact that other EAP methods only export MSK. Other EAP 
methods leave it to the AAA architecture for splitting up the MSK. Why should 
EAP-TLS be different?

--Mohit
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Jan 5, 2021, at 11:05 AM, Michael Richardson  wrote:
> 
> Alan DeKok  wrote:
>> Therefore, we need an explicit signal to the EAP-TLS layer that the
> 
> Do you mean, "to the EAP layer"?
> s/EAP-TLS layer/EAP/ ??

  If the EAP-TLS layer allows TLS negotiation OR EAP-Success, then it's 
possible to bypass TLS by spoofing an EAP-Success.  So the EAP-TLS layer needs 
to have a way to say "we're done, EAP-Success is now OK".

  It's really nested:  EAP ( EAP-TLS ( TLS ) ) 

  We can't finish EAP until we know that EAP-TLS is finished.  We can't finish 
EAP-TLS until we know that TLS is finished.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Michael Richardson]

Alan DeKok  wrote:
> Therefore, we need an explicit signal to the EAP-TLS layer that the

Do you mean, "to the EAP layer"?
s/EAP-TLS layer/EAP/ ??

> EAP-TLS method has finished.


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






signature.asc
Description: PGP signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Salz, Rich]

Since there was a question upthread about what the exporter tags should be; the 
draft picks them and sends email to 
tls-reg-rev...@ietf.org requesting them.  See 
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#exporter-labels
  Pretty easy.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Jan 5, 2021, at 4:47 AM, Mohit Sethi M  wrote:
> What I am gathering is that this commitment message should instead be 
> made into a confirmation message, i.e. it should only be sent after 
> receiving TLS Finished from the client? This would result in one extra 
> round trip to both figure 1 and 3 in the current draft. So we would end 
> up with the same number of messages as RFC 5216 for full authentication 
> (https://tools.ietf.org/html/rfc5216#section-2.1.1) and actually do 
> worse than RFC 5216 (one extra round trip) in case resumption 
> (https://tools.ietf.org/html/rfc5216#section-2.1.2).

  That sounds right.

> Maybe this is acceptable? The draft anyway notes that "Sending the 
> Commitment Message in a separate EAP-Request adds an additional 
> round-trip, but may be necessary in TLS implementations that only 
> implement a subset of TLS 1.3.". In which case, I am not sure if the 
> reasons against using close_notify apply anymore.

  I won't offer opinions on TLS internals, as I'm out of my depth there.

  As an implementor, the priority is getting TLS alerts (expired cert, etc.) 
back from the EAP server to the EAP peer.  Those messages can then be used to 
debug deployment issues.

  The exact method of doing this is less important.  The "0x00" octet works 
now, so I'm happy with it.  But if TLS review decides that should change, 
that's fine, too.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Jan 5, 2021, at 10:05 AM, Mohit Sethi M  wrote:
> This sounds reasonable. I was initially hesitant to change because we have 
> working implementations.

  Nothing has been published in an official release.  So we have some time.

  But I'm at the point now where I'd like to release the next version of 
FreeRADIUS.  We've implemented the current draft.  If there's still 
uncertainty, then I will disable TLS 1.3 support before the release.  It's 
better to forbid something than to do it wrong.

> But after a brief glance at the current hostap implementation: 
> https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server_tls.c#n356; I am 
> convinced that using separate labels for MSK and EMSK is better. The current 
> implementation seems incorrect. 

  IIRC hostap has EAP-TLS working for TLS 1.3.  The PEAP and TTLS patches have 
not yet been merged.

> About the IV: RFC 5247 (published after RFC 5216) says the following 
> (https://tools.ietf.org/html/rfc5247#section-1.2):
> 
>> As a result, its use has been deprecated and it is
>>   OPTIONAL for EAP methods to generate it.  However, when it is
>>   generated, it MUST be unpredictable.
>> 
> Should we still export it in EAP-TLS with TLS 1.3?

  I don't recall any uses of it.  

> And the same question for Enc-SEND-Key and Enc-RECV-Key. They are defined in 
> RFC 2548: https://tools.ietf.org/html/rfc2548, but not exported or used in 
> hostap/freeradius implementations. It could be that they are still used by 
> Microsoft but I am unsure?

   I'm not sure what is meant by Enc-SEND-Key.RFC 2548 Section 2.4.2 
defines MS-MPPE-Send-Key.  That and MS-MPPE-Recv-Key are used everywhere in 
WiFi.  FreeRADIUS and hostap both export and use these fields.

  Removing MS-MPPE-Send-Key and/or MS-MPPE-Recv-Key will destroy global WiFi.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Mohit Sethi M]

Hi Joe,

On 1/5/21 8:44 AM, Joseph Salowey wrote:


On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok 
mailto:al...@deployingradius.com>> wrote:
On Jan 3, 2021, at 10:44 PM, Martin Thomson 
mailto:m...@lowentropy.net>> wrote:
> # Key Schedule
>
> The other thing I observe is the way that this slices up the exporter output. 
>  This was something that old versions of TLS did, but TLS 1.3 did away with.  
> Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.  This could - 
> and should - do the same.  All it means is having more exporter labels.

  That's easy enough to change at this state.  The question is what are those 
labels?
  And, we're getting very close to needing an implementation soon.  RFC 8446 is 
over two years old.  Web services have started serious migration to TLS 1.3.  
But we still don't even have a standard for EAP.  I suggest that this is an 
issue.

  At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with the 
major EAP peer / server implementations.  This code is alpha, and not in any 
major release.  But we need to decide fairly soon what we're doing, as testing 
and releases take time.

  The alternative is to dither around for another year or two, all the while 
relying on legacy TLS versions for 802.1X / WiFi authentication.  i.e. packets 
which are trivially monitored by anyone with a WiFi card.

> I appreciate that this uses exporters now rather than abusing the internal 
> PRF.  That's good.  The next step is to dispense with the intermediate values 
> (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS 
> exporter for each of the six values that the protocol requires.  I also note 
> that the 0x0D value is used multiple times, unnecessarily, both as a context 
> strong to the exporter and as a prefix to the session ID.

  If EAP-TLS was the only TLS-based EAP method, I would agree with you.  But 
it's not.  Historically, each TLS-based EAP method uses it's own key 
derivations, using method-specific strings.  This practice made implementations 
more difficult and error-prone.

[Joe] It may be worth having separate exporter tags for EMSK and MSK.  
(EXPORTER_EAP_TLS_MSK and EXPORTER_EAP_TLS_EMSK).   I believe current 
applications define the use EAP key material based on the MSK or EMSK.   The 
mechanism for splitting the MSK into Enc-RECV-Key and Enc-SNED-Key I believe is 
only used in specific legacy cases (WEP, MPPE?) and may still be the radius 
attributes used in some deployments, so I don't think we should alter that 
derivation.   I'm not sure where the IV is used, but I don't think splitting it 
up more will be helpful.

This sounds reasonable. I was initially hesitant to change because we have 
working implementations. But after a brief glance at the current hostap 
implementation: 
https://w1.fi/cgit/hostap/tree/src/eap_server/eap_server_tls.c#n356; I am 
convinced that using separate labels for MSK and EMSK is better. The current 
implementation seems incorrect.

About the IV: RFC 5247 (published after RFC 5216) says the following 
(https://tools.ietf.org/html/rfc5247#section-1.2):

As a result, its use has been deprecated and it is
  OPTIONAL for EAP methods to generate it.  However, when it is
  generated, it MUST be unpredictable.

Should we still export it in EAP-TLS with TLS 1.3?

And the same question for Enc-SEND-Key and Enc-RECV-Key. They are defined in 
RFC 2548: https://tools.ietf.org/html/rfc2548, but not exported or used in 
hostap/freeradius implementations. It could be that they are still used by 
Microsoft but I am unsure?

--Mohit




  The use of 0x0D is to allow standard key derivations across TLS-based EAP 
methods.  The other methods replaced the 0x0D byte with their own EAP type 
value.  This practice greatly simplifies implementations.

  See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for more 
information.

  Alan DeKok.

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



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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Mohit Sethi M]

Hi again,

The following issues are related but not exactly the same:
1. indication from the server that the handshake is complete and it is 
okay to tear down the tunnel
2. indication from the server that no more post-handshake messages 
(containing NewSessionTicket or something else) will be sent.

We can't rely on EAP-Success as an indication of either since that 
message is never delivered to EAP-TLS and it maybe lost or spoofed. 
Ben's discuss arises from 2 and not 1. More at the end of the email.

On 1/5/21 7:26 AM, Benjamin Kaduk wrote:
> Hi Martin,
>
> Thanks for chiming in here; your insight has been quite helpful already.
> (I am going to reply to the thread in reverse order so as to not duplicate
> what you've already said.)
>
> On Tue, Jan 05, 2021 at 02:50:15PM +1100, Martin Thomson wrote:
>> Hi Alan,
>>
>> On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote:
>>> On Jan 4, 2021, at 6:26 PM, Martin Thomson  wrote:
 Your point about reliability is confusing.  I've read Section 4.2 of RFC 
 3748 and while it says "A peer MUST allow for this circumstance as 
 described in this note.", I see no explanation of how to concretely make 
 that allowance.  Are you saying that EAP methods don't really use 
 EAP-Success and condition their behaviour on other signals?
>>>EAP-Success by itself is *not* a reliable indication of Success.  See
>>> RFC 3748 Section 4.2:
>>>
>>> Success and Failure packets MUST NOT be sent by an EAP authenticator
>>> if the specification of the given method does not explicitly permit
>>> the method to finish at that point.
>> This is fine.  What you might be concerned about is the nature of the 
>> signals that the EAP authenticator is receiving from TLS.  What you had in 
>> the case of TLS 1.2 was the stack providing bytes to send (which were to go 
>> in EAP-Request) and then, after everything is done, a positive signal saying 
>> that the handshake was complete and satisfactory.  That latter signal is the 
>> important one.
> Yes.  Part of what had me so unhappy about this document is that the
> Commitment Message is discussed only as a "promise to not send more
> handshake messages", not "an indication that the handshake is complete and
> the TLS layer is happy".  (Furthermore, what Alan writes below about
> "cannot distinguish a "finished authentication" EAP-Success from a
> "spoofed" EAP-Success" really needs to make its way into the document.)
>
>> TLS 1.3 muddies things by allowing bytes to be sent *after* the 
>> complete+satisfactory signal from TLS.  That's what you are grappling with 
>> here.  What I'm suggesting is that you don't rely on looking at what bytes 
>> hit the wire, but wait until two conditions are complete:
>>
>> 1. The TLS stack says that it is content: the handshake is complete and it 
>> is OK with whatever the other side has provided.
>> 2. The TLS stack has no more bytes to send.
>>
>> The latter is likely where the confusion comes from, but if the stack 
>> doesn't produce bytes when you give it bytes, then you don't need to keep 
>> waiting.  For what you depend on, that's enough.
> I agree that this is probably good enough.  There may be some complications
> depending on how badly the availability of session resumption is desired (I
> know OpenSSL provides an API to let the application requst a new session
> ticket regardless of whether any were sent with the initial handshake -- I
> wrote it -- though I need to tweak it so that it will not always wait for
> application data to send before sending the ticket), but I believe this
> provides the key functionality.
>
>> The mistake with sending application data is that there is no obligation on 
>> the part of the TLS stack to order its sending of NewSessionTicket relative 
>> to the application data.  Nor is is possible for you to correctly 
>> distinguish TLS data that contains your Confirmation Message from a record 
>> that just contains a little bit of a session ticket.  But you don't need to 
>> worry about that.
>>
>> An example might help illustrate:
>>
>> 1. ... many steps occur
>> 2. Client sends EAP-Response ending in a TLS Finished.
>> 3. Server reads that message, processes it and determines that the handshake 
>> is complete and acceptable (e.g., checks the client certificate against its 
>> policy).
>> 4. As the server is happy, it writes the Confirmation Message to TLS.
>> 5. Server asks TLS stack for outstanding data to write; TLS stack provides a 
>> bunch of application_data records.
> (In particular, this is the TLSCiphext content type that is
> "application_data", and the inner content type could be handshake or
> application data.  The application doesn't have visibility into it.)
>
>> 6. Server writes TLS records into an EAP-Request and sends it.
>> 7. Client receives this and sends an empty EAP-Response.
>> 8. Server sends EAP-Success.
>>
>> This is, I assume what you intend here, with a little more detail around 
>> steps 3-5.  But what 

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

[Joseph Salowey]

On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok  wrote:

> On Jan 3, 2021, at 10:44 PM, Martin Thomson  wrote:
> > # Key Schedule
> >
> > The other thing I observe is the way that this slices up the exporter
> output.  This was something that old versions of TLS did, but TLS 1.3 did
> away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.
> This could - and should - do the same.  All it means is having more
> exporter labels.
>
>   That's easy enough to change at this state.  The question is what are
> those labels?

  And, we're getting very close to needing an implementation soon.  RFC
> 8446 is over two years old.  Web services have started serious migration to
> TLS 1.3.  But we still don't even have a standard for EAP.  I suggest that
> this is an issue.
>
>   At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with
> the major EAP peer / server implementations.  This code is alpha, and not
> in any major release.  But we need to decide fairly soon what we're doing,
> as testing and releases take time.
>
>   The alternative is to dither around for another year or two, all the
> while relying on legacy TLS versions for 802.1X / WiFi authentication.
> i.e. packets which are trivially monitored by anyone with a WiFi card.
>
> > I appreciate that this uses exporters now rather than abusing the
> internal PRF.  That's good.  The next step is to dispense with the
> intermediate values (Key_Material, MSK, EMSK, IV) and all the slicing that
> occurs and use the TLS exporter for each of the six values that the
> protocol requires.  I also note that the 0x0D value is used multiple times,
> unnecessarily, both as a context strong to the exporter and as a prefix to
> the session ID.
>
>   If EAP-TLS was the only TLS-based EAP method, I would agree with you.
> But it's not.  Historically, each TLS-based EAP method uses it's own key
> derivations, using method-specific strings.  This practice made
> implementations more difficult and error-prone.
>

[Joe] It may be worth having separate exporter tags for EMSK and MSK.
(EXPORTER_EAP_TLS_MSK
and EXPORTER_EAP_TLS_EMSK).   I believe current applications define the use
EAP key material based on the MSK or EMSK.   The mechanism for splitting
the MSK into Enc-RECV-Key and Enc-SNED-Key I believe is only used in
specific legacy cases (WEP, MPPE?) and may still be the radius attributes
used in some deployments, so I don't think we should alter that
derivation.   I'm not sure where the IV is used, but I don't think
splitting it up more will be helpful.


>
>   The use of 0x0D is to allow standard key derivations across TLS-based
> EAP methods.  The other methods replaced the 0x0D byte with their own EAP
> type value.  This practice greatly simplifies implementations.
>
>   See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for
> more information.
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> e...@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Benjamin Kaduk]

Hi Martin,

Thanks for chiming in here; your insight has been quite helpful already.
(I am going to reply to the thread in reverse order so as to not duplicate
what you've already said.)

On Tue, Jan 05, 2021 at 02:50:15PM +1100, Martin Thomson wrote:
> Hi Alan,
> 
> On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote:
> > On Jan 4, 2021, at 6:26 PM, Martin Thomson  wrote:
> > > Your point about reliability is confusing.  I've read Section 4.2 of RFC 
> > > 3748 and while it says "A peer MUST allow for this circumstance as 
> > > described in this note.", I see no explanation of how to concretely make 
> > > that allowance.  Are you saying that EAP methods don't really use 
> > > EAP-Success and condition their behaviour on other signals?
> > 
> >   EAP-Success by itself is *not* a reliable indication of Success.  See 
> > RFC 3748 Section 4.2:
> > 
> >Success and Failure packets MUST NOT be sent by an EAP authenticator
> >if the specification of the given method does not explicitly permit
> >the method to finish at that point.
> 
> This is fine.  What you might be concerned about is the nature of the signals 
> that the EAP authenticator is receiving from TLS.  What you had in the case 
> of TLS 1.2 was the stack providing bytes to send (which were to go in 
> EAP-Request) and then, after everything is done, a positive signal saying 
> that the handshake was complete and satisfactory.  That latter signal is the 
> important one.

Yes.  Part of what had me so unhappy about this document is that the
Commitment Message is discussed only as a "promise to not send more
handshake messages", not "an indication that the handshake is complete and
the TLS layer is happy".  (Furthermore, what Alan writes below about
"cannot distinguish a "finished authentication" EAP-Success from a
"spoofed" EAP-Success" really needs to make its way into the document.)

> TLS 1.3 muddies things by allowing bytes to be sent *after* the 
> complete+satisfactory signal from TLS.  That's what you are grappling with 
> here.  What I'm suggesting is that you don't rely on looking at what bytes 
> hit the wire, but wait until two conditions are complete:
> 
> 1. The TLS stack says that it is content: the handshake is complete and it is 
> OK with whatever the other side has provided.
> 2. The TLS stack has no more bytes to send.
> 
> The latter is likely where the confusion comes from, but if the stack doesn't 
> produce bytes when you give it bytes, then you don't need to keep waiting.  
> For what you depend on, that's enough.

I agree that this is probably good enough.  There may be some complications
depending on how badly the availability of session resumption is desired (I
know OpenSSL provides an API to let the application requst a new session
ticket regardless of whether any were sent with the initial handshake -- I
wrote it -- though I need to tweak it so that it will not always wait for
application data to send before sending the ticket), but I believe this
provides the key functionality.

> The mistake with sending application data is that there is no obligation on 
> the part of the TLS stack to order its sending of NewSessionTicket relative 
> to the application data.  Nor is is possible for you to correctly distinguish 
> TLS data that contains your Confirmation Message from a record that just 
> contains a little bit of a session ticket.  But you don't need to worry about 
> that.
> 
> An example might help illustrate:
> 
> 1. ... many steps occur
> 2. Client sends EAP-Response ending in a TLS Finished.
> 3. Server reads that message, processes it and determines that the handshake 
> is complete and acceptable (e.g., checks the client certificate against its 
> policy).
> 4. As the server is happy, it writes the Confirmation Message to TLS.
> 5. Server asks TLS stack for outstanding data to write; TLS stack provides a 
> bunch of application_data records.

(In particular, this is the TLSCiphext content type that is
"application_data", and the inner content type could be handshake or
application data.  The application doesn't have visibility into it.)

> 6. Server writes TLS records into an EAP-Request and sends it.
> 7. Client receives this and sends an empty EAP-Response.
> 8. Server sends EAP-Success.
> 
> This is, I assume what you intend here, with a little more detail around 
> steps 3-5.  But what happens if the TLS stack prioritizes application data 
> above its own maintenance such that at step 5 the Confirmation Message is 
> written to the wire before the TLS NewSessionTicket?  Is that a problem?  
> What validation is the client expected to perform at step 7?

I would like to see a more precise description of what properties are
actually needed by peer and responder here, yes.  I agree that TLS 1.3 has
changed things compared to 1.2, but the text currently in the draft doesn't
do very well to motivate why this information is important, and (at least
to me) doesn't give a strong enough justification to 

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

[Martin Thomson]

Hi Alan,

On Tue, Jan 5, 2021, at 14:05, Alan DeKok wrote:
> On Jan 4, 2021, at 6:26 PM, Martin Thomson  wrote:
> > Your point about reliability is confusing.  I've read Section 4.2 of RFC 
> > 3748 and while it says "A peer MUST allow for this circumstance as 
> > described in this note.", I see no explanation of how to concretely make 
> > that allowance.  Are you saying that EAP methods don't really use 
> > EAP-Success and condition their behaviour on other signals?
> 
>   EAP-Success by itself is *not* a reliable indication of Success.  See 
> RFC 3748 Section 4.2:
> 
>Success and Failure packets MUST NOT be sent by an EAP authenticator
>if the specification of the given method does not explicitly permit
>the method to finish at that point.

This is fine.  What you might be concerned about is the nature of the signals 
that the EAP authenticator is receiving from TLS.  What you had in the case of 
TLS 1.2 was the stack providing bytes to send (which were to go in EAP-Request) 
and then, after everything is done, a positive signal saying that the handshake 
was complete and satisfactory.  That latter signal is the important one.

TLS 1.3 muddies things by allowing bytes to be sent *after* the 
complete+satisfactory signal from TLS.  That's what you are grappling with 
here.  What I'm suggesting is that you don't rely on looking at what bytes hit 
the wire, but wait until two conditions are complete:

1. The TLS stack says that it is content: the handshake is complete and it is 
OK with whatever the other side has provided.
2. The TLS stack has no more bytes to send.

The latter is likely where the confusion comes from, but if the stack doesn't 
produce bytes when you give it bytes, then you don't need to keep waiting.  For 
what you depend on, that's enough.

The mistake with sending application data is that there is no obligation on the 
part of the TLS stack to order its sending of NewSessionTicket relative to the 
application data.  Nor is is possible for you to correctly distinguish TLS data 
that contains your Confirmation Message from a record that just contains a 
little bit of a session ticket.  But you don't need to worry about that.

An example might help illustrate:

1. ... many steps occur
2. Client sends EAP-Response ending in a TLS Finished.
3. Server reads that message, processes it and determines that the handshake is 
complete and acceptable (e.g., checks the client certificate against its 
policy).
4. As the server is happy, it writes the Confirmation Message to TLS.
5. Server asks TLS stack for outstanding data to write; TLS stack provides a 
bunch of application_data records.
6. Server writes TLS records into an EAP-Request and sends it.
7. Client receives this and sends an empty EAP-Response.
8. Server sends EAP-Success.

This is, I assume what you intend here, with a little more detail around steps 
3-5.  But what happens if the TLS stack prioritizes application data above its 
own maintenance such that at step 5 the Confirmation Message is written to the 
wire before the TLS NewSessionTicket?  Is that a problem?  What validation is 
the client expected to perform at step 7?

>   With TLS 1.3, we don't know if the authentication has completed until 
> the TLS layer sees either (a) CloseNotify, or (b) application data.  So 
> the EAP-TLS implementations cannot distinguish a "finished 
> authentication" EAP-Success from a "spoofed" EAP-Success.  Because the 
> EAP-TLS implementation has no idea of TLS is done, and therefore no way 
> to tell that the EAP-Success is permitted at this point in the 
> negotiation.

As I indicated in my response to Mohit, if the intent is to provide the client 
with a signal, then using TLS application data to do that is imperfect, but 
probably OK.  What would have been ideal is some EAP-layer message that is 
authenticated somehow.

>   Therefore, we need an explicit signal to the EAP-TLS layer that the 
> EAP-TLS method has finished.  Discussion on the list went back and 
> forth between CloseNotify and sending one octet of application data.  
> Implementations have done both.  The conclusion was that the one octet 
> of application data was slightly easier to implement.
> 
>   Plus, sending CloseNotify precluded the TLS layer from sending a TLS 
> Fatal Alert:  https://www.mail-archive.com/emu@ietf.org/msg03092.html, 
> which says in part:

I agree that sending a close_notify alert isn't ideal - during this process.  I 
also agree that making sure that genuine handshake failures are reported 
reliably using EAP-Request, that's just plain good sense.

I don't understand why you would want to send a fatal alert after successfully 
completing and accepting the handshake, but if that is something you care 
about, then that clearly rules out its use for signaling success.  I didn't 
suggest that.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Jan 4, 2021, at 6:26 PM, Martin Thomson  wrote:
> Your point about reliability is confusing.  I've read Section 4.2 of RFC 3748 
> and while it says "A peer MUST allow for this circumstance as described in 
> this note.", I see no explanation of how to concretely make that allowance.  
> Are you saying that EAP methods don't really use EAP-Success and condition 
> their behaviour on other signals?

  EAP-Success by itself is *not* a reliable indication of Success.  See RFC 
3748 Section 4.2:

   Success and Failure packets MUST NOT be sent by an EAP authenticator
   if the specification of the given method does not explicitly permit
   the method to finish at that point.

  With TLS 1.3, we don't know if the authentication has completed until the TLS 
layer sees either (a) CloseNotify, or (b) application data.  So the EAP-TLS 
implementations cannot distinguish a "finished authentication" EAP-Success from 
a "spoofed" EAP-Success.  Because the EAP-TLS implementation has no idea of TLS 
is done, and therefore no way to tell that the EAP-Success is permitted at this 
point in the negotiation.

  Therefore, we need an explicit signal to the EAP-TLS layer that the EAP-TLS 
method has finished.  Discussion on the list went back and forth between 
CloseNotify and sending one octet of application data.  Implementations have 
done both.  The conclusion was that the one octet of application data was 
slightly easier to implement.

  Plus, sending CloseNotify precluded the TLS layer from sending a TLS Fatal 
Alert:  https://www.mail-archive.com/emu@ietf.org/msg03092.html, which says in 
part:

...
If the Commitment Message is changed to close_notify, the TLS Fatal Alert would 
have to be changed to an EAP-Failure instead. The difference is that The TLS 
Fatal Alert can contain information such as 

   bad_certificate,  unsupported_certificate,  certificate_revoked,  
certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca, 
access_denied, etc. while EAP-Failure must not contain any additional data.
...

  As someone who supports end users, I am very opposed to removing this 
information.  802.1X authentication is hard enough to deploy correctly as it 
is.  If we require the use of CloseNotify for EAP-TLS and TLS 1.3, then a whole 
host of useful error messages just go away.  Errors which are used to debug 
real-world certificate compatibility issues.

  I can't think of many things worse for EAP-TLS than to replace a set of 
descriptive messages with a simple "Failed".  Was your certificate revoked?  
Failed.  Was it expired?  Failed.  Was the CA known?  Failed.  What went wrong? 
 Too bad for you, the only message you get is "Failed".

  End users and sysadmins will be cursing the standard for years.  And, trying 
to stick with something *useful*, such as TLS 1.2.

  My $0.02 is that the one byte of application data is less "pure" than a 
solution which relies on TLS negotiation.  But if using CloseNotify makes 
deployments substantially more difficult, then that is a very strong reason to 
avoid it.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Jan 4, 2021, at 9:40 AM, Eric Rescorla  wrote:
>   That's easy enough to change at this state.  The question is what are those 
> labels?
> 
> They're just strings, so as long as they don't conflict, it's largely up to 
> the EAP WG.

  My point was more that we cannot afford to wait another year or two to pick 
these labels.  This work is becoming timely, and there is no reason to delay it 
any more.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Eric Rescorla]

On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok  wrote:

> On Jan 3, 2021, at 10:44 PM, Martin Thomson  wrote:
> > # Key Schedule
> >
> > The other thing I observe is the way that this slices up the exporter
> output.  This was something that old versions of TLS did, but TLS 1.3 did
> away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.
> This could - and should - do the same.  All it means is having more
> exporter labels.
>
>   That's easy enough to change at this state.  The question is what are
> those labels?
>

They're just strings, so as long as they don't conflict, it's largely up to
the EAP WG.

-Ekr

  The alternative is to dither around for another year or two, all the
> while relying on legacy TLS versions for 802.1X / WiFi authentication.
> i.e. packets which are trivially monitored by anyone with a WiFi card.
>
> > I appreciate that this uses exporters now rather than abusing the
> internal PRF.  That's good.  The next step is to dispense with the
> intermediate values (Key_Material, MSK, EMSK, IV) and all the slicing that
> occurs and use the TLS exporter for each of the six values that the
> protocol requires.  I also note that the 0x0D value is used multiple times,
> unnecessarily, both as a context strong to the exporter and as a prefix to
> the session ID.
>
>   If EAP-TLS was the only TLS-based EAP method, I would agree with you.
> But it's not.  Historically, each TLS-based EAP method uses it's own key
> derivations, using method-specific strings.  This practice made
> implementations more difficult and error-prone.
>
>   The use of 0x0D is to allow standard key derivations across TLS-based
> EAP methods.  The other methods replaced the 0x0D byte with their own EAP
> type value.  This practice greatly simplifies implementations.
>
>   See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for
> more information.
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> e...@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Alan DeKok]

On Jan 3, 2021, at 10:44 PM, Martin Thomson  wrote:
> # Key Schedule
> 
> The other thing I observe is the way that this slices up the exporter output. 
>  This was something that old versions of TLS did, but TLS 1.3 did away with.  
> Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.  This could - 
> and should - do the same.  All it means is having more exporter labels.

  That's easy enough to change at this state.  The question is what are those 
labels?

  And, we're getting very close to needing an implementation soon.  RFC 8446 is 
over two years old.  Web services have started serious migration to TLS 1.3.  
But we still don't even have a standard for EAP.  I suggest that this is an 
issue.

  At this point, we have inter-operability of TLS 1.3 for EAP-TLS, with the 
major EAP peer / server implementations.  This code is alpha, and not in any 
major release.  But we need to decide fairly soon what we're doing, as testing 
and releases take time.

  The alternative is to dither around for another year or two, all the while 
relying on legacy TLS versions for 802.1X / WiFi authentication.  i.e. packets 
which are trivially monitored by anyone with a WiFi card.

> I appreciate that this uses exporters now rather than abusing the internal 
> PRF.  That's good.  The next step is to dispense with the intermediate values 
> (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and use the TLS 
> exporter for each of the six values that the protocol requires.  I also note 
> that the 0x0D value is used multiple times, unnecessarily, both as a context 
> strong to the exporter and as a prefix to the session ID.

  If EAP-TLS was the only TLS-based EAP method, I would agree with you.  But 
it's not.  Historically, each TLS-based EAP method uses it's own key 
derivations, using method-specific strings.  This practice made implementations 
more difficult and error-prone.

  The use of 0x0D is to allow standard key derivations across TLS-based EAP 
methods.  The other methods replaced the 0x0D byte with their own EAP type 
value.  This practice greatly simplifies implementations.

  See https://tools.ietf.org/html/draft-dekok-emu-tls-eap-types-00 for more 
information.

  Alan DeKok.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Thomson]

On Mon, Jan 4, 2021, at 17:18, Joseph Salowey wrote:
> [Joe] I'm not sure I remember correctly, but I think the commitment 
> message was to make the integration with EAP statement machine cleaner 
> and perhaps to future proof against additional messages sent after the 
> handshake.  I tend to agree that the value is low in the current 
> situation (It is a deviation from RFC 5216).   Given all the discussion 
> this message has caused I'm tempted to agree that we should just remove 
> it (or make it "optional" in case implementations already do this).  
> There may need to be some text in the draft that says the 
> NewSessionTicketMessage must be sent in the same flight as the finished 
> message. I'd like to understand if there is an implementation 
> consideration that requires the commitment message.   

That might be possible, but many implementations won't be happy with that 
requirement.  Some implementations, particularly those that use tickets rather 
than server state, can't send NewSessionTicket until they have the client 
Certificate.

> > # Key Schedule
> > 
> > The other thing I observe is the way that this slices up the exporter 
> > output.  This was something that old versions of TLS did, but TLS 1.3 did 
> > away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.  
> > This could - and should - do the same.  All it means is having more 
> > exporter labels.
> > 
> > I appreciate that this uses exporters now rather than abusing the internal 
> > PRF.  That's good.  The next step is to dispense with the intermediate 
> > values (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and 
> > use the TLS exporter for each of the six values that the protocol requires. 
> >  I also note that the 0x0D value is used multiple times, unnecessarily, 
> > both as a context strong to the exporter and as a prefix to the session ID.
> > 
> [Joe]  I can see your point, but I don't think the way the keys are 
> derived is wrong and don't really see the need to change it at this 
> point.  

Depends on what you consider "wrong".  In TLS, we did this so that you could 
exercise good key hygiene.  If you are backing this with PKCS#11, then you 
might prefer not to be exporting the value of keys just so that you can do some 
slicing and then re-import the same value.  I see no reason that EAP would be 
above this.


> [Joe] yes, however I think the agreement during the chartering was that it 
> would 
> just update and not obsolete RFC 5216. 

Given the magnitude of the change, I don't see what this gains you other than a 
document that is really hard to use.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Joseph Salowey]

Hi Martin,

Thanks for taking a look at this, some comments below:

On Sun, Jan 3, 2021 at 7:45 PM Martin Thomson  wrote:

> Hi All,
>
> Ben asked me to take a look at this draft and I think that the general
> gist of Ben's comments need some careful consideration.
>
> # Commitment Message
>
> I think that Ben's concerns about the Commitment Message are justified,
> but aren't as bad a layering violation as observed (almost).  It would be
> annoying and difficult to implement this correctly, but not impossible.
> We've done much worse in QUIC.
>
> However, it would be much better not to include the Commitment Message at
> all.
>
> In addition to the reasons Ben describes, I have a much simpler one: the
> EAP layer has a signal that the protocol is complete: EAP-Success.  The
> only thing that the Commitment Message adds to that is a very narrow form
> of authentication.  The cost of that authentication is fairly significant,
> as Ben identifies, but what it gets you is a strong assurance that the
> messages preceding it were not truncated.
>
> As both entities have to verify that the TLS handshake was successfully
> completed independent of any EAP signals, the only thing the Commitment
> Message provides is the assurance that an attacker didn't insert or remove
> any post-handshake messages.  Any inserted messages would still need to be
> authentic, so given that a server won't send stuff it isn't permitted to
> (unless it likes failures), the exposure is minimal.  The only real
> "attack" I can see based on the current design is the removal of
> NewSessionTicket.  The effect of that attack is limited to denying the
> client access to resumption.  This is something we live with in other TLS
> usage contexts; EAP can probably manage too.
>
> The draft does not attempt to apply similar protection to client messages,
> despite having the same theoretical problem.
>
> I also think that the idea that you might get a TLS Alert after declaring
> success is odd.  I don't see any cause to keep the TLS session active after
> declaring success.  I would also remove EAP-Failure (for TLS reasons at
> least) after EAP-Success from the state machine.  TLS state can be
> discarded once EAP-{Success|Failure} is sent and received.
>
> I would instead either prohibit the use of application data outright or
> say that it carries no semantics unless otherwise negotiated.  The current
> design has the effect of rendering application data unusable, so perhaps
> the former is best.
>
>
[Joe] I'm not sure I remember correctly, but I think the commitment message
was to make the integration with EAP statement machine cleaner and perhaps
to future proof against additional messages sent after the handshake.  I
tend to agree that the value is low in the current situation (It is a
deviation from RFC 5216).   Given all the discussion this message has
caused I'm tempted to agree that we should just remove it (or make it
"optional" in case implementations already do this).  There may need to be
some text in the draft that says the NewSessionTicketMessage must be sent
in the same flight as the finished message. I'd like to understand if there
is an implementation consideration that requires the commitment message.


> # Key Schedule
>
> The other thing I observe is the way that this slices up the exporter
> output.  This was something that old versions of TLS did, but TLS 1.3 did
> away with.  Though RFC 5216 did this, EAP-TLS for TLS 1.3 doesn't need to.
> This could - and should - do the same.  All it means is having more
> exporter labels.
>
> I appreciate that this uses exporters now rather than abusing the internal
> PRF.  That's good.  The next step is to dispense with the intermediate
> values (Key_Material, MSK, EMSK, IV) and all the slicing that occurs and
> use the TLS exporter for each of the six values that the protocol
> requires.  I also note that the 0x0D value is used multiple times,
> unnecessarily, both as a context strong to the exporter and as a prefix to
> the session ID.
>
> [Joe]  I can see your point, but I don't think the way the keys are
derived is wrong and don't really see the need to change it at this point.


> # Editorial Nits
>
> I found the way that this updates RFC 5216 to be extremely difficult to
> process.  Section 2.1.4 (which updates Section 2.1.3...) is particularly
> nasty to read.
>
> RFC 5216 is a short document; obsoleting it completely would have been my
> preferred approach.  There is enough new material in this document that
> applies to TLS 1.2 as well as TLS 1.3 to justify a revision rather than a
> patch.
>
> [Joe] yes, however I think the agreement during the chartering was that it
would just update and not obsolete RFC 5216.


> Section 5.4 "EAP--TLS" has two hyphens.
>
> On Thu, Dec 17, 2020, at 09:38, Benjamin Kaduk wrote:
> > Hi TLS WG,
> >
> > I'm forwarding my ballot comments on the (now-deferred) EAP with TLS 1.3
> > draft here, since they relate to some rather core TLS protocol