[Emu] Call for Agenda items for IETF 119

[Joseph Salowey]

Please let the chairs know if you have any agenda items for the EMU meeting
at IETF 119.

Thanks,

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

[Emu] RFC 7170 bis

[Joseph Salowey]

We are nearing completion of RFC7170bis.   There are a few open issues in
github - https://github.com/emu-wg/rfc7170bis/issues

Issue 21  - links to the
errata to verify that they have been addressed in the draft and provides
text for resolving the errata.  In many cases it might be easier to resolve
as "wait for document update".  Please review to make sure the errata have
been correctly addressed.

Issue 20  - we are waiting
on some flows on PKCS #10/#7 - I think Eliot has this action item.
Issue 8  - is also a related
item, perhaps these can be addressed together.

Issue 17  - this is a
request to add mandatory to implement ciphersuites.  Some more discussion
is needed on this.

Issue 15  - Discusses an
issue with chained EAP methods and proposes that we add some text and a new
error message to address this problem.  Do people think this needs
addressing?

Once we resolve these issues we can move the draft forward.

Cheers,

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

Re: [Emu] Q: TEAP and inner-method challenges

[Joseph Salowey]

On Mon, Jun 5, 2023 at 9:23 PM Alan DeKok  wrote:

>   In TTLS, any inner method challenge (CHAP / MS-CHAP) is tied to the TLS
> session:
>
> https://www.rfc-editor.org/rfc/rfc5281.html#section-11.2.3
>
>   ... Upon receipt of these AVPs from the client, the TTLS server MUST
>verify that the value of the MS-CHAP-Challenge AVP and the value of
>the Ident in the client's MS-CHAP-Response AVP are equal to the
>values generated as challenge material.  If either item does not
>match exactly, the TTLS server MUST reject the client.  Otherwise, it
>forwards the AVPs to the AAA/H in an Access-Request.
>
>   Something similar is done for EAP-FAST, which TEAP is based on:
>
> https://datatracker.ietf.org/doc/html/rfc5422#section-3.3
>
>   ... Portions of the extra 72 octets are used for the EAP-FAST
>provisioning exchange session key seed and as the random challenges
>in the EAP-FAST-MSCHAPv2 exchange.
>
>
>   The question is whether we need something similar for TEAP.
>
>   TEAP has a Crypto-Binding TLV which binds the inner methods via their
> MSK / EMSK, which is good.  But do we need to enforce binding of the
> challenges to the TLS session, too?
>
>   Given that this isn't currently being done in implementations, I think
> that the answer here is "no".  But it's likely worth adding a note to the
> effect that:
>
> [Joe]  I would also say no here.



> * EAP methods such as EAP-MD5 and EAP-MSCHAPv2 rely in part on random
> challenges for their security in non-TEAP uses
>
> * these methods can be tunneled inside of TEAP phase 2
>
> * there is no crypto binding of the challenges used here to the outer TEAP
> session
>
> * however, the results of the authentication bound to the TEAP session via
> the Crypto-Binding TLV.



>
>
  Since EAP-MD5 doesn't generate inner keying material, it might be worth
> banning EAP-MD5 for use in TEAP.  Otherwise it is possible for MITM attacks.
>
> [Joe] I'm in favor of banning EAP-MD5 for this and other reasons.


>   EAP-MSCHAPv2 does generate keying material, so it shouldn't have this
> issue.
>
> [Joe] Yes it seems the protection should mostly be the same.


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

[Emu] Working group Last Call for RFC 7170bis

[Joseph Salowey]

This is the working group last call for draft-ietf-emu-rfc7170bis-05 [1].
Please review the draft and send comments to the list or open issues in
GitHub [2].   Further discussion on the open issues will be considered as
part of the last call. The last call ends March 24, 2023.  The chairs would
appreciate earlier reviews so we can plan to resolve issues during our
Monday meeting on the 27th.

Thanks,

Peter and Joe
[1] https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis
[2] https://github.com/emu-wg/rfc7170bis/issues
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Roman Danyliw's No Objection on draft-ietf-emu-tls-eap-types-12: (with COMMENT)

[Joseph Salowey]

Thanks Alan, your text looks good.

On Thu, Feb 16, 2023 at 5:48 AM Alan DeKok 
wrote:

> On Feb 16, 2023, at 1:28 AM, Joseph Salowey  wrote:
> > [Joe] I think having a separate section in the security considerations
> for Session Resumption is a good idea.   A few comments on the text below
> since I think there is a potential difference between how TTLS  recommends
> overloading newSessionTicket as a protected result indicator and uses of
> NesSessionTicket in other methods where it can be used for session
> resumption of TLS while still executing an inner method.
>
>   OK
>
> > This separation of data allows for a "time of use, time of check"
> > security issue.  Malicious clients can begin a session and receive a
> > NewSessionTicket message.  The malicious client can then abort the
> > authentication session, and use the obtained NewSessionTicket to
> > "resume" the previous session.  The malicious client can then obtain
> > network access without ever being authenticated.
> >
> > [Joe]  I suggest changing the last sentence to:
> >
> > "If the server assumes the ticket was issued after the client was
> authenticated then,
> > the malicious client can then obtain network access without ever being
> authenticated. "
>
>   It's the "server" as whole, but really the TLS implementation.  A naive
> EAP implementation can "hand off" all TLS work to a TLS library.  The
> library then magically allows resumption and the EAP server has a security
> issue.   Perhaps change it to:
>
> If the server allows the session to
> resume without verifying that the user had first been authenticated,
> the malicious client can then obtain network access without ever being
> authenticated network access without ever being authenticated.
>
> > As a result, EAP servers MUST NOT permit sessions to be resumed until
> > after authentication has successfully completed.  This requirement may
> > be met in a number of ways.  Where possible, implementations SHOULD
> > NOT send TLS NewSessionTicket messages until the "inner tunnel"
> > authentication has completed successfully.  However, the interaction
> > between EAP implementations and any underlying TLS library may be
> > complex, and this behavior may not always be possible.
> >
> >
> > [Joe] How about the following.
>
>   I find the suggested text a bit harder to read.  For me, there is a
> clear distinction between the EAP application, and the underlying TLS
> library it uses.  Microsoft has a common TLS library used by multiple
> applications.  OpenSSL plays a similar role elsewhere.
>
>   It's a good idea to suggest re-running the inner method on resumption
> where session tickets cannot be validated.  And also that policies can
> control whether resumed sessions are resumed, or the inner methods are
> run.  This is how my software works, and it's good to explain those issues
> in this document.
>
>   After some major rework, how about the following text.  For me, it goes
> through all possibilities in excruciating detail.  I can say this is what
> implementors need, because I've run into pretty much all of these issues.
>
> As a result, EAP servers MUST NOT assume that a user has been
> authenticated simply because a TLS session is being resumed.  Even if
> a session is being resumed, an EAP server MAY have policies which
> still force the inner authentication methods to be run.  For example,
> the users password may have expired in the time interval between first
> authenticaction, and session resumption.
>
> The guidelines given here therefore describe situations where an EAP
> server is permitted to allow session resumption, not where it is
> required to allow session resumption.  An EAP server could simply
> refuse to issue session tickets, or could run the full inner
> authentication even if a session was resumed.
>
> Where session tickets are used, the EAP server SHOULD track the
> successful completion of an inner authentication, and associate that
> status with any session tickets issued for that session.  This
> requirement can be met in a number of different ways.
>
> One way is for the EAP server to simply not send any TLS
> NewSessionTicket messages until the inner authentication has completed
> successfully.  The EAP server then knows that the existence of a
> session ticket is proof that a user was authenticated, and the session
> can be resumed.
>
> Another way is for the EAP server to simple discard or invalidate any
> session tickets until after the inner authentication has
> completed successfully.  When the user is authenticated, a new TLS
> NewSessi

Re: [Emu] Roman Danyliw's No Objection on draft-ietf-emu-tls-eap-types-12: (with COMMENT)

[Joseph Salowey]

On Wed, Feb 15, 2023 at 7:29 PM Alan DeKok 
wrote:

> On Feb 15, 2023, at 9:53 PM, Roman Danyliw via Datatracker <
> nore...@ietf.org> wrote:
> > ** Section 2.4
> >   It is therefore RECOMMENDED that EAP servers always send a TLS
> >   NewSessionTicket message, even if resumption is not configured.  When
> >   the EAP peer attempts to use the ticket, the EAP server can instead
> >   request a full authentication.  Implementations SHOULD NOT send
> >   NewSessionTicket messages until the "inner tunnel" authentication has
> >   completed, in order to take full advantage of the message as a
> >   protected success indication.
> >
> > It is my understanding that this SHOULD NOT is based in implementation
> > realities.  Can text be added to establish the basis for this not being
> “MUST
> > NOT”.  Please also add cross-references as appropriate into the document
> on the
> > same topic.
>
>   The issue is discussed in more detail in the Security Considerations
> section.  I'll add some text here which references RFC 8446 Section 4.6.1.
>
>   In short, TLS 1.3 allows for NewSessionTicket to be sent from the
> server, even before the application data has been processed.  This means
> that a client could connect, get a ticket, disconnect, and then immediately
> "resume" the session, without ever being fully authenticated.
>
>   As a result, EAP implementations have to either reject session tickets
> which were sent before the user was authenticated, or delay sending
> NewSessionTicket until after the user has been authenticated.
>
>   On closer examination, the text about NewSessionTicket is in the "TTLS"
> section, but is really applicable to all TLS-based EAP methods.  I'll move
> the text from the Security Considerations section to a new section
> discussing TLS NewSessionTicket messages in more detail.  Here's some new
> text:
>
>
[Joe] I think having a separate section in the security considerations for
Session Resumption is a good idea.   A few comments on the text below since
I think there is a potential difference between how TTLS  recommends
overloading newSessionTicket as a protected result indicator and uses of
NesSessionTicket in other methods where it can be used for session
resumption of TLS while still executing an inner method.


> Section "Handling of TLS NewSessionTicket Messages"
>
> In some cases, client certificates are not used for TLS-based EAP
> methods.  In those cases, the user is authenticated only after
> successful completion of the inner tunnel authentication.  However,
> [RFC84346] Section 4.6.1 allows that "At any time after the server has
> received the client Finished message, it MAY send a NewSessionTicket
> message."  This message is sent by the server before the inner
> authentication method has been run, and therefore before the user has
> been authenticated.
>
> This separation of data allows for a "time of use, time of check"
> security issue.  Malicious clients can begin a session and receive a
> NewSessionTicket message.  The malicious client can then abort the
> authentication session, and use the obtained NewSessionTicket to
> "resume" the previous session.  The malicious client can then obtain
> network access without ever being authenticated.
>
>
[Joe]  I suggest changing the last sentence to:

"If the server assumes the ticket was issued after the client was
authenticated then,
the malicious client can then obtain network access without ever being
authenticated. "


> As a result, EAP servers MUST NOT permit sessions to be resumed until
> after authentication has successfully completed.  This requirement may
> be met in a number of ways.  Where possible, implementations SHOULD
> NOT send TLS NewSessionTicket messages until the "inner tunnel"
> authentication has completed successfully.  However, the interaction
> between EAP implementations and any underlying TLS library may be
> complex, and this behavior may not always be possible.
>
>
[Joe] How about the following.

"The interaction between EAP implementations and any underlying TLS library
may be
complex, and the server may not be able to guarantee when a session is
cached
or what information is associated with the cached session.  It is up to the
EAP
server to ensure that it does not allow for insecure uses of EAP. In these
cases the server MUST assume that inner authentication has not completed
and it MUST run the inner authentication methods in the resumed tunnel
before granting
access.  If the server is able to include the state of the client's
authentication in the cached
session state or if the server can guarantee that the newSessionTicket
message is only sent
after successful authentication, then it MAY have a policy that uses this
information to skip
inner methods."



> Is is up to the EAP server to ensure that it does not allow for
> insecure uses of EAP.  It may not be possible to delay the TLS
> NewSessionTicket messages until the "inner tunnel" authentication has
> completed successfully.  In that c

Re: [Emu] RFC7170bis and lack of identities

[Joseph Salowey]

On Thu, Feb 2, 2023 at 11:17 AM Alan DeKok 
wrote:

> On Feb 2, 2023, at 1:52 PM, Alexander Clouter 
> wrote:
> >>  I'm not clear how that would happen.  Nothing in the doc discusses
> >> how a client may choose authentication methods.
> >
> > The documentation does not but I did see Appendix C.9 lets the client
> state what it wants to do:
> >
> >
> https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc7170bis-03#name-c9-peer-requests-inner-meth
>
>   i.e. the client authenticates in phase 1, via something like a client
> cert.
>
>   That flow does look a little odd to me:
>
> EAP-Response/
>   EAP-Type=TEAP, V=1
>   [TLS certificate,]
>TLS client_key_exchange,
>   [TLS certificate_verify,]
>TLS change_cipher_spec,
>TLS finished ->
>   <- EAP-Request/
>   EAP-Type=TEAP, V=1
>   (TLS change_cipher_spec,
>TLS finished,
>Crypto-Binding TLV (Request),
> Result TLV (Success))
>
>
>   So... the first set of data in the tunnel is Crypto-Binding?  Hmm..
>
>   I'll have to test that to see if it works.
>
>
[Joe]  The intent here was that the client authenticated using a
certificate during the TLS handshake and that the server viewed this as
sufficient to meet the authentication requirements, but the client requires
another method to be executed so it uses the request action frame to start
up a new exchange.   Example C4 shows TLS client authentication with
renegotiation, but it seems a bit weird to me in that it is client
initiated in response to a server EAP-IDentity Request.

Did you find out if any of this is supported?

> Using the Identity-Hint TLV to steer the server so at least it knows if
> it is machine or a user authentication coming its way is useful. Some if
> not most sites should find this good enough for them.
> >
> > Though if you are proposing this to be optional, why not define another
> new TLV the client MAY send with Identity-Hint TLV that takes the place of
> the EAP-Identity response for only when it wants to go and do
> Basic-Password-Auth.
>
>   I think it would just need Identity-Hint?
>
> Identity-Hint "bob" -->
>
> <-- Basic-Password-Auth-Req
>
> Basic-Password-Auth-Resp  "bob" password "hello" -->
>
> > To trim a round trip, you could add language on for servers supporting
> this MAY wish to treat this as a username if the server would only send a
> Basic-Password-Auth-Req asking for the same information anyway...to trim a
> round trip.
> >
> > I'm unable to think of a time why you would respond to a username
> request differently for an inner method, so it should be safe...mostly.
>
>   Different authentication types required for user / machine auth?
> Password for users, and EAP-TLS for machines?
>
>   For me it's also partly about not forbidding certain work flows.  Right
> now, "select auth based on identity" is either impossible, or requires
> extra "oopsie" packet exchanges.  That doesn't seem right.
>
>
[Joe] Although this seems OK, I'd rather be removing things than adding
things. I think we should make sure that the working group wants this.


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

[Emu] Canceling January 18 EMU interim

[Joseph Salowey]

I don't think we have much to discuss this week, so I am going to cancel
this week's interim.  Please continue to discuss issues on the list and
suggest PRs on github.

We will likely have another interim in February.

Thanks,

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

Re: [Emu] Question about rfc7170bis && PAC

[Joseph Salowey]

On Sun, Jan 15, 2023 at 7:40 AM Alan DeKok  wrote:

>   One of the questions which came up at the interim call was about the
> PAC.  The discussion there was that PAC support was in hostap, but no other
> implementations support it.
>
>   Even more, there didn't seem to be much support for implementing it.  So
> the question is, should we just drop PAC support from the document?
>
>   There are two good options that I can see:
>
> 1) delete all references to PAC from 7170bis, and replace them with a note
> that PAC is documented in 7170, but not implemented.  As a result, this
> document does not discuss the PAC.  But a future document might re-add it.
>
> 2) leave the text around PAC in, but add a note saying it's not
> implemented, and is untested.
>
>   Comments?  What's the best direction to go?
>
>
[Joe] Speaking as a contributor, I would rather see the text deleted if
no-one plans on implementing it. This would make the document simpler.


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

Re: [Emu] Question about rfc7170bis && PAC

[Joseph Salowey]

On Mon, Jan 16, 2023 at 7:36 AM Alan DeKok 
wrote:

> On Jan 16, 2023, at 9:53 AM, Alexander Clouter 
> wrote:
> > I was wondering what to do with A-ID[1] (and everything around PAC-Info)
> but starting to figure that as you can stuff anything you want into the
> opaque SessionTicket it really does not matter.
>
>   I think so, yes.  For one, A-ID is defined as:
>
> The A-ID is the identity of the authority that issued the PAC.
>
>   Since the Authority-ID is already sent (or should be sent) in the outer
> TLVs, this A-ID seems often superfluous.  But that's another issue. :(
>
>
[Joe] The authority-ID was meant to be sent from the server to the client
so the client could choose the right PAC to use to establish the session
with the server.  I don't think there is an equivalent for TLS tickets, so
perhaps it could be useful in this case.  However, since it only applies to
PAC, I would suggest that it shares the fate of the PAC text unless there
is a need for it.  A mechanism can be added later if the need arises.




> > Not aware this has even been implemented by anyone even for RADIUS
> (D)TLS yet, right?
>
>   FreeRADIUS supports TLS-PSK for both inbound and outbound
> RADIUS/(D)TLS.  It also supports TLS-PSK for EAP-TLS, and any other
> TLS-enabled EAP types.
>
> > Maybe time to hammer out a TLS-PSK implementation just to see what this
> looks and smells like? Previous RFC's have described that TLS-PSK is
> supported but someone here (or was it radext) pointed out that there is no
> mention of a PSK Identity which is needed not just the keying material.
>
>   Yes, that's been discussed in RADEXT.  (D)TLS-bis should describe how to
> do PSK.
>
> > Maybe I am mis-reading it but I think TLS-PSK has effectively been given
> the kibosh by RFC9190 section 2.1.1: "Pre-Shared Key (PSK) authentication
> SHALL NOT be used except for resumption"?
>
>   That's for EAP-TLS, and not for other EAP methods.  EAP-TLS has no other
> way to authenticate users, whereas TEAP could use additional methods inside
> of the TLS tunnel.
>
>   But it is a good reason to frown on TLS-PSK in TEAP, I think.
>

