[Emu] draft-ietf-emu-rfc7170bis-01 - few more comments

[Oleg Pekar]

Hi all,
Few more comments:
1) Section "3.3.4.  Protected Termination and Acknowledged Result
Indication"

Except as noted below, the Crypto-Binding TLV MUST be
   exchanged and verified before the final Result TLV exchange,
   regardless of whether or not there is an inner EAP method
   authentication.  The Crypto-Binding TLV and Intermediate-Result TLV
   MUST be included to perform cryptographic binding after each
   successful authentication in a sequence of one or more inner
   authentications.

--this is confusing by introducing another term "inner authentication" in
addition to two existing in the document "inner method" and "inner EAP
method". Please note that there could be no real authentication but just
unsuccessful inner EAP method negotiation or even just exchange of Identity
Request/Response. Maybe we should do a very formal approach:
• Define inner method as something that is conducted in Phase 2
• Define two types of inner method - inner EAP method (that starts with
Identity Request, no matter whether it performs authentication or not) and
basic password authentication and treat them in the same way
• We should also consider the option when there's no inner method in Phase 2

The same regarding the section "3.6. Error Handling, item #3" and "4.2.11.
Intermediate-Result TLV" and few other places.

2) Nit: Section "5.2.  Intermediate Compound Key Derivations" - looks that
the concatenation operator is escaped, while in the other places it is not:

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

3) Are we planning to address all errata items in this review cycle? Some
of them are not yet in.

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

Re: [Emu] TEAP erratum 5775

[Oleg Pekar]

After implementing EAP-FAST and TEAP, I see a big value in simplifying the
protocol state machine. If we draw a state machine diagram and it can be
placed on a relatively small piece of [virtual] paper and clearly readable
- it is much better for the implementers. Thus I would vote for keeping a
common pattern for everything that happens in Phase 2.

Regarding Crypto-Binding TLV contents when there's no inner method crypto
material available - outer tunnel crypto material is already included via
S-IMCK[0].

Thanks
Oleg



On Thu, Dec 1, 2022 at 3:44 PM Eliot Lear  wrote:

> Hi,
>
> I am reviewing the errata on GitHub and would like to close on them.  The
> first one I am addressing is 5775, which can be found on the RFC Editor
> page at https://www.rfc-editor.org/errata/eid5775.  Joe's proposed fix
> can be viewed at
> https://github.com/emu-wg/teap-errata/commit/6fdcc5b155b8b844c4b9e2e24cddf8701a309424
> .
>
> Th proposed change is as follows:
>
> 4.2.13. Crypto-Binding TLV
>
> The Crypto-Binding TLV is used to prove that both the peer and server
> participated in the tunnel establishment and sequence of authentications.
> It also provides verification of the TEAP type, version negotiated, and
> Outer TLVs exchanged before the TLS tunnel establishment.
>
> The Crypto-Binding TLV MUST be exchanged and verified before the final
> Result TLV exchange, regardless of whether there is an inner EAP method
> authentication or not. It MUST be included with the Intermediate-Result
> TLV to perform cryptographic binding after each successful EAP method in a
> sequence of EAP methods, before proceeding with another inner EAP methodeach
> successful Intermediate-Result TLV to perform cryptographic binding after
> each EAP authenticaiton or basic password method, before proceeding with
> another authentication exchange. If no MSK or EMSK has been generated and a
> Crypto-Binding TLS is required then the MSK Compound MAC field contains the
> MAC using keys generated according to section 5.2. The Crypto-Binding TLV
> is valid only if the following checks pass:
>
> I think we need to back up and review the three cases that we have:
>
>1. There is an inner method.  This means there is no issue (yay!).
>2. No inner method but authentication.
>3. No inner method and just TLVs.
>
> What value is crypto-binding offering in the latter two cases?  I'm not
> sure I see any.  If that is the case, then we should suppress the
> crypto-binding TLV with the result TLV.  This would surely break existing
> TEAP implementations, and would require a version bump.  In this case, with
> regard to the erratum, we would HOLD FOR UPDATE.
>
> If there is any value, then is simply zeroing the field seems wrong.
> Section 5.3 talks about the BUFFER being created from outer TLV
> information.  But outer TLVs are not protected.  Thus anyone can calculate
> this with zero'd fields.  This means we may wish to use TLS seed
> information.  But again, I'm not sure I see value here.
>
> If we choose to zero the field as is suggested in Section 5.2, then I
> suggest we just say that in the text rather than referring to the entirety
> of Section 5.2.  In this case we could VERIFY the erratum.
>
> Eliot
> ___
> 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-rfc7170bis-00.txt Review

[Oleg Pekar]

r
EAP-MSCHAPv2.
[Oleg] then maybe better to refer to RFC 3079 where the order is claimed to
be defined. But essentially, to be formal, it is not also explicitly
defined even there! The only place we found the order is explicitly defined
is here:
https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-chap/5a860bf5-2aeb-485b-82ee-fac1e8e6b76f


>I'm less sure that it's useful to re-iterate that PEAP uses the "normal"
version.  I think it's best to just discuss TEAP, and how TEAP is different
from everything else.
[Oleg] You are absolutely right

>Also for basic password, the  Basic-Password-Auth-Req TLV is *not* marked
mandatory.  It should probably be marked mandatory to match the use of the
"mandatory" bit:
>
>If the peer wishes to participate in password
>authentication, then it responds with a Basic-Password-Auth-Resp TLV
>as defined in Section 4.2.15 that contains the username and password.
>If it does not wish to perform password authentication, then it
>responds with a NAK TLV indicating the rejection of the
Basic-Password-Auth-Req TLV.
>
> Whereas the later text in Section 4.2 says:
>
>The mandatory bit in a TLV indicates whether
>support of the TLV is required.  If the peer or server does not
>support a TLV marked mandatory, then it MUST send a NAK TLV in the
>response, and all the other TLVs in the message MUST be ignored.

> It MUST NOT send a NAK
>TLV for a TLV that is not marked mandatory
[Oleg] Oh, this is a good catch

I created basic password authentication protocol state machine diagram and
would like to share it for reference. Is there a standard way to share
images in the WG?

Thanks
Oleg

On Sun, Jan 1, 2023 at 8:41 PM Alan DeKok  wrote:

> On Dec 31, 2022, at 12:14 PM, Oleg Pekar 
> wrote:
> >
> > Hi all,
> > Few initial comments:
>
>
>
> > 1)  Section "3.3.1.  EAP Sequences"
> > It says "Upon completion of each EAP method in the tunnel, the server
> MUST send an Intermediate-Result TLV...". We have discussed previously that:
> > a) EAP RFC 3748 calls EAP types 1..3 also "EAP methods":
>
>   This is address with discussion in commit
> https://github.com/emu-wg/rfc7170bis/commit/57b157e748603b282f3fb1c50cea3598587c490e
>
>   In short, RFC 3748 uses "EAP method" everywhere to mean "EAP
> authentication method",
>
>   I'm OK with changing it, but I don't think it's a large source of
> confusion.
>
> > 2) Regarding using both password authentication and EAP authentication
> method inside the same TEAP tunnel - should we merge the explanation on
> what to do after completion of each EAP authentication method and password
> authentication into a common section since the completion is the same?
>
>   Perhaps.  I'm trying to keep it close to RFC 7170, as minimal changes
> may help it get published more quickly.
>
> > 3) If we explicitly mention that password authentication can be used for
> pin operations and thus multiple round trips are supported - should we also
> allow passing user prompt and other pin related things?
>
>   Yes.  The Basic-Password-Auth-Req TLV already allows for a prompt field,
> so that seems to be sufficient.
>
> > 4) Since multiple roundtrips of password authentication are allowed - we
> should specify what exactly to consider a "completion" of it since it
> induces the finalization flow
>
>   The completion should just be sending a Result TLV?
>
>   The final paragraph of 3.3.2 says:
>
> Multiple round trips of password authentication requests and responses MAY
> be used to support some "housecleaning" functions such as a password or pin
> change before a user is authenticated.
>
>   Perhaps it's best to add some clarifying text:
>
>
> * the EAP server decides (somehow, implementation-defined) when it should
> stop sending Basic-Password-Auth-Req
>
> * there is a limit on the number of round trips which can be made
>
> * Using this method to change passwords is NOT RECOMMENDED
>
> > 5) Regarding "3.3.3.  EAP-MSCHAPv2" I would suggest to explicitly
> mention the document where EAP-MSCHAPv2 MSK 16-octets blocks order is
> defined (the order that is different from EAP-FAST-MSCHAPv2). We should
> also mention that in PEAP and maybe some other protocols the original (non
> EAP-FAST-MSCHAPv2) order is used.
>
>   I can add a reference to
> https://datatracker.ietf.org/doc/html/draft-kamath-pppext-eap-mschapv2-02
> for EAP-MSCHAPv2.
>
>   I'm less sure that it's useful to re-iterate that PEAP uses the "normal"
> version.  I think it's best to just discuss TEAP, and how TEAP is different
> from everything else.
>
>   Also for basic password, the  Basic-Password-Auth-R

[Emu] draft-ietf-emu-rfc7170bis-00.txt Review

[Oleg Pekar]

Hi all,
Few initial comments:

1)  Section "3.3.1.  EAP Sequences"
It says "Upon completion of each EAP method in the tunnel, the server MUST
send an Intermediate-Result TLV...". We have discussed previously that:
a) EAP RFC 3748 calls EAP types 1..3 also "EAP methods":

6.2.  Method Types

   The original EAP method Type space has a range from 1 to 255, and is
   the scarcest resource in EAP, and thus must be allocated with care.
   Method Types 1-45 have been allocated...

b) However after EAP method types 1..3 we should not send
Intermediate-Result TLV.

Thus we considered in one of the previous discussions to say in Section
3.3.1 of TEAP "Upon completion of each EAP __authentication__ method in the
tunnel, the server MUST send an Intermediate-Result TLV...". And then "EAP
authentication method is EAP type 4 or greater".

There are few more places in TEAP draft where the same "EAP authentication
method" substitution may be required instead of "EAP method"

2) Regarding using both password authentication and EAP authentication
method inside the same TEAP tunnel - should we merge the explanation on
what to do after completion of each EAP authentication method and password
authentication into a common section since the completion is the same?

3) If we explicitly mention that password authentication can be used for
pin operations and thus multiple round trips are supported - should we also
allow passing user prompt and other pin related things?

4) Since multiple roundtrips of password authentication are allowed - we
should specify what exactly to consider a "completion" of it since it
induces the finalization flow

5) Regarding "3.3.3.  EAP-MSCHAPv2" I would suggest to explicitly mention
the document where EAP-MSCHAPv2 MSK 16-octets blocks order is defined (the
order that is different from EAP-FAST-MSCHAPv2). We should also mention
that in PEAP and maybe some other protocols the original (non
EAP-FAST-MSCHAPv2) order is used.

The next portion of the comments is coming soon...

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

Re: [Emu] Adoption call for RFC 7170bis

[Oleg Pekar]

I would like to provide comments as well. We should also bump the version
of the protocol so as not to harm the existing implementations (yes, they
implemented the spec with filed errata, the spec is sometimes ambiguous but
those implementations are already on the market).

Regards,
Oleg

On Fri, Dec 16, 2022 at 12:29 AM Peter Yee  wrote:

> This is an adoption call for RFC 7170bis
> (draft-dekok-emu-rfc7170bis-00)[1].
> I'd call this mostly a formality since it's pretty clear the WG is
> interested in updating TEAP and TEAP was already adopted by the WG (back in
> May 2011). With Alan having generated a new working version to host the
> update and even preparing a Git repository[2] to that end, I believe we're
> in a good place to revise RFC 7170. That said, if anyone has an objection
> to
> starting off from Alan's kind offering, please let us know by December 22,
> 2022.
>
> Joe and Peter
>
> 1) https://datatracker.ietf.org/doc/draft-dekok-emu-rfc7170bis/
> 2) https://github.com/alandekok/rfc7170-bis.git
>
>
>
> ___
> 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] Clarification about OCSP Stapling in EAP-TLS 1.3

[Oleg Pekar]

Dear workgroup,
Please help me to clarify the next question.

RFC 9190 "EAP-TLS 1.3", Section "5.4.  Certificate Revocation" says:
"EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
Requests (OCSP stapling) as specified in [RFC6066] and Section 4.4.2.1 of
[RFC8446]"

Wording "MUST Implement" doesn't explicitly specify whether an EAP-TLS
server must reply to a particular peer's OCSP stapling request or not.

RFC 6066 "TLS Extensions Definition", Section "8.  Certificate Status
Request" says:
"Note that a server MAY also choose not to send a "CertificateStatus"
   message, even if has received a "status_request" extension in the
   client hello message and has sent a "status_request" extension in the
   server hello message."

These two references create ambiguity, as I see it - is it mandatory for
EAP-TLS server to respond to OCSP stapling request? If not, per RFC 6066,
then "MUST Implement" of RFC 9190 has no effect since it's possible to
implement an EAP-TLS 1.3 server that never responds to OCSP stapling
request and it is equal to not implementing OCSP stapling at all. This is
what I would be happy to clarify.

Note: there's at least one scenario when an EAP-TLS server has a good
motivation not to send CertificateStatus message - when the peer send the
list of trusted OCSP Responders where the server's OCSP Responder is not
mentioned.

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

