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

2021-07-09 Thread Joseph Salowey via Datatracker
Joseph Salowey has requested publication of draft-ietf-emu-eap-tls13-18 as 
Proposed Standard on behalf of the EMU working group.

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


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


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

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

Cheers,

Joe

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

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


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

2021-07-08 Thread Joseph Salowey
On Thu, Jul 8, 2021 at 6:11 AM Alan DeKok  wrote:

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


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


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

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

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

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


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


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

2021-07-06 Thread Joseph Salowey
On Mon, Jun 28, 2021 at 8:11 AM Oleg Pekar 
wrote:

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


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


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


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

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

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

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

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

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

Thanks,

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


Re: [Emu] Minor PR on eap-tls13

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

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




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


Re: [Emu] Minor PR on eap-tls13

2021-06-24 Thread Joseph Salowey
On Tue, Jun 22, 2021 at 6:02 AM Alan DeKok 
wrote:

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

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

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

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





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


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

2021-06-18 Thread Joseph Salowey
On Thu, Jun 17, 2021 at 9:55 AM Alan DeKok 
wrote:

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


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

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


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


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

2021-06-13 Thread Joseph Salowey
On Sun, Jun 13, 2021 at 2:44 PM Bernard Aboba 
wrote:

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


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


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

2021-06-13 Thread Joseph Salowey
On Fri, Jun 11, 2021 at 11:29 AM Alan DeKok 
wrote:

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



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

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

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

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

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



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

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


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

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

2021-06-11 Thread Joseph Salowey
Hi Folks,

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

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

Thanks,

Joe

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

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


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

2021-05-24 Thread Joseph Salowey
I made some changes to the pull request to address some of the comments and
make the text clearer:

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

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

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


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

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


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

2021-05-20 Thread Joseph Salowey
On Wed, May 19, 2021 at 5:58 AM Alan DeKok 
wrote:

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


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


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

2021-05-16 Thread Joseph Salowey
Hi Oleg,

thanks for the review, comments below:

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

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


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

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

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


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


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


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


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

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

2021-05-16 Thread Joseph Salowey
On Thu, May 6, 2021 at 12:11 PM Alan DeKok 
wrote:

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



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


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


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


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

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

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

Thanks,

Joe

2.2.  Identity Verification

   This section updates Section 2.2 of [RFC5216].

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

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


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


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

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


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

2021-05-11 Thread Joseph Salowey
On Mon, May 10, 2021 at 10:53 AM John Mattsson 
wrote:

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

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


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


[Emu] EAP-TLS 1.3 Section 2.2 text

2021-05-09 Thread Joseph Salowey
Alan's review made the following comments:

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

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

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

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

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

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

[Joe]  This can be called out in this section

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

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

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

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

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

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

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

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

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

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


[Emu] Consensus call on EAP-TLS key derivation

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

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

Thanks,

Joe

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

Draft-15 Text:

Type-Code = 0x0D

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


Proposed New Text:

Type-Code = 0x0D

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

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

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

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


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


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

2021-05-07 Thread Joseph Salowey
On Fri, May 7, 2021 at 1:09 PM Jorge Vergara  wrote:

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


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


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

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

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

Thanks,

Joe

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

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

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


Re: [Emu] Issue 59 - Key Update

2021-04-12 Thread Joseph Salowey
On Mon, Apr 12, 2021 at 4:58 AM Alan DeKok 
wrote:

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

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


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


Re: [Emu] Issue 47 Certificate identity checks

2021-04-12 Thread Joseph Salowey
On Mon, Apr 12, 2021 at 6:02 AM Eliot Lear  wrote:

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


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


Re: [Emu] Issue 47 Certificate identity checks

2021-04-12 Thread Joseph Salowey
On Mon, Apr 12, 2021 at 5:48 AM Alan DeKok 
wrote:

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


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


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


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

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


[Emu] Issue 61 Clarifying NAI handling during resumption

2021-04-11 Thread Joseph Salowey
Please review and discuss the following on this thread.

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

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

Thanks,

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


[Emu] Issue 47 Certificate identity checks

2021-04-11 Thread Joseph Salowey
Please review the following proposal and discuss it on this thread.

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

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

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

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

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

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

Cheers,

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


[Emu] Issue 59 - Key Update

2021-04-11 Thread Joseph Salowey
Please review the following proposal and discuss issues on this thread.

Alan's review pointed out the following

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


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

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

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

Thanks,

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


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

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

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

Thanks,

Joe

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

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


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


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


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

[Joe] OK


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




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

[Emu] Resolving EAP-TLS issues

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

Thanks,

Joe

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

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

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

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

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


Open Issues without proposed Resolution

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


[Emu] Github repo for EAP-TLS 1.3 document

2021-03-04 Thread Joseph Salowey
Hi Folks,

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

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

Resolution to issues will be posted to the list.

Cheers,

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


[Emu] EAP-TLS 1.3 Success result indications resolution

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

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

Cheers,

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


[Emu] EAP-TLS key derivation resolution

2021-02-27 Thread Joseph Salowey
The current draft test specifies the following for key derivation:

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

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


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

1) has not received support from the working group

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


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


Cheers,


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


[Emu] Call for Agenda Items for IETF 110

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

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

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

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


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

2021-02-19 Thread Joseph Salowey
On Fri, Feb 19, 2021 at 3:32 AM Alan DeKok 
wrote:

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


Was this both Peer and server implementation?


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


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

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

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

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

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

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

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

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

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

Joe

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

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


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

2021-02-15 Thread Joseph Salowey
On Sun, Feb 14, 2021 at 6:47 PM Benjamin Kaduk  wrote:

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


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


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


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

2021-02-13 Thread Joseph Salowey via Datatracker
Joseph Salowey has requested publication of draft-ietf-emu-eap-noob-03 as 
Proposed Standard on behalf of the EMU working group.

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


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


[Emu] Key Derivation for EAP-TLS 1.3

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

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

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

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

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

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

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

Cheers,

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


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

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

This consensus call has two parts:

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

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

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

Thanks,

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


[Emu] Way Forward for EAP-TLS 1.3

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

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

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

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

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

Cheers,

Joe

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


Re: [Emu] EAP-TLS protected result indications

2021-02-02 Thread Joseph Salowey
On Tue, Feb 2, 2021 at 11:41 AM Bernard Aboba 
wrote:

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



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


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

2021-02-02 Thread Joseph Salowey
On Tue, Feb 2, 2021 at 2:10 PM Alan DeKok  wrote:

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


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


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

2021-02-01 Thread Joseph Salowey
On Mon, Feb 1, 2021 at 8:23 PM Benjamin Kaduk  wrote:

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


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

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

2021-02-01 Thread Joseph Salowey
On Mon, Feb 1, 2021 at 12:04 PM Alan DeKok 
wrote:

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

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

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

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

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




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


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


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

2021-02-01 Thread Joseph Salowey
On Mon, Feb 1, 2021 at 11:55 AM Alan DeKok 
wrote:

> On Feb 1, 2021, at 2:32 PM, Joseph Salowey  wrote:
> >
> >
> >
> > On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok 
> wrote:
> > On Feb 1, 2021, at 11:26 AM, Eric Rescorla  wrote:
> > > Yes, this is what I have in mind. So, maybe there's never any need for
> the server to say "I won't say anything more" after just one round trip?
> >
> >   I think so, yes.
> >
> >   That means of course EAP-TLS will always require 4.5 round trips.
> >
> > [Joe] I don't follow why this means 4.5 round trips would be required.
>
>   If the CloseNotify signal is sent by the server *after* it receives the
> client certs, then another round trip is required.  At least, according to
> Figure 1 of draft-13.
>
>   The CloseNotify can't be sent with the EAP-Success, because the
> EAP-Success can't carry data.  So the packet flow looks something like this:
>
>
[Joe] What purpose is the CloseNotify serving? RFC 5216 does not require
CloseNotify.


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


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

2021-02-01 Thread Joseph Salowey
On Mon, Feb 1, 2021 at 11:25 AM Alan DeKok 
wrote:

> On Feb 1, 2021, at 11:26 AM, Eric Rescorla  wrote:
> > Yes, this is what I have in mind. So, maybe there's never any need for
> the server to say "I won't say anything more" after just one round trip?
>
>   I think so, yes.
>
>   That means of course EAP-TLS will always require 4.5 round trips.
>
>
[Joe] I don't follow why this means 4.5 round trips would be required.


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


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

2021-02-01 Thread Joseph Salowey
On Mon, Feb 1, 2021 at 9:12 AM Benjamin Kaduk  wrote:

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


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


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

2021-01-31 Thread Joseph Salowey
On Sun, Jan 31, 2021 at 6:17 PM Benjamin Kaduk  wrote:

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


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

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

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

2021-01-29 Thread Joseph Salowey
HI Alan,

THanks for this message, comments inline below:

On Fri, Jan 29, 2021 at 12:02 PM Alan DeKok 
wrote:

>   This is a new message to summarize history, requirements, etc. for
> EAP-TLS and TLS 1.3.  The focus here is the requirements for EAP-TLS, and
> how the 0x00 commitment message versus CloseNotify meets those.  I'll
> ignore the exporter changes here, as those are less controversial.
>
>   The original proposal in the EAP-TLS draft was to send a zero-length
> application data message in order to signal that no more post-handshake
> messages were needed.  From the -05 version:
>
>When an EAP server has sent its last handshake message (Finished or a
>Post-Handshake), it commits to not sending any more handshake
>messages by appending an empty application data record (i.e. a TLS
>record with TLSPlaintext.type = application_data and
>TLSPlaintext.length = 0) to the last handshake record.  After sending
>an empty application data record, the EAP server may only send an
>EAP-Success, an EAP-Failure, or an EAP-Request with a TLS Alert
>Message.
>
>   However, the OpenSSL APIs (among others) do not allow for sending zero
> octets of application data.  The proposal was then changed to send a 0x00
> octet.
>
>  There was discussion that CloseNotify could achieve the same goals.  But
> CloseNotify requires an additional round trip.  There are strong opinions
> that additional round trips are bad.
>
>   In addition, CloseNotify prevents the TLS layer from sending a TLS Fatal
> Alert:  https://www.mail-archive.com/emu@ietf.org/msg03092.html
>
>   i.e. there would be no TLS layer signalling for the following situations:
>
>bad_certificate,  unsupported_certificate,  certificate_revoked,
> certificate_expired, certificate_unknown,  illegal_parameter, unknown_ca,
> access_denied, etc
>
>   This limitation would be an unmitigated disaster for EAP-TLS.  Those
> messages are required by people deploying EAP-TLS.  Without those messages,
> it will be near impossible to debug configuration issues.
>
>   As a result, we cannot use CloseNotify to signal "no more handshake
> messages" from the server.
>
>   There is a related issue, in that TLS 1.3 separates Session Tickets from
> TLS handshakes.  So it's still possible for the EAP state machine to send a
> 0x00 octet, and then the TLS state machines sends that *before* a Session
> Ticket.
>
>   In addition, RFC 8446 Figure 1 shows that application data can be sent
> by the server to the client, *before* the client certificate is sent to the
> server.  So sending this octet in EAP-TLS does not prove that the client
> certificate has been validated.
>
> DISCUSS: the EAP-TLS draft should explain that the 0x00 byte is NOT a
> positive signal of either "finished TLS", or "successful authentication".
>
> [Joe] It would be good to be clear about the purpose of the message.


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


> DISCUSS: We have interoperable implementations of -13.  Does this mean
> that the EAP state machines *implicitly* work with the TLS state machines?
> There is no *explicit* requirement in the draft about ordering, and no
> discussion thereof.  I suspect that this means the implementations work in
> part by accident, instead of by design.  So updates to TLS libraries *may*
> break EAP-TLS.  It would be best to make any assumptions explicit.  And /
> or to recommend to implementors that they be flexible with respect to
> changing order of the 0x00 octet vs session tickets.
>
> [Joe] Yes we should be clear about this.


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


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

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

2021-01-29 Thread Joseph Salowey
On Fri, Jan 29, 2021 at 11:34 AM Mohit Sethi M  wrote:

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

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


>
> With respect to the "commitment message", I thought we had a discussion
> that revealed that the mechanism in the -13 could not fulfil its stated
> purpose, and that also called into question whether that stated purpose was
> actually the right thing that the protocol needed.  My understanding,
> therefore, was that the TLS WG could not contribute further insight until
> there was a revised proposal from people who understand the needs of the
> EAP-TLS protocol from TLS that would both satisfy the needs of EAP and
> actually be achievable.
>
>
>   We have multiple inter-operable implementations which have implemented 
> draft-13.  That work over the last few months have resulted in implementors 
> making plans to do beta testing in the next few weeks.  Those plans have been 
> put on indefinite hold, due to the recent request for changes.
>
>   I understand getting feedback from the TLS WG is useful.  But I would 
> prefer to have consensus on a *solution*. Right now, we just have a series of 
> proposed changes, with little to no discussion.
>
> I think this is becaues the TLS WG members (in aggregate) do not have a
> clear picture of what property or properties EAP-TLS will require from TLS
> that led to the need for an additional message when using TLS 1.3 as
> opposed to the RFC 5216 case with TLS 1.2.  The prospect of an
> "authenticated signal from TLS to EAP-TLS that the authentication completed
> successfully" was mentioned, but I did not have the sense that there 

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

2021-01-27 Thread Joseph Salowey
On Wed, Jan 27, 2021 at 7:17 AM Alan DeKok 
wrote:

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


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


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

2021-01-10 Thread Joseph Salowey
On Thu, Jan 7, 2021 at 2:42 PM Martin Thomson  wrote:

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

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

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

the IANA section would explicitly list: EXPORTER_EAP_TLS_MSK-13


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




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


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

2021-01-10 Thread Joseph Salowey
Forwarded this conversation from the TLS list.  The question is about
changing the key derivation.

Joe

-- Forwarded message -
From: Joseph Salowey 
Date: Tue, Jan 5, 2021 at 10:24 PM
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on
draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
To: Alan DeKok 
Cc: Mohit Sethi M , EMU WG ,
Benjamin Kaduk , t...@ietf.org 




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

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


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


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

2021-01-05 Thread Joseph Salowey
On Tue, Jan 5, 2021 at 8:31 AM Alan DeKok  wrote:

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


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


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

2021-01-05 Thread Joseph Salowey
On Tue, Jan 5, 2021 at 8:14 AM Mohit Sethi M  wrote:

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



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


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

2021-01-04 Thread Joseph Salowey
On Mon, Jan 4, 2021 at 6:08 AM Alan DeKok  wrote:

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

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

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


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


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

2021-01-03 Thread Joseph Salowey
Hi Martin,

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

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

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


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


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


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

Re: [Emu] Revised resolution for TEAP erratum 5127

2020-11-23 Thread Joseph Salowey
At the IETF 109 EMU meeting Oleg suggest that we make it clear that if an
MSK is generated it must be used.  I suggest we do this by updating this
revision as below:

Section 5.2 says

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

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

 If an inner method does not support export of an Extended Master
 Session Key (EMSK), then IMSK is the MSK of the inner method.  The
 MSK is truncated at 32 octets if it is longer than 32 octets or
 padded to a length of 32 octets with zeros if it is less than 32
 octets.

It should say:

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

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

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

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

 If an inner method does not support export of an Extended Master
 Session Key (EMSK), then the IMSK MUST be derived from the
 MSK of the inner method.  The MSK is truncated at 32
 octets if it is longer than 32 octets or padded to a length of 32
 octets with zeros if it is less than 32 octets.

Cheers,

Joe



On Thu, Oct 29, 2020 at 10:05 PM Joseph Salowey  wrote:

> I think this erratum is done. I've also started a GH repo to track the
> changes in the document which might help show them in context a bit better.
> The PR for this issue is https://github.com/emu-wg/teap-errata/pull/2.
> Please post here or comment on the PR if you think this needs any
> additional work.
>
> Errata 5127: https://www.rfc-editor.org/errata/eid5127
> Proposed State: Verified
> Revision: https://github.com/emu-wg/teap-errata/pull/2
> Section 5.2 says
>
>  IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
>  "\0" | 64)
>
>  where "|" denotes concatenation, EMSK is the EMSK from the inner
>  method, "teapbind...@ietf.org" consists the ASCII value for the
>  label "teapbind...@ietf.org" (without quotes), "\0" = is a NULL
>  octet (0x00 in hex), length is the 2-octet unsigned integer in
>  network byte order, and TLS-PRF is the PRF negotiated as part of
>  TLS handshake [RFC5246].
>
> It should say:
>
>  IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org",
>  0x00 | 0x00 | 0x40)
>
>  where "|" denotes concatenation and the TLS-PRF is defined in
>  [RFC5246] as
>
>  PRF(secret, label, seed) = P_(secret, label | seed).
>
>  the secret is the EMSK from the inner method, the label is
>  "teapbind...@ietf.org" consisting of the ASCII value for the
>  label "teapbind...@ietf.org" (without quotes),  the seed
>  consists of the "\0" null delimiter (0x00) and 2-octet unsigned
>  integer length in network byte order (0x00 | 0x4) specified
>  in [RFC5295].
>
> Notes:
>
> RFC5246 The Transport Layer Security (TLS) Protocol Version 1.2
> 5. HMAC and the Pseudorandom Function
>
> "TLS's PRF is created by applying P_ to the secret as:
>
> PRF(secret, label, seed) = P_(secret, label + seed)"
>
> In this case the seed is the 2-byte length of the output as defined by RFC
> 5295. In terms of P_ the derivation would look like:
>
> IMSK = P_(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40)
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Proposed Resolution for TEAP errata 5768

2020-11-22 Thread Joseph Salowey
On Thu, Nov 19, 2020 at 8:53 PM Jorge Vergara 
wrote:

> Sorry for the last minute comment on this one before the meeting. I would
> like to mark this as a “discuss” - I have some compat concern about making
> the TLV length variable. Current implementations truncate the MAC field at
> 20 octets. Although I agree in spirit with the direction of this change, I
> think it would require changing the version of the Crypto-Binding TLV.
>
>
>
> I recognize that most probably won’t have time to review this concern
> before the meeting and so the discussion may not be able to occur there.
> Apologies again as I only realized this concern as I was giving everything
> a final pass-over.
>
>
>

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

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