[Joe]  I can imagine use cases where TLS-PSK is used to establish a tunnel
for the initial provisioning of credentials,  but it might be good to limit
its use until a need is explicitly defined.


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

[Emu] Agenda for EMU interim on January 11

[Joseph Salowey]

EMU Interim - Wednesday 2023-01-11 09:00 PST
https://meetings.conf.meetecho.com/interim/?short=18b67a69-dc0a-498c-90b5-4ddd9dbfb5e4
https://datatracker.ietf.org/meeting/interim-2023-emu-02/session/emu

Agenda:
1. Errata 5770 and 5775.
2. Other technical issues with RFC 7170

Cheers,

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

[Emu] Proposed resolution for TEAP errata 5767

[Joseph Salowey]

Since this errata is about aligning terminology throughout the document I
propose that this resolution would be "Hold for Update" since it would
require editorial changes throughout the document.  We would still need to
resolve this issue in 7170bis.

Any objection to this errata resolution?

Thanks,

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

[Emu] Resolution for TEAP Errata 5128

[Joseph Salowey]

I think we still have an open issue with 5128.  The following resolutions
differ from what is currently in RFC7170bis.  Please review the text
changes below and indicate if it aligns with implementation and
discussion.

Thanks,

Joe

The definition of the TLS-PRF is given in 5246 as:

PRF(secret, label, seed) = P_(secret, label | seed)

This construction only defines 3 parameters and does not define a length.
I don't think current implementations include the length as an input to the
key derivation so I think the following is the correct resolution:

Original Text (Section 5.2):

The derivation
   of S-IMCK is as follows:

  S-IMCK[0] = session_key_seed
  For j = 1 to n-1 do
   IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
IMSK[j], 60)
   S-IMCK[j] = first 40 octets of IMCK[j]
   CMK[j] = last 20 octets of IMCK[j]

   where TLS-PRF is the PRF negotiated as part of TLS handshake
   [RFC5246].

Corrected Text (Section 5.2):

The derivation of S-IMCK is as follows:

  S-IMCK[0] = session_key_seed
  For j = 1 to n-1 do
   IMCK[j] = the first 60 octets of TLS-PRF(S-IMCK[j-1],
  "Inner Methods Compound Keys", IMSK[j])
   S-IMCK[j] = first 40 octets of IMCK[j]
   CMK[j] = last 20 octets of IMCK[j]

  The TLS-PRF is defined in [RFC5246] as

PRF(secret, label, seed) = P_(secret, label | seed),

  where "|" denotes concatenation.

  The secret is S-IMCK[j-1],  the label is ASCII value for the
  text "Inner Methods Compound Keys" without quotes,
  and the seed consists of IMSK[j].

In addition there are similar corrections to section 5.3

Original Text:

 MSK and EMSK are generated as part of the IMCKn key hierarchy as
   follows:

  MSK  = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)
  EMSK = TLS-PRF(S-IMCK[j],
   "Extended Session Key Generating Function", 64)

   where j is the number of the last successfully executed inner EAP
   method.

New Text (Section 5.3):

MSK = the first 64 octets of TLS-PRF(S-IMCK[j],
   "Session Key Generating Function")
  EMSK = the first 64 octets of TLS-PRF(S-IMCK[j],
   "Extended Session Key Generating Function")

  The TLS-PRF is defined in
  [RFC5246] as

PRF(secret, label, seed) = P_(secret, label | seed),

  where "|" denotes concatenation.

 The secret is S-IMCK[j]  where j is the number of the last generated
 S-IMCK from section 5.2.  The label is is the ASCII value for the
 string without quotes.  The seed is empty (0 length) and omitted from
 the derivation.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Resolution of TEAP Errata 5127

[Joseph Salowey]

According to the discussion in the interim last week and previous
discussions the resolution of errata 5127 should be as below.  Please
review the text change below and indicate if it aligns with discussion and
implementation.  It is intended that it matches the current draft of RFC7170bis
draft  (Commit

).

Thanks,

Joe

Type: Technical
Original Text:

IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
  "\0" | 64)

 where "|" denotes concatenation, EMSK is the EMSK from the inner
 method, "teapbind...@ietf.org" consists the ASCII value for the
 label "teapbind...@ietf.org" (without quotes), "\0" = is a NULL
 octet (0x00 in hex), length is the 2-octet unsigned integer in
 network byte order, and TLS-PRF is the PRF negotiated as part of
 TLS handshake [RFC5246].

Corrected Text:

IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org",
   0x00 || 0x00 || 0x40)

where "||" denotes concatenation and the TLS-PRF is defined in
[RFC5246] as

PRF(secret, label, seed) = P_(secret, label || seed).

The secret is the EMSK from the inner method, the label is
"teapbind...@ietf.org" consisting of the ASCII value for the
label "teapbind...@ietf.org" (without quotes),  the seed
consists of the "\0" null delimiter (0x00) and 2-octet unsigned
integer length in network byte order (0x00 || 0x4) specified
in [RFC5295].
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] TEAP erratum 5775

[Joseph Salowey]

On Tue, Jan 3, 2023 at 9:14 AM Alexander Clouter 
wrote:

> On Tue, 3 Jan 2023, at 14:16, Eliot Lear wrote:
>
> My expectation is that you use the EMSK from the outer-TLS authentication
> to do this calculation.
>
> However, I now understand your point about the *value* of doing this.
> Generating a Cryptobinding on the outer-TLS authentication does not protect
> the inner Request-Action-TLV.
>
> Yes.  The purpose of a crypto binding is to bind one *identity* to another.
>
>
> My (weak/dire) understanding of Cryptobinding is it does this, but a
> subtle effect is that the inner-TLVs after it also gain its protection
> somewhat.
>
> If you have a MitM attack taking place, a non-zero MSK based Cryptobinding
> is going to fail validation before any Request-Action-TLV's would be
> processed...so no harm done, right?
>
> Once the Cryptobinding passes the mustard, you have in effect spot checked
> there is no (active) MitM?
>
> This is really outside my expertise, so I am being very fluffy and hand
> wavy about it...sorry.
>
> [Joe]  I think you are on the right track.  Crypto binding was introduced
to prevent an inner method executed outside of TEAP from being redirected
into a TEAP tunnel by an MITM attacker.  When inner method keys are
generated the binding provides some assurance that the inner method
endpoints and the TLS endpoints are the same.  I think the main reason why
we decided to keep the cryptobinding TLVs even for non key generating
methods was to simplify the state machine the same.   The binding also
makes sure that the peer and server have the same notion of what has
succeeded and fails, but I'm not sure how valuable that is at this point.

> The place where that *might* be necessary is when PKCS#10/PKCS#7
> exchanges are made, where the RA/CA can prove that the enrollee is the same
> as the EAP peer (and visa versa).  What's important is that the CA not be
> duped into issuing a certificate to an intermediary.  But RFC 7170 Section
> 3.8.2 seems to cover that independent of CB.
>
>
>
[Joe] You do want to make sure that any authentication method that has run
has had a successful crypto-binding with the TLS tunnel to ensure that you
are not issuing a cert to a man in the middle.  The use of TLS unique in
the PKCS#10 in section 3.8.2 does replace this functionality of the crypto
binding.  I believe that the use of the TLS unique ensures that the PKCS 10
originates from the TLS peer instead of somewhere else.


> 3.8.2 does state "only after an authentication method has run and provided
> an identity proof on the peer prior to a certificate is being issued".
>
> Looks like you need something in there, which I suspect might be either
> re-running EAP-TLS but on the inside or decide the mutual authentication
> outside the tunnel suffices.
>
> I really have no idea.
>
> What am I missing?
>
>
> Probably nothing, I was fortunate enough to be able to ignore the
> Request-Action-TLV and the PKCS parts for our implementation.
>
> Thanks
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Reminder EMU WG Virtual Interim 2023-01-04

[Joseph Salowey]

The EAP Method Update (emu) WG will hold a virtual interim meeting on
2023-01-04 from 09:00 to 10:00 America/Los_Angeles (17:00 to 18:00 UTC).

Upcoming interim meetings are listed here -
https://datatracker.ietf.org/meeting/upcoming

Agenda:
1. TEAP Errata
a. https://www.rfc-editor.org/errata/rfc7170
b. some Proposed resolutions - https://github.com/emu-wg/teap-errata
2. TEAP Revision
a. https://datatracker.ietf.org/doc/draft-ietf-emu-rfc7170bis/
b. https://github.com/alandekok/rfc7170-bis

Information about remote participation:
https://meetings.conf.meetecho.com/interim/?short=1756daa0-b496-469f-aed3-1a61158f90b6
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EMU TEAP Interims

[Joseph Salowey]

Not everyone could make it at the same time so I attempted to set up a
series of meetings to go over the TEAP Errata and work on a revision in
January.

Wed January 4: 9:00-10:00 AM PT
Wed January 11: 9:00-10:00 AM PT
Wed January 18: 9:00-10:00 AM PT

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

[Emu] EMU Interim Dates

[Joseph Salowey]

We would like to hold an EMU interim to resolve TEAP errata and other TEAP
issues.  Here is a link for a doodle poll to find a date early next year
where folks can make it: https://doodle.com/meeting/participate/id/bq79gK2e.

If you plan on attending the interim please fill out the poll by Thursday
December 8.  I hope we can make some progress on kicking off TEAP revision
over the next few weeks as well.

Cheers,

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

Re: [Emu] [EXTERNAL] Re: More TEAP issues

[Joseph Salowey]

It sounds like we are gaining consensus to create a revision of TEAP.  The
emphasis would be (in priority order):

   - Aligning specification with current implementations
   - Clarifying the existing specification
   - Adding missing TLVs to make existing use cases work better

The goal is to get this revision done quickly to prevent further
implementation divergence.  Changes will need to go through the working
group process. Errata should be addressed when relevant portions of the
document are updated.

Does anyone object to this approach?

Thanks,

Joe and Peter

On Wed, Nov 30, 2022 at 12:48 PM Bruno Pereira Vidal  wrote:

> I also think option 3 is the preferred one at this point, given the
> interoperable implementations that have already shipped. In addition to
> Cisco ISE, the Windows TEAP implementation has also been validated against
> Aruba ClearPass.
>
> The person who implemented the Windows client code is no longer at
> Microsoft and, unfortunately, I don't recall why this ended up being
> implemented like this. It is likely that it was inadvertently inherited
> from EAP-FAST as mentioned below.
>
> Thanks,
> Bruno
>
> -Original Message-
> From: Emu  On Behalf Of Jouni Malinen
> Sent: Wednesday, November 30, 2022 10:33 AM
> To: Alexander Clouter 
> Cc: EMU WG 
> Subject: [EXTERNAL] Re: [Emu] More TEAP issues
>
> On Wed, Nov 30, 2022 at 03:01:08PM +, Alexander Clouter wrote:
> > On Tue, 29 Nov 2022, at 22:34, Alan DeKok wrote:
> > > Based on interoperability testing, it looks like implementations
> > > followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170:
>
> > EAP-FAST almost does not document this until you look at a latter RFC
> covering the provisioning component:
> >
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > rfc-editor.org%2Frfc%2Frfc5422%23section-3.2.3&data=05%7C01%7CBruno.Vi
> > dal%40microsoft.com%7C0e1894aabf524f8c70d708dad30154ed%7C72f988bf86f14
> > 1af91ab2d7cd011db47%7C1%7C0%7C638054299953760498%7CUnknown%7CTWFpbGZsb
> > 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%
> > 7C3000%7C%7C%7C&sdata=PqpDLwSPz0sh%2BsSlXadTZCAWI2835mdqgZvR2jN1Vgw%3D
> > &reserved=0
>
> And that section has a history of its own.. If you take a look at the
> latest draft (-10), that language is not there, i.e., it got added quite
> late in the process and the related discussions were not exactly
> considering this positively. If I remember correctly, this mismatch with
> how EAP-MSCHAPv2 was defined was seen as something that should not really
> have been done and the EAP-FAST-MSCHAPv2 was named such to be distinguished
> from EAP-MSCHAPv2 and also as a reminder not to use this variant for
> anything else than EAP-FAST (which had already been deployed with it).
> Nevertheless, here we are 15 years later hitting this exact same thing with
> TEAP having been deployed with the design that was not supposed to be
> repeated..
>
> > Really easy to miss for an implementer, especially as when you start
> implementing FAST (or TEAP) you begin with authentication and think you can
> ignore the PAC component at first.
>
> While I started working on TEAP implementation by copying FAST
> implementation to be the starting point, one of my first steps was to try
> to remove all the hacks needed to get EAP-FAST interoperable since I was
> familiar with the history.. But yes, it would be next to impossible to
> implement either EAP-FAST or EAP-TEAP based on just the RFCs and get to
> something that interoperates with anything already deployed.
>
> > The other biggy is that it is easy to miss that for each EAP method in a
> sequence, you need to include an EAP Identity response along with the
> Identity-Type TLV to the peer.
>
> And that will hopefully not include another instance of Crypto-Binding for
> the EAP-Identity exchange. This is related to one of my errata comments on
> EAP method vs. EAP authentication method (the latter needs crypto binding;
> the former probably does not, but RFC 7170 is not clear).
>
> > > 3) declare 7170  irretrievably broken, and write 7170bis which
> > > documents how TEAP version 1 operates in practice.
> >
> > This is my preference too.
>
> While this might not result in the cleanest protocol design, I'd agree
> that this is likely the best approach from the view point of getting
> something useful out there and into wider use.
>
>
> Regarding a separate comment about new TLVs (and new functionality in
> general, I'd guess), I have no significant issues including that in a new
> RFC, but I do hope that the initial focus would be in addressing the
> existing areas and already identified issues to get to a point where there
> is a clearly identifiable Internet-Draft describing how one can
> successfully implement EAP-TEAP in a manner that interoperates with
> deployed implementations.
>
> --
> Jouni MalinenPGP id EFC895FA
>
> _

Re: [Emu] More TEAP issues

[Joseph Salowey]

On Tue, Nov 29, 2022 at 2:35 PM Alan DeKok 
wrote:

>   Based on interoperability testing, it looks like implementations
> followed EAP-FAST for derivation of the MS-MPPE keys, and not RFC 7170:
>
> http://lists.infradead.org/pipermail/hostap/2022-July/040639.html
>
> http://lists.infradead.org/pipermail/hostap/2022-November/041060.html
>
>   I think this issue is larger than an errata.  We now have shipping code
> (Windows 10, Windows 11, and Cisco ISE at least) which don't follow RFC
> 7170.  But which do interoperate with each other.
>
>   Hostap / wpa_supplicant follows 7170, but doesn't interoperate with
> Windows.
>
>   FreeRADIUS is currently being updated to support TEAP.  For reasons of
> interoperability, we'd probably choose to follow Windows.
>
>   The question is what to do next?
>
>   I would suggest that at this point, shipping code is more important than
> theoretical specifications.  The implementors have shipped interoparable
> versions, and shipped millions of devices with a particular implementation.
>
>   So our choices are:
>
> 1) declare the implementations broken, and update 7170 with minor tweaks
> for what "should" happen.  New implementations will do ??? and current
> implementations will do ???
>
> 2) declare 7170 irretrievably broken, and write 7170bis which defines TEAP
> version 2.  That document can define TEAP behavior as ???
>
> 3) declare 7170  irretrievably broken, and write 7170bis which documents
> how TEAP version 1 operates in practice.
>
>   My preference would be (3).  I'd also prefer to get agreement in EMU
> that this is the way forward, so we can ship FreeRADIUS with a "correct"
> implementation.  I would very much prefer to not add to the mess by
> shipping code which fails to follow RFC 7170 and which also fails to follow
> existing implementations.
>
>   If the WG agrees, I'd be OK acting as editor for RFC 7170bis.  The goal
> would be to change as little as possible of the text.  Just fix the errata,
> and add a note saying "ignore 7170, as it's wrong".  99% of the text is OK,
> and can be left as-is.
>
> [Joe] speaking as a participant, I'd be happy to assist with a revision.
I think it is needed.  Most of the current errata are tracked here -
https://github.com/emu-wg/teap-errata/pulls.  I think the target would be
to obsolete 7170 with a revision that just fixes the errata and makes any
needed clarifications.  We can also work on posting the Errata, but the
revised document would be more effective at getting these issues fixed.


>   This issue is getting timely, as there is now strong customer demand for
> TEAP in Q1 / Q2 2023.  So it would be good to get consensus before going
> down any particular path.
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Presentations for Monday's meeting

[Joseph Salowey]

The EMU meeting (Agenda
) is
scheduled for Monday Afternoon (GMT).  If you are presenting please either
propose your slides in the data tracker or send them to the chairs.

Thanks,

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

[Emu] Publication has been requested for draft-ietf-emu-tls-eap-types-09

[Joseph Salowey via Datatracker]

Joseph Salowey has requested publication of draft-ietf-emu-tls-eap-types-09 as 
Proposed Standard on behalf of the EMU working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/


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

Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?

[Joseph Salowey]

I also notice that the document header says it updates RFC 5247 instead of
RFC 4851.



On Tue, Sep 20, 2022 at 12:50 PM Alan DeKok 
wrote:

> On Sep 10, 2022, at 3:59 AM, Alexander Clouter 
> wrote:
> > I have both implemented EAP-FAST and TEAP, and also slogged through the
> interoperability testing of the TLS 1.3 changes proposed here for EAP-TTLS
> and PEAP.
> >
> > This probably qualifies me to chip in here.
>
>   Thanks.
>
> > Section 2.2 - TEAP
> > --
> > I do not think changing the language for the definition of the MAC used
> for the Compound MAC was necessary.
>
>   I don't see if changing the definition that much,  There's just a
> reference to the previous section, which was changed.  That definition was
> just changed to use TLS-Exporter() instead of TLS-PRF().
>
>   Are there any other changes which need highlighting (or fixing) ?
>
> > If any wording changes need to be made, maybe to be more explicit in
> stating "the MAC from the handshake" or "cipher_suite from RFC8446 section
> 4.1.3"? I find the existing "section 7.1 of RFC 8446" wording unusable to
> someone trying to answer "what am I actually meant to do here?"
>
>   Do you have explicit text to suggest?
>
> > Maybe I am just dumb so someone can help join the dots for me, but as an
> implementer it is unclear to me how anyone could get from "look at RFC8446
> section 7.1" to "use SSL_CIPHER_get_handshake_digest()"?
>
>   Perhaps updating it to say:
>
> For TLS 1.3, the message authentication code (MAC) is computed with
> the HMAC algorithm negotiated for HKDF in the key schedule, as per
> section 7.1 of RFC 8446.  That is, the MAC used is the MAC derived
> from the TLS handshake.
>
>
> > Having a deep guru level of knowledge of RFC8446 should never be a
> prerequisite to implementing TEAP...or any standard.
>
>   Agreed.
>
> > Maybe I am the only one here who gets depressed when instructed to look
> at a TLS RFC to gain wisdom?
>
>   I'l take the fifth here.
>
> > Section 2.2.1 - Client Certificates [TEAP]
> > --
> > I think we should remove the unnecessary additional SSL handshake, as
> three full handshakes is getting excessive and life is too short for
> multi-second WAN authentications.
>
>   I agree that the layered TLS sessions are less than optimal.
>
> > On a practical note for this type of chained authentication we are
> already at the ~25 mark of the default limit of 50 EAP round trips that
> some EAP implementations (eg. hostapd and FreeRADIUS) set as the threshold
> of "things are now getting silly" and abort the conversion. This may thwart
> chaining future EAP methods.
>
>   Agreed.
>
> > Picking though our options, whilst Identity-Type TLV is needed to
> provide the EAP server on what is being authenticated, this TLV is also
> permitted as an outer-TLV in RFC7170 section 4.3.1.
> >
> > RFC7170 being an RFC that relishes in contradiction, section 4.2.3
> states this TLV MUST be passed alongside either an EAP-Payload or
> Basic-Password-Auth-{Req,Resp} which themselves are only permitted as
> inner-TLVs.
> >
> > Fortunately section 4.3.1 also states outer-TLVs MUST be marked optional
> which I see as the way to break out of this situation.
> >
> > I would propose allowing an Identity-Type outer-TLV during Phase 1 to
> provide the necessary hinting to support machine/user authentication.
>
>   That seems fine.  I'll update the section to say:
>
> However, an implementation may send Identity-Type as an outer-TLV, in
> which case a client certificate can be sent in Phase 1, and that
> client certificate MUST be associated with the referenced
> Identity-Type.
>
>
> > Only if it would help some people on the fence land a decision, I am
> willing to do some interoperability testing to verify that sending
> outer-TLVs in this manner does not cause any unintended consequences? If
> you are that person, let me know.
>
>   I don't see a problem with it.
>
> > Section 2.3 - EAP-FAST
> > --
> > I think you should be explicit that an implementer should now only look
> to session tickets for their PAC provisioning needs.
> >
> > Maybe something more like:
> >
> >  EAP-FAST previously used a PAC, which is functionally equivalent to
> >  session tickets provided by TLS 1.3 that contain a pre-shared key (PSK)
> >  along with other data. As such, the use of a PAC is deprecated for
> >  EAP-FAST in TLS 1.3. PAC provisioning [RFC5422] is also no longer part
> >  of EAP-FAST when TLS 1.3 is used.
>
>   Updated, thanks.  I'll add similar text for TEAP.
>
> > Section 2.4 - EAP-TTLS
> > --
> > I know that it is trying to communicate context is empty but it still
> looks like a typo, maybe instead:
> >
> >  EAP-TTLS_challenge = TLS-Exporter("ttls challenge", {}, n)
> >
> > Then highlight 'context={}' means 'empty'/'zero length' as per RFC8446
> Section 7.5?
>
>   The other EAP RFCs just use an empty context, and not {}.  So I'm OK
> with leaving that a

Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?

[Joseph Salowey]

On Sat, Sep 10, 2022 at 1:40 AM Alexander Clouter 
wrote:

> Hello,
>
> On Fri, Sep 09, 2022 at 05:35:26PM -0400, Alan DeKok wrote:
> >
> >> I guess the argument is that those are the labels that are used in TEAP
> (without exporter) and the same labels are used by EAP-FAST (with different
> method ID).  My main concern is that they labels are somewhat generic
> (session key seed, session key generating function)  which might lead to
> confusion.
> >
> >  It's a balance between that, and changing them to something different
> just for TLS 1.3.
> >
> >  Given the minimal feedback from implementors, I'd be inclined to change
> as little as possible.
>
> I for one appreciate the labels being made all the same; the
> implementations in hostapd and FreeRADIUS make it easier just just vary
> 'Type'.
>
> It also sets a precedence for future methods and maybe even TLS
> versions.
>
> Changing a label constant is less effort than moving from a PRF to
> TLS-Exporter and including 'Type' as context. I do not really think
> tweaking the contents of a label is an issue.
>
> When reading specs, I really appreciate the presence of a section on
> "differences to earlier versions" and this draft has that in the form of
> Section 2.1. Once published, RFC7170 will gain an 'updated by RFCwxyz'
> and implementers will find this information.
>
> Personally, I find the contents of all labels in RFCs meaningless and
> just treat them as constants that I am expected to push into my crypto
> key generating sausage machine.
>
> I rely on the *variable* naming far more than the values or functions
> that generate them. The variable naming guides me how to derive the
> answer and having fewer constants just makes this process easier.
>
>
[Joe] Thanks for taking a look at this Alex. looking at this issue some
more I think the labels mostly line up the RFC 7170 which I think is good
for implementers.  There is just one that doesn't

RFC 7170 label - "EXPORTER: teap session key seed"
 Current draft label - "EXPORTER: session key seed"

I think it would be helpful to make this change.



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

Re: [Emu] Working Group Last Call For EAP-AKA'-PFS

[Joseph Salowey]

Hi Folks,

I realize this call coincided with the end of summer vacation for some.  We
need some review of this document before we can move it forward.  Can a few
people commit to reviewing?

Thanks,

Joe

On Tue, Aug 16, 2022 at 1:41 PM Joseph Salowey  wrote:

> This is the working group last call for EAP-AKA’ PFS
> (draft-ietf-emu-aka-pfs-07)[1]. Please note that the document is targeted
> at the informational track and has IPR declarations[2]. Please review the
> document and respond to the list indicating if you think the document is
> ready or not for publication. This call will end on September 1, 2022.
>
> Thanks,
>
> Peter and Joe
>
> [1] https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/
> [2]
> https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-emu-aka-pfs
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?

[Joseph Salowey]

I've done a re-review of the TEAP section and I think it would be good to
move forward, but I have one question below.  The current plan for this
document is to resolve the issue and then submit the document (or revision
if necessary) to the IESG for publication.  If you have concerns about
including the EAP-FAST or TEAP sections of the document please respond to
this message.

Question:

Why do we use a different label for the TEAP session key seed in this
document:

 RFC 7170 label - "EXPORTER: teap session key seed"
 Current draft label - "EXPORTER: session key seed"

Do we need to use a different label or can we use the same one?
Also wouldn't it be better to start all of the exporter labels with
teap since these keys are specific to teap?

   * EXPORTER: session key seed
   * EXPORTER: Inner Methods Compound Keys
   * EXPORTER: Session Key Generating Function
   * EXPORTER: Extended Session Key Generating Function


I guess the argument is that those are the labels that are used in TEAP
(without exporter) and the same labels are used by EAP-FAST (with different
method ID).  My main concern is that they labels are somewhat generic
(session key seed, session key generating function)  which might lead to
confusion.

Cheers,

Joe


On Wed, Sep 7, 2022 at 6:54 AM Alan DeKok  wrote:

> On Sep 7, 2022, at 12:57 AM, Joseph Salowey  wrote:
> > I think we need to have some review of the EAP-FAST and TEAP sections
> before publication.  If we can't get the review then maybe we should remove
> those sections.  Is someone willing to step up and review these sections of
> the draft, preferably who has implementation experience?
>
>   I don't know of anyone who's implemented TLS 1.3 for FAST or TEAP.  The
> TEAP implementors are still working on interoperability for earlier
> versions of TLS.  i.e. there are pending patches to hostap / wpa_supplicant
> which help it interoperate with Windows.
>
>   I would suggest that the sections be left in, even if there is no
> feedback from implementors.  Perhaps add a warning to the sections saying
> "This is what is proposed, but at this time there is no implementation
> experience".
>
>   If it works, great.  If not, it's probably a minor errata.
>
>   The TEAP RFC was in exactly this situation for many years before people
> started implementing it.  I would argue that's ample precedent for saying
> "either people don't care, or it doesn't matter.  Just publish it"
>
>   It's better to have guidance which is mostly correct (but might be
> incorrect), than to give no guidance.  That makes it effectively impossible
> for implementors to upgrade to TLS 1.3.
>
>   Alan DeKok.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?

[Joseph Salowey]

I think we need to have some review of the EAP-FAST and TEAP sections
before publication.  If we can't get the review then maybe we should remove
those sections.  Is someone willing to step up and review these sections of
the draft, preferably who has implementation experience?

Thanks,

Joe

On Fri, Aug 12, 2022 at 1:24 PM Alan DeKok 
wrote:

> On Aug 12, 2022, at 4:00 PM, Joseph Salowey  wrote:
> > [Joe] The chairs are reviewing the status and will have an update next
> week.
>
>   Thanks.
>
> > [Joe]  Is the statement in the draft about lack of implementation
> experience with EAP-FAST and TEAP still accurate?
>
>   Yes.  I haven't seen any progress on EAP-FAST.  TEAP might actually
> work, as implementors are working on interoperability.  But the base TEAP
> spec still has issues unrelated to TLS 1.3.  So that might take a while to
> get finished.
>
> > You mentioned some interop issues in the meeting, are those issues on
> the path to getting resolved?
>
>   The interop issues were (a) a crash which is being worked on, and (b) a
> choice to not support session tickets for TTLS, which has been reported and
> is being addressed.
>
>   So not so much interop issues as implementation issues.
>
>   At this point. everything we know is in the document and is up to date.
> I think it's worth publishing.  Given the lack of interest in FAST / TEAP
> with TLS 1.3, I think that shouldn't be a barrier to publication.
>
>


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

[Emu] Working Group Last Call For EAP-AKA'-PFS

[Joseph Salowey]

This is the working group last call for EAP-AKA’ PFS
(draft-ietf-emu-aka-pfs-07)[1]. Please note that the document is targeted
at the informational track and has IPR declarations[2]. Please review the
document and respond to the list indicating if you think the document is
ready or not for publication. This call will end on September 1, 2022.

Thanks,

Peter and Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs/
[2]
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-emu-aka-pfs
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WG last call for draft-ietf-emu-tls-eap-types ?

[Joseph Salowey]

On Thu, Aug 11, 2022 at 4:07 AM Alan DeKok 
wrote:

>   Can we make some progress on the document? There have been no
> substantive comments for a while now.
>
>
[Joe] The chairs are reviewing the status and will have an update next week.


>   The document is finished, the code is interoperable across multiple
> implementations.
>
>
[Joe]  Is the statement in the draft about lack of implementation
experience with EAP-FAST and TEAP still accurate?

You mentioned some interop issues in the meeting, are those issues on the
path to getting resolved?


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

Re: [Emu] IETF 114

[Joseph Salowey]

You can also propose slides through the datatracker -
https://datatracker.ietf.org/meeting/114/session/emu


On Mon, Jul 25, 2022 at 9:38 AM Joseph Salowey  wrote:

> Please send your presentations for EMU at IETF 114 to the chairs.
>
> Thanks,
>
> Joe
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] IETF 114

[Joseph Salowey]

Please send your presentations for EMU at IETF 114 to the chairs.

Thanks,

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

[Emu] Draft EMU Agenda for IETF 114

[Joseph Salowey]

Draft EMU agenda is available here:

https://datatracker.ietf.org/meeting/114/materials/agenda-114-emu

And copied Below:
IETF 114 - EMU Agenda (draft)

Wednesday Session III
Wednesday, July 27, 2022 15:00-17:00 EDT
Philadelphia, Sheraton Downtown, Independence A/B
--

   1.

   Administrivia (5 Min)
   A. Note takers 
   B. Chat - xmpp:e...@jabber.ietf.org?join
   C. Video - Meetecho
   
   D. Onsite Tool
   
   2.

   Working Group Documents (40 Min)
   A. TLS-based EAP types and TLS 1.3
    (20 Min)
   B. EAP-AKA' FS
 (20
   Min)
   3. Non-Working group Items (40 Min)
   A. EAP-DPP  (15
   Min)
   B. EAP-EDHOC
    (15
   Min)
   C. EAP onboarding
   (10
   Min)
   4. Future of EMU (15 Min)
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Call for EMU agenda Items for IETF 114

[Joseph Salowey]

The EMU meeting is scheduled for  15:00-17:00 Wednesday Session III.
Please let the chairs know if you would like to present.  It would be
good to get updates from authors for the current working group items.

Thanks,

Joe


On Tue, May 31, 2022 at 9:10 AM Joseph Salowey  wrote:

> Please let the chairs know if you have items for discussion for the
> upcoming meeting in Philadelphia.
>
> Thanks,
>
> Joe
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Working Group Last Call for draft-ietf-emu-tls-eap-types

[Joseph Salowey]

This is the working group last call for draft-ietf-emu-tls-eap-types.  You
can find the document here:

https://datatracker.ietf.org/doc/html/draft-ietf-emu-tls-eap-types

Please respond to the list with comments by June 24, 2022.   Responses that
indicate that you have read the draft and think it is ready to move forward
are also useful.

Thanks,

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

[Emu] Call for EMU agenda Items for IETF 114

[Joseph Salowey]

Please let the chairs know if you have items for discussion for the
upcoming meeting in Philadelphia.

Thanks,

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

Re: [Emu] Call for Adaption for draft-chen-emu-eap-tls-ibs

[Joseph Salowey]

The chairs have reviewed the responses to the adoption call and they do not
see enough interest from the working group to adopt this draft. Only a few
active working group participants indicated they would review the draft.
The authors may take this draft to the independent submission process to
get a draft published and codepoints assigned.

Thanks,

Joe and Mohit

On Sun, Apr 10, 2022 at 8:35 PM Joseph Salowey  wrote:

> This is an adoption call for EAP-IBS (
> https://datatracker.ietf.org/doc/draft-chen-emu-eap-tls-ibs/
> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-chen-emu-eap-tls-ibs%2F&data=04%7C01%7Csethim1%40aaltofi.mail.onmicrosoft.com%7Cf3616098606341f5279008da15ccda7a%7Cae1a772440414462a6dc538cb199707e%7C1%7C0%7C637846267280657694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=wGEqJxy%2F6rW1iELDQxGkoLNNSfkRqHcxQTpDQK6Zrmg%3D&reserved=0>)
> as an EMU working group item.  Please respond to this call and answer the
> following questions by April 24, 2022:
>
> 1. Do you think this draft should be an EMU working group Item?
>
> 2. Would you contribute by reviewing this document?
>
> 3. Would you contribute text to this document?
>
> Thanks,
>
> The Chairs
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Call for Adaption for draft-chen-emu-eap-tls-ibs

[Joseph Salowey]

This is an adoption call for EAP-IBS (
https://datatracker.ietf.org/doc/draft-chen-emu-eap-tls-ibs/
)
as an EMU working group item.  Please respond to this call and answer the
following questions by April 24, 2022:

1. Do you think this draft should be an EMU working group Item?

2. Would you contribute by reviewing this document?

3. Would you contribute text to this document?

Thanks,

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

[Emu] Note taker for IETF 113

[Joseph Salowey]

We have a packed agenda so we would like to have some volunteers for note
taking to avoid awkward delays at the beginning of the meeting.  If you
would like to volunteer for notetaker, let the chairs know.

Thanks,

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

[Emu] Presentations for IETF 113

[Joseph Salowey]

Presenters please provide slides ASAP. You can propose new slides through
the datatracker or you can send them to the chairs.

Thanks,

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

[Emu] Agenda Items for EMU at IETF 113

[Joseph Salowey]

EMU has been scheduled for a 1 hour slot on Tuesday, March 22 at
13:00-14:00 UTC+1.  The chairs would like to solicit input from the WG for
agenda topics. Please send your agenda topics request and an estimate for
how much time you will need to emu-cha...@ietf.org. Please note that we
will prioritize existing WG items.

Thanks,

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

Re: [Emu] draft-ietf-emu-tls-eap-types

[Joseph Salowey]

Thanks for the nudge on this.  We just issued the WGLC for this document.
Please send your reviews on that thread.

On Thu, Feb 17, 2022 at 5:40 AM Alan DeKok 
wrote:

>   There has been nothing preventing anyone from reviewing the document at
> any time in the last year.  Since all of the implementors are happy with
> the document, and there are multiple inter-operable implementations, it's
> time to issue a WGLC, and publish it.
>
>   I'm happy to fix any minor issues in the document as a result of
> reviews.  But as a matter of process, it seems very broken to me we require
> a WGLC in order for people to review a WG document.  This seems like a very
> problematic change in the IETF process.
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

[Joseph Salowey]

This is a working group last call for TLS-based EAP types and TLS 1.3. The
document is available here:
https://datatracker.ietf.org/doc/draft-ietf-emu-tls-eap-types/

Please review the document and provide comments by March 4, 2022

Thanks,

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

Re: [Emu] EMU Meetings

[Joseph Salowey]

We are requesting a session at IETF 113.  There has not been a whole lot of
discussion on the list of any topic. Before scheduling an interim we would
like to understand what the topics would be.

Do we need an interim for EAP-Types or is it ready for last call?

What is the working group interested in meeting on?

Thanks,

Joe


On Wed, Jan 19, 2022 at 4:58 AM Alan DeKok 
wrote:

> On Jan 19, 2022, at 6:38 AM, John Mattsson 
> wrote:
> > >draft-arkko-emu-rfc3748bis
> >
> >   I heard significant opposition to that at the last EMU meeting.  I
> don't see a compelling reason to rev 3748.
> >
> > John: I think we should get back to this topic for more discussion on if
> and how. Bernard expressed opposition to obsolete as he said that would
> require recertification of products. But there was also a suggestion that
> we should instead do Internet Standard instead. EAP does definitly deserve
> to be an Internet Standard. Another suggestion was to make an update
> instead of obsolete which would not trigger recertification.
>
>   Are there any implementors of EAP who are asking for it to be updated?
> From what I can see, the answer is "no".  Which means that the IETF is free
> to work on a document, but it will be either opposed, or at best, ignored.
>
> > The following has been brought up as reasons for doing some kind of
> update:
> > - EAP is essential for network acces authentication and should be an
> Internet Standard
>
>   Like RADIUS accounting.  But we've lived for 25+ years without that.  I
> think it's fine.
>
> > - "Master" should be changed to "Main" tofollow inclusive language
> recommendations (TLS is already doing this).
>
>   This reminds me of a comment about "codes of conduct" for software
> projects.  The observation was that in many cases, the proponents of such
> codes engaged in such extreme behavior that they should have been banned
> under the codes which they were proposing.  Yet that never happened.  The
> only conclusion then is that something else is going on.
>
>   In linguistics these re-naming of "bad" things is called the "euphemism
> treadmill".  History has other names for such morality plays.
>
> > - Several of the methods defines in RFC 3748 like MD5-Challenge would
> benefit from security consideration and references to more recommended
> methods such as EAP-TLS.
>
>   While that's true, I would like to see how that benefit is worth the
> effort involved in updating the standard.
>
> > - There are errata.
> > - The consideration and recommendations for identity protection is not
> up to data with current best practice.
>
>   For me, that's been adequately patched in updates to EAP methods.  i.e.
> methods where identity protection matter.  For insecure methods, they're
> used in situations where identity protection doesn't really matter.
>
> > - RFC 3748 does not even mention forward secrecy is more and more
> becoming a requirement to acceptable security.
> > - Mention new access technologies such as 5G where EAP is an essential
> part.
>
>   I don't understand how this is useful.
>
> > - Mention of recommend use of documents such as [RFC4137] [RFC5113]
> [RFC5247] [RFC6677] [RFC7029].
> >
> > IETF is at least nowadays very often making updates such as this
> (RFC7296, RFC8446bis, RFC7616, RFC8489, RFC8656, RFC8445, etc.)
> >
> > My personal view would be that the security considerations considering
> MD5, identity protection, and forward secrecy would be worthwhile doing in
> some way. It would also be good to mention essential updates such as RFC
> 4137.
>
>   Given the significant opposition, I don't see how WG consensus can be
> achieved here.  The only way forward would be to ignore all of the EAP
> implementors, and declare consensus despite their objections.
>
> > >draft-ingles-eap-edhoc
> >
> >   That seems useful for limited situations (i.e. IoT).  It also has
> issues with publicizing identities.
> >
> > John: I think the only thing that is missing is to mandate use of
> ananymous NAIs.
>
>   I don't see any provision in the draft for providing a "real" identity.
> So the only NAI used is the outer one, which therefore cannot be fully
> anonymized.
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Francesca Palombini's No Objection on draft-ietf-emu-eap-tls13-20: (with COMMENT)

[Joseph Salowey]

Thanks Francesca,

We'll take a look at the reference substitution.  It would be better to be
accurate with the section.  A quick check suggests that this shouldn't be
too hard.  It's also possible that some of the references may be in text
that is updated.

Cheers,

Joe

On Tue, Oct 5, 2021 at 2:10 PM Francesca Palombini via Datatracker <
nore...@ietf.org> wrote:

> Francesca Palombini has entered the following ballot position for
> draft-ietf-emu-eap-tls13-20: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
>
>
>
> --
> COMMENT:
> --
>
> Thank you for the work on this document. I only have one minor comment and
> a
> nit. Neither require replies strictly speaking, please feel free to
> address as
> you see fit.
>
> Francesca
>
> ## minors
>
> 1. -
>
>All the following references in [RFC5216] are updated as specified
>below when EAP-TLS is used with TLS 1.3.
>
>All references to [RFC2560] are updated with [RFC6960].
>
>All references to [RFC3280] are updated with [RFC5280].
>
>All references to [RFC4282] are updated with [RFC7542].
>
> FP: I just want to double check everybody is ok with doing this type of
> update
> to the references: as the table of contents of these documents are not
> exactly
> the same, strictly speaking this could lead to some inaccuracies - for
> example
> RFC 5216 states:
>
>as a server certificate.  Implementations SHOULD use the Extended Key
>Usage (see Section 4.2.1.13 of [RFC3280]) extension and ensure that
>
> Section 4.2.1.13 of RFC 3280 is
>
>   4.2.1.13. CRL Distribution Points ..45
>
> Section 4.2.1.13 of RFC 5280 is
>
>4.2.1.13  Extended Key Usage . . . . . . . . . . . . . . . .  40
>
> This is not a big issue because the table of contents are mostly the same,
> but
> still requires the reader to be able to backtrack the right section (in
> this
> case, it would be 4.2.1.14) (This is only an example, I haven't checked all
> occurrences of those references in RFC 5216).
>
> ## nits
>
> 2. -
>
> FP: s/shepard/shepherd
>
>
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Benjamin Kaduk's No Objection on draft-ietf-emu-eap-tls13-20: (with COMMENT)

[Joseph Salowey]

Thanks for your review.  Comments inline below:

On Thu, Oct 7, 2021 at 4:17 PM Benjamin Kaduk via Datatracker <
nore...@ietf.org> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-emu-eap-tls13-20: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
>
>
>
> --
> COMMENT:
> --
>
> Updating my ballot position from Discuss to No Objection in light of the
> discussion that we had at the telechat today.
>


> Previous Discuss position:
> ==
> Many thanks for the updates since the -13, the last version I reviewed.
> I'm happy to report that the structural issues I noted in that version
> have been addressed, and my new Discuss point is a fairly mundane one.
>
> In several sections, we say that the text "updates Section X of
> [RFC5216] by amending it with the following text", but I'm quite unclear
> on exactly what that is intended to mean.  Are we adding to the end,
> prepending to the beginning, replacing wholesale, replacing in part, or
> doing something else to the indicated text of RFC 5216?  I expect that
> just tweaking a few words can resolve the ambiguity, but am not sure
> which ones yet.
>
> It is also interesting to contrast the "amending" language with what we
> say in Sections 2.1.4 and 2.3 about "replacing" text from RFC 5216 and
> the various places where we report a "new section when compared to
> [RFC5216]".
> ==
>
> The discussion helped shed some light on the process the WG took to get
> to the current state of having an amalgamation of new and existing text
> where the new text amends the existing text in a way that has the reader
> perform their own synthesis, avoiding a need for specification authors to
> engage in a tedious exercise of going sentence-by-sentence to check all
> the details.



>
>
I would suggest to make a change of the form:
>
> OLD:
> updates Section X of [RFC5216] by amending it with the following text
>
> NEW:
> updates Section X of [RFC5216] by amending it in accordance with the
> following
> discussion
>
>
[Joe] I'll let the authors weigh in on this recommendation. It looks fine
to me.


>
> Original COMMENT section retained unchanged:
> ==
> I echo the sentiments of other reviewers that constructing EAP-TLS 1.3
> as something of a diff against RFC 5216 will make it harder to
> eventually deprecate/obsolete/etc RFC 5216 and makes it somewhat
> challenging to read the EAP-TLS 1.3 specification as a whole.  That
> said, this is just the comment section, so I am not strenuously
> objecting to it.
>
> As another general note, in many places the phrasings used to describe
> TLS 1.3 behaviors feel rather un-idiomatic to me, based on my experience
> with TLS and TLS specifications.  That said, the behavior seems
> well-specified as is, so I don't propose to make any changes in response
> to this comment.  If there is demand, I could probably be persuaded to
> suggest alternative text, but I don't expect much demand at this stage
> in the document's lifecycle.
>
> I made a github PR with some editorial suggestions:
> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/92
>
> [Joe] Thank you.  I will take a look.


> Section 2.1
>
>This section updates Section 2.1 of [RFC5216] by amending it with the
>following text.
>[...]
>TLS 1.3 changes both the message flow and the handshake messages
>compared to earlier versions of TLS.  Therefore, much of Section 2.1
>of [RFC5216] does not apply for TLS 1.3.  Except for Sections 2.2 and
>5.7 this document applies only when TLS 1.3 is negotiated.  When TLS
>1.2 is negotiated, then [RFC5216] applies.
>
> There is perhaps some philosophical question of what "this document"
> means in the context of an updated collection of text that includes RFC
> 5216 and the text that is being amended as directed here.  I hope that
> the RFC Editor will have some thoughts on this matter, but perhaps
> s/this document/[RFC]/ would reduce ambiguity.  If this change is
> made, there would be similar/corresponding changes later on as well,
> e.g., whenever the amended text includes a section reference to this
> document, it would be "Section 2.1.3 of [RFC]".
>
>
[Joe]  would changing "this" to "this update" help?


> Als

[Emu] EMU Meetings

[Joseph Salowey]

Mohit and I discussed some options for meetings this year.  We think it
would be better not to meet at IETF 112 and instead schedule some
focused virtual interim meetings where we can address specific issues.
These interims will most likely take place after IETF 112. If you have a
topic you would like to cover at an interim please let us know.

Thanks,

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

Re: [Emu] The EMU WG has placed draft-aviram-tls-deprecate-obsolete-kex in state "Call For Adoption By WG Issued"

[Joseph Salowey]

I clicked the wrong button, this should have been for TLS.  Sorry for the
spam.

On Sun, Aug 8, 2021 at 11:57 AM IETF Secretariat <
ietf-secretariat-re...@ietf.org> wrote:

>
> The EMU WG has placed draft-aviram-tls-deprecate-obsolete-kex in state
> Call For Adoption By WG Issued (entered by Joseph Salowey)
>
> The document is available at
> https://datatracker.ietf.org/doc/draft-aviram-tls-deprecate-obsolete-kex/
>
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Publication has been requested for draft-ietf-emu-eap-tls13-18

[Joseph Salowey via Datatracker]

Joseph Salowey has requested publication of draft-ietf-emu-eap-tls13-18 as 
Proposed Standard on behalf of the EMU working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/


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

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

[Joseph Salowey]

I created PR that I think captures these suggestions and another editorial
fix - https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/87

Cheers,

Joe

On Thu, Jul 8, 2021 at 9:36 AM Oleg Pekar  wrote:

>
>
> On Thu, Jul 8, 2021 at 8:31 AM Mohit Sethi M 
> wrote:
>
>> Hi Oleg, Joe, all,
>> On 7/8/21 8:06 AM, Joseph Salowey wrote:
>>
>>
>>
>> On Tue, Jul 6, 2021 at 10:08 PM Joseph Salowey  wrote:
>>
>>>
>>>
>>> On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar 
>>> wrote:
>>>
>>>> I still see unclearness in Section "2.2. Identity Verification", I'm
>>>> trying to look from the implementer's perspective.
>>>>
>>>> 1) "Since EAP-TLS deployments may use more than one EAP
>>>>server, each with a different certificate, EAP peer implementations
>>>>SHOULD allow for the configuration of a unique trusted root (CA
>>>>certificate) to authenticate the server certificate and one or more
>>>>server names to match against the SubjectAltName (SAN) extension in
>>>>the server certificate.  To simplify name matching, an EAP-TLS
>>>>deployment can assign a name to represent an authorized EAP server
>>>>and EAP Server certificates can include this name in the list of SANs
>>>>for each certificate that represents an EAP-TLS server."
>>>>
>>>> --- question: Should the server name match *any* of SAN extensions in
>>>> the server certificate? If so - then suggest to say this explicitly.
>>>>
>>>>
>> [Joe] DOes adding the following sentence help?
>>
>> "If any of the configured names match any of the names in the SAN
>> extension then the name check passes."
>>
>> This makes sense. I will update the draft in github.
>>
>>
>>
>>>
>>> [Joe] yes the behavior is to match any.
>>>
>>>
>>>> 2) "If server
>>>>name matching is not used, then peers may end up trusting servers for
>>>>EAP authentication that are not intended to be EAP servers for the
>>>>network."
>>>>
>>>> --- question: It looks like a warning, right? Suggest to make it more
>>>> explicit. Something like "If server name matching is not used, then it
>>>> essentially decreases the level of security of peer's authentication since
>>>> the peer may end up trusting servers for EAP authentication that are not
>>>> intended to be EAP servers for the network."
>>>>
>>>>
>>> [Joe] Thanks, I think that is better wording.
>>>
>> I find the text a little hard to parse. I am not sure how comfortable we
>> are with defining "levels" of security. Also, "peer's authentication" might
>> confuse the reader since we are talking about server name matching. I don't
>> really have a better suggestion. Perhaps something along the lines:  it
>> essentially degrades the peer's confidence that the EAP server with which
>> it is interacting is authoritative for the given network??
>>
> Mohit, this wording makes sense, thanks!
>
> --Mohit
>>
>>
>>>
>>>> Regards,
>>>> Oleg
>>>>
>>>> On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey  wrote:
>>>>
>>>>> This is the working group last-call (WGLC) for draft-ietf-emu-eap-tls13.
>>>>> Please review the draft, focus on the changes since the last WGLC and
>>>>> submit your comments to the list by July 8, 2021.
>>>>>
>>>>> The IETF datatracker status page for this draft is:
>>>>> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
>>>>>
>>>>> There is also an htmlized version available at:
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-17
>>>>>
>>>>> A diff from the previous WGLC version (-15):
>>>>>
>>>>> https://www.ietf.org//rfcdiff?url1=draft-ietf-emu-eap-tls13-17&url2=draft-ietf-emu-eap-tls13-15
>>>>>
>>>>> A diff from the previous version is available at:
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-17
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Joe
>>>>> ___
>>>>> Emu mailing list
>>>>> Emu@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/emu
>>>>>
>>>>
>> ___
>> Emu mailing listEmu@ietf.orghttps://www.ietf.org/mailman/listinfo/emu
>>
>>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

[Joseph Salowey]

On Thu, Jul 8, 2021 at 6:11 AM Alan DeKok  wrote:

> On Jul 8, 2021, at 2:52 AM, tom.ri...@securew2.com wrote:
> > Maybe this has been discussed already, but we often see the need for
> multiple root cas when people are migrating the root CA of their RADIUS
> server. They would then configure both the old and new Root CA in the
> client to allow seamless transition.
>
>   Yes, that makes sense.  Perhaps instead:
>
> SHOULD allow for the configuration of one or more trusted root (CA
>certificates)
>
>
[Joe] Yes good catch


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

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

[Joseph Salowey]

On Tue, Jul 6, 2021 at 10:08 PM Joseph Salowey  wrote:

>
>
> On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar 
> wrote:
>
>> I still see unclearness in Section "2.2. Identity Verification", I'm
>> trying to look from the implementer's perspective.
>>
>> 1) "Since EAP-TLS deployments may use more than one EAP
>>server, each with a different certificate, EAP peer implementations
>>SHOULD allow for the configuration of a unique trusted root (CA
>>certificate) to authenticate the server certificate and one or more
>>server names to match against the SubjectAltName (SAN) extension in
>>the server certificate.  To simplify name matching, an EAP-TLS
>>deployment can assign a name to represent an authorized EAP server
>>and EAP Server certificates can include this name in the list of SANs
>>for each certificate that represents an EAP-TLS server."
>>
>> --- question: Should the server name match *any* of SAN extensions in the
>> server certificate? If so - then suggest to say this explicitly.
>>
>>
[Joe] DOes adding the following sentence help?

"If any of the configured names match any of the names in the SAN extension
then the name check passes."


>
> [Joe] yes the behavior is to match any.
>
>
>> 2) "If server
>>name matching is not used, then peers may end up trusting servers for
>>EAP authentication that are not intended to be EAP servers for the
>>network."
>>
>> --- question: It looks like a warning, right? Suggest to make it more
>> explicit. Something like "If server name matching is not used, then it
>> essentially decreases the level of security of peer's authentication since
>> the peer may end up trusting servers for EAP authentication that are not
>> intended to be EAP servers for the network."
>>
>>
> [Joe] Thanks, I think that is better wording.
>
>
>> Regards,
>> Oleg
>>
>> On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey  wrote:
>>
>>> This is the working group last-call (WGLC) for draft-ietf-emu-eap-tls13.
>>> Please review the draft, focus on the changes since the last WGLC and
>>> submit your comments to the list by July 8, 2021.
>>>
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
>>>
>>> There is also an htmlized version available at:
>>> https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-17
>>>
>>> A diff from the previous WGLC version (-15):
>>>
>>> https://www.ietf.org//rfcdiff?url1=draft-ietf-emu-eap-tls13-17&url2=draft-ietf-emu-eap-tls13-15
>>>
>>> A diff from the previous version is available at:
>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-17
>>>
>>> Thanks,
>>>
>>> Joe
>>> ___
>>> Emu mailing list
>>> Emu@ietf.org
>>> https://www.ietf.org/mailman/listinfo/emu
>>>
>>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

[Joseph Salowey]

On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar 
wrote:

> I still see unclearness in Section "2.2. Identity Verification", I'm
> trying to look from the implementer's perspective.
>
> 1) "Since EAP-TLS deployments may use more than one EAP
>server, each with a different certificate, EAP peer implementations
>SHOULD allow for the configuration of a unique trusted root (CA
>certificate) to authenticate the server certificate and one or more
>server names to match against the SubjectAltName (SAN) extension in
>the server certificate.  To simplify name matching, an EAP-TLS
>deployment can assign a name to represent an authorized EAP server
>and EAP Server certificates can include this name in the list of SANs
>for each certificate that represents an EAP-TLS server."
>
> --- question: Should the server name match *any* of SAN extensions in the
> server certificate? If so - then suggest to say this explicitly.
>
>
[Joe] yes the behavior is to match any.


> 2) "If server
>name matching is not used, then peers may end up trusting servers for
>EAP authentication that are not intended to be EAP servers for the
>network."
>
> --- question: It looks like a warning, right? Suggest to make it more
> explicit. Something like "If server name matching is not used, then it
> essentially decreases the level of security of peer's authentication since
> the peer may end up trusting servers for EAP authentication that are not
> intended to be EAP servers for the network."
>
>
[Joe] Thanks, I think that is better wording.