Re: [Emu] EAP Erratum 6154 on RFC 3579:

[Oleg Pekar]

I submitted errata on this https://www.rfc-editor.org/errata/eid6915

On Thu, Mar 31, 2022 at 5:21 PM Alan DeKok 
wrote:

> On Mar 31, 2022, at 10:05 AM, Oleg Pekar 
> wrote:
> >
> > It looks like RADIUS RFC 2865, Section "5. Attributes" is ambiguous when
> it talks about the attribute value size:
> >
> > First it says: "The Value field is zero or more octets", then it
> provides 5 possible value data types none of which allows a zero length
> value.
>
>   Yeah.  :(  It's horrible.
>
> > Section "5.26. Vendor-Specific" also says about the value of a
> vendor-specific attribute "The String field is one or more octets".
> >
> > Thus the RFC allows empty values for attributes in general but prohibits
> for any declared types of the attributes.
>
>   Yes.
>
>   RADIUS is weird and terrible.
>
>   Alan DeKok.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] EAP Erratum 6154 on RFC 3579:

[Oleg Pekar]

Hi all,

It looks like RADIUS RFC 2865, Section "5. Attributes" is ambiguous when it
talks about the attribute value size:

First it says: "The Value field is zero or more octets", then it provides 5
possible value data types none of which allows a zero length value.

Section "5.26. Vendor-Specific" also says about the value of a
vendor-specific attribute "The String field is one or more octets".

Thus the RFC allows empty values for attributes in general but prohibits
for any declared types of the attributes.

Regards,
Oleg

On Thu, Mar 31, 2022 at 12:08 PM Independent Submissions Editor (Eliot
Lear)  wrote:

> Dear EMU working group,
>
> Alan Dekok has reported two errata[1,2] against RFC 3579.  RFC 3579 is
> classed an independent submission, and thus falls under the purview of
> the Independent Submissions Editor (ISE).  The ISE is inclined to verify
> both errata, and will do so in the next two months unless this group
> advises otherwise.
>
> Eliot Lear (ISE)
>
> [1] https://www.rfc-editor.org/errata/eid6154
> [2] https://www.rfc-editor.org/errata/eid6259
>
> ___
> 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] Provisioning, configuration, etc. and EAP

[Oleg Pekar]

>When this configuration process fails or does not work, there is typically
no way to inform the user or administrator as to what went wrong.  Which
makes it essentially impossible to debug configuration and compatibility
issues.
[Oleg] If the configuration process is conducted by a centralized system
(connected to EAP authentication server) then each step of configuring a
specific supplicant can be tracked on the system, inducing the final
result. So the admin can see it and undertake some recovery action. What
are the example scenarios where such tracking is impossible?

>However, the benefit of this approach is that the provisioning system
becomes infinitely flexible.  It can use any existing internet protocol.
It can download any amount of data.
[Oleg] There are existing configuration and provisioning methods that
require the supplicant to connect to a quarantine network and get the IP
layer this way, then the provisioning software or manual user actions do
the configuration. But this method is usually proprietary per network
access control system and is pretty complicated. We can standardize this
method: create a configuration and provisioning protocol over IP (not EAP)
that will be supported by supplicants and network access control systems
and all they need to do before is to accept the supplicant on the
quarantine network.

On Fri, Mar 25, 2022 at 9:37 PM Alan DeKok 
wrote:

>   There has been a push to perform provisioning and/or configuration over
> EAP.  e.g. TEAP, NOOB, and various other proposals.  There are both costs
> and benefits to this approach.
>
>   The benefits are that admins can configure end-user systems with minimal
> effort.  "Download things over EAP" is simply to explain, and simple to
> administer.  When it works, it's great.  No one has to deploy additional
> systems, or do additional configuration.  Just poke the authentication
> servers, and they will configure the clients / supplicants.
>
>   However, there are multiple standards for doing provisioning over EAP,
> and more are proposed.  This would seem to indicate that the solutions are
> designed for specific needs, and that there is no over-arching design
> theory, requirements, or process.
>
>
>   On top of that issue, the costs of using EAP are non-zero, and the
> failure modes are significant.
>
>   When this configuration process fails or does not work, there is
> typically no way to inform the user or administrator as to what went
> wrong.  Which makes it essentially impossible to debug configuration and
> compatibility issues.
>
>   EAP implementations are limited to exchanging ~64K of data before
> supplicant and/or server gives up.  If there is a need to exchange more
> data than this, it's impossible.  Configuration data tends to grow over
> time, because of a tendency to just use the existing system, even though it
> isn't really intended for that use.  People tend to (ab)use existing
> systems in surprising ways, too.
>
>   As Bernard noted in the meeting, RFC 3748 Section 1.3 says that EAP is
> not a general transport protocol:
>
>EAP was designed for use in network access authentication, where IP
>layer connectivity may not be available.  Use of EAP for other
>purposes, such as bulk data transport, is NOT RECOMMENDED.
>
>Since EAP does not require IP connectivity, it provides just enough
>support for the reliable transport of authentication protocols, and
>no more.
>
>
> I've been pushing for provisioning via standard internet protocols.
>  RFC 9190 Section 5.6 explicitly provides for unauthenticated EAP-TLS,
> where the client may not even verify the servers certificate.  This
> practice has not been widely used.  IIRC, either the WiFi alliance or the
> WBA defines unauthenticated EAP-TLS for provisioning, but uses a
> vendor-specific EAP type.  It's not clear why EAP-TLS was insufficient here.
>
>   This method also has a cost.  Administrators now have to set up
> additional services in order to do provisioning.  This may not always be
> possible.  As Eliot pointed out, there are also security issues with
> exposing additional servers (EST, etc.) to unauthenticated users.
>
>   However, the benefit of this approach is that the provisioning system
> becomes infinitely flexible.  It can use any existing internet protocol.
> It can download any amount of data.
>
>   I think it's useful to take a step back, and discuss the requirements.
> There are many users of EAP, and each are creating solutions largely in a
> vacuum.  It would be helpful to get a good description of the problem
> statements, as it relates to EAP.
>
>   I would split this up into:
>
> bootstrapping - starting from nothing, or almost nothing, how does a
> device get on the network, and get a minimal configuration enabled?
>
> provisioning - how does a device with some existing network access /
> configuration get onto a new network, perhaps with a new identity?
>
> reconfiguration - how does a device with an 

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

[Oleg Pekar]

Here are my two cents:

1) Section: 2.1. Key Derivation
   When talking about EAP types "Type = value of the EAP Method type"
suggest providing an example of a Type here so it will be clear what is it
about for the rest of the document (e.g. for PEAP Type is 0x19)

2) Here TLS-Exporter function is mentioned for the first time in the
document. Suggest to put a direct reference to the original document where
it is defined:
   "TLS-Exporter is defined in [RFC8446] section-7.5 as TLS-Exporter(label,
context_value, key_length) = HKDF-Expand-Label(Derive-Secret(Secret, label,
""), "exporter", Hash(context_value), key_length).
   This could help the reader to understand better what do the function
parameters mean and what does the function do. Such a reference to a PRF is
used in other documents (e.g. TEAP RFC 7170)

3) Section: 2.2 TEAP
"IMSK = TLS-Exporter("teapbind...@ietf.org", EMSK, 32)" - this may be not
clear to the reader since this formula is effective when inner method
generates EMSK. It worth mentioning that in other case IMSK is selected per
TEAP RFC

4) In this sentence "For TLS 1.3, the hash function used is the same as the
ciphersuite hash function negotiated for HKDF" suggest saying "the MAC
function" instead of "the hash function"

5) Section: 2.3. FAST
"For FAST, the session_key_seed is also used as the key_block, as defined
in [RFC4851] Section 5.1" - suggest rephrasing to "For FAST, the
session_key_seed is also a part of the key_block..."

6) There are references to implement some EAP-FAST keys with TLS 1.3
similar to TEAP. I think the section about the specific protocol should be
self-contained since the reader may be interested in EAP-FAST but is not
familiar with TEAP. We should also specify the exact key derivation schemes
instead of referencing to TEAP. E.g. "T-PRF is replaced with TLS 1.3
TLS-Exporter function".

7) In addition, since TLS 1.3 allows session resumption using PSK, suggest
to explain explicitly why PAC cannot be supported anymore.

8) "EAP-FAST previously used a PAC, which is a type of pre-shared key
(PSK)" - it is more correct to say "PAC is a session ticket that contains
pre-shared key and other data"
Suggest also directly mentioning the PAC Provisioning RFC5422.

9) Section: 5. Implementation Status
"Implementors have demonstrated significant interest in getting PEAP and
TTLS working for TLS 1.3, but less interest in EAP-FAST and TTLS" -
probably the last method should be "TEAP"

10) Section: 7. IANA Considerations
"These labels are used only for TEAP" - should say "...for TEAP and FAST".

11) Section: 8.1. Normative References
RFC 5422 "Dynamic Provisioning Using Flexible Authentication via Secure
Tunneling Extensible Authentication Protocol (EAP-FAST)" is missing

12) Section: 2.5. PEAP
Some PEAP versions support CryptoBinding. PRF+ is used there so we should
mention that it is replaced with TLS-Exporter also.

13) Section: 3. Application Data
"behavior seen in earlier TLS versions/" - typo, should end with a dot
instead of a slash

14) Section: 3.1. Identities
"Using an anonymous NAI has two benefits. First, an anonymous identity
makes it more difficult to track users.  Second, an NAI allows the EAP
session to be routed in an AAA framework" - could you please explian what
does the second benefit mean?

15) "EAP servers MUST cause authentication to fail if an EAP peer uses an
anonymous "inner" identity for any TLS-based EAP method" - the word "inner"
identity should be always either with double quotes or without. It was
mentioned witout double quotes before and now with them.

16) If there is such a strict requirement "MUST fail" for anonymous
identity used inside the tunnel - then it worth defining exactly what is
anonymous identity

17) "The outer identity contains an NAI realm, which ensures that the inner
authentication method is routed to the correct destination." - suggest
explaining more on how NAI realm is used as outer identity. Should it be in
the form of "anonymous@my_ad.example.com" or in any other form?

18) "In general, routing identifiers should be strongly tied to the data
which they are routing" - could you please explain this sentence?

19) Suggest explaining explicitly what the routing identifier is.

20) "The inner identity can then be fully qualified (user name plus realm)
of the organization" - suggest to rephrase "The inner identity can then be
fully qualified name of the organization", since "fully qualified name" is
a standard term

On Fri, Feb 18, 2022 at 7:18 PM Joseph Salowey  wrote:

> 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
>
___
Emu mailing 

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

[Oleg Pekar]

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=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] Question for draft-ietf-emu-tls-eap-types-03

[Oleg Pekar]

Alan, agree on the MAC randomization problem. Is there any existing
standard or proposal for the network deployments where the Network Access
Control server needs to track the device with randomized MAC moving between
intranet SSIDs?

About usage of physical MAC address - maybe some client systems will not
have access to the physical MAC rather than just to a randomized MAC.

Regards,
Oleg

On Mon, Jun 28, 2021 at 4:21 PM Alan DeKok 
wrote:

>   One thing missing in the current document is how to address the modern
> issue of MAC address randomization.
>
>   i.e. admins would like to ensure that only certain devices access the
> network.  But with MAC address randomization, it's difficult to have a
> static device identifier.  Even client certificates can be installed on
> multiple machines, if they're just sent to the user.
>
>   Would it be worth adding a note that systems SHOULD implement RFC 6677
> channel bindings to address this issue?  And that the Calling-Station-Id
> inside of the channel bindings MUST be the actual physical MAC, and not the
> public / randomized MAC?
>
>   I've seen this problem more and more in customer deployments.  It's
> becoming a serious security issue.
>
>   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)

[Oleg Pekar]

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.

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

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=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] EAP-TLS 1.3 Section 2.2 text

[Oleg Pekar]

This version is fine. Just the term "EAP servers for the network" still
looks confusing to me. Maybe we can use instead the more detailed
explanation that you provided above.

On Tue, May 25, 2021 at 7:45 AM Joseph Salowey  wrote:

> I made some changes to the pull request to address some of the comments
> and make the text clearer:
>
> The EAP peer identity provided in the EAP-Response/Identity is not
>authenticated by EAP-TLS.  Unauthenticated information MUST NOT be
>used for accounting purposes or to give authorization.  The
>authenticator and the EAP-TLS server MAY examine the identity
>presented in EAP-Response/Identity for purposes such as routing and
>EAP method selection.  EAP-TLS servers MAY reject conversations if
>the identity does not match their policy.  Note that this also
>applies to resumption, see Sections 2.1.3, 5.6, and 5.7.
>
>The EAP server identity in the TLS server certificate is typically a
>fully qualified domain name (FQDN) in the SubjectAltName (SAN)
>extension.  Since EAP-TLS deployments may use more than one EAP
>server, each with a different certificate, EAP peer implementations
>SHOULD allow for the configuration of a unique trusted root (CA
>certificate) to authenticate the server certificate and one or more
>server names to match against the SubjectAltName (SAN) extension in
>the server certificate.  To simplify name matching, an EAP-TLS
>deployment can assign a name to represent an authorized EAP server
>and EAP Server certificates can include this name in the list of SANs
>for each certificate that represents an EAP-TLS server.  If server
>name matching is not used, then peers may end up trusting servers for
>EAP authentication that are not intended to be EAP servers for the
>network.  If name matching is not used with a public root CA, then
>effectively any server can obtain a certificate which will be trusted
>for EAP authentication by the Peer.
>
>The process of configuring a root CA certificate and a server name is
>non-trivial and therefore automated methods of provisioning are
>RECOMMENDED.  For example, the eduroam federation [RFC7593] provides
>a Configuration Assistant Tool (CAT) to automate the configuration
>process.  In the absence of a trusted root CA certificate (user
>configured or system-wide), EAP peers MAY implement a trust on first
>use (TOFU) mechanism where the peer trusts and stores the server
>certificate during the first connection attempt.  The EAP peer
>ensures that the server presents the same stored certificate on
>subsequent interactions.  Use of a TOFU mechanism does not allow for
>the server certificate to change without out-of-band validation of
>the certificate and is therefore not suitable for many deployments
>including ones where multiple EAP servers are deployed for high
>availability.
>
>
> On Thu, May 20, 2021 at 10:23 PM Joseph Salowey  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

[Oleg Pekar]

+Peter

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.

On Mon, May 17, 2021 at 11:58 PM Oleg Pekar 
wrote:

> To section: 2.2.  Identity Verification
>
> 1)
> 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.
>
> -- comment:
> What is meant by "EAP server for the network"?
>
> 2)
> EAP peer implementations SHOULD allow users to configuring a unique trust
> root (CA certificate)
>
> -- comment:
> Should say "a unique trusted root" in conformance with the other
> occurrence.
>
> 3)
> 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.
>
> -- comment:
> Could you please clarify the idea of adding the same name to SAN of
> multiple certificates, since some EAP-TLS server certificates are just
> generic certificates and their SAN DNS and IP fields may contain the unique
> value per server instance.
>
> Regards,
> Oleg
>
> On Mon, May 17, 2021 at 7:06 PM Russ Housley  wrote:
>
>> Nit: RFC 5280 (see Section 4.2.1.6) talks about the subject alternative
>> name extension, which as an ASN.1 definition for SubjectAltName.  So,
>> please do not refer to subjectAlternativeName.
>>
>> Russ
>>
>>
>> On May 15, 2021, at 8:21 PM, Joseph Salowey  wrote:
>>
>> 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 certific

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

[Oleg Pekar]

To section: 2.2.  Identity Verification

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

-- comment:
What is meant by "EAP server for the network"?

2)
EAP peer implementations SHOULD allow users to configuring a unique trust
root (CA certificate)

-- comment:
Should say "a unique trusted root" in conformance with the other occurrence.

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

-- comment:
Could you please clarify the idea of adding the same name to SAN of
multiple certificates, since some EAP-TLS server certificates are just
generic certificates and their SAN DNS and IP fields may contain the unique
value per server instance.

Regards,
Oleg

On Mon, May 17, 2021 at 7:06 PM Russ Housley  wrote:

> Nit: RFC 5280 (see Section 4.2.1.6) talks about the subject alternative
> name extension, which as an ASN.1 definition for SubjectAltName.  So,
> please do not refer to subjectAlternativeName.
>
> Russ
>
>
> On May 15, 2021, at 8:21 PM, Joseph Salowey  wrote:
>
> I proposed a PR#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 

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

[Oleg Pekar]

Thanks Joe, one comment regarding item #16 is inline below.

On Sun, May 16, 2021 at 9:52 PM Joseph Salowey  wrote:

> 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 

[Emu] EAP-TLS 1.3 - few more comments

[Oleg Pekar]

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

—

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?

—

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.

—

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.

—

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?

—

10)

2.1.5.  No Peer Authentication

Figure 7: EAP-TLS without peer authentication

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

—

11)

2.1.6.  Hello Retry Request

Figure 8: EAP-TLS with Hello Retry Request

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

—

12)

2.2.  Identity Verification

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:
What is the configured server name? Do the supplicants that play EAP-TLS
peer role usually have such configuration?

—

13)

2.2.  Identity Verification

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.

--comment:
What is meant by "EAP server for the network"?

—

14)

2.4.  

Re: [Emu] Proposed Resolution to TEAP Errata 5844

[Oleg Pekar]

Right!

One comment on wording: it may cause an illusion that the condition "if the
exchange is successful" relates to the whole sentence and not just to
Crypto-Binding
TLV.

On Thu, Nov 12, 2020 at 5:33 AM Joseph Salowey  wrote:

>
>
> On Tue, Nov 10, 2020 at 2:17 PM Oleg Pekar 
> wrote:
>
>> Section 3.3.2 says:
>>> Upon receiving the response, the server
>>>indicates the success or failure of the exchange using an
>>>Intermediate-Result TLV.
>>> It Should say:
>>> Upon receiving the response, the server MUST
>>>indicate the success or failure of the exchange using an
>>>Intermediate-Result TLV.
>>
>>
>>  Shouldn't it be:
>>
>> Upon receiving the response, the server MUST
>>indicate the success or failure of the exchange using an
>>Intermediate-Result TLV and Crypto-Binding TLV.
>>
>> Since necessity to send Crypto-Binding TLV after basic password
>> authentication was already mentioned in section 4.2.13 of Errata 5775 mail
>> thread.
>>
>>
> [Joe] The crypto binding TLS is only included on a successful exchange.
> section 4.2.11 says "An Intermediate-Result TLV indicating success
>
>MUST be accompanied by a Crypto-Binding TLV."  Maybe it should say:
>
>
> "Upon receiving the response, the server MUST
>indicate the success or failure of the exchange using an
>Intermediate-Result TLV accompanied by a Crypto-Binding
>
>TLV if the exchange is successful."
>
>
>
>
>> On Mon, Nov 2, 2020 at 12:12 AM Joseph Salowey  wrote:
>>
>>> Revision for 8544. The wording needs some review.  Additional revisions
>>> were made to section 4.2.13 in 5775.
>>>
>>> PR Section 5: https://github.com/emu-wg/teap-errata/pull/19
>>> PR section 3: https://github.com/emu-wg/teap-errata/pull/22
>>> PR section 3: https://github.com/emu-wg/teap-errata/pull/23
>>> PR section 4: https://github.com/emu-wg/teap-errata/pull/24
>>>
>>> Errata 5844: https://www.rfc-editor.org/errata/eid5844
>>> Status: Verified
>>> Revision:
>>>
>>> Section 3.3.2 says:
>>>
>>> Upon receiving the response, the server
>>>indicates the success or failure of the exchange using an
>>>Intermediate-Result TLV.
>>>
>>> It Should say:
>>>
>>> Upon receiving the response, the server MUST
>>>indicate the success or failure of the exchange using an
>>>Intermediate-Result TLV.
>>>
>>> Section 3.6 says:
>>>
>>> 3. The Intermediate-Result TLVs carry success or failure indications of
>>> the individual EAP methods in TEAP Phase 2.
>>>
>>> It Should say:
>>>
>>> 3. The Intermediate-Result TLVs carry success or failure indications of
>>> each individual EAP authentication method or basic password authentication
>>> in TEAP Phase 2.
>>>
>>> Section 4.2.11 says:
>>>
>>> The Intermediate-Result TLV provides support for acknowledged
>>> intermediate Success and Failure messages between multiple inner EAP
>>> methods within EAP.
>>>
>>> It Should say:
>>>
>>> The Intermediate-Result TLV provides support for acknowledged
>>> intermediate Success and Failure messages for inner EAP authentication
>>> methods and basic password authentication.
>>>
>>> Section C.1 says:
>>>
>>> <- Crypto-Binding TLV (Request),
>>> Result TLV (Success),
>>> (Optional PAC TLV)
>>>
>>>Crypto-Binding TLV(Response),
>>>Result TLV (Success),
>>>(PAC-Acknowledgement TLV) ->
>>>
>>> It should say:
>>>
>>> <- Intermediate-Result-TLV (Success),
>>> Crypto-Binding TLV (Request),
>>> Result TLV (Success),
>>> (Optional PAC TLV)
>>>
>>>Intermediate-Result-TLV (Success),
>>>Crypto-Binding TLV(Response),
>>>Result TLV (Success),
>>>(PAC-Acknowledgement TLV) ->
>>>
>>> Section C.2 Says:
>>> <- Result TLV (Failure)
>>>
>>> Result TLV (Failure) ->
>>>
>>> It Should Say:
>>>
>>> <- Intermediate-Result-TLV (

Re: [Emu] Proposed Resolution to TEAP Errata 5844

[Oleg Pekar]

>
> Section 3.3.2 says:
> Upon receiving the response, the server
>indicates the success or failure of the exchange using an
>Intermediate-Result TLV.
> It Should say:
> Upon receiving the response, the server MUST
>indicate the success or failure of the exchange using an
>Intermediate-Result TLV.


 Shouldn't it be:

Upon receiving the response, the server MUST
   indicate the success or failure of the exchange using an
   Intermediate-Result TLV and Crypto-Binding TLV.

Since necessity to send Crypto-Binding TLV after basic password
authentication was already mentioned in section 4.2.13 of Errata 5775 mail
thread.

On Mon, Nov 2, 2020 at 12:12 AM Joseph Salowey  wrote:

> Revision for 8544. The wording needs some review.  Additional revisions
> were made to section 4.2.13 in 5775.
>
> PR Section 5: https://github.com/emu-wg/teap-errata/pull/19
> PR section 3: https://github.com/emu-wg/teap-errata/pull/22
> PR section 3: https://github.com/emu-wg/teap-errata/pull/23
> PR section 4: https://github.com/emu-wg/teap-errata/pull/24
>
> Errata 5844: https://www.rfc-editor.org/errata/eid5844
> Status: Verified
> Revision:
>
> Section 3.3.2 says:
>
> Upon receiving the response, the server
>indicates the success or failure of the exchange using an
>Intermediate-Result TLV.
>
> It Should say:
>
> Upon receiving the response, the server MUST
>indicate the success or failure of the exchange using an
>Intermediate-Result TLV.
>
> Section 3.6 says:
>
> 3. The Intermediate-Result TLVs carry success or failure indications of
> the individual EAP methods in TEAP Phase 2.
>
> It Should say:
>
> 3. The Intermediate-Result TLVs carry success or failure indications of
> each individual EAP authentication method or basic password authentication
> in TEAP Phase 2.
>
> Section 4.2.11 says:
>
> The Intermediate-Result TLV provides support for acknowledged intermediate
> Success and Failure messages between multiple inner EAP methods within EAP.
>
> It Should say:
>
> The Intermediate-Result TLV provides support for acknowledged intermediate
> Success and Failure messages for inner EAP authentication methods and basic
> password authentication.
>
> Section C.1 says:
>
> <- Crypto-Binding TLV (Request),
> Result TLV (Success),
> (Optional PAC TLV)
>
>Crypto-Binding TLV(Response),
>Result TLV (Success),
>(PAC-Acknowledgement TLV) ->
>
> It should say:
>
> <- Intermediate-Result-TLV (Success),
> Crypto-Binding TLV (Request),
> Result TLV (Success),
> (Optional PAC TLV)
>
>Intermediate-Result-TLV (Success),
>Crypto-Binding TLV(Response),
>Result TLV (Success),
>(PAC-Acknowledgement TLV) ->
>
> Section C.2 Says:
> <- Result TLV (Failure)
>
> Result TLV (Failure) ->
>
> It Should Say:
>
> <- Intermediate-Result-TLV (Failure),
>  Result TLV (Failure)
>
> Intermediate-Result-TLV (Failure),
>Result TLV (Failure) ->
>
>
> Notes:
>
> Section 3.3.2 implies that Intermediate-Result TLV is used after each
> round of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence
> in C.1 does not show this. The proposed change in this errata adds the
> Intermediate-Result TLV indication here. Similar change should be done in
> C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that
> include Result TLV) since the language in 3.3.2 describe the indication to
> be used for both success and failure cases.
>
> In addition to this change in C.1, it would be good to clarify the
> specification globally to avoid confusion about this case since almost all
> discussion regarding Intermediate-Result TLV currently is in the context of
> inner EAP authentication. 3.3.2 should have a MUST statement similar to
> 3.3.1. 3.6 should cover success or failure indications of basic password
> auth like it does EAP methods. 4.2.11 should note Intermediate-Result TLV
> is used with both inner EAP and basic password auth.
>
>
>
> On Mon, Oct 26, 2020 at 8:44 PM Joseph Salowey  wrote:
>
>>
>>
>> On Mon, Oct 26, 2020 at 8:39 PM Joseph Salowey  wrote:
>>
>>>
>>>
>>> On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar 
>>> wrote:
>>>
>>>> Few comments:
>>>> 1) It seems that the server MUST send Crypto-Binding TLV after a single
&g

Re: [Emu] Revised Erratum for 5775

[Oleg Pekar]

A typo: "Crypto-Binding TLS" ==> "Crypto-Binding TLV"

On Sun, Nov 1, 2020 at 11:42 PM Joseph Salowey  wrote:

> The section 5 revision is rewritten to reflect handling of the case where
> no MSK is generated and text on handling the 0 MSK is moved from errata
> 5770.  this erratum could use more review.  Please comment on the list or
> in the PR.
>
> Section 4 PR - https://github.com/emu-wg/teap-errata/pull/12
> Section 5 PR - https://github.com/emu-wg/teap-errata/pull/11
>
>
> Errata ID: 5775 - https://www.rfc-editor.org/errata/eid5775
> Status: verified
> Type: Technical
> Revision:
>
> Section 4.2.13 Says:
>
> The Crypto-Binding TLV MUST be exchanged and verified before the
>  final Result TLV exchange, regardless of whether there is an inner
>  EAP method authentication or not.  It MUST be included with the
>  Intermediate-Result TLV to perform cryptographic binding after each
>  successful EAP method in a sequence of EAP methods, before proceeding
>  with another inner EAP method.  The Crypto-Binding TLV is valid only
>  if the following checks pass:
>
> It should say:
>
>The Crypto-Binding TLV MUST be exchanged and verified before the
>final Result TLV exchange, regardless of whether there is an inner
>EAP method authentication or not. It MUST be included with each
>successful Intermediate-Result TLV to perform cryptographic binding
>after each EAP authentication or basic password method, before
>proceeding with another authentication exchange.  If no MSK or EMSK
>has been generated and a Crypto-Binding TLS is required then the MSK
>Compound MAC field contains the MAC using keys generated according
>to section 5.2. The Crypto-Binding TLV is valid only if the following
>checks pass:
>
> Section 5.2 says:
>
>The first step in these calculations is the generation of the base
>compound key, IMCK[n] from the session_key_seed, and any session keys
>derived from the successful execution of nth inner EAP methods.  The
>inner EAP method(s) may provide Inner Method Session Keys (IMSKs),
>IMSK1..IMSKn, corresponding to inner method 1 through n.
>
> It should say:
>
>The first step in these calculations is the generation of the base
>compound key, IMCK[j] from the session_key_seed, and any session keys
>derived from the successful execution of jth inner EAP authentication
>methods or basic password authentication. The inner EAP method(s) may
>provide Inner Method Session Keys (IMSKs), IMSK1..IMSKn, corresponding
>to inner method 1 through n.  When the jth exchange, such as a basic
>password exchange, does not derive key material then a special 0 IMSK
>is used as described below.
>
> Section 5.2 says:
>
>If the ith inner method does not generate an EMSK or MSK, then IMSKi
>is set to zero (e.g., MSKi = 32 octets of 0x00s).  If an inner method
>fails, then it is not included in this calculation.
>
> It Should say:
>
>If no inner EAP authentication method is run then no EMSK or MSK
>will be generated (e.g. when basic password authentication
>is used or when no inner method has been run and the crypto-binding TLV
>for the Result-TLV needs to be generated).  In this case, IMSK[j]
>is set to zero (i.e., MSK = 32 octets of 0x00s).  If an inner method
>fails, then it is not included in this calculation.
>
> Section 5.4 Says
>
> TEAP authentication assures the Master Session Key (MSK) and Extended
>  Master Session Key (EMSK) output from the EAP method are the result
>  of all authentication conversations by generating an Intermediate
>  Compound Key (IMCK).  The IMCK is mutually derived by the peer and
>  the server as described in Section 5.2 by combining the MSKs from inner
>  EAP methods with key material from TEAP Phase 1. The resulting
>  MSK and EMSK are generated as part of the IMCKn key hierarchy as
>  follows:
>
> It should say:
>
>TEAP authentication assures the Master Session Key (MSK) and Extended
>Master Session Key (EMSK) output from the EAP method are the result
>of all authentication conversations by generating an Intermediate
>Compound Key (IMCK).  The IMCK is mutually derived by the peer and
>the server as described in Section 5.2 by combining the IMSKs from inner
>EAP authentication and basic password methods with key material from
>TEAP Phase 1.  The resulting MSK and EMSK are generated as part of the
>IMCK key hierarchy as follows:
>
> Notes:
>
> This revision clarifies handling cases when the 0 MSK is used because no
> key material is derived.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed Resolution for Errata 5845

[Oleg Pekar]

>It should say:
>
>   EAP method messages are carried within EAP-Payload TLVs defined in
>   Section 4.2.10.  Upon method completion, the server MUST send an
>  Intermediate-Result TLV indicating the result.

Jouni explained in errata 5767 that not all EAP methods are EAP
authentication methods, to be exact. In the proposed fix for errata 5767
you have already suggested that for Section 3.3.1 text:

>Section 3.3.1
>
>It should say:

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



On Sun, Oct 25, 2020 at 9:14 PM Joseph Salowey  wrote:

> Errata 5845: https://www.rfc-editor.org/errata/eid5845
> Proposed Status: Verified
> Revision:
>
> Section 3.3.1 says:
>
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  If more than one method is going to be executed in
>the tunnel, then upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
>
> It should say:
>
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  Upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
>
> Notes:
>
> Description of whether Intermediate-Result TLV is supposed to be used in
> the case where only a single inner EAP authentication method is used.
> Section 3.3.1 says "more than one method is going to be executed in the
> tunnel, then upon method completion, the server MUST send an
> Intermediate-Result TLV indicating the result", Section 3.3.3 says "The
> Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform
> cryptographic binding after each successful EAP method in a sequence of one
> or more EAP methods", 4.2.13 says "It MUST be included with the
> Intermediate-Result TLV to perform cryptographic binding after each
> successful EAP method in a sequence of EAP methods", Annex C.3 shows an
> example exchange with a single inner EAP authentication method with use of
> Intermediate-Result TLV.
>
> It looks like the majority of the places discussion this topic implies
> that there is going to be an Intermediate-Result TLV after each inner EAP
> authentication method and the text in 3.3.1 is the only clear case of
> conflicting (or well, at least misleading if one were to claim it does not
> explicitly say MUST NOT for the one inner EAP authentication method case).
> As such, I'd conclude the Intermediate-Result TLV is indeed going to be
> exchanged after each EAP authentication method and the proposed text change
> to 3.3.1 covers that.
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed Resolution to TEAP Errata 5844

[Oleg Pekar]

Few comments:
1) It seems that the server MUST send Crypto-Binding TLV after a single EAP
authentication method, after each of EAP authentications methods in a
sequence, after no inner method but not after
Basic-Password-Authentication. Shouldn't we close this gap for the sake of
simplicity and structure? (Only Zero-MSK Crypto-Binding TLV is possible in
this case, the same as in no inner method case). Is
Basic-Password-Authentication treated as a case of no inner method?
Technically it is already correct but still may not be clear enough.

This also affects section "4.2.13. Crypto-Binding TLV":

The Crypto-Binding TLV MUST be exchanged and verified before the final
Result TLV exchange, regardless of whether there is an inner EAP
method authentication or not.

Shouldn't we mention "inner EAP method or basic password authentication"?

2) [Minor] It is written both "EAP methods **and** basic password
authentication" and "EAP methods **or**basic password authentication" in
different sections above. Shouldn't we use the same all the time?


On Sun, Oct 25, 2020 at 9:10 PM Joseph Salowey  wrote:

> Errata 5844: https://www.rfc-editor.org/errata/eid5844
> Status: Verified
> Revision:
>
> Section 3.3.2 says:
>
> Upon receiving the response, the server
>indicates the success or failure of the exchange using an
>Intermediate-Result TLV.
>
> It Should say:
>
> Upon receiving the response, the server MUST
>indicate the success or failure of the exchange using an
>Intermediate-Result TLV.
>
> Section 3.6 says:
>
> 3. The Intermediate-Result TLVs carry success or failure indications of
> the individual EAP methods in TEAP Phase 2.
>
> It Should say:
>
> 3. The Intermediate-Result TLVs carry success or failure indications of
> the individual EAP methods and basic password authentication in TEAP Phase
> 2.
>
> Section 4.2.11 says:
>
> The Intermediate-Result TLV provides support for acknowledged intermediate
> Success and Failure messages between multiple inner EAP methods within EAP.
>
> It Should say:
>
> The Intermediate-Result TLV provides support for acknowledged intermediate
> Success and Failure messages between multiple inner EAP methods or basic
> password authentication within EAP.
>
> Section C.1 says:
>
> <- Crypto-Binding TLV (Request),
> Result TLV (Success),
> (Optional PAC TLV)
>
>Crypto-Binding TLV(Response),
>Result TLV (Success),
>(PAC-Acknowledgement TLV) ->
>
> It should say:
>
> <- Intermediate-Result-TLV (Success),
> Crypto-Binding TLV (Request),
> Result TLV (Success),
> (Optional PAC TLV)
>
>Intermediate-Result-TLV (Success),
>Crypto-Binding TLV(Response),
>Result TLV (Success),
>(PAC-Acknowledgement TLV) ->
>
> Section C.2 Says:
> <- Result TLV (Failure)
>
> Result TLV (Failure) ->
>
> It Should Say:
>
> <- Intermediate-Result-TLV (Failure),
>  Result TLV (Failure)
>
> Intermediate-Result-TLV (Failure),
>Result TLV (Failure) ->
>
>
> Notes:
>
> Section 3.3.2 implies that Intermediate-Result TLV is used after each
> round of Basic-Password-Auth-Req/Resp TLVs. However, the example sequence
> in C.1 does not show this. The proposed change in this errata adds the
> Intermediate-Result TLV indication here. Similar change should be done in
> C.2 (i.e., add Intermediate-Result TLV (Failure) to the messages that
> include Result TLV) since the language in 3.3.2 describe the indication to
> be used for both success and failure cases.
>
> In addition to this change in C.1, it would be good to clarify the
> specification globally to avoid confusion about this case since almost all
> discussion regarding Intermediate-Result TLV currently is in the context of
> inner EAP authentication. 3.3.2 should have a MUST statement similar to
> 3.3.1. 3.6 should cover success or failure indications of basic password
> auth like it does EAP methods. 4.2.11 should note Intermediate-Result TLV
> is used with both inner EAP and basic password auth.
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Proposed resolution for TEAP errata 5775

[Oleg Pekar]

>
> It Should say:
>
> 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].
> If no inner EAP method has been run the S-IMCK and CMK are generated as
> above from S-IMCK[0].


Joe, for me it still doesn't sound as exact enough instructions. We should
explain how to generate S-IMCK and CMK for no inner method case with more
details.

The Crypto-Binding TLV MUST be exchanged and verified before the
>  final Result TLV exchange, regardless of whether there is an inner
>  EAP method authentication or not.

This still remains an open question whether we MUST send Crypto-Binding TLV
after Basic-Password-Authentication exchange or not. Is
Basic-Password-Authentication treated just as a case of no inner EAP
authentication method? It is also discussed in the errata 5844 thread.

Regarding introduction of Zero-MSK flag in Crypto-Binding TLV - do you
think it is unnecessary? So if one peer doesn't export a specific inner
method MSK and ESMK and uses Zero-MSK and another peer expects MSK or ESMK
- then the Crypto-Binding TLV exchange will fail naturally. Maybe it's
worth saying exactly that if the inner method exports MSK or EMSK then each
peer MUST use it and not Zero-MSK.

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

Re: [Emu] Proposed Resolution for TEAP errata 5768

[Oleg Pekar]

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

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

On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey  wrote:

> Errata 5768:  https://www.rfc-editor.org/errata/eid5768
> Proposed State: Verified
> Revision:
>
> Section 4.2.13. Says:
>
> Length
>
> 76
>
> It should say:
>
> Length
>
>  36 plus the length of the 2 MAC fields
>
> Section 4.2.13. Says:
>
>EMSK Compound MAC
>
>   The EMSK Compound MAC field is 20 octets.  This can be the Server
>   MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
>   MAC is described in Section 5.3.
>
>MSK Compound MAC
>
>   The MSK Compound MAC field is 20 octets.  This can be the Server
>   MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
>   MAC is described in Section 5.3.
>
> It Should Say:
>
>EMSK Compound MAC
>
>   The computation of the MAC is described in Section 5.3.  This can be
>   the Server MAC (B1_MAC) or the Client MAC (B2_MAC).
>
>MSK Compound MAC
>
>   The computation of the MAC is described in Section 5.3.  This can be
>   the Server MAC (B1_MAC) or the Client MAC (B2_MAC).
>
> Section 5.3 Says:
>
>  The Compound MAC computation is as follows:
>
>   CMK = CMK[j]
>   Compound-MAC = MAC( CMK, BUFFER )
>
>where j is the number of the last successfully executed inner EAP
>method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246], and
>BUFFER is created after concatenating these fields in the following
>order:
>
>1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
>   Compound MAC fields zeroed out.
>
>2  The EAP Type sent by the other party in the first TEAP message.
>
> It Should say:
>
>  The Compound MAC computation is as follows:
>
>   CMK = CMK[j]
>   Compound-MAC = MAC( CMK, BUFFER )
>
>where j is the number of the last successfully executed inner EAP
>method, MAC is HMAC [RFC2104] using the hash function negotiated in
>TLS [RFC5246].  The output length is the length of the output of the
> HMAC
>function.  The BUFFER is created after concatenating these fields in
>the following order:
>
>1  The entire Crypto-Binding TLV attribute with both the EMSK and MSK
>   Compound MAC fields zeroed out.
>
>2  The EAP Type sent by the other party in the first TEAP message. This
>is a single octet encoded as (0x37)
>
> Notes:
>
> This corrects the problem that the MAC output will vary depending upon the
> TLS hash function. It clarifies that HMAC is used with the hash function
> negotiated in TLS.   It also clarifies that the  EAP Type used in the TLS
> message is the TEAP EAP type encoded as a single byte.
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Oleg Pekar]

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



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