Section 5.3 Says:



 The Compound MAC computation is as follows:

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

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

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

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



It Should say:



 The Compound MAC computation is as follows:

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

   where j is the number of the last successfully executed inner EAP
   method, MAC is HMAC [RFC2104] using the hash function negotiated in

   TLS [RFC5246].  If the output of the HMAC is greater than 20 bytes then

   it is truncated to 20 bytes.  The BUFFER is created after concatenating

   these fields in the following order:


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

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

   is a single octet encoded as (0x37)


> Jorge Vergara
>
>
>
> *From:* Oleg Pekar 
> *Sent:* Saturday, October 24, 2020 4:30 PM
> *To:* Joseph Salowey 
> *Cc:* EMU WG ; Jouni Malinen ; Jorge Vergara <
> jover...@microsoft.com>
> *Subject:* Re: Proposed Resolution for TEAP errata 5768
>
>
>
> > 2  The EAP Type sent by the other party in the first TEAP message. This
> is a single octet encoded as (0x37)
>
>
>
> Shouldn't we clarify the motivation for placing the octet with TEAP type
> 0x37 into the BUFFER? Joe, I remember you explained that it is for
> protection against cross protocol attacks if Crypto-Binding TLV was reused
> (e.g. from PEAP).
>
>
>
> On Sun, Oct 25, 2020 at 12:45 AM Joseph Salowey  wrote:
>
> Errata 5768:  https://www.rfc-editor.org/errata/eid5768
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5768=04%7C01%7Cjovergar%40microsoft.com%7C100b027d04c14dc5f59b08d87874b568%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637391789943190120%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=jn7e%2FfR9O%2Fa%2B%2F1gPWuUcUaXKKyf%2F8cTAR0qTXXx6MRM%3D=0>
>
> Proposed State: Verified
>
> Revision:
>
>
>
> Section 4.2.13. Says:
>
>
>
> Length
>
>
>
> 76
>
>
>
> It should say:
>
>
>
> Length
>
>
>
>  36 plus the length of the 2 MAC fields
>
>
>
> Section 4.2.13. Says:
>
>
>EMSK Compound MAC
>
>   The EMSK Compound MAC field is 20 octets.  This can be the Server
>   MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
>   MAC is described in Section 5.3.
>
>MSK Compound MAC
>
>   The MSK Compound MAC field is 20 octets.  This can be the Server
>   MAC (B1_MAC) or the Client MAC (B2_MAC).  The computation of the
>   MAC is described in Section 5.3.
>
>
>
> It Should Say:
>
>
>
>EMSK Compound MAC
>
>   The computation of the MAC is described in Section 5.3.  This can be
>
>   the Server MAC (B1_MAC) or the Client MAC (B2_MAC).
>
>MSK Compound MAC
>
>   The computation of the MAC is described in Section 5.3.  This can be
>
>   the Server MAC (B1_MAC) or the Client MAC (B2_MAC).
>
>
>
> Section 5.3 Says:
>
>
>
>  The Compound MAC computation is as follows:
>
>   CMK = CMK[j]
>   Compound-MAC = MAC( CMK, BUFFER )
>
>where j is the number of the last successfully executed inner EAP
>method, MAC is the MAC function negotiated in TLS 1.2 [RFC5246

[Emu] Working Group Last Call for draft-ietf-emu-eap-noob-02

2020-11-21 Thread Joseph Salowey
At  IETF 109 meeting there was support for moving EAP-NOOB forward.  The
chairs and authors believe the document is ready to progress so this starts
the working group last call for EAP-NOOB [1].   Please review the document
and send comments to the list by December 11, 2020.  Statements of support
or opposition are welcome especially if accompanied with reasons for the
position.

Thanks,

Joe

[1] https://datatracker.ietf.org/doc/draft-ietf-emu-eap-noob/
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] EMU at IETF 109

2020-11-18 Thread Joseph Salowey
If you are presenting at IETF 109 tomorrow please send your slides to the
chairs.

Friday, November 20, 2020 12:00 - 14:00 (+07)

Agenda 
Meeting Information

   1.

   Participants Guide
   

   https://www.ietf.org/how/meetings/109/session-participant-guide/
   2.

   Meetecho Link
   

   https://meetings.conf.meetecho.com/ietf109/?group=emu==1
   3.

   CodiMD Link 

   https://codimd.ietf.org/notes-ietf-109-emu
   4.

   Audio Link 

   http://mp3.conf.meetecho.com/ietf109/emu/1.m3u
   5.

   Jabber

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


Re: [Emu] Proposed Resolution to TEAP Errata 5844