> Regards,
> Oleg
>
> On Mon, Jun 28, 2021 at 2:26 AM Joseph Salowey  wrote:
>
>> This is the working group last-call (WGLC) for draft-ietf-emu-eap-tls13.
>> Please review the draft, focus on the changes since the last WGLC and
>> submit your comments to the list by July 8, 2021.
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/
>>
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-17
>>
>> A diff from the previous WGLC version (-15):
>>
>> https://www.ietf.org//rfcdiff?url1=draft-ietf-emu-eap-tls13-17&url2=draft-ietf-emu-eap-tls13-15
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-17
>>
>> Thanks,
>>
>> Joe
>> ___
>> Emu mailing list
>> Emu@ietf.org
>> https://www.ietf.org/mailman/listinfo/emu
>>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] WG Last Call for Using EAP-TLS with TLS 1.3 (draft-ietf-emu-eap-tls13-17)

[Joseph Salowey]

This is the working group last-call (WGLC) for draft-ietf-emu-eap-tls13.
Please review the draft, focus on the changes since the last WGLC and
submit your comments to the list by July 8, 2021.

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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-17

A diff from the previous WGLC version (-15):
https://www.ietf.org//rfcdiff?url1=draft-ietf-emu-eap-tls13-17&url2=draft-ietf-emu-eap-tls13-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-17

Thanks,

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

Re: [Emu] Minor PR on eap-tls13

[Joseph Salowey]

On Thu, Jun 24, 2021 at 4:43 PM Joseph Salowey  wrote:

>
>
> On Tue, Jun 22, 2021 at 6:02 AM Alan DeKok 
> wrote:
>
>> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/86
>>
>>   I didn't see anything on cross-protocol use of certs.
>>
>>   i.e. Section 2.2 suggests that the certs contain an FQDN.  But it's
>> likely bad practice to allow the same cert to be used for EAP, and for WWW.
>>
>>   There's some suggested text forbidding this behavior.
>>
>>   I would have expected similar text to be part of RFC 8446, but I
>> couldn't find anything relevant.
>>
>> ---
>>
>> 5.11 Certificate Reuse
>>
>> Certificates used for EAP-TLS MUST NOT be used in any other protocol
>> besides EAP. Section 2.2 above suggests that certificates typically have
>> one or more FQDNs in the SAN extension. However, those fields are for EAP
>> validation only, and do not indicate that the certificates are suitable for
>> use on WWW (or other) protocol server on the named host.
>>
>> Allowing the same certificate to be used in multiple protocols would
>> possibly allow for an attacker to authenticate via one protocol, and then
>> "resume" that session in another protocol. Section 5.7 above suggests that
>> authorization rules should be re-applied on resumption, but does not
>> mandate this behavior. As a result, this cross-protocol resumption could
>> allow the attacker to bypass authorization policies, and toobtain undesired
>> access to secured systems. The simplest way to prevent this attack is to
>> forbid the use of the same certificate across multiple protocols.
>>
>
> My comment is that we should mark this as cross protocol attacks.  We
> should consider a separate work item to define ALPN for EAP-TLS.  Here is a
> revision to Alan's suggestion as section "5.11 Cross-Protocol attacks" or
> perhaps an addition to 5.7
>
> "Section 2.2  suggests that certificates typically have one or more FQDNs
> in the SAN extension. However, those fields are for EAP validation only,
> and do not indicate whether the certificates are suitable for use with
> another protocol server on the named host. If the same certificate and the
> resumption cache is usable in EAP-TLS and another protocol an attacker
> could authenticate via one protocol, and then "resume" that session in
> another protocol.
>
> Section 5.7 above suggests that authorization rules should be re-applied
> on resumption, but does not mandate this behavior. As a result, this
> cross-protocol resumption could allow the attacker to bypass authorization
> policies, and to obtain undesired access to secured systems. Along with
> making sure that appropriate authorization information is available and
> used during resumption, using different certificates and resumption caches
> for different protocols is RECOMMENDED to help keep different protocol
> usages separate."
>
>
>
Actually, PR#83 removes the MAY that makes the authorization behavior on
resumption optional.  Do you still think we need to add this text to
section 5.7?




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

Re: [Emu] Minor PR on eap-tls13

[Joseph Salowey]

On Tue, Jun 22, 2021 at 6:02 AM Alan DeKok 
wrote:

> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/86
>
>   I didn't see anything on cross-protocol use of certs.
>
>   i.e. Section 2.2 suggests that the certs contain an FQDN.  But it's
> likely bad practice to allow the same cert to be used for EAP, and for WWW.
>
>   There's some suggested text forbidding this behavior.
>
>   I would have expected similar text to be part of RFC 8446, but I
> couldn't find anything relevant.
>
> ---
>
> 5.11 Certificate Reuse
>
> Certificates used for EAP-TLS MUST NOT be used in any other protocol
> besides EAP. Section 2.2 above suggests that certificates typically have
> one or more FQDNs in the SAN extension. However, those fields are for EAP
> validation only, and do not indicate that the certificates are suitable for
> use on WWW (or other) protocol server on the named host.
>
> Allowing the same certificate to be used in multiple protocols would
> possibly allow for an attacker to authenticate via one protocol, and then
> "resume" that session in another protocol. Section 5.7 above suggests that
> authorization rules should be re-applied on resumption, but does not
> mandate this behavior. As a result, this cross-protocol resumption could
> allow the attacker to bypass authorization policies, and toobtain undesired
> access to secured systems. The simplest way to prevent this attack is to
> forbid the use of the same certificate across multiple protocols.
>

My comment is that we should mark this as cross protocol attacks.  We
should consider a separate work item to define ALPN for EAP-TLS.  Here is a
revision to Alan's suggestion as section "5.11 Cross-Protocol attacks" or
perhaps an addition to 5.7

"Section 2.2  suggests that certificates typically have one or more FQDNs
in the SAN extension. However, those fields are for EAP validation only,
and do not indicate whether the certificates are suitable for use with
another protocol server on the named host. If the same certificate and the
resumption cache is usable in EAP-TLS and another protocol an attacker
could authenticate via one protocol, and then "resume" that session in
another protocol.

Section 5.7 above suggests that authorization rules should be re-applied on
resumption, but does not mandate this behavior. As a result, this
cross-protocol resumption could allow the attacker to bypass authorization
policies, and to obtain undesired access to secured systems. Along with
making sure that appropriate authorization information is available and
used during resumption, using different certificates and resumption caches
for different protocols is RECOMMENDED to help keep different protocol
usages separate."





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

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

[Joseph Salowey]

On Thu, Jun 17, 2021 at 9:55 AM Alan DeKok 
wrote:

> On Jun 17, 2021, at 12:04 PM, John Mattsson 
> wrote:
> > I have made a single PR addressing all the currently listed issues in
> the way suggested by Joe.
> >
> > https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/83/files
> >
> > - Does PR #83 address the currently listed issues?
>
>   I'll have to go through it and see.  It's normally traditional to
> respond to reviews.  And, to reply with proposed text for the document
> update.  That process allows reviewers to quickly see if their issues have
> been addressed.
>
>   The current use of GitHub makes this process rather more opaque.  There
> are changes to the document pushed as commits, but it requires rooting
> through multiple commits and references in order to see which commit
> addresses which issue.  The many commits of "updated document" make it more
> difficult to see what is changed, and why.
>
>
[Joe]  The github PRs make it easier to view the changes in the context of
the document.  I realize there may be a little bit of extra work to
associate the changes to the issues, but this should be too difficult to
do.


> > - Are there any other remaining issues that are not listed on GitHub?
>
>   My review of a few days ago had extensive comments.  It may be worth
> going through that and addressing each issue.  Some of the items have been
> addressed, which is positive.  However, it looks like all of my comments
> for Section 5 remain unaddressed.
>
>
[Joe] I opened issue 84 (
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/84) to track
this.

I think most of the section 5 issues have been addressed or can be
addressed with simple changes.  It's not clear what you wanted to address
in section 5.3.


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

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

[Joseph Salowey]

On Sun, Jun 13, 2021 at 2:44 PM Bernard Aboba 
wrote:

> draft-ietf-emu-eap-tls13-16 Section 2.1 contains the following text:
>
>EAP-TLS 1.3 remains backwards compatible with EAP-TLS 1.2 [RFC5216] . TLS 
> version
>negotiation is handled by the TLS layer, and thus outside of the
>scope of EAP-TLS.  Therefore so long as the underlying TLS
>implementation correctly implements TLS version negotiation, EAP-TLS
>will automatically leverage that capability.
>
>
> I am concerned that this statement is potentially misleading. An
> implementation of RFC 5216 that negotiates TLS 1.2 and utilizes the key
> hierarchy defined in RFC 5216 Section 2.3 will not interoperate with an
> implementation of draft-ietf-emu-tls13-16 that also negotiates TLS 1.2 and
> utilizes the key hierarchy defined in Section 2.3 of that document.
>
> So in what sense is EAP-TLS 1.3 "backwards compatible" with EAP-TLS 1.2?
>
> The only way this makes sense to me is if it is stated that
> draft-ietf-emu-eap-tls13 applies only when TLS 1.3 is negotiated, and that
> if TLS 1.2, 1.1 or 1.0 is negotiated, then RFC 5216 applies.
>
>
[Joe] Good point.  I think this is missing from the draft.  The EAP-TLS
implementation does need to know which version of TLS is negotiated.   I
agree that this draft applies to when TLS 1.3 is negotiated and not
previous versions of TLS.


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

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

[Joseph Salowey]

On Fri, Jun 11, 2021 at 11:29 AM Alan DeKok 
wrote:

> On Jun 11, 2021, at 2:12 PM, Mohit Sethi M 
> wrote:
> > The comment here says adding text about "TLS version negotiation". There
> > is a comment from you below saying: "I don't understand why it's
> > necessary to include discussion of TLS negotiation in EAP, when that
> > negotiation does not affect EAP in any way." Am I missing something or
> > is there conflicting feedback?
>
>   There are two unrelated issues here.
>
>   It would be good to explain why EAP-TLS 1.3 is compatible with earlier
> versions of EAP-TLS.  This compatibility is done by EAP-TLS *implicitly*
> relying on TLS for version negotiation.
>
>   i.e. there is no version in the EAP-TLS header.  And EAP-TLS has no
> provisions for version negotiation outside of TLS.
>
>
[Joe]  The existing text already refers to relying on the underlying TLS
version negotiation.



>   The later comments about other TLS negotiation are for other handshake
> messages, and are entirely unrelated to version negotiation.
>
>   TLS has a large number of handshake messages which can be exchanged.
> Section 2.1.6 calls out HelloRetryRequest as special, but with no
> explanation as to why.  There is no discussion that the HelloRetryRequest
> affects EAP-TLS in any way.  As such, I ask again why is the text about
> HelloRetryRequest included in the document.  And if the EAP-TLS
> specification needs to discuss HelloRetryRequest, why not also include a
> section for every handshake message used by TLS?
>
>
[Joe]  I don't see a problem with covering new TLS handshake messages in
the document, however they are covered somewhat inconsistently.  Perhaps we
should cover them all in a "new handshake messages section".

TLS 1.3 introduces several new handshake messages including
HelloRetryRequest, NewSessionTicket, KeyUpdate.  In general, these messages
will be handled by the underlying TLS libraries and are not visible to
EAP-TLS, however there are a few things to note.

The HelloRetryRequest is used by the server to reject the parameters
offered in the ClientHello and suggest new parameters.  When this message
is encountered it will increase the number of round trips used by the
protocol.

The NewSessionTicket message is used to convey session
resumption information and is covered in sections 2.1.2 and 2.1.3.

The KeyUpdate message is used to update the encryption keys used on a TLS
connection.  EAP-TLS does not encrypt significant amounts of this data so
this functionality is not needed.  Implementations SHOULD NOT send this
message, however some TLS libraries may automatically generate and process
this message.   (remove current text on KeyUpdate)



>   Does Section 2.1.6 mandate any behavior for EAP-TLS implementations?  If
> the text in Section 2.1.6 doesn't require EAP-TLS implementations to do
> anything, then that section can be omitted without any issue.
>
> >>> e.g. The "no peer authentication" situation MUST NOT be used to give
> >>> normal network access to EAP peers.  Instead, deployments SHOULD
> >>> provide access which is limited in both time, and in capability.
> >>> Usually this means a "quarantine" network, or "walled garden", which
> >>> has only limited capability.
> > There is text already in the draft which says : "While the EAP server
> > SHOULD require peer authentication, this is not mandatory, since there
> > are circumstances in which peer authentication will not be needed (e.g.,
> > emergency services, as described in [UNAUTH]), or where the peer will
> > authenticate via some other means.". This is what was said also in RFC
> > 5216. We also have also have the following text in the draft: "Some
> > deployments may permit no peer authentication for some or all
> > connections.  When peer authentication is not used, implementations MUST
> > take care to limit network access  appropriately for unauthenticated
> > peers and implementations MUST use resumption with caution to ensure
> > that a resumed session is not granted more privilege than was intended
> > for the original session.". I think we have tried to find a careful
> > balance between providing sufficient guidance vs. being repetitive. Is
> > there something that should be repeated in section 2.1.5?
>
>   The common terms used for limited access networks include "walled
> garden" and "quarantine network".  Using these terms would both make it
> clear to the reader what is expected, and reiterate that these well-known
> processes are being required here.
>
>   i.e. "take care to limit network access  appropriately" gives
> insufficient guidance for an implementor.  "taking care" is not an
> actionable recommendation.  In contrast, asking people to "enable your
> vendors walled garden functionality" is actionable.
>
>
[Joe]  OK how about adding:

"An example of limiting network access would be to invoke a vendor's walled
garden or quarantine network functionality."


> >>   I don't understand why it's necessary to include discuss

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

[Joseph Salowey]

Hi Folks,

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

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

Thanks,

Joe

On Fri, Jun 11, 2021 at 10:33 AM Alan DeKok 
wrote:

> On Jun 11, 2021, at 12:20 PM, Mohit Sethi M 
> wrote:
> > I find it odd that you claim your suggestions have been ignored or
> rejected.
>
>   So -16 does address my review from May 6?  Could you please go through
> my review of today, and point out in -16 where each of my comments was
> addressed?
>
>   As a reminder, many of those comments go back to my earlier review of
> -13 on March 13.   So we now have -14, -15, and -16 which (so far as I can
> tell) don't address substantial portions of the reviews.
>
> > We have created many issues on github  (
> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues?q=is%3Aissue+is%3Aclosed+Alan)
> and submitted many pull requests addressing your comments (
> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pulls?q=is%3Apr+Alan+is%3Aclosed).
>
> >
> > When I merged this PR in the morning:
> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/71, it looked
> like all of your comments had been addressed in the PR. Joe (the other
> co-chair) had approved this PR?
>
>   I had sent a review of -13 on March 3.  And another one May 6.  And
> another today.  The second and third reviews were largely copied from the
> first one.  And contained issues which (so far as I can tell) have not been
> addressed, much less discussed.  These issues do not appear to be addressed
> in that PR.
>
> > As authors of a working group document of a voluntary standards
> organization, we have been doing voluntary service over the last several
> years. We started working on this document in 2018 (
> https://datatracker.ietf.org/doc/html/draft-mattsson-eap-tls13). You have
> been helping us with the document since the beginning. So thank you for
> your voluntary service as well. While it is not mandatory, helping us with
> github issues/PRs related to your reviews can help us ensure that your
> comments are not inadvertently left unaddressed; and that this community
> effort moves forward faster.
>
>   I'm asking that my reviews be discussed and/or addressed, by the
> authors, in the WG.  I didn't expect to get that particular response.  It
> is distinctly unusual.
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Joseph Salowey]

I made some changes to the pull request to address some of the comments and
make the text clearer:

The EAP peer identity provided in the EAP-Response/Identity is not
   authenticated by EAP-TLS.  Unauthenticated information MUST NOT be
   used for accounting purposes or to give authorization.  The
   authenticator and the EAP-TLS server MAY examine the identity
   presented in EAP-Response/Identity for purposes such as routing and
   EAP method selection.  EAP-TLS servers MAY reject conversations if
   the identity does not match their policy.  Note that this also
   applies to resumption, see Sections 2.1.3, 5.6, and 5.7.

   The EAP server identity in the TLS server certificate is typically a
   fully qualified domain name (FQDN) in the SubjectAltName (SAN)
   extension.  Since EAP-TLS deployments may use more than one EAP
   server, each with a different certificate, EAP peer implementations
   SHOULD allow for the configuration of a unique trusted root (CA
   certificate) to authenticate the server certificate and one or more
   server names to match against the SubjectAltName (SAN) extension in
   the server certificate.  To simplify name matching, an EAP-TLS
   deployment can assign a name to represent an authorized EAP server
   and EAP Server certificates can include this name in the list of SANs
   for each certificate that represents an EAP-TLS server.  If server
   name matching is not used, then peers may end up trusting servers for
   EAP authentication that are not intended to be EAP servers for the
   network.  If name matching is not used with a public root CA, then
   effectively any server can obtain a certificate which will be trusted
   for EAP authentication by the Peer.

   The process of configuring a root CA certificate and a server name is
   non-trivial and therefore automated methods of provisioning are
   RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
   a Configuration Assistant Tool (CAT) to automate the configuration
   process.  In the absence of a trusted root CA certificate (user
   configured or system-wide), EAP peers MAY implement a trust on first
   use (TOFU) mechanism where the peer trusts and stores the server
   certificate during the first connection attempt.  The EAP peer
   ensures that the server presents the same stored certificate on
   subsequent interactions.  Use of a TOFU mechanism does not allow for
   the server certificate to change without out-of-band validation of
   the certificate and is therefore not suitable for many deployments
   including ones where multiple EAP servers are deployed for high
   availability.


On Thu, May 20, 2021 at 10:23 PM Joseph Salowey  wrote:

>
>
> On Wed, May 19, 2021 at 5:58 AM Alan DeKok 
> wrote:
>
>> On May 19, 2021, at 8:37 AM, Oleg Pekar 
>> wrote:
>> > After thinking a bit more about it - for the sake of the client
>> implementation clarity, would it be better if we provide the strict
>> algorithm for server identity check or maybe reference RFC 6125.
>>
>>   Given the time frame and what we know, I think the existing text is OK.
>>
>>
> [Joe] In addition the intent of the text is to make implementers aware of
> the issues and provide some guidance as to how to solve the problem.  I
> don't think we can dictate too much more at this point.   We can have
> follow-on work to have a strict algorithm is depolyers and implementers
> feel it is necessary.
>
>
>>   This is what wpa_supplicant does in it's implementation, and it seems
>> to work fine.  Apple appears to do the same thing:
>>
>>
>> https://opensource.apple.com/source/eap8021x/eap8021x-264.30.3/EAP8021X.fproj/EAPTLSUtil.c.auto.html
>>
>>   Look for "trusted_server_names", which leads to:
>>
>>
>> https://opensource.apple.com/source/eap8021x/eap8021x-156/EAP8021X.fproj/EAPTLSUtil.c
>>
>> server_name_matches_server_names()
>>
>>   Which checks if the name from the cert is an exact match for one of the
>> "trusted_server_names", or contains "*." followed by a suffix which is one
>> of the trusted server names.
>>
>>   I think it's past the time where this document can ask supplicants to
>> change their behavior.  We know what the supplicants do, it's not wrong,
>> and it seems to work.  So let's document that, and move on.
>>
>>   Alan DeKok.
>>
>>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Joseph Salowey]

On Wed, May 19, 2021 at 5:58 AM Alan DeKok 
wrote:

> On May 19, 2021, at 8:37 AM, Oleg Pekar  wrote:
> > After thinking a bit more about it - for the sake of the client
> implementation clarity, would it be better if we provide the strict
> algorithm for server identity check or maybe reference RFC 6125.
>
>   Given the time frame and what we know, I think the existing text is OK.
>
>
[Joe] In addition the intent of the text is to make implementers aware of
the issues and provide some guidance as to how to solve the problem.  I
don't think we can dictate too much more at this point.   We can have
follow-on work to have a strict algorithm is depolyers and implementers
feel it is necessary.


>   This is what wpa_supplicant does in it's implementation, and it seems to
> work fine.  Apple appears to do the same thing:
>
>
> https://opensource.apple.com/source/eap8021x/eap8021x-264.30.3/EAP8021X.fproj/EAPTLSUtil.c.auto.html
>
>   Look for "trusted_server_names", which leads to:
>
>
> https://opensource.apple.com/source/eap8021x/eap8021x-156/EAP8021X.fproj/EAPTLSUtil.c
>
> server_name_matches_server_names()
>
>   Which checks if the name from the cert is an exact match for one of the
> "trusted_server_names", or contains "*." followed by a suffix which is one
> of the trusted server names.
>
>   I think it's past the time where this document can ask supplicants to
> change their behavior.  We know what the supplicants do, it's not wrong,
> and it seems to work.  So let's document that, and move on.
>
>   Alan DeKok.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Joseph Salowey]

Hi Oleg,

thanks for the review, comments below:

On Sun, May 16, 2021 at 1:55 AM Oleg Pekar 
wrote:

> Hi, few more comments on the draft #15
> https://datatracker.ietf.org/doc/draft-ietf-emu-eap-tls13/15/:
>
> 1)
>
> 2.1.1.  Authentication
>
> The full handshake in EAP-TLS with TLS 1.3 always
>provide forward secrecy by exchange of ephemeral "key_share"
>extensions in the ClientHello and ServerHello (e.g. containing
>ephemeral ECDHE public keys).
>
> —- comment:
> should say “provides”
>
> —
>
> 2)
>
> 2.1.1.  Authentication
>
> After the EAP-TLS server has received an
>empty EAP-Response to the EAP-Request containing the TLS application
>data 0x00, the EAP-TLS server sends EAP-Success.
>
> -- comment:
> the phrase “empty EAP-Response” may be confusing. EAP-TLS RFC [RFC 5216]
> calls such messages as "EAP-Response packet of EAP-Type=EAP-TLS and no
> data" (Section 2.1.3. Termination, 2.1.5.  Fragmentation). Suggest continue
> using the old RFC terminology since Figure 1 preserves the same messages
> names.
>
> —
>
> 3)
>
> 2.1.1.  Authentication
>
> Figure 1: EAP-TLS mutual authentication
>
> -- comment:
> "TLS Application Data 0x00)" lacks opening round bracket
>
> —
>
> 4)
>
> 2.1.2.  Ticket Establishment
>
> Figure 2: EAP-TLS ticket establishment
>
> -- comment:
> "TLS Application Data 0x00)" lacks opening round bracket
>
> —
>
> 5)
>
> 2.1.3.  Resumption
>
> Figure 3: EAP-TLS resumption
>
> -- comment:
> "TLS Application Data 0x00)" lacks opening round bracket
>
> —
>
>
[Joe] Authors, please address the above nits.


> 6)
>
> 2.1.3.  Resumption
>
> Providing a
>"key_share" and using the "psk_dhe_ke" pre-shared key exchange mode
>is also important in order to limit the impact of a key compromise.
>When using "psk_dhe_ke", TLS 1.3 provides forward secrecy meaning
>that key leakage does not compromise any earlier connections.  It is
>RECOMMMENDED to use "psk_dhe_ke" for resumption.
>
> -- comment:
> The recommendation may be interpreted ambiguously. Is it recommended to
> TLS server to reject EAP-TLS session resumption from EAP-TLS peer and
> fallback to full handshake when there's no "psk_dhe_ke" extension?
>

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

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


>
>
> —
>
> 7)
>
> 2.1.4.  Termination
>
> In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a
>fatal error condition.  Failure to send TLS Error alerts means that
>the peer or server would have no way of determining what went wrong.
>EAP-TLS 1.3 strengthen this requirement.  Whenever an implementation
>encounters a fatal error condition, it MUST send an appropriate TLS
>Error alert.
>
> -- comment:
> It there a way to enforce sending TLS Error alert? Since the conversation
> is probably failed anyway after the case that requires sending TLS Error
> alert - there is no real feasible enforcement to be specified. I remember a
> lot of suffering due to EAP-TLS peers just broke connection with no
> indication of what was wrong, so admins cannot really reveal the cure for
> the failed authentication.
>
>
[Joe] This section does say that TLS error alerts MUST be sent.  Are you
looking for something else?


> —
>
> 8)
>
> 2.1.4.  Termination
>
> Figure 6 shows an example message flow where the EAP-TLS server
>authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
>fails to authenticate to the EAP-TLS server and sends a TLS Error
>alert.
>
> -- comment:
> "the EAP-TLS peer fails to authenticate to the EAP-TLS server and sends a
> TLS Error" - there's an impression from this text that EAP-TLS peers sends
> a TLS error. However it is EAP-TLS server that does it. Should be
> clarified. Example of suggestion:
>
> Figure 6 shows an example message flow where the EAP-TLS server
>authenticates to the EAP-TLS peer successfully, but the EAP-TLS peer
>fails to authenticate to the EAP-TLS server and the server sends a TLS
> Error
>alert.
>
>
[Joe] Authors please reword this text to be less ambiguous.


> —
>
> 9)
>
> 2.1.5.  No Peer Authentication
>
> -- comment:
> Can "TLS CertificateRequest" message still be sent by EAP-TLS server?
> Should EAP-TLS peer silently discard it or reject the connection in case it
> is sent but EAP-TLS peer doesn't own a credentials to authenticate?
>
>
[Joe] I think this is covered by TLS behavior.  I don't think we need to
describe it further here.  The peer includes the certificate or not
according to its policy and the server applies it policy accordingly.


> —
>
> 10)
>
> 2.1.5.  No Peer Authentication
>
> Figure 7: EAP-TLS without peer authentication
>
> -- c

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

[Joseph Salowey]

On Thu, May 6, 2021 at 12:11 PM Alan DeKok 
wrote:

>
>
> > On May 5, 2021, at 11:33 AM, Joseph Salowey  wrote:
> >
> > This is the working group last-call for draft-ietf-emu-eap-tls13.
> Please review the draft, focus on the recent changes and submit your
> comments to the list by May 20, 2021.
>
>
> Section 1 says:
>
>   While this document updates EAP-TLS [RFC5216], it
>   remains backwards compatible with it and existing implementations of
>   EAP-TLS.
>
> Other than the abstract, this is the only reference to EAP-TLS 1.3
> being backwards compatible with older versions of EAP-TLS.  This
> compatibility is simply asserted, with no further explanation given.
>
> Q: What does "backwards compatible" mean?  How is it achieved?
>
> Suggestion: add text explaining how it is backwards compatible.  How
> will EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps
> update Section 2.1 with text indicating that TLS version negotiation
> is handled by the TLS layer, and thus outside of the scope of EAP-TLS.
> Therefore so long as the underlying TLS implementation correctly
> implements TLS version negotiation, EAP-TLS will automatically
> leverage that capability.
>
>
[Joe]  This text is in PR #71
<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/71>.



>
> Section 2.1.1 says:
>
>   TLS 1.3 introduced the Post-Handshake KeyUpdate
>   message which is not useful and not expected in EAP-TLS.
>
> Q: What does it mean that the message is "not expected"?  This seems
> like a source of implementation-defined behavior, which experience
> shows has been a source of interoperability and security issues.
>
> Suggestion: If there is no use for KeyUpdate messages, then mandate
> that it SHOULD be ignored, or perhaps connections which use KeyUpdate
> MUST be closed without updating the keys.  OpenSSL as APIs to
> determine the status of key updates, so this suggestion is
> implementable.
>
>
[Joe]  I don't see an advantage to having a special case for the KeyUpdate
message.  If the server sends a key update then the peer can just process
it with the rest of the payload it receives.  Since the peer sends no data
it does not matter if it updates the keys or not.   It might be useful to
update this section to say " TLS 1.3 introduced the Post-Handshake
KeyUpdate message which SHOULD NOT be used in EAP-TLS because only one byte
of application data is sent."


>
> Section 2.1.3 says this about the session ticket:
>
>   ... If the EAP-TLS server
>   accepts it, then the security context of the new connection is tied
>   to the original connection and the key derived from the initial
>   handshake is used to bootstrap the cryptographic state instead of a
>   full handshake.
>
> Nit: This the the only reference to "bootstrap the cryptographic
> state" in this document.  This text seems like an unnecessary
> repetition of RFC 8446 Section 2.2.
>
> Suggestion: Perhaps say instead
>
>   ... If the EAP-TLS server
>   accepts it, then the resumed session has been deemed to be
>   authenticated, and securely associated with the prior authentication
>   or resumption.
>
>
[Joe]  This text is in PR #71
<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/71>.


>
> Section 2.1.4
>
>In TLS 1.3 [RFC8446], error alerts are not mandatory to send after a
>fatal error condition.  Failure to send TLS Error alerts means that
>the peer or server would have no way of determining what went wrong.
>EAP-TLS 1.3 strengthen this requirement.
>
> NIT: strengthenS this requirement.
>
>
[Joe] This nit is fixed in the current git-hub draft


> Section 2.1.5 is essentially empty.
>
>  Is there guidance as to when no peer authentication should /
> should not be used?  Is it possible for an EAP peer to present a
> client certificate, but have the EAP server ignore it?  What kind of
> network access should an EAP peer have if it does not use peer
> authentication?
>
>   Perhaps some of the text from Section 5.6 could be added here.
>
> Perhaps suggest that in the normal case, deployments SHOULD use peer
> authentication.  Also that the "no peer authentication" case be
> strictly limited in both time, and network access.
>
> e.g. The "no peer authentication" situation MUST NOT be used to give
> normal network access to EAP peers.  Instead, deployments SHOULD
> provide access which is limited in both time, and in capability.
> Usually this means a "quarantine" network, or "walled garden", which
> has only limited capability.
>
> Also, the Security Considurations section has no discussion of the
> security impact of not authenticat

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

[Joseph Salowey]

I proposed a PR#72
<https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/72> based on this
suggestion. The resulting text for the section is below.  Please review to
see if it is OK.

Thanks,

Joe

2.2.  Identity Verification

   This section updates Section 2.2 of [RFC5216].

   The EAP peer identity provided in the EAP-Response/Identity is not
   authenticated by EAP-TLS.  Unauthenticated information SHALL NOT be
   used for accounting purposes or to give authorization.  The
   authenticator and the EAP-TLS server MAY examine the identity
   presented in EAP-Response/Identity for purposes such as routing and
   EAP method selection.  EAP-TLS servers MAY reject conversations if
   the identity does not match their policy.  Note that this also
   applies to resumption, see Sections 2.1.3, 5.6, and 5.7.

   The EAP server identity in the TLS server certificate is typically a
   fully qualified domain name (FQDN).  EAP peer implementations SHOULD
   allow users to configure a unique trust root (CA certificate) and a
   server name to authenticate the server certificate and match the
   subjectAlternativeName (SAN) extension in the server certificate with
   the configured server name.  EAP-TLS deployments will often use more
   than one EAP server.  In this case each EAP server may have a
   different certificate.  To facilitate SAN matching, EAP Server
   certificates can include the same name in the list of SANs for each
   certificate that represents the EAP-TLS servers.  EAP-TLS peers
   SHOULD allow for the configuration of multiple EAP server names since
   deployments may choose to use multiple EAP servers each with their
   own certificate.  If server name matching is not used, then peers may
   end up trusting servers for EAP authentication that are not intended
   to be EAP servers for the network.  If name matching is not used with
   a public root CA, then effectively any server can obtain a
   certificate which will be trusted for EAP authentication by the Peer.


   The process of configuring a root CA certificate and a server name is
   non-trivial and therefore automated methods of provisioning are
   RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
   a Configuration Assistant Tool (CAT) to automate the configuration
   process.  In the absence of a trusted root CA certificate (user
   configured or system-wide), EAP peers MAY implement a trust on first
   use (TOFU) mechanism where the peer trusts and stores the server
   certificate during the first connection attempt.  The EAP peer
   ensures that the server presents the same stored certificate on
   subsequent interactions.  Use of a TOFU mechanism does not allow for
   the server certificate to change without out-of-band validation of
   the certificate and is therefore not suitable for many deployments
   including ones where multiple EAP servers are deployed for high
   availability.


On Mon, May 10, 2021 at 5:11 AM Alan DeKok 
wrote:

> On May 9, 2021, at 9:16 PM, Joseph Salowey  wrote:
> > [Joe]  This is a good question.  There are multiple ways this could be
> addressed.  All servers should have one of their list of SANs that matches
> the name used for EAP servers.  Another option is for supplicants to allow
> for the configuration of multiple certificates or allow for a wild card
> match.
>
>   FWIW, wpa_supplicant has a list of allowed host names for SAN.  I don't
> think it allows wildcards.
>
> >   How about this text addition:
> >
> > "EAP-TLS deployments will often use more than one EAP server.  In this
> case each EAP server may have a different certificate.  To facilitate the
> SAN matching, EAP Server certificates can include the same name in the list
> of SANs for each certificate that represents the EAP-TLS servers.  EAP-TLS
> peers SHOULD allow for the configuration of multiple EAP server names since
> deployments may choose to use multiple EAP servers each with their own
> certificate."
>
>   That's good.
>
> > [Joe] Is your comment about HA and the TOFU mechanism?  I'm not really
> sure how the TOFU mechanism is supposed to work and be secure.  Perhaps we
> should remove the TOFU mechanism text or state that it does not work well
> in all HA configurations (where different servers use different
> certificates)
>
>   Perhaps just state that it does not work well in HA configurations.
>
>   I don't think TOFU can be secure here.
>
>   Alan DeKok.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Joseph Salowey]

On Mon, May 10, 2021 at 10:53 AM John Mattsson 
wrote:

> I don’t see any strong reasons to keep the -15 key derivation. I started
> to prepare a PR for the likely change back to -13.
>
>
>
> https://github.com/emu-wg/draft-ietf-emu-eap-tls13/pull/68
>
>
>
> - Version 15 has the following wrong text that need to change.
> Key_Material can now be kept, but IV should be removed.
>
>
>
>   “the Key_Material, IV, and Method-Id SHALL be derived”
>
>   ”derivation of Key_Material, IV and Method-Id”
>
>
>
> - The IANA table need to change.
>
>
>
> - I would suggest to have the text agreed in -13 stating stating that the
> derivation from Key_Material is the same as in RFC 5216.
>
>
>
>The MSK and EMSK are derived in the same manner as with EAP-TLS
> [RFC5216], Section 2.3. The definitions are repeated below for simplicity:
>
>
>
>MSK = Key_Material(0, 63)
>
>EMSK = Key_Material(64, 127)
>

[Joe] how about  "are derived from Key_Material in the same manner as with
EAP_TLS... "


>
>
> John
>
>
>
> *From: *Emu  on behalf of Joseph Salowey <
> j...@salowey.net>
> *Date: *Sunday, 9 May 2021 at 19:54
> *To: *EMU WG 
> *Subject: *[Emu] Consensus call on EAP-TLS key derivation
>
>
>
> We had discussion on the list on whether to include context in the key
> derivation, but we never closed on the issue of separating out the MSK and
> EMSK derivation.  As a result several implementers have gone down the path
> of implementing what is in draft 13 and not separating out the derivation.
> The main difference is that draft 15 separated out the EMSK and MSK
> derivation using two different labels while draft 13 used a single label to
> derive key material which is partitioned into two keys.   The reason for
> the change was to enable different access control for these two different
> quantities for different callers, however in practice it is EAP-TLS
> application which needs access to both keys that is the caller of the TLS
> library so this separation is not particularly useful.   Therefore the
> recommendation is to align with implementation and derive the MSK and EMSK
> by partitioning the key material from the key material produced by a single
> label of the exporter function.
>
>
>
> Please respond to the list if you support the change below or not to
> revert some of the text in the key derivation section.  If you object to
> the change please state why.  Please respond by May 20,2021.
>
>
>
> Thanks,
>
>
>
> Joe
>
>
>
> The proposal is to use the following key derivation which is largely a
> reversion to draft 13:
>
>
>
> Draft-15 Text:
>
>
>
> Type-Code = 0x0D
>
> MSK= TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64)
>
> EMSK   = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64)
>
> Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64)
>
> Session-Id = Type-Code || Method-Id
>
>
>
> Proposed New Text:
>
>
>
> Type-Code = 0x0D
>
> Key_Material = TLS-Exporter("EXPORTER_EAP_TLS_Key_Material",
>
>Type-Code, 128)
>
> MSK  = Key_Material(0, 63)
>
> EMSK = Key_Material(64, 127)
>
> Method-Id= TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",
>
>Type-Code, 64)
>
> Session-Id = Type-Code || Method-Id
>
>
>
> The rest of the text of the section remains the same as draft-15.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP-TLS 1.3 Section 2.2 text