>implementation. Since our implementations interop, I assume we must have
the same implementation.



Jorge, thanks for pointing that out. Cisco also implements option number 1
from above. I referenced to EAP-FAST implementation by mistake, sorry.


So, not to harm at least two implementations, all we can do for errata
5127, 5128 - is just to change the wording to be more clear, removing
ambiguity.

On Thu, Oct 22, 2020 at 7:58 PM Jorge Vergara 
wrote:

> >[Joe] This is the one we have not discussed yet.  This derivation is also
> ambiguous.  THis section does not reference 5295.  It's not clear if the
> original intent was to include the length in the hash or not.  I think
> there are a few interpretations:
>
> >
>
> >1. TLS-PRF(S-IMCK[j], "Session Key Generating Function")  iterated to
> generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”)
>
> >2. TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64)  iterated
> to generate 64 bytes = P_hash(S-IMCK[j], "Session Key Generating Function”
> | 0x00 | 0x40)
>
> >3. (Follow 5295 parameters) TLS-PRF(S-IMCK[j], "Session Key Generating
> Function", "\0" | 64) = P_hash(S-IMCK[j], "Session Key Generating
> Function” | 0x00 | 0x00 | 0x40)
>
> >
>
> >I think 1 or 2 is what was probably originally intended, however it seems
> that 3 is what has been implemented.  Do we have agreement on this is what
> current implementations do?
>
>
>
> No, Microsoft implements number 1 of Joe’s presented options. That is -
> P_(S-IMCK[j], "Session Key Generating Function").
>
>
>
> This follows the same pattern as the errata we are discussion. I am very
> surprised to hear that Cisco’s implementation may be different. Oleg, could
> you please double check? I have just double checked our implementation.
> Since our implementations interop, I assume we must have the same
> implementation.
>
>
>
> Jorge Vergara
>
>
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Thursday, October 22, 2020 9:53 AM
> *To:* Oleg Pekar 
> *Cc:* EMU WG ; Jorge Vergara ;
> Jouni Malinen 
> *Subject:* Re: Proposed resolution for TEAP errata for 5128
>
>
>
>
>
>
>
> On Thu, Oct 22, 2020 at 9:29 AM Oleg Pekar 
> wrote:
>
> I agree that changing the KDF is harmful to existing implementations.
> However, if I understood correctly, Joe's suggestion for IMCK[j] also
> breaks the existing implementation. I still see that we can define a
> unified KDF by changing the API in the RFC but with the same harm to the
> existing implementation in IMCK[j] as in both proposals:
>
>
>
> TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
> label | 0x00 | optional data, length)
>
> Joe, thanks for pointing out that RFC 5295 doesn't specify that a 0x00 is
> used to represent no optional data, that was just my mistake.
>
>
>
> IMSK:
>
> Current Microsoft and Cisco implementation: P_hash(EMSK, "
> teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
>
> Joe's proposal: P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 |
> 0x40), the same, just the API correction
>
> Unified KDF proposal: TEAP-PRF(EMSK, "teapbind...@ietf.org",  data>, 64) = P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
>
> --- no implementation change
>
>
>
> IMCK[j]:
>
> Current Microsoft and Cisco implementation: P_hash(S-IMCK[j-1], "Inner
> Methods Compound Keys” | IMSK[j])
>
> Joe's proposal: P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" |
> IMSK[j] | 0x00 | 0x3C)
>
> Unified KDF proposal: TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
> IMSK[j], 60) = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j]
> | 0x00 | 0x3C)
>
> --- implementation change
>
>
>
> [Joe] That was my initial proposal, but based on Jorge's comment it is
> modified to:
>
>
> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])
> to generate a length of 60 bytes
>
> IMCK[j] = P_hash(S-IMCK[j-1], "Inner Methods Compound Keys” | IMSK[j])
>
>
>
>
>
> MSK:
>
> Current Microsoft and Cisco implementation: P_hash(S-IMCK[j], "Session Key
> Generating Function” | 0x00 | 0x00 | 0x40)
>
> Unified KDF proposal: TEAP-PRF(S-IMCK[

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

[Oleg Pekar]

I agree that changing the KDF is harmful to existing implementations.
However, if I understood correctly, Joe's suggestion for IMCK[j] also
breaks the existing implementation. I still see that we can define a
unified KDF by changing the API in the RFC but with the same harm to the
existing implementation in IMCK[j] as in both proposals:

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

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

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

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

Jorge, please correct me if I misinterpret the Microsoft implementation.

On Thu, Oct 22, 2020 at 6:55 PM Joseph Salowey  wrote:

>
>
> On Thu, Oct 22, 2020 at 6:59 AM Oleg Pekar 
> wrote:
>
>> Hi all,
>> Speaking about both errata 5127 and 5128, I think we need to align all
>> key derivation calls in TEAP RFC with the same rule/format to make the RFC
>> easier to understand. This can be achieved by introducing a unified single
>> PRF function that will be called from all the relevant RFC locations. For
>> me it sounds better than if we align just part of KDF calls with RFC 5295
>> (where the output length is included into seed). Also: in some KDF calls we
>> do have optional data and in some no. This could be also unified.
>>
>> [Joe] I don't think this was the original intent of the document.  The
> IMSK derivation referenced 5295 while the others just reference the TLS
> PRF.  I think to unify them would require a document update and I'm not
> sure what we would gain especially if we have implementations that do
> this.
>
>
>> So I would suggest introducing:
>> TEAP-PRF (secret, key label, optional data, length) = TLS-PRF(secret, key
>> label | 0x00 | optional data, length)
>> where a single byte 0x00 is used for no optional data, length is a
>> 2-octet unsigned integer in network byte order.
>>
>> [Joe] I don't think that 5295 specifies that a 0x00 is used to represent
> no optional data.  Did you see this in the spec? It may be ambiguous, but I
> think the intent is that optional data is just omitted if it is not
> provided.
>
>
>
>> Then:
>> IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 64) =
>> TLS-PRF(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x00 | 0x40)
>> IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j],
>> 60) = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys" | 0x00 | IMSK[j] |
>> 0x00 | 0x3C)
>> MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function”, 64) =
>> TLS-PRF(S-IMCK[j], "Session Key Generating Function" | 0x00 | 0x00 | 0x00 |
>> 0x40)
>> EMSK = TEAP-PRF(S-IMCK[j], ”Extended Session Key Generating Function”,
>> 64) = TLS-PRF(S-IMCK[j], "Extended Session Key Generating Function" | 0x00
>> | 0x00 | 0x00 | 0x40)
>>
>> This may change the existing implementation but will make it more clear -
>> need to create and call just one KDF function.
>>
>> We can remove 0x00 that comes after the key label - while it is required
>> by RFC 5295. But there the key label is also ASCII printable string. Joe,
>> do you remember what was the motivation to put 0x00 after the key label
>> parameter?
>>
>
> [Joe] the null after the key label is to provide a delimiter between the
> key label and optional data.  Since the optional data can be arbitrary
> content the null prevents two different lablels with specially crafted
> optional data from deriving the same key.
>

Re: [Emu] Resolution of TEAP Errata 5767

[Oleg Pekar]

The proposal is aligned with previously discussed. One small wording I
would change is:

Section 4.2.13 says:
It MUST be included with the Intermediate-Result TLV to perform
cryptographic binding after each successful EAP authentication method in a
sequence of >>>one or more<<< EAP methods, before proceeding with another
inner EAP method.

Just "sequence" sounds like it denotes the case where there should be more
than one EAP authentication method.

On Thu, Oct 22, 2020 at 3:39 AM Jorge Vergara 
wrote:

> I agree with all the proposed resolutions. For context, there was some
> prior discussion of this errata here:
> https://mailarchive.ietf.org/arch/msg/emu/K_XWBMevKNdxdWskK8RkBt1ZpSQ/
>
>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Wednesday, October 21, 2020 5:13 PM
> *To:* EMU WG ; Jouni Malinen ; Jorge Vergara <
> jover...@microsoft.com>; Oleg Pekar 
> *Subject:* Resolution of TEAP Errata 5767
>
>
>
> Errata 5767: https://www.rfc-editor.org/errata/eid5767
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5767=04%7C01%7Cjovergar%40microsoft.com%7C50b56afadcf34732d50708d8761f45d5%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389223977410444%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=24y%2BkrsBw1mdGuNMMgqmqiRz%2BqeFt9jVX4qUHtlUJwY%3D=0>
> Status: Verified
>
> Revision:
>
>
>
> Section 3.3.1 says:
>
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  If more than one method is going to be executed in
>the tunnel, then upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
>
> It should say:
>
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  Upon completion of each EAP authentication method in
>the tunnel, the server MUST send an Intermediate-Result TLV
>indicating the result.
>
>
>
> Section 3.3.3 says:
>
>
>
>   The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
>
>   to perform cryptographic binding after each successful EAP method in a
>
>   sequence of one or more EAP methods.
>
>
>
> It should say:
>
>
>
>   The Crypto-Binding TLV and Intermediate-Result TLV MUST be included
>
>   to perform cryptographic binding after each successful EAP
> authentication
>
>   method in a sequence of one or more EAP methods.
>
>
>
> Section 3.8.3 says:
>
>
>Upon successful completion of the EAP method in Phase 2, the peer and
>server exchange a Crypto-Binding TLV to bind the inner method with
>the outer tunnel and ensure that a man-in-the-middle attack has not
>been attempted.
>
>
>
> It should say:
>
>
>
>Upon successful completion of the EAP authentication method in Phase 2,
>
>the peer and server exchange a Crypto-Binding TLV to bind the inner
>
>method with the outer tunnel and ensure that a man-in-the-middle attack
>
>has not been attempted.
>
>
>
> Section 4.2.11 says:
>
>
>
>The Intermediate-Result TLV provides support for acknowledged
>
>intermediate Success and Failure messages between multiple
>
>inner EAP methods within EAP.
>
>
>
> It should say:
>
>
>
>   The Intermediate-Result TLV provides support for acknowledged
>
>   intermediate Success and Failure messages after each inner EAP
>
>   authentication method.
>
>
>
> Section 4.2.13 says:
>
>
>
>  It MUST be included with the Intermediate-Result TLV to perform
>
>  cryptographic binding after each successful EAP method in a
>
>  sequence of EAP methods, before proceeding with another inner
>
>  EAP method.
>
>
>
> It should say:
>
>
>
>  It MUST be included with the Intermediate-Result TLV to perform
>
>  cryptographic binding after each successful EAP authentication
>
>  method in a sequence of EAP methods, before proceeding with
>
>  another inner EAP method.
>
>
>
> Notes:
>
> TEAP description is somewhat vague in discussion about "EAP methods" vs.
> "EAP authentication methods" as it comes to the EAP methods performed in
> Phase 2 within the TLS tunnel. RFC 3748 defines Identity request/response
> as an EAP method. However, this method is not an "authentication method"
> which is a special case of an method where the Type is 4 or greater.
>
> RFC 7170 uses correct terminology in the first paragraph of Section 3.3.1
> when talking about multiple authentication methods not being allowed by RFC
> 3748 i

Re: [Emu] Proposed resolution for TEAP errata 5765

[Oleg Pekar]

The Authority-ID TLV is used by the client to identify the TEAP server it
is talking to. If the same client talks to more than one TEAP server - it
can keep PACs or cached data from all of them identified by
the Authority-ID. If we make it optional in TEAP start message but keep
mandatory in PAC-Info part of the PAC - TEAP servers can stop sending it
during TEAP start and then clients will need to fetch it from PAC, if there
is a PAC in the conversation. But if there's no PAC - then no way to
identify TEAP server.

Maybe we should keep it mandatory?



On Thu, Oct 22, 2020 at 12:47 AM Joseph Salowey  wrote:

> Errata 5765: https://www.rfc-editor.org/errata/eid5765
> Proposed Status: Verified
> Revision: (unmodified from original posting)
>
> Section 4.2.2 says:
>
>M
>
>   Mandatory, set to one (1)
>
> It should say:
>
>M
>
>   0 (Optional)
>
> Notes:
>
> Authority-ID TLV is used only as an Outer TLV (in TEAP/Start) and Section
> 4.3.1 mandates all Outer TLVs to be marked as optional ("Outer TLVs MUST be
> marked as optional"). As such, Section 4.2.2 is incorrect in claiming the
> Authority-ID TLV to use M=1.
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Oleg Pekar]

 PRF as:
>>
>> PRF(secret, label, seed) = P_(secret, label + seed)
>>
>>
>>
>> So the calculation implementations are currently performing with an empty
>> seed ends up as:
>>
>> P_(secret, label)
>>
>>
>>
>> Note that in RFC 5295, the length *is* explicitly mentioned as being
>> concatenated with the label
>>
>> USRK = KDF(EMSK, key label | "\0" | optional data | length)
>>
>>
>>
>> RFC 5295 is mentioned earlier in the TEAP RFC, in the section covered by
>> errata 5127. *However* it is not mentioned in this portion of the RFC.
>> Since this calculation is not on an EMSK, I do not believe RFC 2395 applies
>> and this is likely why implementations went with the seedless
>> P_(secret, label) calculation instead.
>>
>>
>>
>> Is there concern about updating the RFC in a way that breaks existing
>> implementations?
>>
>>
>>
>> [Joe] Yes this is a concern and I think your interpretation of the
>> current document is also valid.  There may be more than one
>> implementation.  So what you implemented was:
>>
>>
>>
>> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) =
>> P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>>
>>
>>
>> taken out to 60 bytes.  The problem is that the TEAP spec references a
>> TLS-PRF in a way that it does not define.  I think the errata points out
>> the definition that should be used:
>>
>>
>>
>> PRF(secret, label, seed) = P_(secret, label + seed)
>>
>>
>>
>> That does not include length so the 60 in the original definition is
>> ambiguous.   The new text would then be something like:
>>
>>
>>
>> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])
>> to generate a length of 60 bytes
>>
>>
>>
>> Does the revision in 5167 match you implementation ( I don't think
>> Jouni's comment changes the underly calculation, just its representation)?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Jorge Vergara
>>
>>
>>
>> *From:* Joseph Salowey 
>> *Sent:* Wednesday, October 21, 2020 2:34 PM
>> *To:* EMU WG ; Jouni Malinen ; Jorge Vergara <
>> jover...@microsoft.com>; Oleg Pekar (olpekar) 
>> *Subject:* Proposed resolution for TEAP errata for 5128
>>
>>
>>
>> Errata 5128: https://www.rfc-editor.org/errata/eid5128
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5128=04%7C01%7Cjovergar%40microsoft.com%7C38c27add2cb64a06310108d8761a22d3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637389201909062787%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=XudZt9FPh4jOBFQj01SQysnhX4p7G%2BflW2Pn2yIaJRM%3D=0>
>>
>> Proposed State: Verified
>>
>> Revision:
>>
>>
>>
>> Section 5.2. says
>>
>>
>> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
>> IMSK[j], 60)
>>
>> It should say:
>>
>> IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j] |
>> 60)
>>
>> Note:
>>
>> According to
>>
>> RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
>>
>> 5. HMAC and the Pseudorandom Function
>>
>> "TLS's PRF is created by applying P_hash to the secret as:
>>
>> PRF(secret, label, seed) = P_(secret, label + seed)"
>>
>>
>>
>> In terms of P_ this would look like the following with the length
>> represented as a 2 byte value in network byte order:
>>
>>
>>
>> IMCK[j] = P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j]
>> | 0x00 | 0x3C)
>>
>>
>>
>>
>>
>>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] Fwd: Appropriate AAA/EAP response to a peer's NAK when there are no overlapping methods

[Oleg Pekar]

Hi Terry

>In practise:
>
>* FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure.
>* hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message /
EAP-Failure.
>* A commercial RADIUS server implementation sends nothing.

Cisco Identity Services Engine RADIUS also returns  RADIUS
Access-Reject / EAP-Message / EAP-Failure in this case.

Not sure that if AAA server will send a list of his allowed protocols
in reply to NAK - the EAP client would be able to use it. Usually
credentials are configured per protocol and not always
interchangeable. So if the client wants EAP-GTC as an inner method in
PEAP and claims this in an inner EAP NAK message and the server will
reply that it has EAP-MSCHAPv2 and EAP-TLS inner methods - client can
be unable to leverage this info.

-Oleg


On Thu, Aug 20, 2020 at 3:39 AM Terry Burton  wrote:
>
> Hi,
>
> I'm unable to find the authoritative source that state exactly how the
> following conversation continues (TL;DR; the peer NAKs the original
> method and the AAA doesn't support any of the peer's proposals):
>
> 1. NAS --> Peer : EAP-Request / Identity
> 2. Peer --> NAS : EAP-Response / Identity ( ID )
> 3. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response /
> Identity ( ID )
> 4. AAA --> NAS:  RADIUS Access-Challenge / EAP-Message / EAP-Request /
> Method Foo
> 5. NAS --> Peer: EAP-Request / Method Foo
> 6. Peer --> NAK: EAP-Response / EAP-Type=NAK (Methods [Bar])
> 7. NAS --> AAA: RADIUS Access-Request / EAP-Message / EAP-Response /
> NAK ( Methods [ Bar ] )
> (* Let's assume that the AAA does not support Method Bar so we have
> derived that there are no overlapping methods.)
> 8. AAA: Now what?
>
> I've reviewed RFC 3748 (EAP) and RFC 3579 (RADIUS Support For EAP) and
> neither seems to be explicit about what the AAA should do in response
> to a NAK in the event of no overlapping methods.
>
> In practise:
>
> * FreeRADIUS sends RADIUS Access-Reject / EAP-Message / EAP-Failure.
> * hostapd's RADIUS server sends RADIUS Access-Reject / EAP-Message /
> EAP-Failure.
> * A commercial RADIUS server implementation sends nothing.
>
> It seems right to indicate an EAP-Failure to the peer in the case of
> no overlapping methods (as well as to terminate the NAS's outstanding
> RADIUS Access-Request with an Access-Reject), as is the case for a
> number of other failure conditions, e.g. authentication failure
> *within* an EAP method (Appendix A by way of example), invalid packets
> leading to a fatal error within an EAP method (section 2.2).
>
> RFC 3748 section 4.2 on Success and Failure introduces these messages
> within the context of finalising an ongoing EAP method:
>
>The Success packet is sent by the authenticator to the peer after
>completion of an EAP authentication method (Type 4 or greater) to
>indicate that the peer has authenticated successfully to the
>authenticator.  The authenticator MUST transmit an EAP packet with
>the Code field set to 3 (Success).  If the authenticator cannot
>authenticate the peer (unacceptable Responses to one or more
>Requests), then after unsuccessful completion of the EAP method in
>progress, the implementation MUST transmit an EAP packet with the
>Code field set to 4 (Failure).
>
> Perhaps one can argue that a NAK is an unacceptable response to an
> ongoing method and therefore the method is unsuccessfully completed so
> a Failure should be generated? That's not entirely clear, if that is
> the case.
>
> RFC 3748 section 5.3.1 throws in some more doubt, having the following
> text that deals explicitly with the peer sending a NAK containing "no
> desired alternative" method:
>
>   Type zero (0) is used to indicate that the sender has
>   no viable alternatives, and therefore the authenticator SHOULD NOT
>   send another Request after receiving a Nak Response containing a
>   zero value.
>
> That's specific to one case for which a strict reading would indicate
> that the EAP server should remain quiet and consider the EAP
> conversation to be complete. It's tempting to think that the same
> response (i,e. no response!) should apply more broadly as none of the
> AAA implementations I've tested actually differentiate between a NAK
> with no desired alternative method vs a NAK with an incompatible list
> of alternative methods. (A subtle difference might be relevant: In the
> case of NAK / method = [] the peer knows that the EAP conversion can
> go no further, whereas in the case that it sends a list of methods
> that the AAA happens to not support it does not know this unless it is
> subsequently told.)
>
> If I've not missed something then this looks an omission (or lack of
> clarity) and the intended AAA response to no overlapping methods (and
> indeed "no desired alternative") should be decided and codified.
>
>
> Thanks,
>
> Terry
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] TEAP errata 5770

[Oleg Pekar]

Joe, nice proposal. Few questions:
1. We have a case of Basic Password Authentication instead of inner method
thus we should also use Crypto-Binding TLV based on Zero-MSK after it
2. As Eliot mentioned, we have a case of no inner method at all - we should
use Crypto-Binding TLV based on Zero-MSK after it
3. Since it is not clear whether MSK or Zero-MSK is used - we should
introduce a new flag value for Crypto-Binding TLV: "0" - Zero-MSK
based Compound MAC is used in place of MSK Compound MAC field.
4. We have a TLS-PRF usage ambiguity here (Errata 5127 and 5128):
TLS 1.2 RFC 5246 in section "5.  HMAC and the Pseudorandom Function"
defines PRF(secret, label, seed) = P_(secret, label + seed)

TEAP RFC uses TLS-PRF several times:
* IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" | "\0" |
64)
  The call refers to RFC 5295 that defines USRK = KDF(EMSK, key label |
"\0" | optional data | length) but that RFC says "USRKs MUST be at least 64
octets in length" and IMSK is 32 octets
* IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
* MSK  = TLS-PRF(S-IMCK[j], "Session Key Generating Function", 64) and
similar for EMSK

We can see that all three times the parameters are different and don't
exactly fit the definition and this creates some confusion.

In the other earlier thread you mentioned that truncation of 64-octets USRK
to 32 octet is valid. In yet another thread you mentioned that we should
define TLS-PRF function with the output size as a parameter and we should
just concatenate for all TLS-PRF calls all the parameters starting from the
second. Is that understanding correct? This should be also helpful when
mapping to TLS1.3 HKDF extract and expand functions.

Thanks
Oleg

On Thu, Oct 10, 2019 at 11:00 AM Eliot Lear  wrote:

> Just one comment:
>
> TEAP does not *require* an inner method, and indeed for IoT it is not
> necessary.
>
> Eliot
>
> On 9 Oct 2019, at 07:46, Joseph Salowey  wrote:
>
> Based on Jouni's analysis the derivation of the S-IMCKs is not well
> specified.  To me it looks like the solution to handle an arbitrary number
> of methods that may or may not make an EMSK available would be fairly
> complex.
>
> I think the most straight forward solution is to either always assume that
> for an EMSK generating method the EMSK is either always available or always
> unavailable.  It seems that it is safer to always assume that the EMSK is
> unavailable and will therefore never be used.  I think this has the
> following implications:
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> -  The EMSK compound MAC is not used
> -  Implementations must have a policy that accepts MSK MACs
>
> It would appear that from a cryptographic analysis point of view the MSK
> and EMSK are equivalent since these keys will only be used in these
> TEAP calculations and not for other purposes..  There are documented
> drawbacks of using the MSK described in RFC7029 (
> https://tools.ietf.org/html/rfc7029#page-12).   If the properties of the
> EMSK binding are needed in the use cases currently under consideration then
> I think we could redefine the way the EMSK MAC to be computed from the EMSK
> of the inner method changing the above to
>
> -  The S-IMCK is always generated from the inner method MSK or the
> all-zero value if the method does not generate key material.
> - Compute EMSK MAC from the inner-method EMSK instead of the S-IMCK
>  Compound-MAC = MAC( EMSK[J], BUFFER )
> -  Implementations have a policy that prevents EMSK downgrade to MSK
>
> Hopefully there is a more elegant solution. Any ideas?
>
> 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 mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] TEAP - RFC 7170 - Errata

[Oleg Pekar]

Jorge, thanks for correction: Intermediate-Result TLV must be sent at the
end of Basic Password Authentication. I think we also need to list all four
inner method cases that I mention in above explicitly, for example in
"3.3.3.  Protected Termination and Acknowledged Result Indication" section.

Since every Intermediate-Result TLV indicating success must be accompanied
with Crypto-Binding TLV (section "4.2.11.  Intermediate-Result TLV") -
please refer to the Zero-MSK addition discussed in the other thread with
subject "[Emu] draft-dekok-emu-tls-eap-types discussion". Zero-MSK based
Crypto-Binding TLV should be used when we have no inner method or after
Basic Password Authentication exchange. Per Joe's suggestion and Jorge's
confirmation we should not support downgrading from MSK to Zero MSK if the
inner method supports MSK.

Thanks
Oleg

On Fri, May 22, 2020 at 11:56 PM Jorge Vergara 
wrote:

> I am going to consider these 3 errata separately as I think it is clearest:
>
>
>
> Errata ID 5767:
>
>
>
> I believe Jouni’s differentiation of an “EAP authentication method” vs
> “EAP method” is that an “EAP authentication method” has a type >= 4. Jouni
> mentions this in his errata filing and it is also mentioned in RFC 3748
> Section 2.1 <https://tools.ietf.org/html/rfc3748#section-2.1> (possibly
> other places also). Jouni, I apologize if I have misinterpreted – please
> correct me if so.
>
>
>
> So, an EAP-Identity (type 1) request is an “EAP method”, but there is
> obviously no intermediate result TLV or crypto binding TLV exchanged after
> an EAP-Identity exchange.
>
>
>
> Jouni has done an excellent job in this errata of identifying where the
> terminology should be updated, and I agree with Jouni’s changes. I think
> the intent of the RFC in the four instances Jouni identified was fairly
> clear.
>
>
>
> Errata ID 5844:
>
>
>
> Oleg, your final proposal seems to indicate that an Intermediate-Result
> TLV should NOT be sent after Basic Password Authentication – I’m not sure I
> follow this. Section 3.3.2 outlines that an Intermediate-Result TLV SHOULD
> be sent after Basic Password Authentication.
>
>
>
> So I find this errata valid and agree with Jouni that section C.1 and C.2
> should be updated to include the Intermediate-Result TLV in the diagrams.
>
>
>
> I agree with the rest of the proposals Jouni has made as well that this
> should be made clearer throughout the document. Most of the time where the
> Intermediate-Result TLV is mentioned, only EAP is discussed and the Basic
> Password Authentication is forgotten. I don’t believe Jouni’s proposals
> change any timings – just clarify the language.
>
>
>
> Errata ID 5845:
>
>
>
> I find the errata valid and agree with Jouni. The direction in the rest of
> the document seems to be that an Intermediate-Result TLV is always
> exchanged (after both EAP authentication methods and Basic Password
> Authentications) and the text in 3.3.1 is confusing.
>
>
>
> *
>
>
>
> In summary – I find all of these errata valid and appreciate Jouni’s
> suggestions for clarifications. I find them all to be language
> clarifications and don’t believe any exchanges need to be altered..
>
>
>
> Oleg, your final proposal seems to be removing the exchange of
> Intermediate-Result TLVs in the Basic Password Authentication case – I am
> not sure I follow this but if you believe this is needed for the resolution
> of this errata I would like to better understand why.
>
>
>
> Thanks,
>
> Jorge
>
>
>
> *From:* Emu  *On Behalf Of * Oleg Pekar
> *Sent:* Sunday, May 3, 2020 10:02 AM
> *To:* Jouni Malinen ; EMU WG 
> *Subject:* [Emu] TEAP - RFC 7170 - Errata
>
>
>
> Hi Jouni,
>
> You filed Errata ID: 5767, 5844, 5845 regarding sending of
> Intermediate-Result TLV. Can we clarify a general scheme of
> sending Intermediate-Result TLV and Crypto-Binding TLV in all cases? It is
> not exactly clear what is "EAP authentication method" and what is its
> different from "EAP method" (you referred to appendix C.3 as an example of
> "EAP Method" but it is not clear why it is not an "EAP authentication
> method" - could you please clarify).
>
>
>
> Here's the list of cases with the current RFC instructions (please add if
> something is missing):
>
>
>
> 1. A single inner EAP method is executed inside the tunnel.
>
> *** RFC says ***
>
> Section 4.2.11 "An Intermediate-Result TLV indicating success MUST be
> accompanied by a Crypto-Binding TLV". Section 3.3 "Phase 2 MUST always end
> with a Crypto-Binding TLV exchange"
>
>
>
> 2. Multi

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

[Oleg Pekar]

Jorge, Joe, thank you for your comments. So the updated proposal should be:

1) In Section "4.2.13.  Crypto-Binding TLV" make "EMSK Compound MAC" and
"MSK Compound MAC" fields variable length depending on the number of output
bits of the MAC function negotiated by TLS protocol. A field "Compound MAC
Length" of size 1 octet is added after the "Nonce" field to represent the
length of each of "EMSK Compound MAC" and "MSK Compound MAC" fields. The
minimum length for each Compound MAC field is 20 octets (to honor the
original RFC fixed size and to allow usage of SHA-1 - that is still used in
TLS 1.2 - to provide MAC without padding). The length should never be less
than 20 octets since there are no ciphers supported by TLS 1.2 with a
digest of less than 160 bits output size. Therefore if "Compound MAC
Length" field value is less than 20 then the Crypto-binding TLV should be
considered of erroneous format and handled as described in section 3.6.
Error Handling. The value of the length field of the whole Crypto-Binding
TLV should be calculated accordingly (currently fix 76 octets).

The updated structure of Crypto-Binding TLV:

The Crypto-Binding TLV is defined as follows:

0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |M|R| TLV Type  |Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Reserved   |Version|  Received Ver.| Flags|Sub-Type|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |
   ~ Nonce ~
   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |  Comp MAC Len |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |   |
   ~   EMSK Compound MAC   ~
   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   |
   ~MSK Compound MAC   ~
   |   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


If we would not bump the TEAP protocol version - we still can change
the Crypto-Binding TLV version to 2.


2) [This was accepted and stays unchanged]

3) In Section "5.3.  Computing the Compound MAC" when specifying the
list of fields to be placed in the BUFFER" should say "...2  A single
octet contains TEAP EAP method type 0x37". However to let this byte
play a role in protection of Crypto-Binding TLV I would suggest to
place in it the inner EAP method type related to the calculation or
0x0 if no inner EAP method was executed. What are your opinions on
this?

Thanks
Oleg


On Tue, May 26, 2020 at 12:29 PM Jorge Vergara 
wrote:

>
>
> *From:* Joseph Salowey 
> *Sent:* Monday, May 25, 2020 9:27 PM
> *To:* Jorge Vergara 
> *Cc:* Oleg Pekar ; Jouni Malinen ;
> EMU WG 
> *Subject:* Re: [Emu] TEAP - RFC 7170 - Errata ID 5768
>
>
>
>
>
>
>
> On Fri, May 22, 2020 at 1:18 PM Jorge Vergara  40microsoft@dmarc.ietf.org> wrote:
>
> My review of this errata and the current responses from Oleg:
>
>
>
>1. I agree with this proposed resolution. I do think this is an
>important omission that needs to be clarified in the RFC. Otherwise it is
>somewhat guesswork that truncation is the right action. I think the current
>wording leans toward truncation, but I definitely asked this question
>myself while implementing.
>
> [Joe]  Why not just change the TLV to be variable length?  It seems if we
> hardcode the length to 100 we risk having the same problem in the future?
>
>
>
> [Jorge] I have to admit that in my original response my brain skipped over
> the TLV length adjustment and focused only on the truncation. If the TLV
> length is going to be adjusted at all, I am in favor of making the TLV
> variable length. A minimum length could also be added (32 bits seems to be
> the current recommendation). However, I do believe this is a breaking
> change to any TEAP implementation – would the TEAP version need to be
> bumped?
>
>
>1.
>2. This bleeds into Alan’s TLS 1.3 document somewhat, but I agree with
>Jouni that this will need to change when the rest of the document is
>eventually updated to TLS 1.3.. There 

Re: [Emu] TEAP Request-Action TLV

[Oleg Pekar]

Eliot gave me some hint offline and here's what we can do in TEAP with
regards of certificate provisioning/enrollment/renewal.

In the current TEAP RFC, when the peer wants to get list of Trusted Roots
it sends Trusted-Server-Root TLV with credential type field - a constant
value 1 for PKCS#7 and with no other content. The server replies
with Trusted-Server-Root TLV and puts PKCS#7 inside it. So there's a kind
of request-response with the same TLV.

However for certificate request the peer should send PKCS#10 TLV and the
server should response with PKCS#7 TLV. It shows some inconsistency on one
hand and gives no possibility for the server to control certificate renewal..

Suggest closing that gap by introducing a new "Peer-Certificate TLV" with
exactly the same format as Trusted-Server-Root TLV.

   - When the peer wants to request a certificate it
   sends "Peer-Certificate TLV" with credential type field equal to 1
   for PKCS#7 and optional PKCS#10 TLV as a content
   - If no PKCS#10 TLV attached then the server can just renew the existing
   certificate if it has such capabilities and required data (or can say that
   the peer wants a certificate based on its current certificate and the
   current server policies).
   - If PKCS#10 TLV is attached then the server generates peer certificate
   according to the data in the request
   - If the server wants to generate peer certificate it may reply with
   "Peer-Certificate TLV" with credential type field equal to 1 for PKCS#7
   and PKCS#10 TLV as a content.
   - If the server wants the peer to send certificate request with all the
   data - it sends "Peer-Certificate TLV" with credential type field equal to
   1 for PKCS#7 and no content
   - We don't need to use Request-Action TLV in the whole flow

Would that work?

Regards
Oleg

On Wed, May 6, 2020 at 4:57 PM Oleg Pekar  wrote:

> Hi Eliot,
> Few thoughts:
>
>- If the current client's certificate was requested via TEAP by
>PKCS#10 TLV - then maybe it makes sense for the client to send
>Request-Action TLV + PKCS#10 TLV again with the same certificate parameters
>- If the current client's certificate was not requested via TEAP -
>then there's no evidence that the certificate renewal will be addressed
>(maybe TEAP is not connected to any CA)
>- If the current client's certificate was obtained from the external
>CA (e.g. via SCEP or EST) - then there's no evidence that the certificate
>renewal will be addressed
>- If the current client's certificate was preinstalled - then the
>client may not have a clue what does it want and will be unable to
>fill PKCS#10 request. On the other hand, the CA that TEAP server is
>connected to could be unable to generate certificate with exactly the same
>properties and the current client certificate. Simple example: the current
>certificate is ECDSA and the CA can generate RSA only. Hard example: the
>current client certificate contains vendor specific extensions like Policy
>or Template Name. So it will be hard to put those extensions to the
>generated certificate
>
> Regards
> Oleg
>
> On Thu, Apr 30, 2020 at 4:19 PM Eliot Lear  40cisco@dmarc.ietf.org> wrote:
>
>> All:
>>
>> Here is a circumstance one could easily imagine, and in fact we attempted
>> to address in draft-lear-eap-teap-brski:
>>
>> Client requires a new certificate for some reason or another.  Perhaps
>> its is about to expire, or perhaps the signer has been compromised, or what
>> have you.
>>
>>
>> We were thinking that we could use the Request-Action Frame for this
>> purpose with a type of PKCS#10.  But that now seems wrong, as the language
>> in the draft states that one appends a Request-Action frame with a full
>> TLV, and not just a *type, * and further that the other end process the
>> TLV.  In looking at Jouni’s code, he is doing precisely that with the PAC
>> TLV.
>>
>> And so it seems we have three choices:
>>
>>
>>- Create a new TLV that has a length of *two* that can be used in a
>>REQUEST_ACTION frame.
>>- Create a new TLV that is what we thought we meant: here is a list
>>of two(ish)-byte types whose TLVs I want you to send to me.
>>- Hard code the ordering of requests so everyone knows what to expect..
>>
>>
>> Each of these has its own problems.
>>
>> The first requires that we create a new EAP TYPE for TLV one end needs
>> the other to send, but it’s pretty easy to process. The second requires
>> extra processing but requires less standardization.  The last seems to go
>> against the EAP model and reduces deployment flexibility.
>>
>> Thoughts?
>>
>> Eliot
>> ___
>> 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] TEAP Request-Action TLV

[Oleg Pekar]

Hi Eliot,
Few thoughts:

   - If the current client's certificate was requested via TEAP by PKCS#10
   TLV - then maybe it makes sense for the client to send Request-Action
   TLV + PKCS#10 TLV again with the same certificate parameters
   - If the current client's certificate was not requested via TEAP - then
   there's no evidence that the certificate renewal will be addressed (maybe
   TEAP is not connected to any CA)
   - If the current client's certificate was obtained from the external CA
   (e.g. via SCEP or EST) - then there's no evidence that the certificate
   renewal will be addressed
   - If the current client's certificate was preinstalled - then the client
   may not have a clue what does it want and will be unable to fill PKCS#10
   request. On the other hand, the CA that TEAP server is connected to could
   be unable to generate certificate with exactly the same properties and the
   current client certificate. Simple example: the current certificate is
   ECDSA and the CA can generate RSA only. Hard example: the current client
   certificate contains vendor specific extensions like Policy or Template
   Name. So it will be hard to put those extensions to the generated
   certificate

Regards
Oleg

On Thu, Apr 30, 2020 at 4:19 PM Eliot Lear 
wrote:

> All:
>
> Here is a circumstance one could easily imagine, and in fact we attempted
> to address in draft-lear-eap-teap-brski:
>
> Client requires a new certificate for some reason or another.  Perhaps its
> is about to expire, or perhaps the signer has been compromised, or what
> have you.
>
>
> We were thinking that we could use the Request-Action Frame for this
> purpose with a type of PKCS#10.  But that now seems wrong, as the language
> in the draft states that one appends a Request-Action frame with a full
> TLV, and not just a *type, * and further that the other end process the
> TLV.  In looking at Jouni’s code, he is doing precisely that with the PAC
> TLV.
>
> And so it seems we have three choices:
>
>
>- Create a new TLV that has a length of *two* that can be used in a
>REQUEST_ACTION frame.
>- Create a new TLV that is what we thought we meant: here is a list of
>two(ish)-byte types whose TLVs I want you to send to me.
>- Hard code the ordering of requests so everyone knows what to expect.
>
>
> Each of these has its own problems.
>
> The first requires that we create a new EAP TYPE for TLV one end needs the
> other to send, but it’s pretty easy to process. The second requires extra
> processing but requires less standardization.  The last seems to go against
> the EAP model and reduces deployment flexibility.
>
> Thoughts?
>
> Eliot
> ___
> 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] TEAP - RFC 7170 - Errata ID 5768

[Oleg Pekar]

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

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



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

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

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

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

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

[Emu] TEAP - RFC 7170 - Errata

[Oleg Pekar]

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

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

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

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

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

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

**
Jouni, you provided multiple suggestions for fixing this. Incorporating you
suggestions, the bottomline could be:
* Send Intermediate-Result TLV after each inner EAP method but not after Basic
Password Authentication TLV exchange
* Send Crypto-Binding TLV based on inner method MSK/EMSK after each inner
EAP method that exports MSK/EMSK and send Crypto-Binding TLV based on
Zero-MSK in case of no inner method was executed

And then it should be declared explicitly and all the places where these
TLV are mentioned can be fixed accordingly.

Please share your opinion.
~ Oleg
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Oleg Pekar]

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