2020-11-11 Thread Joseph Salowey
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 (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

Re: [Emu] Agenda Items for virtual IETF 109

2020-11-03 Thread Joseph Salowey
On Tue, Nov 3, 2020 at 9:40 PM Mohit Sethi M 
wrote:

> I think our slot is scheduled for 05:00 - 07:00 UTC. The times shown on
> the agenda: https://datatracker.ietf.org/meeting/109/agenda are in UTC +
> 7.
>
> [Joe] Yes that is correct, sorry for the confusion.

> --Mohit
> On 11/4/20 7:33 AM, Joseph Salowey wrote:
>
> At the virtual IETF 100 meeting, we will have a 2 hour session on
> Friday, November 20, between 12:00 - 14:00 UTC.
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Agenda Items for virtual IETF 109

2020-11-03 Thread Joseph Salowey
At the virtual IETF 100 meeting, we will have a 2 hour session on
Friday, November 20, between 12:00 - 14:00 UTC.

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

Don't forget to include the title of your presentation, related drafts,
and the approximate amount of time needed.  We will be giving priority
to items we ran out of time for at IETF 108 and to working group
items.

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


[Emu] Proposed TEAP Errata Resolution Summary

2020-11-01 Thread Joseph Salowey
Below is the summary of the TEAP errata resolutions.  The text that will be
sent to the AD is in the linked emails.  The GitHub PR is provided to make
it easier to review the revision in context.  Anything that is marked for
final review will be sent to the AD next week if there are no objections
raised.  Ones marked discuss should have some discuss to verify the
resolution (5765, 5767, 5775, 5844).

Thanks,

Joe

Errata ID: 5127
Status: Verified - Final Review
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/R5uypu9Kna8vTpyV5BlIXDm-Mdk/
PR: https://github.com/emu-wg/teap-errata/pull/2

Errata ID: 5128
Status: Verified - Final Review
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/fYBuPgWa7xiH7JmoHfP5yrU7HV0/
PR: https://github.com/emu-wg/teap-errata/pull/4

Errata ID: 5765
Status: Verified - Discuss
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/Ga8evJZzLG8lCML-kkxV6G_JS0E/
Mail: https://mailarchive.ietf.org/arch/msg/emu/676S5r51SkmxtzLZH9FqNFB6aOQ/
PR: https://github.com/emu-wg/teap-errata/pull/18

Errata ID: 5767
Status: Hold For Document Update - Discuss
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/QIOT258m2LNCnmCGKgpjCYVFLWE/

Errata ID: 5768
Status: Verified - Final Review
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/r-nAObtWmZ6tt1Dd0fmc7cHEBNs/
PR for section 5 is: https://github.com/emu-wg/teap-errata/pull/8
PR for section 4 is: https://github.com/emu-wg/teap-errata/pull/7

Errata ID: 5770
Status: Verified - Final Review
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/mXzpSGEn86Zx_fa4f1uULYMhMoM/
PR for section 5: https://github.com/emu-wg/teap-errata/pull/13

Errata ID: 5775
Status: Verified - Discuss
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/u96Oxo2oFnsntJUFRFgiPENDcYQ/
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: 5844
Status: Verified - Discuss
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/1ceqDbGP3mozqbzZ40xo48zFiDo/

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 ID: 5845
Status: Verified - Final review
Type: Technical Mail:
https://mailarchive.ietf.org/arch/msg/emu/Ucy2tg7UyZFry99k3oGOY_aS6mk
The PR for section 3: https://github.com/emu-wg/teap-errata/pull/20

Errata ID: 6157
Status: Verified - Final Review
Type: Technical
Mail: https://mailarchive.ietf.org/arch/msg/emu/t1HhhUL0QFgBmgAFYRMRkKXWXaA/
PR:https://github.com/emu-wg/teap-errata/pull/21
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Proposed Resolution for Errata 5845

2020-11-01 Thread Joseph Salowey
I think this one is ready to go.
The PR for section 3: https://github.com/emu-wg/teap-errata/pull/20

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 completion of an EAP authentication method, 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.

On Mon, Oct 26, 2020 at 8:23 PM Joseph Salowey  wrote:

>
>
> On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar 
> wrote:
>
>> >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.
>>
>>
> [Joe] Yes, I think you are correct.
>
>
>>
>>
>> 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 authent

Re: [Emu] Proposed Resolution to TEAP Errata 5844

2020-11-01 Thread Joseph Salowey
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
>>> 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"?
>>>
>>
>> [Joe] There are two cases where CryptoBinding is used, after completion
>> of an EAP authentication exchange and with the Result-TLV exchange.   Since
>> password based authentication does not generate a key there is no need for
>> crypto bi

[Emu] New proposed resolution for Errata 5767

2020-11-01 Thread Joseph Salowey
I think we should hold this one for document update.  The reason is there
are many places where we need to make changes, which is beyond what should
be done in the scope of an errata.  The changes are also more editorial
than technical.

Errata 5767: https://www.rfc-editor.org/errata/eid5767
Status: Hold for document Update
Type: Technical

There are many places in the document where the term "EAP Method" is used
to mean any EAP authentication method, excluding the EAP-Identity method.
In these places EAP authentication method should be used.  Some of the
places are identified below:

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.


Notes:

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

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

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

3.3.3: "after each successful EAP method" --> "after each successful EAP
authentication method"
3.8.3: "completion of the EAP method" --> "completion of the EAP
authentication method"
4.2.11: "between multiple inner EAP methods within EAP" --> "after each
inner EAP authentication method"
4.2.13: "after each successful EAP method" --> "after each successful EAP
authentication method"
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Revised TEAP Erratum 5770

2020-11-01 Thread Joseph Salowey
This revision removes the modification to section 5.4 to erratum 5775.  It
also leaves the discussion of the 0 MSK to a separate paragraph to be
revised in 5770.  I think this revision is ready.  Please comment on the
list or the PR if you do not think it is ready.

PR for section 5: https://github.com/emu-wg/teap-errata/pull/13

Errata ID: 5770 https://www.rfc-editor.org/errata/eid5770
Status: Verified
Type: Technical
Revision:

Section 5.2 Says:

On the sender of the Crypto-Binding TLV side:

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

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

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

   On the receiver of the Crypto-Binding TLV side:

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

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

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

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

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

It Should Say:

On the sender of the Crypto-Binding TLV side:

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

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

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

   On the receiver of the Crypto-Binding TLV side:

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

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

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

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

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

The IMSK used is either the EMSK-based IMSK or the MSK based IMSK depending
upon the rules outlined above.  It is possible that two S-IMCKs for a step
may be
generated based on the rules above.  In this
case the S-IMCK for further calculations is chosen as follows.  If the MAC
based
on the CMK-EMSK is verified then the S-IMCK generated based on the EMSK is
used.  Else, if the MAC based on the CMK-MSK is verified then the S-IMCK
generated based on the MSK is used.  If an inner method fails or MAC
verification
fails then S-IMCK is not used in further calculation.


Notes:

This revision clarifies handling cases where the EMSK may not be available
and the MSK may not be allowed by policy.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Revised Erratum for 5775

2020-11-01 Thread Joseph Salowey
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


[Emu] Revised Resolution for TEAP erratum 5768

2020-11-01 Thread Joseph Salowey
This revision has small changes to the text in the length field and changes
the text that describes what j represents to the last successfully
generated IMCK.  I think this revision is ready.  Please comment on the
list or the PR if you do not think it is ready.

PR for section 5  is: https://github.com/emu-wg/teap-errata/pull/8
PR for section 4 is: https://github.com/emu-wg/teap-errata/pull/7

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 included 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 generated IMCK,
   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.   The use of the
TEAP type is to prevent cross protocol attacks in the case that the same
crypto-binding TLV structure is used in multiple EAP tunneling protocols.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Proposed resolution for TEAP errata 5765

2020-11-01 Thread Joseph Salowey
On Fri, Oct 23, 2020 at 9:20 AM Jouni Malinen  wrote:

> On Thu, Oct 22, 2020 at 05:44:33PM +0300, Oleg Pekar wrote:
> > 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?
>
> That would be in conflict with Section 4.3.1: "Outer TLVs MUST be marked
> as optional."
>
> Please note that this M flag does not define whether the attribute must
> be included in the message; it defines whether the recipient has to
> reject the message if it does not support the TLV. We can still
> require the Authority-ID TLV to be present in TEAP/Start while marking
> it optional for the receiver to understand it (M=0).. And Section 3.2
> does indeed say that:
>The EAP server initiates the TEAP conversation with an EAP request
>containing a TEAP/Start packet.  This packet includes a set Start (S)
>bit, the TEAP version as specified in Section 3.1, and an authority
>identity TLV.
>
> This is still valid with M=0 for that TLV..
>
>
[Joe] I agree with Jouni here.  It is still valid to require the authority
ID in the message, the receiver does not have to process it.




> --
> Jouni MalinenPGP id EFC895FA
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

2020-10-30 Thread Joseph Salowey
On Fri, Oct 30, 2020 at 4:44 AM Michael Richardson 
wrote:

>
> Joseph Salowey  wrote:
> >> I suggest:
> >>
> >> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
> >> recovation checks,  MUST implement Certificate Status Requests
> using OCSP
> >> stapling as specified in Section 4.4.2.1 of [RFC8446].
>
> > [Joe] Thanks Michael,  I think your suggestion is a better way to
> phrase it
>
> Just so that we are clear:  this mandates OCSP+stapling for systems that do
> revocation checks.
>
> Systems that don't do revocation checks (current mbedtls), therefore don't
> need to do OCSP or stapling.
>

[Joe] That's not how I read your text.  I think your text mandates
OCSP+stapling for systems that use OCSP for revocation.

TLS 1.3 RFC 8446 does not mandate a particular revocation mechanism either,
as revocation is part of PKIX.

Also to be clear you text does not mandate that either servers or clients
support OCSP Stapling.

I think it would be appropriate to modify your text to replace "use" with
support.

"EAP-TLS servers supporting TLS 1.3 that support OCSP to do certificate
revocation checks,  MUST implement Certificate Status Requests using OCSP
stapling as specified in Section 4.4.2.1 of [RFC8446]."





> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Revised resolution for Erratum 5128

2020-10-29 Thread Joseph Salowey
I think this one is also done.  PR is here
https://github.com/emu-wg/teap-errata/pull/4.  Please comment on this
thread or PR if you think it still needs work:

Errata 5128: https://www.rfc-editor.org/errata/eid5128
Proposed State: Verified
Revision:

Section 5.2. says

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

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

It Should Say:

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

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

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

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

Section 5.4 Says:

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

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

It should say:

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

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

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

 The secret is S-IMCK[j]  where j is the number of the last generated
 S-IMCK from section 5.2.  The label is is the ASCII value for the
 string without quotes.  The seed is empty (0 length) and omitted from
 the derivation.

Notes:

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


Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

2020-10-29 Thread Joseph Salowey
On Thu, Oct 29, 2020 at 3:12 PM Michael Richardson 
wrote:

>
> Joseph Salowey  wrote:
> > 2. Require Servers to Implement and Recommended to Use OCSP with text
> > similar to the following:
>
> I don't think that this text is quite right.
>
> I note that "RECOMMENDED" is a synonym for SHOULD, and usually we ask
> documents to explain what a reasonable exception might look like.
> This text does not do that.
>
> > “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
> > Requests (OCSP stapling) as specified in Section 4.4.2.1 of
> [RFC8446].  It
> > is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
> > verifying the status of server certificates as specified in Section
> 4.4.2.1
> > of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the
> certificate
> > status of the EAP-TLS server, it MUST use Certificate Status
> Requests for
> > the server's certificate chain and it MUST treat a CertificateEntry
> (except
> > the trust anchor) without a valid CertificateStatus extension as
> invalid
> > and abort the handshake with an appropriate alert.“
>
> I suggest:
>
> “EAP-TLS servers supporting TLS 1.3 that use OCSP to do certificate
> recovation checks,  MUST implement Certificate Status Requests using OCSP
> stapling as specified in Section 4.4.2.1 of [RFC8446].
>
> It is RECOMMENDED that EAP-TLS peers and servers use OCSP (with stapling)
> for
> verifying the status of server certificates as specified in Section 4.4.2.1
> of [RFC8446].
>  mandated for TLS. I can't find the right place>
>
> When an EAP-TLS peer uses OCSP to verify the certificate status of the
> EAP-TLS server, it MUST use Certificate Status Requests for the server's
> certificate chain and it MUST treat a CertificateEntry (except the trust
> anchor) without a valid CertificateStatus extension as invalid and abort
> the
> handshake with an appropriate alert.“
>
> I don't know much about the last part.
> I suggest it be split as three paragraphs for readability.
>
>
[Joe] Thanks Michael,  I think your suggestion is a better way to phrase it


> --
> Michael Richardson. o O ( IPv6 IøT consulting )
>Sandelman Software Works Inc, Ottawa and Worldwide
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

2020-10-29 Thread Joseph Salowey
On Thu, Oct 29, 2020 at 10:30 AM Max Pala  wrote:

> Hi Eliot, all,
>
>
>
> In our industry we solved this issue by *requiring OCSP stapling if and
> only if the certificate being validated carries the OCSP URI in the
> certificate*.
>
>
>
> This allows us to live in a mixed environment where support for OCSP might
> have been introduced later on and allows the CA to explicitly support OCSP
> for the certificate by including the URL in it.
>
>
>
> If the “ecosystem” policy allows it – you might suggest that if OCSP
> responses are not not provided but the URL where to get OCSP responses is
> known to the device (or it is in the certificate), the device/entity can
> continue with the authentication but it should not enable any device/entity
> functionality before successfully executing (and validating) the OCSP
> protocol first (and disconnect if not reachable/invalid/revoked).
>
>
>

[Joe] So you are in favor of both clients and servers
mandatory implementing OCSP, but only requiring it be used when it is
signalled in the certificate?


> Just my 2 cents.
>
>
>
> Cheers,
> Max
>
>
>
> *From: *Emu  on behalf of Eliot Lear  40cisco@dmarc.ietf.org>
> *Date: *Thursday, October 29, 2020 at 10:53 AM
> *To: *Joseph Salowey 
> *Cc: *EMU WG 
> *Subject: *Re: [Emu] Consensus Call on OCSP usage in
> draft-ietf-emu-eap-tls13-11
>
>
>
> Hi Joe,
>
>
>
> My suggestion is that we add some discussion about what to do in the case
> of no connectivity to the CA.  This will be a not-uncommon occurrence,
> IMHO, in industrial use cases.
>
>
>
> Eliot
>
>
>
> On 29 Oct 2020, at 17:23, Joseph Salowey  wrote:
>
>
>
> An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the
> mandatory requirement for OCSP stapling [1].  The document makes the use of
> OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this
> may not be feasible in all deployments.  This is a quick consensus call for
> this issue.   Please indicate which option below you support and why.
> Please respond by November 5, 2020.
>
> 1. Keep the text as is with OCSP mandatory for all implementations
>
> 2. Require Servers to Implement and Recommended to Use OCSP with text
> similar to the following:
>
> “EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
> Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It
> is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
> verifying the status of server certificates as specified in Section 4.4.2.1
> of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate
> status of the EAP-TLS server, it MUST use Certificate Status Requests for
> the server's certificate chain and it MUST treat a CertificateEntry (except
> the trust anchor) without a valid CertificateStatus extension as invalid
> and abort the handshake with an appropriate alert.“
>
>
>
> Thanks,
>
>
>
> Joe
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/
> [2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>
>
>
> ___ Emu mailing list
> Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Consensus Call on OCSP usage in draft-ietf-emu-eap-tls13-11

2020-10-29 Thread Joseph Salowey
An issue was raised in a review of  draft-ietf-emu-eap-tls13-11 on the
mandatory requirement for OCSP stapling [1].  The document makes the use of
OCSP mandatory in section 5.4 [2]. Several folks have pointed out that this
may not be feasible in all deployments.  This is a quick consensus call for
this issue.   Please indicate which option below you support and why.
Please respond by November 5, 2020.

1. Keep the text as is with OCSP mandatory for all implementations

2. Require Servers to Implement and Recommended to Use OCSP with text
similar to the following:

“EAP-TLS servers supporting TLS 1.3 MUST implement Certificate Status
Requests (OCSP stapling) as specified in Section 4.4.2.1 of [RFC8446].  It
is RECOMMENDED that EAP-TLS peers and servers use OCSP stapling for
verifying the status of server certificates as specified in Section 4.4.2.1
of [RFC8446]. When an EAP-TLS peer uses OCSP to verify the certificate
status of the EAP-TLS server, it MUST use Certificate Status Requests for
the server's certificate chain and it MUST treat a CertificateEntry (except
the trust anchor) without a valid CertificateStatus extension as invalid
and abort the handshake with an appropriate alert.“