[Joseph Salowey]

Alan's review made the following comments:

>  Section 2.2 has substantial new text which was not previously discussed
on the WG mailing list.

>  The EAP server identity in the TLS server certificate is typically a
>  fully qualified domain name (FQDN).  EAP peer implementations SHOULD
>   allow users to configuring a unique trust root (CA certificate) and a
>   server name to authenticate the server certificate and match the
>   subjectAlternativeName (SAN) extension in the server certificate with
>   the configured server name.

> Comment: How does this text related to RFC 5216 Section 5.2 ?  There
seems to be substantial overlap.

> What does this text add to / change from RFC 5216 Section 5.2 ?

[Joe] It was brought up in discussions that RFC 5216 does not sufficiently
describe how to validate the identity in the certificate.

>  Requiring a supplicant to be configured with a peer name is a new
requirement from RFC 5216, and isn't called out as such.

[Joe]  This can be called out in this section

>  What happens in a high availability (HA) environment?  Are all of the
EAP servers required to have the same FQDN?

[Joe]  This is a good question.  There are multiple ways this could be
addressed.  All servers should have one of their list of SANs that matches
the name used for EAP servers.  Another option is for supplicants to allow
for the configuration of multiple certificates or allow for a wild card
match.   How about this text addition:

"EAP-TLS deployments will often use more than one EAP server.  In this case
each EAP server may have a different certificate.  To facilitate the SAN
matching, EAP Server certificates can include the same name in the list of
SANs for each certificate that represents the EAP-TLS servers.  EAP-TLS
peers SHOULD allow for the configuration of multiple EAP server names since
deployments may choose to use multiple EAP servers each with their own
certificate."

>  While this text is intended to increase security, there are
implementation and operational considerations which need addressing.

>   In the absence of a user-configured root
>  CA certificate,

> Comment: I'm not sure what that means.  It seems to assume certain things
without explaining them.

[Joe] This text doesn't seem to add much.  I'd suggest removing that
sentence.

>   The process of configuring a root CA certificate and a server name is
>   non-trivial and therefore automated methods of provisioning are
>   RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
>   a Configuration Assistant Tool (CAT) to automate the configuration
>   process.  In the absence of a trusted root CA certificate (user
>   configured or system-wide), EAP peers MAY implement a trust on first
>   use (TOFU) mechanism where the peer trusts and stores the server
>   certificate during the first connection attempt.  The EAP peer
>   ensures that the server presents the same stored certificate on
>   subsequent interactions.  Use of TOFU mechanism does not allow for
>   the server certificate to change without out-of-band validation of
>   the certificate and is therefore not suitable for many deployments.

>  i.e. when there's an HA configuration.

[Joe] Is your comment about HA and the TOFU mechanism?  I'm not really sure
how the TOFU mechanism is supposed to work and be secure.  Perhaps we
should remove the TOFU mechanism text or state that it does not work well
in all HA configurations (where different servers use different
certificates)
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Consensus call on EAP-TLS key derivation

[Joseph Salowey]

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

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

Thanks,

Joe

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

Draft-15 Text:

Type-Code = 0x0D

MSK= TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64)
EMSK   = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64)
Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64)
Session-Id = Type-Code || Method-Id


Proposed New Text:

Type-Code = 0x0D

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

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

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

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


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

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

[Joseph Salowey]

On Fri, May 7, 2021 at 1:09 PM Jorge Vergara  wrote:

> >   When EAP-TLS is used with TLS version 1.3 the Key_Material, IV, and
> >   Method-Id SHALL be derived from the exporter_secret using the TLS
> >   exporter interface [RFC5705] (for TLS 1.3 this is defined in
> >   Section 7.5 of [RFC8446]).
> >
> >   Type-Code  = 0x0D
> >   MSK= TLS-Exporter("EXPORTER_EAP_TLS_MSK",Type-Code,64)
> >   EMSK   = TLS-Exporter("EXPORTER_EAP_TLS_EMSK",Type-Code,64)
> >   Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id",Type-Code,64)
> >   Session-Id = Type-Code || Method-Id
> >
> > All this is nice, but it might be too late.  I'd check with major
> implementations which have frozen their code, and are shipping.
>
> The Windows implementation is using draft-13 exporters; it is not possible
> to change at this point unless a critical technical issue that prevents
> functionality or impacts security were to be discovered. I don't think this
> is such an issue. The preference to keep draft-13 exporters was discussed
> at IETF 110 and I do not recall any objection. The draft-15 exporter is
> problematic for Windows at this point.
>
>
[Joe] I think the one issue that was raised during TLS review was that
using the same label for MSK and EMSK could make it more difficult to
separate out the derivations of these keys at the TLS level.  For example,
example, perhaps the TLS implementation could restrict access to the MSK
and EMSK independently depending upon hte caller.  In practice, it is
EAP-TLS that is the caller and the use cases that require the separate
derivation of these two keys of these two keys is few to none.  I'll start
a short consensus call on this issue.


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


> Jorge
>
> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: Thursday, May 6, 2021 12:12 PM
> To: Joseph Salowey 
> Cc: EMU WG 
> Subject: Re: [Emu] WG Last Call for Using EAP-TLS with TLS 1.3
>
>
>
> > On May 5, 2021, at 11:33 AM, Joseph Salowey  wrote:
> >
> > This is the working group last-call for draft-ietf-emu-eap-tls13.
> Please review the draft, focus on the recent changes and submit your
> comments to the list by May 20, 2021.
>
>
> Section 1 says:
>
>   While this document updates EAP-TLS [RFC5216], it
>   remains backwards compatible with it and existing implementations of
>   EAP-TLS.
>
> Other than the abstract, this is the only reference to EAP-TLS 1.3 being
> backwards compatible with older versions of EAP-TLS.  This compatibility is
> simply asserted, with no further explanation given.
>
> Q: What does "backwards compatible" mean?  How is it achieved?
>
> Suggestion: add text explaining how it is backwards compatible.  How will
> EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps update Section
> 2.1 with text indicating that TLS version negotiation is handled by the TLS
> layer, and thus outside of the scope of EAP-TLS.
> Therefore so long as the underlying TLS implementation correctly
> implements TLS version negotiation, EAP-TLS will automatically leverage
> that capability.
>
>
> Section 2.1.1 says:
>
>   TLS 1.3 introduced the Post-Handshake KeyUpdate
>   message which is not useful and not expected in EAP-TLS.
>
> Q: What does it mean that the message is "not expected"?  This seems like
> a source of implementation-defined behavior, which experience shows has
> been a source of interoperability and security issues.
>
> Suggestion: If there is no use for KeyUpdate messages, then mandate that
> it SHOULD be ignored, or perhaps connections which use KeyUpdate MUST be
> closed without updating the keys.  OpenSSL as APIs to determine the status
> of key updates, so this suggestion is implementable.
>
>
> Section 2.1.3 says this about the session ticket:
>
>   ... If the EAP-TLS server
>   accepts it, then the security context 

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

[Joseph Salowey]

This is the working group last-call for draft-ietf-emu-eap-tls13.  Please
review the draft, focus on the recent changes and submit your comments to
the list by May 20, 2021.

Thanks,

Joe

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

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

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

Re: [Emu] Issue 59 - Key Update

[Joseph Salowey]

On Mon, Apr 12, 2021 at 4:58 AM Alan DeKok 
wrote:

> On Apr 11, 2021, at 10:40 PM, Joseph Salowey  wrote:
> > This does seem to require some more specification.  Here is a proposal.
> >
> > "TLS 1.3 introduced the Post-Handshake KeyUpdate message which is not
> useful and not expected in EAP-TLS.  Implementations SHOULD NOT send a
> KeyUpdate message.  If a KeyUpdate message is received then an
> implementation SHOULD ignore the message and it SHOULD NOT send a KeyUpdate
> message in response."
> >
> > I think this is better than "implementations MUST NOT send this message
> and MUST fail upon reception".  The problem here is that the EAP TLS
> implementation may not have control over this behavior.
>
>   It looks like key update messages are explicitly requested by either
> party.  From OpenSSL:
>
>   https://www.openssl.org/docs/man1.1.1/man3/SSL_key_update.html
>
>   If the KeyUpdate message is sent only when requested, it would make
> sense to forbid sending it.  EAP-TLS has no reason to just randomly change
> the encryption keys used for TLS.  EAP-TLS is using TLS for authentication,
> and not for bulk data transfer.
>
>   If the underlying TLS library randomly sends it (or sends it subject to
> unknown criteria), then the EAP-TLS implementation (peer or authenticator)
> should be able to detect it via a callback:
>
> https://www.openssl.org/docs/man1.0.2/man3/SSL_set_msg_callback.html
>
>   There appears to be no way for the application to tell the TLS library
> to ignore the message.
>
>   The safest thing would seem to be:
>
> a) forbidding EAP-TLS implementations from explicitly requesting it
>
> b) noting that TLS libraries may still do key updates
>
> c) noting that EAP-TLS implementations can often detect key updates, and
>
> d) leaving it to the implementation to decide what to do.
>
>   i.e. "We don't know why you'd use it.  But if someone else does use it,
> and it works, great.  Otherwise, buyer beware".
>
>
[Joe] OK, this sounds reasonable to me.  How about text like the following:

"EAP-TLS implementations MUST NOT explicitly request key updates.  It is
possible that a TLS library implementation may automatically send a key
update message so an implementation detecting the reception of a keyUpdate
message MAY process or ignore the message since only a minimum amount of
application data is exchanged in the channel."


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

Re: [Emu] Issue 47 Certificate identity checks

[Joseph Salowey]

On Mon, Apr 12, 2021 at 6:02 AM Eliot Lear  wrote:

> Hi Alan,
>
> On 12 Apr 2021, at 14:52, Alan DeKok  wrote:
>
>
> EAP TLS peer implementations MUST allow for configuration of a unique
> trust root to validate the server's certificate.
>
>
> This statement seems independent of the previous one, and may be overly
> broad.  Let me give you an example: a device may be designed only to
> operate as part of a federation.
>
>
>  I would agure there that the federation should have it's own CA.
>
>
> That’s what I’m thinking.  But I could imagine hardcoded devices that make
> use of it.  That’s all.
>
>
[Joe] Relying on a burned in certificate this way seems like a really bad
idea.  What happens when that certificate expires?


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

Re: [Emu] Issue 47 Certificate identity checks

[Joseph Salowey]

On Mon, Apr 12, 2021 at 5:48 AM Alan DeKok 
wrote:

> On Apr 11, 2021, at 11:19 PM, Joseph Salowey  wrote:
> > RFC 5216 lacks guidance on how to validate the EAP server's certificate
> especially with respect to identities.
>
>   Yes.  :)
>
> > RFC 5216 recommends validating the certificate path is valid and that
> the extended key usage attributes are either not present, allow for any
> usage or allow for TLS server usage.   This creates an issue that if the
> same truest root is used for EAP TLS and for other TLS server usage that
> any TLS server will be able to extend its privilege and behave as an EAP
> server.   The following recommendations are made for implementations and
> deployments to avoid this problem.
>
>   One of my colleagues, Arran Cudbard-Bell wrote a cute tool a few years
> ago.  It would pretend to be a WiFI hotspot.  Then when systems tried to do
> EAP, it would strip the realm from the EAP identity.  It would then, use
> HTTPS to connect to a web server for that realm, and download that HTTPS
> server cert.  That cert would then be cloned under a new "self signed" CA,
> and the cloned cert presented to the user.
>
>   The only real difference between the "real" and "fake" certs was the
> root CA / trust anchor.
>
>   So yes, this is a real issue.  Even in a trusted environment, a web
> server admin can set up a WiFi hotspot using the HTTPS server cert.  This
> seems wrong.
>
> > 1. EAP TLS Peer implementations SHOULD allow for configuration of names
> to match against SANs of type DNS name that are authorized to act as
> EAP-TLS servers.
>
>   Given the above attacks, I'm not sure that this helps.
>
>
[Joe] You would need to use the name matching in conjunction with
validation to a trusted root.


> > 2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN
> EKU specified in RFC 3770.  EAP TLS peer implementations SHOULD allow for
> the configuration to require the id-kp-eapOverLAN EKU for validation of EAP
> server certificates.
>
>   That's good, but as discussed previously on this list, it's essentially
> impossible to get those certs from public CAs.  Claims of "just start your
> own public CA" notwithstanding, the only practical way to do it is with a
> private CA.
>
>
[Joe]  without some sort of name matching using certs from a public CA is
unwise.


> > 3. If the above options are not available then separate trust roots need
> to be used to issue certificates for EAP-TLS server and for TLS servers.
> EAP TLS peer implementations MUST allow for configuration of a unique trust
> root to validate the server's certificate.
> >
> > EAP-TLS peer implementations SHOULD provide ways to automate the
> configuration of the information necessary for the validation of the
> certificate.
>
>   After looking into this in some depth, the only real thing you can
> depend on is the CA.  If the CA is trusted, nothing else matters.  If the
> CA is not trusted, then nothing else matters.
>
> [Joe] In this case we would have to rule out CAs that are not under the
organizations control (public CAs)


>   i.e. for any kind of increased security you'd like to add to EAP-TLS,
> you can almost always find a scenario where that security forbids
> real-world use-cases we'd like to support

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

[Emu] Issue 61 Clarifying NAI handling during resumption

[Joseph Salowey]

Please review and discuss the following on this thread.

Alan's review raised the issue that  the text allows for different
identities to be used for the initial handshake and subsequent resumption.
Instead the proposal is to always use the same NAI for resumption as for
the initial handshake.

I'd like to understand the reason for this concern.  It seems like this
would make things worse from a privacy perspective unless we also required
the NAI to just be @REALM which is the minimum amount of information that
can be disclosed and still have the current system work.

Thanks,

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

[Emu] Issue 47 Certificate identity checks

[Joseph Salowey]

Please review the following proposal and discuss it on this thread.

RFC 5216 lacks guidance on how to validate the EAP server's certificate
especially with respect to identities.

RFC 5216 recommends validating the certificate path is valid and that the
extended key usage attributes are either not present, allow for any usage
or allow for TLS server usage.   This creates an issue that if the same
truest root is used for EAP TLS and for other TLS server usage that any TLS
server will be able to extend its privilege and behave as an EAP server.
The following recommendations are made for implementations and
deployments to avoid this problem.

1. EAP TLS Peer implementations SHOULD allow for configuration of names to
match against SANs of type DNS name that are authorized to act as EAP-TLS
servers.

2. CAs MAY issue certs to EAP Servers that specify the id-kp-eapOverLAN EKU
specified in RFC 3770.  EAP TLS peer implementations SHOULD allow for the
configuration to require the id-kp-eapOverLAN EKU for validation of EAP
server certificates.

3. If the above options are not available then separate trust roots need to
be used to issue certificates for EAP-TLS server and for TLS servers.  EAP
TLS peer implementations MUST allow for configuration of a unique trust
root to validate the server's certificate.

EAP-TLS peer implementations SHOULD provide ways to automate the
configuration of the information necessary for the validation of the
certificate.

Cheers,

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

[Emu] Issue 59 - Key Update

[Joseph Salowey]

Please review the following proposal and discuss issues on this thread.

Alan's review pointed out the following

Section 2.1.1 says:
>TLS 1.3 introduced the Post-Handshake KeyUpdate
>message which is not useful and not expected in EAP-TLS.
> Q: What does it mean that the message is "not expected"?  This seems
> like a source of implementation-defined behavior, which experience
> shows has been a source of interoperability and security issues.


This does seem to require some more specification.  Here is a proposal.

"TLS 1.3 introduced the Post-Handshake KeyUpdate message which is not
useful and not expected in EAP-TLS.  Implementations SHOULD NOT send a
KeyUpdate message.  If a KeyUpdate message is received then an
implementation SHOULD ignore the message and it SHOULD NOT send a KeyUpdate
message in response."

I think this is better than "implementations MUST NOT send this message and
MUST fail upon reception".  The problem here is that the EAP TLS
implementation may not have control over this behavior.

Thanks,

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

Re: [Emu] Review of draft-ietf-emu-eap-tls13

[Joseph Salowey]

I went through the review and created issues for the ones that were not
covered by existing issues or PRs.  Some issues, such as Issue 58 on nits
contain several of the comments below.

Issues may be discussed on the list or in github issues, however
resolutions for any normative or substantial text not discussed on the list
are to be posted to the list before resolution.  Therefore it would be
better to have substantial changes discussed on the mailing list.

Thanks,

Joe

On Thu, Mar 4, 2021 at 9:47 AM Alan DeKok  wrote:

> Section 1 says:
>
> This document defines how to use EAP-TLS with TLS 1.3 (or higher) and
>
> This text is incorrect.
>
> Q: Does this document define how to use EAP-TLS with TLS 1.4?  What if
> TLS 1.4 changes the TLS layer in such a way that EAP-TLS requires
> modification, as done with TLS 1.2 to TLS 1.3?
>
> Suggestion: remove all "or higher" text.  Add in text which says that
> by default, EAP-TLS 1.3 implementations MUST limit the maximum TLS
> version to 1.3, unless later versions are explicitly enabled by the
> administrator.
>


> There is no reason for implementations to allow the use of an
> undefined version of EAP-TLS.  It is not appropriate for this document
> to suggest that it defines EAP-TLS 1.4+ when it does not.
>
> As background, most EAP-TLS implementations have relied on the
> underlying TLS library to negotiate TLS versions.  Most EAP-TLS
> implementations did not limit the maximum TLS version.  As a result,
> when the TLS libraries were updated to for TLS 1.3, many EAP-TLS
> implementations would negotiate TLS 1.3, and then fail.  Because any
> behavior was accidental instead of specified, and therefore nothing
> would interoperate.
>
> This interoperability failure has been the source of a great many
> problems in many deployments.  The only solution was to upgrade the
> EAP peer and/or the EAP server in order to forcibly limit the maximum
> TLS version to 1.2.  In some cases, the implementations did not even
> export a configuration option which controlled the TLS versions, so
> that had to be added, too.
>
> Implementations should not make the same mistake with TLS 1.4 as was
> done with TLS 1.3.  Therefore, this document should explicitly call
> out this issue, and suggest a path for implementations to follow.
>
> [Joe] I agree with being cautious about the next version. I created an
issue to track this - Issue #57
.