Jorge, please note that the same problem exists in PEAP Crypto-Binding TLV
as specified in its documentation
<https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-peap/ebb2b12b-cd53-4f3a-afed-36588566c7c2>
- when one side has an inner method that provided MSK and another side has
this inner method that didn't provide MSK.

There is also a case where no inner method is executed. For example, when
client certificate was received during TEAP outer tunnel establishment. In
this case we also need to use zero-MSK. For such case both values of the
flag work - "0 for zero-MSK" and "2 for MSK". This creates unnecessary
ambiguity and thus would be better to request using flag's value "0" for
zero MSK in such case (today we use value "2" and it doesn't create
ambiguity). However there's a question here: in case of TEAP certificate
based authentication that is typically done by running inner method
EAP-TLS, should we allow in sending client certificate during TEAP tunnel
establishment or inside the tunnel and this way skipping EAP-TLS inner
method? On one hand it makes authentication shorter. On the other hand it
causes switching from MSK/EMSK exported by the inner method EAP-TLS to
zero-MSK.

If we do allow skipping any inner method then we need explicitly say that
zero-MSK should be used in such case.

I've started rebuilding section "5.2
<https://tools.ietf.org/html/rfc7170#section-5.2>. Intermediate Compound
Key Derivations" of the RFC according to the proposal on this thread and
will post it here shortly.

~ Oleg




On Mon, Apr 20, 2020 at 3:57 AM Jorge Vergara 
wrote:

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

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

[Oleg Pekar]

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



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


Good! Then we can leave the protocol unchanged but re-write the
relevant sections 5.2, 5.3 and maybe 5.4 to define clearly the algorithm.
Right, it would be great to hear from Jouni whether this will satisfy the
Errata 5770.


Oleg

On Wed, Apr 15, 2020 at 9:31 PM Jorge Vergara 
wrote:

> > For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning
> to find the common method of TLS 1.3 support for all three or you just want
> to release TLS 1.3 support at the same time for all three?
>
>
>
> It’s not our intention to try to force the same solution for every method.
> We plan to update our implementations at the same time, since we anticipate
> the updates will be similar (though not necessarily identical).
>
>
>
> >Could this method work? Should we make it more clearly specified? Or
> should we change the protocol to arrive explicitly to the understanding
> which type (MSK/EMSK) of IMSK[j] to use?
>
>
>
> You clarification is what I understood the intention of the RFC to be as
> well, and makes sense to me. I don’t think there needs to be a protocol
> update if this clarification sounds good to all parties. I would welcome
> Jouni’s thoughts as the filer of the errata.
>
>
>
> Jorge
>
>
>
> *From:* Emu  *On Behalf Of * Oleg Pekar
> *Sent:* Wednesday, April 15, 2020 9:25 AM
> *To:* Jorge Vergara 
> *Cc:* EMU WG 
> *Subject:* Re: [Emu] draft-dekok-emu-tls-eap-types discussion
>
>
>
> Hi Jorge,
>
> For Microsoft supported protocol suite PEAP/TTLS/TEAP - are you planning
> to find the common method of TLS 1.3 support for all three or you just want
> to release TLS 1.3 support at the same time for all three?
>
>
>
> For TEAP errata 5770:
>
> Technically TEAP RFC suggests the implicit method of taking the correct
> IMSK[j] and all the subsequent keys after each inner method via negotiation
> taking place in Crypto-Binding TLV exchange.
>
>
>
> Let's say we are on the inner method number j that supports both MSK and
> EMSK and we are server which implementation generates both MSK and EMSK for
> this inner method. We generated keys according to the rules below - two
> sets, for IMSK[j] derived from inner method EMSK and for IMSK[j] equal to
> inner method MSK. Because we don't know whether client implementation
> supports both MSK and EMSK.
>
>
>
> S-IMCK[0] = session_key_seed
>
>   For j = 1 to n-1 do
>
>IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys",
>
> IMSK[j], 60)
>
>S-IMCK[j] = first 40 octets of IMCK[j]
>
>CMK[j] = last 20 octets of IMCK[j]
>
>
>
> So we have two CMK[j] and we create Crypto-Binding TLV with both Compound
> MAC for MSK and EMSK. The client sends Crypto-Binding TLV in response and
> we can understand from it whether it supports EMSK for this inner method or
> not. And here we can decide which version of IMCK[j] to take for this inner
> method - derived from EMSK or MSK. This is just not explicitly specified in
> the RFC.
>
>
>
> Could this method work? Should we make it more clearly specified? Or
> should we change the protocol to arrive explicitly to the understanding
> which type (MSK/EMSK) of IMSK[j] to use?
>
>
>
> Thanks
>
> Oleg
>
>
>
>
>
> On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara  40microsoft@dmarc.ietf.org> wrote:
>
> >Microsoft has already said that they won't rev their EAP-TLS
> implementation until they can also rev PEAP.
>
> PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the
> same time and will postpone TLS 1.3 support until such a time as we are
> able to make the updates together.
>
> >* should the document drop references to TEAP?
> > Given Jouni Malinen's comments on implementing TEAP, it may be worth
> simply noting that we're waiting for a TEAP update document
>
> I've reviewed the current errata, and acknowledge their validity, but am
> not sure that any of them would impact this document.
>
> The most relevant errata to this document seems to be
> https://www.rfc-editor.org/errata/eid5770
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5770=02%7C01%7Cjovergar%40mi

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

[Oleg Pekar]

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

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

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

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


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

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

Thanks
Oleg


On Wed, Apr 8, 2020 at 12:09 AM Jorge Vergara  wrote:

> >Microsoft has already said that they won't rev their EAP-TLS
> implementation until they can also rev PEAP.
>
> PEAP/TTLS/TEAP - we (Microsoft) believe all should be addressed at the
> same time and will postpone TLS 1.3 support until such a time as we are
> able to make the updates together.
>
> >* should the document drop references to TEAP?
> > Given Jouni Malinen's comments on implementing TEAP, it may be worth
> simply noting that we're waiting for a TEAP update document
>
> I've reviewed the current errata, and acknowledge their validity, but am
> not sure that any of them would impact this document.
>
> The most relevant errata to this document seems to be
> https://www.rfc-editor.org/errata/eid5770. As noted in the errata, the
> calculation of keys becomes confusing when methods export both MSK and EMSK
> because it is not clearly specified which value IMCK[j] should take on
> during the calculation of S-IMCK[j]. The addition of clarifying information
> is welcome, but I don't believe this ambiguity currently prevents a
> compliant implementation - for example, an implementation could avoid this
> ambiguity by choosing to use either the MSK/EMSK exclusively, and
> communicating that to the server via the Compound MAC TLV. The server can
> then make a policy decision on whether it is accepting of this decision by
> the client and follow suit, or reject the client.
>
> The specifics of resolving this particular errata is a digression from my
> main point - I believe a clarification can be added to the main TEAP
> document at a future time without impacting the contents of this document..
> Ambiguity about which IMCK to use in S-IMCK calculation should not impact
> the definition of the cryptographic calculations.
>
> On the document contents themselves, I have this review: The key
> derivation proposed for TEAP/FAST uses the definition from FAST, which is
> not identical to the TEAP derivation. Namely, FAST used MSK[j] in the
> derivation, but TEAP uses IMSK[j], which may be equivalent in some cases,
> but may not in others where the inner method exports an EMSK.
>
> Specifically, I believe this line of section 2.2 should change from
>   IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
> S-IMCK[j-1] | MSK[j], 60)
> To
>   IMCK[j] = TLS-Exporter("EXPORTER: Inner Methods Compound Keys",
> S-IMCK[j-1] | IMSK[j], 60)
> For TEAP.
>
> Jorge
>
> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: Friday, April 3, 2020 1:48 PM
> To: EMU WG 
> Subject: [Emu] draft-dekok-emu-tls-eap-types discussion
>
>
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools..ietf.org%2Fhtml%2Fdraft-dekok-emu-tls-eap-types-01data=02%7C01%7Cjovergar%40microsoft.com%7C2c42095edc4e4cd61ce408d7d8106200%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637215437188744711sdata=ndLp%2FSzsDlX%2FKYx0UR0uf77rHgCjGej4kdZPpywuD9Q%3Dreserved=0
>
>   I haven't seen much discussion on the document.  There are still some
> open questions:
>
> * should it be published simultaneously with draft-ietf-emu-eap-tls13?
>If so, we need some consensus on this document, and quick.
>
>If not, when do we publish this draft?  Microsoft has already said that
> they won't rev their EAP-TLS 

Re: [Emu] RFC 7170 Erratum 5845

[Oleg Pekar]

Hi Eliot,

The correction is definitely true.



Question 1: The RFC says that no need to send Intermediate-Result TLV after
Basic Password Authentication and when client provided certificate for
authentication during tunnel establishment. What if server requires to
conduct Basic Password Authentication for User and EAP-MSCHAPv2 for Machine
within the same TEAP tunnel - should Intermediate-Result TLV be sent after
Basic Password Authentication?

Question 2: I think that the whole description of Intermediate-Result TLV
should be rephrased to provide a clear message what is it purpose and when
it should be used per your description in notes below. The current
description doesn't bring all this info:



4.2.11 .
Intermediate-Result TLV



The Intermediate-Result TLV provides support for acknowledged

   intermediate Success and Failure messages between multiple inner EAP

   methods within EAP.  An Intermediate-Result TLV indicating success

   MUST be accompanied by a Crypto-Binding TLV.  The optional TLVs

   associated with this TLV are provided for future extensibility to

   provide hints about the current result.





Thanks

Oleg

On Wed, Jan 22, 2020 at 3:46 PM Eliot Lear  wrote:

> Hi Jouni and all,
>
> Getting back to 7170 errata.
>
> You wrote:
>
> Section 3.3.1 says:
>
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  If more than one method is going to be executed in
>the tunnel, then upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
>
>
> It should say:
>
>EAP method messages are carried within EAP-Payload TLVs defined in
>Section 4.2.10.  Upon method completion, the server MUST send an
>Intermediate-Result TLV indicating the result.
>
>
> Notes:
>
> Description of whether Intermediate-Result TLV is supposed to be used in
> the case where only a single inner EAP authentication method is used.
> Section 3.3.1 says "more than one method is going to be executed in the
> tunnel, then upon method completion, the server MUST send an
> Intermediate-Result TLV indicating the result", Section 3.3.3 says "The
> Crypto-Binding TLV and Intermediate-Result TLV MUST be included to perform
> cryptographic binding after each successful EAP method in a sequence of one
> or more EAP methods", 4.2.13 says "It MUST be included with the
> Intermediate-Result TLV to perform cryptographic binding after each
> successful EAP method in a sequence of EAP methods", Annex C.3 shows an
> example exchange with a single inner EAP authentication method with use of
> Intermediate-Result TLV.
>
> It looks like the majority of the places discussion this topic implies
> that there is going to be an Intermediate-Result TLV after each inner EAP
> authentication method and the text in 3.3.1 is the only clear case of
> conflicting (or well, at least misleading if one were to claim it does not
> explicitly say MUST NOT for the one inner EAP authentication method case).
> As such, I'd conclude the Intermediate-Result TLV is indeed going to be
> exchanged after each EAP authentication method and the proposed text change
> to 3.3.1 covers that.
>
>
> Given the example in Section C.3, odd as it seems, is there any reason
> *not* to accept this erratum?
>
> Eliot
> ___
> 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] Query about two types of TEAP TLS session resume

[Oleg Pekar]

Hi,

I have several questions about TEAP TLS session resume since I am not sure
I succeeded to interpret the relevant sections of RFC 7170 and RFC 5077
correctly.


1) Does it make sense for TEAP server to support both TLS session resume
using server state and TLS session resume using PAC? Should the server have
an explicit configuration of which type of session resume it supports? In
EAP-FAST there was a dedicated stage of PAC provisioning (Phase 0) that
typically ended with PAC provisioning to the client inside the tunnel.
However TEAP RFC says that PAC should be provisioned either as TLS session
ticket after client sent empty TLS SessionTicket extension or in Phase 2
after client requested a PAC in Request-Action TLV + PAC TLV. So in TEAP
PAC provisioning is always initiated by the client. This gives the server a
chance to presume that if the client didn’t ask for PAC - it doesn’t
support PACs and thus the server should save TLS state of this conversation
in its memory for subsequent TLS session resume using server state.


2) Should it be a restriction for the total time of TLS session resume
using PAC as it exists for TLS session resume using server state? RFC 5077
says that if the conversation was resumed using SessionTicket then the
server can provide a new SessionTicket. Every SessionTicket has its
lifetime restriction but the total time of sequential conversations that
apply TLS session resume using SessionTicket (PAC) is not restricted. I.e.
there is no requirement to conduct a full TLS handshake once per specific
time interval. Doesn’t it create a security issue? Or is it totally on
client's responsibility to conduct a full TLS handshake once per specific
time so the client can verify TLS server's certificate?


3) TEAP RFC says: "If the PAC-Opaque included in the

   SessionTicket extension is valid and the EAP server permits the

   abbreviated TLS handshake, it will select the ciphersuite from

   information within the PAC-Opaque and finish with the abbreviated TLS

   handshake."


What is the reason for storing ciphersuite in the PAC and using it in TLS
session resume using PAC, if server can anyway control the ciphersuites to
eliminate weak cipher usage?


Thank you in advance for your answers,

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