Thanks,

Joe

[1] https://mailarchive.ietf.org/arch/msg/emu/0DnfUWPqvKX0_Wo8s-ZypergMHI/
[2] https://tools.ietf.org/html/draft-ietf-emu-eap-tls13-11#section-5.4
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Proposed Resolution to TEAP Errata 5770

2020-10-27 Thread Joseph Salowey
On Tue, Oct 27, 2020 at 12:23 AM Eliot Lear  wrote:

> Hi,
>
> >
> > [Joe] Yes I think it is fine to say EAP authentication method.   I have
> been convinced that the spec requires crypto-binding with the basic
> password authentication.   I'll need to add this in.
> >
>
> Keep in mind that there might not even be basic auth.  One case is that
> one just uses the OUTER auth, does some PKCS ops or extensions and then
> wants to conclude.  No inner in this case.  Which erratum is that covered
> by?
>
>
[Joe]  Erratum 5775 discusses how to generate key material when there is
no inner authentication method such as the case you describe.


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


Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-27 Thread Joseph Salowey
On Tue, Oct 27, 2020 at 11:27 AM Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi Joe,
>
>
>
> a few remarks below.
>
>
>
>
>
> On Fri, Oct 23, 2020 at 12:38 AM Hannes Tschofenig <
> hannes.tschofe...@arm.com> wrote:
>
> Hi Joe,
>
>
>
> I do not understand certificate revocation checking is a topic specific to
> the use of TLS 1.3 in EAP-TLS.
>
>
>
> [Joe]  TLS 1.3 discusses OCSP and (SCT).  OCSP stapling is a revocation
> mechanism that will work when the EAP-TLS client does not have connectivity
> yet, which is a common case in EAP-TLS deployments.The way the draft is
> written now it mandates that this mechanism be used and implements.  TLS
> 1.3 does not require this.
>
>
>
> [hannes] It is also common to give network access to devices that need a
> software update or configuration changes.
>
>
>
> What do you expect to happen if the device finds out that the certificate
> offered by the server has expired?
>
>
>
[Joe] If the server is offering an expired or revoked certificate then that
needs to be remedied on the server.


>
>
> If this topic is important to the group then why isn’t this a generic
> recommendations for all EAP methods that use public key based
> authentication?
>
>
>
>
>
> [Joe] Certificate revocation is specific to the use of certificates.
>
>
>
> [Hannes] Many EAP methods use certificates but they do not mandate the use
> of OCSP.
>
>
>
> Wouldn’t this be a topic to address in ? IMHO
> this would make more sense given that  talks
> about large certificates and long certificate chains and any proposal to
> make those even larger should be evaluated in this context.
>
>
>
>
>
> [Joe] No,  discusses handling large
> certificates not revocation.
>
>
>
> [Hannes] Here the problem description that motivates
> 
>
> “
>
> Large certificates and long
>
>certificate chains combined with authenticators that drop an EAP
>
>session after only 40 - 50 round-trips is a major deployment problem.
>
>This document looks at the this problem in detail and describes the
>
>potential solutions available.
>
> “
>
> OCSP information travels alongside the certificates and therefore
> increases the problem outlined by 
>
>
>
> EAP-TLS is the right place to discuss revocation issues.
>
>
>
> It seems there are several questions that need to be answered:
>
>
>
>1. Should the document mandate that OCSP stapling be used?
>
> [Hannes] No.
>
>
>
> 2. Should the document mandate that OCSP stapling be implemented?
>
> [Hannes] No.
>
>
>
> 3. What should the document say in the security sections with respect to
> OCSP stapling and other mechanisms?
>
> [Hannes] IMHO TLS 1.3 says the relevant solution parts. OCSP stapling is
> available for use in TLS 1.3 and it is one suitable mechanism for
> certificate revocation.
>
>
>
> Do any of these recommendations also apply to EAP-TLS with TLS 1.2 as well
> (since it also offers OCSP stapling)? Would the recommendations also apply
> to EAP methods that use TLS under the hood, such as TEAP, EAP-FAST, or
> EAP-TTLS? Would they apply to methods like EAP-IKEv2 or the recently
> suggested EAP-EDHOC, which are also methods that use certificates?
>

[Joe] the document under consideration is EAP-TLS 1.3.   In my opinion any
document that deals with certificates ought to have some discussion on
revocation.  In particular, EAP is deployed into an environment where some
revocation mechanisms may not work as expected because there is no network
access available to do out of band checks.


>
>
> Ciao
>
> Hannes
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Thursday, October 22, 2020 11:12 PM
> *To:* Eliot Lear 
> *Cc:* Hannes Tschofenig ; emu@ietf.org
> *Subject:* Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
>
>
>
>
>
>
>
> On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear  40cisco@dmarc.ietf.org> wrote:
>
> +1.  How does anyone even do OCSP without having first gotten onto the
> network?
>
>
>
>
>
> [Joe] THat is what OCSP stapling is supposed to solve since the OCSP
> messages are sent in the TLS handshake.   I believe there are some EAP-TLS
> implementations that support OCSP, but I am not sure if it is actually
> deployed.
>
>
>
> Eliot
>
>
>
> On 21 Oct 2020, at 11:02, Hannes Tschofenig 
> wrote:
>
>
>
> Hi all,
>
>
>
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
> believe this is a problem for implementations. This extra bu

Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-27 Thread Joseph Salowey
On Fri, Oct 23, 2020 at 12:38 AM Hannes Tschofenig <
hannes.tschofe...@arm.com> wrote:

> Hi Joe,
>
>
>
> I do not understand certificate revocation checking is a topic specific to
> the use of TLS 1.3 in EAP-TLS.
>
>
>