>
> Section 1 says:
>
>While this document updates EAP-TLS [RFC5216], it
>remains backwards compatible with it and existing implementations of
>EAP-TLS.
>
> Other than the abstract, this is the only reference to EAP-TLS 1.3
> being backwards compatible with older versions of EAP-TLS.  This
> compatibility is simply asserted, with no further explanation given.
>
> Q: What does "backwards compatible" mean?  How is it achieved?
>
> Suggestion: add text explaining how it is backwards compatible.  How
> will EAP-TLS 1.3 implementations negotiate EAP-TLS 1.2?  Perhaps
> update Section 2.1 with text indicating that TLS version negotiation
> is handled by the TLS layer, and thus outside of the scope of EAP-TLS.
> Therefore so long as the underlying TLS implementation correctly
> implements TLS version negotiation, EAP-TLS will automatically
> leverage that capability.
>
>
[Joe]  It seems it would be sufficient to just add "backwards compatible
through TLS version negotiation.


>
> Section 1 says:
>
> ... Privacy, which in EAP-TLS means that the peer username is not
>disclosed
>
> Nit: For resumption, the peer username (TLS PSK identity) is
> disclosed, but it is meaningless.  Also, EAP uses "Identity" and not
> "username".
>
> Suggestion: instead, say
>
> ... Privacy, which in EAP-TLS means that no information about
>the underlying peer identity is disclosed.
>

[Joe] OK


>
> Section 2.1.1 says:
>
>TLS 1.3 introduced the Post-Handshake KeyUpdate
>message which is not useful and not expected in EAP-TLS.
>
> Q: What does it mean that the message is "not expected"?  This seems
> like a source of implementation-defined behavior, which experience
> shows has been a source of interoperability and security issues.
>
> Suggestion: If there is no use for KeyUpdate messages, then mandate
> that it SHOULD be ignored, or perhaps connections which use KeyUpdate
> MUST be closed without updating the keys.  OpenSSL as APIs to
> determine the status of key updates, so this suggestion is
> implementable.
>
>
[Joe] I think the best thing to do here is to say the key update MUST NOT
be sent and SHOULD be ignored if it is received.




>
> Section 2.1.1 says:
>
>The EAP-TLS
>server always commits to not send any more handshake messages by
>sending a TLS close_notify alert.
>
> The topic of close_notify versus application data has been discussed
> elsewhere.  However, the text here implies that EAP-TLS is overloading
> TLS layer semantics in ord

[Emu] Resolving EAP-TLS issues

[Joseph Salowey]

The authors have been working on the draft-ietf-emu-eap-tls13 in the GitHub
Repo (https://github.com/emu-wg/draft-ietf-emu-eap-tls13).  Below is a
brief summary of the Issues and PRs that have recently been merged or ready
to be merged.  If you are aware of issues that are not currently tracked in
the repo please add them or let the chairs know.  We are looking to publish
a new draft in the next few weeks so indicate on the list if there are
problems with these resolutions.

Thanks,

Joe

PR #44  -
Merged - Editorial - Clarifies that Message Flows are Examples
PR #50  -
Merged - Editorial - Moving from Master to Main terminology as in RFC8446bis
PR #51  -
Merged - Editorial - added text to suggest that one session ticket be sent
- Issue 48 
PR #53  -
Merged - Normative - Uses type code in the context of the key
derivation - Issue
32  - Issue 56

PR #40  - Ready
to Merge - Editorial - alignment with EAP State Machine Terminology - Issue
33  Issue 36

PR #41  - Ready
to Merge - Editorial - Discussion of packet modification attacks - Issue 36

PR #42  - Ready
to Merge - Editorial - Reference EAP-Types draft
PR #45  -
Ready to Merge - Editorial - Describes why session resumption is needed - Issue
34 
PR #46  - Ready
to Merge - Normative - Makes it mandatory to send Error Alerts to
single EAP Failure - Issue 37
 - Issue 38

PR #54  - Ready
to Merge - Normative - uses protected success indicators as single 0x00
byte of application data - Issue 55


Open Issues without proposed Resolution

Issue #52  -
Needs Discussion and Proposal - Update security considerations with
discussion of implications no peer authentication
Issue #47  -
Needs DIscussion and proposal - how does the peer validate the identity of
the server?
Issue #29  -
Needs DIscussion and proposal - mutual authentication section is broader
than mutual authentication
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Github repo for EAP-TLS 1.3 document

[Joseph Salowey]

Hi Folks,

I want to make the working group aware that there is a github repo for
EAP-TLS 1.3.
https://github.com/emu-wg/draft-ietf-emu-eap-tls13

I've asked the authors not to update the document directly, but rather use
issues and PRs that can be discussed.  I encourage other members of the
working group with an interest to contribute to review and add to the
discussion there.

Resolution to issues will be posted to the list.

Cheers,

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

[Emu] EAP-TLS 1.3 Success result indications resolution

[Joseph Salowey]

We have two options for protected Success 1) a single byte of application
data set to 0 or 2) use close notify.  We have two implementation reports
to indicate that both of these options should be implementable in most
cases.  However, it seems that we have more implementation experience with
the application data than we do with close_notify.  It is also pretty
certain that libraries that provide interfaces to applications, such as
EAP-TLS, will provide a way to send and receive application data.  The
sending of close_notify may not be as controllable and the reception may
not be as detectable in all libraries.

The proposal is to move forward with a single byte of application data set
to 0.  Please comment on the thread if you disagree.  It's likely that we
will discuss this in the EMU meeting at IETF 110.  Perhaps we will have
some more implementation experience by then.

Cheers,

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

[Emu] EAP-TLS key derivation resolution

[Joseph Salowey]

The current draft test specifies the following for key derivation:

   Type-Code  = 0x0D
   MSK= TLS-Exporter("EXPORTER_EAP_TLS_MSK_"+Type-Code,
   "",64)
   EMSK   = TLS-Exporter("EXPORTER_EAP_TLS_EMSK_"+Type-Code,
   "",64)
   Method-Id  = TLS-Exporter("EXPORTER_EAP_TLS_Method-Id_"+Type-Code,
   "",64)
   Session-Id = Type-Code || Method-Id

   A zero-length context (indicated by "") is used in the TLS exporter
   interface.  The EAP-TLS Type-Code of '0D' (in hexadecimal) is
   appended to the label strings.  Other TLS based EAP methods can use
   exporters in a similar fashion by replacing the EAP-TLS Type-Code
   with their own Type-Code (encoded as a hexadecimal string).


The main alternative proposals are to 1) include identity information
in the context and 2) include the type code in the context instead of
the label.

1) has not received support from the working group

2) is a viable alternative, but it really isn't in the spirit of the context.


The proposed resolution is to use the type-code in the label as
defined above and in draft-14.  Please comment on this thread if you
disagree.


Cheers,


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

[Emu] Call for Agenda Items for IETF 110

[Joseph Salowey]

The EMU meeting at IETF 110 will be on Monday, March 8, 2021, from
13:00-15:00 CET.

Please send the chairs (emu-cha...@ietf.org) requests for presentation slots.

Don't forget to include the title of your presentation, related
drafts, and the approximate amount of time needed.

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

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

[Joseph Salowey]

On Fri, Feb 19, 2021 at 3:32 AM Alan DeKok 
wrote:

> On Feb 19, 2021, at 12:26 AM, Joseph Salowey  wrote:
> > I'd like to hear from implementers about their experience with this
> mechanism:
> >


Was this both Peer and server implementation?


>
> > 1. Have you implemented the zero byte application record signa? If not,
> why not?l
>
>   Yes.
>
> > a. Is it sent after receiving the client finished?
>
>   Originally no, but now yes.
>
> > b. Do you anticipate problems if the application record comes before or
> after a NewSessionTicket message?
>
>   No.
>
> > c. did you run into any issues with this mechanism?
>
>   No.
>
> > 2. Have you implemented the close notify method? If not, why not?
>
>   Yes.  Right now, it's a secret configurable flag to switch between these
> options.
>
> > a. Is it sent after receiving the client finished?
>
>   Yes.
>
> > b. Were you able to cause the message to be sent for the server or
> determine that the message was received for the peer/supplicant?
>
>   Yes.
>
> > c. Did you run into any issues with this mechanism?
>
>   No.
>
>   Alan DeKok.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Joseph Salowey]

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

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

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

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

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

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

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

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

Joe

On Sat, Feb 6, 2021 at 5:22 PM Joseph Salowey  wrote:

> There is growing support for mandating result indicators for EAP-TLS 1.3.
> The result indicators help protect the EAP protocol exchange in the many
> different types of environments EAP-TLS is used and make the integration
> with the EAP state machine clearer.  This has the impact of adding a round
> trip to EAP-TLS 1.3 making a total of 4.5 round trips.  It may be possible
> to optimize this exchange, but that would need further study and would be
> beyond the scope of this effort.
>
> This consensus call has two parts:
>
> 1. Please respond to the list if you support adding explicit result
> indications of success and failure from the EAP Server to the EAP Peer in
> EAP-TLS 1.3.  If you object please respond to the list indicating why.
>
> 2. Please respond to the list if you support using TLS close_notify alert
> for a success indication and TLS error alert for a failure indication.  If
> you object please respond to the list indicating why.
>
> This call will run for 1 week.  Please respond by February 15, 2021.
>
> Thanks,
>
> Joe
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Joseph Salowey]

On Sun, Feb 14, 2021 at 6:47 PM Benjamin Kaduk  wrote:

> On Wed, Feb 10, 2021 at 10:48:10AM +, John Mattsson wrote:
> > With Alan's comments, I think we are down to 3 alternatives:
> >
> > (1a). Use close_notify alert as protected success.
> >   Use error alerts as protected failure.
> >
> >  - Forbid close_notify except as success indication
> >  - Mandate Error alert before EAP-Failure
> >  - Forbid all use of user_cancelled
> >
> > (1b). Use close_notify alert as protected success.
> >   Use all other alerts as protected failure.
> >
> >   - Forbid close_notify except as success indication
> >   - Mandate Error alert or user_cancelled before EAP-Failure
> >
> > (2). Use application data as protected success.
> >  Use all alerts as protected failure.
> >
> > - After sending application data in an EAP-Request the EAP-TLS
> server MUST send only EAP-Success.
> > - Mandate alert (closure, error) before EAP-Failure
> >
> > I think it is important to discuss what the ongoing EMU consensus call
> will mean in practice. Previous discussions was mostly about not sending
> more handshake messages. Protected result indicators are quite different.
> >
> > It would we very good with early feedback from Ben and the TLS WG if
> they see problems with any of the alternatives.
>
> On first look it seems like all of those will be able to achieve the
> required properties.  In some sense it is "probably" going to be "easier"
> for an application using TLS to use TLS application data (as opposed to
> alerts) to affect its behavior, though I believe that TLS implementations
> generally do provide the needed information about received alerts and
> flexibility in what alert to send that's needed for the (1) variants.
>
>
[Joe] In the past handling of close_notify was one of the rougher parts of
TLS implementations.  I'm not sure how much it has improved.


> Another potential factor that I'm not (currently) equipped to evaluate is
> the reusability of the machinery defined by EAP-TLS for use by other EAP
> mechanisms.  E.g., if we say that for EAP-TLS any application data is a
> protected success, would that be in conflict with any scenarios for the EAP
> mechanisms that do have to send some data on the TLS application data
> stream?
>
>
[Joe]  TEAP already has a result indicator within the tunnel, so it would
not need to use the same machinery.  I believe that many of the other
tunnel methods have something similar, so I would expect tunneled methods
to use their own mechanism as a result indication.


> I'd be happy to hear some more voices from the TLS WG chiming in to
> corroborate (or contradict) my conclusions in the first paragraph.
>
> Thanks,
>
> Ben
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Publication has been requested for draft-ietf-emu-eap-noob-03

[Joseph Salowey via Datatracker]

Joseph Salowey has requested publication of draft-ietf-emu-eap-noob-03 as 
Proposed Standard on behalf of the EMU working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/


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

[Emu] Key Derivation for EAP-TLS 1.3

[Joseph Salowey]

I'd like to get feedback from the working group on the EAP-TLS 1.3 key
derivation.  Does this improve the security of the system?  Are there any
implementation barriers?

The key derivation for TLS 1.3 uses the key exporters defined for TLS 1.3.
A few reviews have pointed out that the exporter master secret for TLS
exporters includes server identity information, but does not include
information about the peer/client identity.

Both Martin and Ben proposed adding the peer identity into the context
parameter for the TLS exporter key derivation. This binds the peer identity
into the key derivation for EAP-TLS keys that are used in lower layer
protocols.   This explicit binding strengthens the resulting authentication
implied by the key and should make formal analysis of the system easier.

For example, if the EAP-TLS server is requesting a certificate from the
peer then the key derivation would look something like:

Key =  TLS-Exporter(label, peerID/peer certificate, 64)

Where the label is the label defined for the key and the peer ID is
identity information for the peer.  Since the peer ID in EAP-TLS has some
potential ordering issues, it may be better to use the end entity
certificate of the peer as the peerID.

In the case where the peer is not asked for a certificate then the
derivation would not include the peerID. The TLS resumption key derivation
is derived using both the peer and server identity from the original
exchange so adding the peerID into the EAP-TLS key derivation in the
resumption is not necessary.

Cheers,

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

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

[Joseph Salowey]

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

This consensus call has two parts:

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

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

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

Thanks,

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

[Emu] Way Forward for EAP-TLS 1.3

[Joseph Salowey]

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

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

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

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

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

Cheers,

Joe

[1] https://mailarchive.ietf.org/arch/msg/emu/hawPjEH2RRin4MlzqJe57Yrf0bQ/
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP-TLS protected result indications

[Joseph Salowey]

On Tue, Feb 2, 2021 at 11:41 AM Bernard Aboba 
wrote:

> Joe Salowey said:
>
> "[Joe] Based on RFC 5216 the server could fail the finished message or as
>
> section 2.1.3 shows it could send the finish and then it can send an Alert 
> and result in EAP-Failure.  In this case it would be possible for an attacker 
> to remove the Alert and send a success.  Whether your
> implementation ends up in this scenario or not probably depends upon why
> the auth failed and the behavior of your TLS library.
>
> I do not believe that RFC 5216 provides protected result indications.   It 
> would be a fine thing to add, but it is new to the specification and I'm not 
> sure that is why the commitment message was added to begin with."
>
> [BA] EAP-TLS implementations do provide protected result indications.  Due to 
> injection attacks, implementations were modified to support RFC 4137 so as to 
> protect against spoofed EAP-Success and EAP-Failure messages.  For example, 
> implementations of the EAP-TLS state machine should not be driven by 
> EAP-Success and EAP-Failure messages, which are unprotected. This ensures 
> that an Alert sent after Finish will be correctly recognized as an alternate 
> failure indication, regardless of whether an attacker injected an EAP-Success 
> message in between.
>
> [Joe] Aha, It's coming back to me now and it does seem that
implementations do this.  Do you know if the implementation requirements
were documented anywhere?



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

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

[Joseph Salowey]

On Tue, Feb 2, 2021 at 2:10 PM Alan DeKok  wrote:

> On Feb 2, 2021, at 4:42 PM, John Mattsson  40ericsson@dmarc.ietf.org> wrote:
> > 4. was something I thought was clear. The -13 version states that “The
> EAP-TLS server commits to not send any more handshake messages”. This was
> according to my memory exactly what was requested from the implementors.
>
>   The text is in draft-mattsson-eap-tls13-02, but not in
> draft-ietf-emu-eap-tls13-00.  The announcement message is here:
>
> https://mailarchive.ietf.org/arch/msg/emu/8Axkmgh_ZPCTwhvmRjVMvXGTKko/
>
>   Which doesn't mention the commitment message.  I can't find any other
> discussion about the commitment message on the archive.  That doesn't
> necessarily mean much, as the archive is difficult to search.
>
>   So it's not clear where that came from.
>
>
[Joe] I think this message from Jouni explains the original impetus to add
the commit message.
https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/
What I'm gathering from this discussion is the state machine between TLS
1.3 and 1.2 is different enoguh that EAP-TLS implementations are going to
have to account for it.


> > In the last weeks discussion, the commitment message has been given a
> lot of different interpretations that are not coming from the draft. The
> meaning of and requirements for the -13 commitment message now seems quite
> unclear.
>
>   An in-progress draft is not an authoritative source of information.  The
> WG is discussing what the commitment message means, with an eye to making
> recommendations for the draft, and implementors.
>
  Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] [TLS] 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: [Emu] [TLS] 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.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

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

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

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

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

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

Re: [Emu] [TLS] 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 ser

Re: [Emu] [TLS] 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 s

Re: [Emu] [TLS] 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 was

Re: [Emu] NewSessionTicket, Resumption, close_notify, and number of round-trips

[Joseph Salowey]

On Wed, Jan 27, 2021 at 7:17 AM Alan DeKok 
wrote:

> On Jan 27, 2021, at 10:09 AM, John Mattsson  40ericsson@dmarc.ietf.org> wrote:
> >
> > Looking at the GitHub version after the latest changes. I don't think
> the tradeoffs make sense anymore.
> >
> > - Full handshake is now 4.5 round-trips
>
>   Does that account for large / long certificate chains?
>
> > - Resumption is now 4.5 round-trips.
> >
> > This does not seem like a good tradeoff or optimization at all. If we
> instead skipped Resumption, the full handshake could as far as I understand
> always be done in 3.5 round-trips. This would cut a large amount of
> complexity from the draft and implementations and make the protocol much
> faster.
>
>   That sounds good.  But how would this affect other TLS-based EAP
> methods?  They send data inside of the tunnel, which adds round trips.  So
> perhaps resumption is useful there?
>
>   It would likely be problematic if EAP-TLS doesn't support resumption,
> but TTLS / PEAP / etc. required it.
>
>
[Joe] It seems that resumption would help in the case that large
certificates cause multiple round trips.  Do you have an idea of how
widespread resumption use is in current EAP-TLS implementations?   Its
likely that TEAP implementations would use resumption, however they handle
commitment in a different way.


>   And of course, this ignores the timeliness of the changes.  I suspect
> that silence from the WG means that consensus is "we can afford to wait
> another year for EAP-TLS to be finished".
>
>   Alan DeKok.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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