[Joe]  TLS 1.3 discusses OCSP and (SCT).  OCSP stapling is a revocation
mechanism that will work when the EAP-TLS client does not have connectivity
yet, which is a common case in EAP-TLS deployments.The way the draft is
written now it mandates that this mechanism be used and implements.  TLS
1.3 does not require this.


> If this topic is important to the group then why isn’t this a generic
> recommendations for all EAP methods that use public key based
> authentication?
>
>
>

[Joe] Certificate revocation is specific to the use of certificates.


> Wouldn’t this be a topic to address in ? IMHO
> this would make more sense given that  talks
> about large certificates and long certificate chains and any proposal to
> make those even larger should be evaluated in this context.
>
>
>

[Joe] No,  discusses handling large certificates
not revocation.  EAP-TLS is the right place to discuss revocation issues.
It seems there are several questions that need to be answered:

1. Should the document mandate that OCSP stapling be used?
2. Should the document mandate that OCSP stapling be implemented?
3. What should the document say in the security sections with respect to
OCSP stapling and other mechanisms?







> Ciao
>
> Hannes
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Thursday, October 22, 2020 11:12 PM
> *To:* Eliot Lear 
> *Cc:* Hannes Tschofenig ; emu@ietf.org
> *Subject:* Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling
>
>
>
>
>
>
>
> On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear  40cisco@dmarc.ietf.org> wrote:
>
> +1.  How does anyone even do OCSP without having first gotten onto the
> network?
>
>
>
>
>
> [Joe] THat is what OCSP stapling is supposed to solve since the OCSP
> messages are sent in the TLS handshake.   I believe there are some EAP-TLS
> implementations that support OCSP, but I am not sure if it is actually
> deployed.
>
>
>
> Eliot
>
>
>
> On 21 Oct 2020, at 11:02, Hannes Tschofenig 
> wrote:
>
>
>
> Hi all,
>
>
>
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
> believe this is a problem for implementations. This extra burden is IMHO
> unjustified. For the type of deployments where EAP is used there is no need
> for a mandatory certificate revocation checking with OCSP.
>
>
>
> Having it optional, like the use of many other TLS extensions, is fine for
> me. FWIW even TLS 1.3, which is used in a more generic environment, does
> not mandate the use of OCSP stapling.
>
>
>
> This requirement will make the problem described in
> draft-ietf-emu-eaptlscert worse. I am sure the authors are aware of this
> fact since they are also co-authors of draft-ietf-emu-eaptlscert.
>
>
>
> Ciao
>
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> 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
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Proposed Resolution to TEAP Errata 5770

2020-10-26 Thread Joseph Salowey
On Mon, Oct 26, 2020 at 12:51 PM Jorge Vergara 
wrote:

> This is a detailed one so I’ve tried to go over it carefully. Most of it
> looks good but I’m unsure about this part:
>
>
>
> > If an inner method fails or MAC verification
>
> fails then S-IMCK is not used in further calculation.
>
>
>
> It is a valid scenario that multiple authentication methods run and some
> fail, but the overall TEAP authentication succeeds. For example, if two
> inner EAP Authentication methods run and the first fails but the seconds
> succeeds, the calculation needs to be valid. Based on the old text, that
> authentication method is omitted from calculations. This is what current
> implementations do.
>
>
>
> My editorial comment based on some other errata would be to that text
> needs to specify “authentication” methods (per Jouni’s other errata) since
> the Identity method doesn’t factor in here. I think it would also be
> beneficial to be specific about the behavior of basic username and password
> authentication here. Oleg made some comments to this effect on another
> email. Our implementation doesn’t support basic username and password
> authentication so I don’t have any prior experience here.
>
>
[Joe] Yes I think it is fine to say EAP authentication method.   I
have been convinced that the spec requires crypto-binding with the basic
password authentication.   I'll need to add this in.


>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Saturday, October 24, 2020 5:18 PM
> *To:* EMU WG 
> *Cc:* Oleg Pekar ; Jouni Malinen ;
> Jorge Vergara 
> *Subject:* Proposed Resolution to TEAP Errata 5770
>
>
>
> Errata 5770: https://www.rfc-editor.org/errata/eid5770
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid5770=04%7C01%7Cjovergar%40microsoft.com%7C728ceb6af6694e40e08e08d8787b669d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637391818689781723%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=RuRrXZ5c70r43Rmyl4s%2BVUKAA22nGtoenLElbCeUkmE%3D=0>
>
> Proposed Status: Verified
>
> Revision:
>
>
>
> Section 5.2 Says:
>
>
>
> On the sender of the Crypto-Binding TLV side:
>
>  If the EMSK is not available, then the sender computes the Compound
>  MAC using the MSK of the inner method.
>
>  If the EMSK is available and the sender's policy accepts MSK-based
>  MAC, then the sender computes two Compound MAC values.  The first
>  is computed with the EMSK.  The second one is computed using the
>  MSK.  Both MACs are then sent to the other side.
>
>  If the EMSK is available but the sender's policy does not allow
>  downgrading to MSK-generated MAC, then the sender SHOULD only send
>  EMSK-based MAC.
>
>On the receiver of the Crypto-Binding TLV side:
>
>  If the EMSK is not available and an MSK-based Compound MAC was
>  sent, then the receiver validates the Compound MAC and sends back
>  an MSK-based Compound MAC response.
>
>  If the EMSK is not available and no MSK-based Compound MAC was
>  sent, then the receiver handles like an invalid Crypto-Binding TLV
>  with a fatal error.
>
>  If the EMSK is available and an EMSK-based Compound MAC was sent,
>  then the receiver validates it and creates a response Compound MAC
>  using the EMSK.
>
>  If the EMSK is available but no EMSK-based Compound MAC was sent
>  and its policy accepts MSK-based MAC, then the receiver validates
>  it using the MSK and, if successful, generates and returns an MSK-
>  based Compound MAC.
>
>  If the EMSK is available but no EMSK Compound MAC was sent and its
>  policy does not accept MSK-based MAC, then the receiver handles
>  like an invalid Crypto-Binding TLV with a fatal error.
>
>
>
> If the ith inner method does not generate an EMSK or MSK, then IMSKi
> is set to zero (e.g., MSKi = 32 octets of 0x00s).  If an inner method
> fails, then it is not included in this calculation.
>
>
>
> It Should Say:
>
>
>
> On the sender of the Crypto-Binding TLV side:
>
>  If the EMSK is not available, then the sender computes the Compound
>  MAC using the CMK generated from MSK (CMK-MSK) of the inner method.
>
>  If the EMSK is available and the sender's policy accepts MSK-based
>  MAC, then the sender computes two Compound MAC values.  The first
>  is computed with the CMK generated from the EMSK (CMK-EMSK).  The
>
>  second one is computed using the CMK-MSK.  Both MACs are
>
>  then sent to the other side.  This also means the sender must generate
>
>  b

Re: [Emu] Proposed Resolution to TEAP Errata 5844

2020-10-26 Thread Joseph Salowey
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
>> 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"?
>>
>
> [Joe] There are two cases where CryptoBinding is used, after completion of
> an EAP authentication exchange and with the Result-TLV exchange.   Since
> password based authentication does not generate a key there is no need for
> crypto binding.  It is just treated as a TLV.
>
>

[Joe] Section 4.2.11 contradicts this - "An Intermediate-Result TLV
indicating success MUST be accompanied by a Crypto-Binding TLV."  I think
we need to use the 0 MSK with the 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?
>>
>> [Joe] It should be consistent. Re-worded slightly:
>
> 3. The Intermediate-Result TLVs carry success or failure indications of
> each individual EAP authentication method or basic password authentication
> in TEAP Phase 2.
>
> And
>
> The Intermediate-Result TLV provides support for acknowledged intermediate
> Success and Failure messages for inner EAP authentication methods or basic
> password authentication.
>
>
>>
>> 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-Acknow

Re: [Emu] Proposed Resolution to TEAP Errata 5844

2020-10-26 Thread Joseph Salowey
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
> 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"?
>

[Joe] There are two cases where CryptoBinding is used, after completion of
an EAP authentication exchange and with the Result-TLV exchange.   Since
password based authentication does not generate a key there is no need for
crypto binding.  It is just treated as a TLV.


>
> 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?
>
> [Joe] It should be consistent. Re-worded slightly:

3. The Intermediate-Result TLVs carry success or failure indications of
each individual EAP authentication method or basic password authentication
in TEAP Phase 2.

And

The Intermediate-Result TLV provides support for acknowledged intermediate
Success and Failure messages for inner EAP authentication methods or basic
password authentication.


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

Re: [Emu] Proposed Resolution for Errata 5845

2020-10-26 Thread Joseph Salowey
On Mon, Oct 26, 2020 at 1:27 AM Oleg Pekar 
wrote:

> >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.
>
>
[Joe] Yes, I think you are correct.


>
>
> 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 for TEAP errata 5775

2020-10-26 Thread Joseph Salowey
On Mon, Oct 26, 2020 at 1:25 AM Oleg Pekar 
wrote:

> 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.
>
>
[Joe]  Good catch,  S-IMCK[0] is only 40 octets.   Looking at this I think
it makes more sense to Change

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


To:

If the jth inner method does not generate an EMSK or MSK, or no inner

  method has been run then IMSK[j] is set to zero (32 octets of 0x00s).




> 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.
>
> [Joe] I don't think so, but let's discuss on the 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.
>

[Joe]  It doesn't seem to me that the Zero-MSK flag is necessary, I'd
rather not add new signals if we do not need them now.  If a method
generates an MSK then I think it must be used.   We can add a sentence
saying that to the above revision.

 If the jth inner method does not generate an EMSK or MSK, or no inner

 method has been run then IMSK[j] is set to zero (32 octets of 0x00s).

 If a method generates an MSK or EMSK the zero IMSK MUST NOT be used.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Proposed Resolution for TEAP Errata 6157

2020-10-25 Thread Joseph Salowey
Errata 6157: https://www.rfc-editor.org/errata/eid6157
Proposed Status: Verified
Revision:
Section 4.2.9 says:

  Status

  The Status field is one octet.  This indicates the result if the
  server does not process the action requested by the peer.

It should say:

  Status

  The Status field is one octet.  This indicates the result if the
  party who receives this TLV does not process the action.

Notes:

The status field is carried in the "Request-Action" frame. As is repeatedly
stated in the chapeau of the section, the frame can be sent either by the
server or the peer.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


[Emu] Proposed Resolution for Errata 5845

2020-10-25 Thread Joseph Salowey
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


[Emu] Proposed Resolution to TEAP Errata 5844

2020-10-25 Thread Joseph Salowey
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


[Emu] Proposed resolution for TEAP errata 5775

2020-10-25 Thread Joseph Salowey
Errata 5775: https://www.rfc-editor.org/errata/eid5775
Proposed Status: Verified
Revision:

Section 5.2 Says:

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

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

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.  If an inner EAP method is not
 executed with successful authentication then the EMSK Compound MAC
 field contains the MAC using keys generated according to section 5.2.
 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:

Notes:

How to calculate the CMK and other keys when no inner method was run was
unspecified.  This revision specifies that the CMK is generated from
S-IMSK[0]
and the MAC goes into the EMSK field.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Proposed Resolution for TEAP errata 5768

2020-10-24 Thread Joseph Salowey
On Sat, Oct 24, 2020 at 4:29 PM Oleg Pekar 
wrote:

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

[Joe]  That's more of an editorial comment that we would hold for a
document revision.  I think we should try to keep the revision text at a
minimum, but we certainly can include this information in the errata
notes.


> 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


[Emu] Proposed Resolution to TEAP Errata 5770

2020-10-24 Thread Joseph Salowey
Errata 5770: https://www.rfc-editor.org/errata/eid5770
Proposed Status: Verified
Revision:

Section 5.2 Says:

On the sender of the Crypto-Binding TLV side:

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

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

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

   On the receiver of the Crypto-Binding TLV side:

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

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

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

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

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

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

It Should Say:

On the sender of the Crypto-Binding TLV side:

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

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

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

   On the receiver of the Crypto-Binding TLV side:

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

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

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

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

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

The IMSK used is either the EMSK-based IMSK or the MSK based IMSK depending
upon the rules outlined above. 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).It
is possible
that two S-IMCKs for a step may be generated based on the rules above.  In
this
case the S-IMCK for further calculations is chosen as follows.  If the MAC
based
on the CMK-EMSK is verified then the S-IMCK generated based on the EMSK is
used.  Else, if the MAC based on the CMK-MSK is verified then the S-IMCK
generated based on the MSK is used.  If an inner method fails or MAC
verification
fails then S-IMCK is not used in further 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.

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 

[Emu] Proposed Resolution for TEAP errata 5768

2020-10-24 Thread Joseph Salowey
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

2020-10-23 Thread Joseph Salowey
I think we have agreement on what the derivation would be now it's a matter
of clearly describing it. Here is a proposal:
IMCK[j] = the first 60 bytes of TLS-PRF(S-IMCK[j-1], "Inner Methods
Compound Keys", IMSK[j])

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

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

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

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

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

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

 The secret is S-IMCK[j-1]  where j is the number of the last
successfully
 executed inner EAP method.  The label is is the ASCII value for the
 string without quotes.  The seed is empty (0 length) and omitted from
 the derivation.

On Fri, Oct 23, 2020 at 9:58 AM Jouni Malinen  wrote:

> There were so many messages in this thread that I'm not going try to
> address each point separately, but I think in general I do agree with
> the comments and it looks like all the identified implementation are
> doing the same thing here..
>
> I don't see any strong need to encode the output length of the PRF into
> the input data especially since we are using hardcoded output lengths in
> these cases. That said, I'm not against keeping it there for the IMSK
> derivation since that particular case seemed to be explicitly defined as
> using a 2-octet field in network byte order (and all the known
> implementations doing exactly that). IMHO, the other cases should not be
> modified to try to be consistent with this.
>
> While I do understand the benefits of having an explicit fixed delimiter
> "\0" between the label and seed to enforce unique interpretation if two
> labels were to have same prefix, I don't see that as a critical issue in
> any of the instances used within TEAP due to no such common prefix case
> exist nor do we even use TLS-PRF with the same secret/key. Furthermore,
> RFC 5246 does not mandate or even discuss such delimiter.
>
> There is no need to convert an empty seed to 0x00 or anything else.
> TLS-PRF can be used with secret=something, label=ASCII string,
> seed=0-length data) without issues.
>
> If we want to define a new TEAP-PRF() function, I'd prefer it to be
> using consistent terminology with TLS-PRF in RFC 5246 (and well, to
> extend possible, also be as consistent as can be with the TLS-Exporter
> use in RFC 8446). This would also mean not trying to enforce some 0x00
> delimiter or length in context data. At its simplest and only with TLS
> v1.2 in mind for clarity here, this could look something like
>
> TEAP-PRF(secret, label, seed, output length) =
> PRF(secret, label, seed) outputting "output length" octets
>
> label = ASCII string, no "\x0" termination
> seed = arbitrary binary data (including possibility of 0-length empty
> case)
>
> With this, we would have following:
> IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 0x00 |
> 0x00 | 0x40, 64)
> IMCK[j] = TEAP-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j], 60)
> MSK = TEAP-PRF(S-IMCK[j], "Session Key Generating Function", , 64)
> EMSK = TEAP-PRF(S-IMCK[j], "Extended Session Key Generating Function",
> , 64)
>
> RFC 5295 rules about EMSK use for USRK/DSRK applies for the first one of
> these and it does seem to give justification for the seed to have "\0"
> and "length" (as 2-octet unsigned integer in network byte order). While
> one could claim that the rules for DSUSRK derivation applies to those
> other instances and as such, would require 0x00 and length to be added
> around the seed shown above, I'd note that there does not seem to be any
> MUST statement about that in RFC 5295 and as such, I think the versions
> described above (and the ones used in known implementations today) seem
> to be justifiable especially taken into account the unique label string
> prefixes and fixed length of output data.
>
> --
> Jouni MalinenPGP id EFC895FA
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] Proposed resolution for TEAP errata 5127

2020-10-23 Thread Joseph Salowey
On Fri, Oct 23, 2020 at 9:11 AM Jouni Malinen  wrote:

> On Wed, Oct 21, 2020 at 02:14:45PM -0700, Joseph Salowey wrote:
> > On Wed, Oct 21, 2020 at 12:11 PM Jouni Malinen  wrote:
> >
> > > On Wed, Oct 21, 2020 at 09:30:33AM -0700, Joseph Salowey wrote:
> > > > Errata 5127: https://www.rfc-editor.org/errata/eid5127
> > > > Proposed State: Verified
> > > > Revision:
> > > > Section 5.2.
> > > > OLD
> > > >
> > > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
> > > >  "\0" | 64)
> > > >
> > > > NEW
> > > >
> > > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org" |
> > > >'/0', 64)
> > >
> > > Why would this change "\0" to '/0'?
> > >
> > > [Joe] that was my mistake should be "/0"
> >
> >
> > > How is that 64 supposed to be encoded if it is the "seed" argument to
> > > PRF(secret, label, seed) define in RFC 5246 Section 5?
> > >
> > >
> > [Joe] 7170 says "length is the 2-octet unsigned integer in network byte
> > order"
>
> It does, but how would one know that this particular 64 is "length"?
> This "64" argument is the "seed" argument to PRF and that could be any
> arbitrary data.. The length of TLS-PRF output is meta data that is not
> passed to the PSK() defined in RFC 5246 directly as an argument, i.e.,
> inclusion of the output length in the seed is something that RFC 7170 is
> doing here for some reason and it could have included any other
> arbitrary seed value here for that matter.. IMHO, this is too vague and
> it would be better to spell out the exact contents of the seed value
> (0x00 | 0x40 im this particular case shown here or 0x00 | 0x00 | 0x40 if
> following the proposal below).
>
>
[Joe]  The length is called out as 64 octets in the sentence just before
this, to me this is not very vague.   However, I do agree that specifying
the exact encoding would be even clearer.  Here is a proposed revision that
I think addresses this and the comment later on in the message:

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

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

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

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


> > > Using P_hash(EMSK, "teapbind...@ietf.org" | 0x00 | 0x00 | 0x40) looks
> > > correct, but it looks strange to me if we are trying to include the
> > > first 0x00 at the end of the "label" argument to PRF(secret, label,
> > > seed) especially when the label is define to be "an ASCII string. It
> > > should be included in the exact form it is given without a length byte
> > > or trailing null character". I would have expected
> > > "teapbind...@ietf.org" to be the "label" while 0x00 | 0x00 | 0x40
> would
> > > be the "seed". In other words:
> > >
> > > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org",
> > >   0x00 | 0x00 | 0x40).
> > >
> > >
> > [Joe] Yes I agree that is better how about this as the text change
> >
> > IMSK = First 32 octets of TLS-PRF(EMSK, "teapbind...@ietf.org", "\0" |
> 64)
>
> It looks quite strange to me to define a binary seed data as a
> concatenation of a string and an integer. I have the exact same question
> about the encoding of 64 here since this does not describe explicitly
> this instance of 64 to be the "length" which has the particular encoding
> described in RFC 7170. For me, using 0x00 | 0x00 | 0x40 and deleting
> that note about length encoding would be significantly clearer. If that
> is not acceptable, I would still replace "\0" with 0x00 in this context
> since this is not an ASCII string or label anymore, but binary data. And
> in addition to that, the "64" part would need to be replaced with
> something like "TLS-PRF output length" and then the "TLS-PRF output
> length" could be mentioned to be 64 in this instance and the encoding
> for that would be 2-octet unsigned integer in network byte order.
>
> --
> Jouni MalinenPGP id EFC895FA
>
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling

2020-10-22 Thread Joseph Salowey
On Thu, Oct 22, 2020 at 8:08 AM Eliot Lear 
wrote:

> +1.  How does anyone even do OCSP without having first gotten onto the
> network?
>
>
[Joe] THat is what OCSP stapling is supposed to solve since the OCSP
messages are sent in the TLS handshake.   I believe there are some EAP-TLS
implementations that support OCSP, but I am not sure if it is actually
deployed.


> Eliot
>
> On 21 Oct 2020, at 11:02, Hannes Tschofenig 
> wrote:
>
> Hi all,
>
> this draft mandates OCSCP stapling (for use with TLS 1.3 in EAP-TLS) and I
> believe this is a problem for implementations. This extra burden is IMHO
> unjustified. For the type of deployments where EAP is used there is no need
> for a mandatory certificate revocation checking with OCSP.
>
> Having it optional, like the use of many other TLS extensions, is fine for
> me. FWIW even TLS 1.3, which is used in a more generic environment, does
> not mandate the use of OCSP stapling.
>
> This requirement will make the problem described in
> draft-ietf-emu-eaptlscert worse. I am sure the authors are aware of this
> fact since they are also co-authors of draft-ietf-emu-eaptlscert.
>
> Ciao
> Hannes
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
> ___
> 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] Proposed resolution for TEAP errata for 5128

2020-10-22 Thread Joseph Salowey
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[j], "Session Key Generating
> Function”, , 64) = P_hash(S-IMCK[j], "Session Key
> Generating Function” | 0x00 | 0x00 | 0x40)
> --- no implementation change
>
> [Joe] This is the one we have not discussed yet.  This derivation is also
ambiguous.  THis section does not reference 5295.  It's not clear if the
original intent was to include the length in the hash or not.  I think
there are a few interpretations:

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

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





> Jorge, please correct me if I misinterpret the 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, b

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

2020-10-22 Thread Joseph Salowey
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.


>
> Oleg
>
>
> On Thu, Oct 22, 2020 at 2:54 AM Joseph Salowey  wrote:
>
>> (I accidentally dropped this list from the conversation)
>>
>> On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara 
>> wrote:
>>
>>> >[Joe] Yes this is a concern and I think your interpretation of the
>>> current document is also valid.  There may be more than one
>>> implementation.  So what you implemented was:
>>>
>>> >
>>>
>>> >IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j])
>>> = P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>>>
>>>
>>>
>>> Yes, this is what I implemented. As you mentioned, there are multiple
>>> possible interpretations of this since the TEAP usage is incorrect.
>>> However, my implementation does interop with at least 2 large vendor
>>> implementations. If the implementations were using different calculations
>>> here, the Wi-Fi/Ethernet connections that depend on the MSK would fail. But
>>> since connections work, I can assume we are all using the same
>>> implementation and arriving at the same MSK. Cisco is one of the
>>> implementations that I have tested against which is why I was hoping Oleg
>>> may offer more context as to what he has seen.
>>>
>>>
>>>
>> [Joe] I can hope Jouni can chime in on this as well.  I think the
>> original intent was to not include the length as is your suggestion.
>>
>>
>>
>>> >[Joe] Does the revision in 5167 match you implementation ( I don't
>>> think Jouni's comment changes the underly calculation, just its
>>> representation)?
>>>
>>>
>>>
>>> I have not implemented this portion of the RFC as I found it too unclear
>>> to work with. Thus I can’t comment on what implementations may be doing.
>>> However, I agree with the current revision in 5167 as the most natur

[Emu] Resolution of TEAP Errata 5767

2020-10-21 Thread Joseph Salowey
Errata 5767: https://www.rfc-editor.org/errata/eid5767
Status: Verified
Revision:

Section 3.3.1 says:

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

It should say:

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

Section 3.3.3 says:

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

It should say:

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

Section 3.8.3 says:

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

It should say:

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

Section 4.2.11 says:

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

It should say:

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

Section 4.2.13 says:

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

It should say:

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

Notes:

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

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

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

3.3.3: "after each successful EAP method" --> "after each successful EAP
authentication method"
3.8.3: "completion of the EAP method" --> "completion of the EAP
authentication method"
4.2.11: "between multiple inner EAP methods within EAP" --> "after each
inner EAP authentication method"
4.2.13: "after each successful EAP method" --> "after each successful EAP
authentication method"
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu


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

2020-10-21 Thread Joseph Salowey
(I accidentally dropped this list from the conversation)

On Wed, Oct 21, 2020 at 4:48 PM Jorge Vergara 
wrote:

> >[Joe] Yes this is a concern and I think your interpretation of the
> current document is also valid.  There may be more than one
> implementation.  So what you implemented was:
>
> >
>
> >IMCK[j] = TLS-PRF(S-IMCK[j-1], "Inner Methods Compound Keys", IMSK[j]) =
> P_(S-IMCK[j-1], "Inner Methods Compound Keys" | IMSK[j])
>
>
>
> Yes, this is what I implemented. As you mentioned, there are multiple
> possible interpretations of this since the TEAP usage is incorrect.
> However, my implementation does interop with at least 2 large vendor
> implementations. If the implementations were using different calculations
> here, the Wi-Fi/Ethernet connections that depend on the MSK would fail. But
> since connections work, I can assume we are all using the same
> implementation and arriving at the same MSK. Cisco is one of the
> implementations that I have tested against which is why I was hoping Oleg
> may offer more context as to what he has seen.
>
>
>
[Joe] I can hope Jouni can chime in on this as well.  I think the original
intent was to not include the length as is your suggestion.



> >[Joe] Does the revision in 5167 match you implementation ( I don't think
> Jouni's comment changes the underly calculation, just its representation)?
>
>
>
> I have not implemented this portion of the RFC as I found it too unclear
> to work with. Thus I can’t comment on what implementations may be doing.
> However, I agree with the current revision in 5167 as the most natural
> interpretation. If others have implemented this portion of the RFC then
> certainly their comments would be welcome.
>
>
> By the way, we’ve dropped the EMU group on our replies here – not sure if
> intentional or not.
>
>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Wednesday, October 21, 2020 4:36 PM
> *To:* Jorge Vergara 
> *Subject:* Re: Proposed resolution for TEAP errata for 5128
>
>
>
>
>
>
>
> On Wed, Oct 21, 2020 at 3:20 PM Jorge Vergara 
> wrote:
>
> In theory I agree this is a possible resolution. However, this doesn’t
> match any of the current TEAP implementations that I am aware of. Perhaps
> Oleg can weigh in as well in terms of what he’s seen.
>
>
>
> I believe all current implementations treat 60 as the desired output
> length without treating as a seed. In terms of P_, this means
> implementations are performing the calculation without a seed.
>
>
>
> RFC 5246 defines the TLS 1.2 PRF as:
>
> PRF(secret, label, seed) = P_(secret, label + seed)
>
>
>
> So the calculation implementations are currently performing with an empty
> seed ends up as:
>
> P_(secret, label)
>
>
>
> Note that in RFC 5295, the length *is* explicitly mentioned as being
> concatenated with the label
>
> USRK = KDF(EMSK, key label | "\0" | optional data | length)
>
>
>
> RFC 5295 is mentioned earlier in the TEAP RFC, in the section covered by
> errata 5127. *However* it is not mentioned in this portion of the RFC.
> Since this calculation is not on an EMSK, I do not believe RFC 2395 applies
> and this is likely why implementations went with the seedless
> P_(secret, label) calculation instead.
>
>
>
> Is there concern about updating the RFC in a way that breaks existing
> implementations?
>
>
>
> [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 <
&

  1   2   3   4   >