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

[Michael Richardson]

Joseph Salowey  wrote:
> 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.

I think that it should say, if you do OCSP, then you must staple.
But, the intro suggests that revocation checking is mandatory with TLS 1.3.
(I didn't double check if that's MUST, SHOULD, or what)

Since CRLs won't be fresh and can't be retrieved until online, then it seems
that OCSP is needed if one is going to revocation checking.

What I read in section 5.4 is that servers have to support OCSP stapling
requests.  I see a tiny bit of wiggle room as to whether the peer actually
must USE it :-)
Maybe that wiggle room can be made official for Hannes.

The document currently says: (1.0)

   Privacy is mandatory and achieved without any additional round-trips,
   revocation checking is mandatory and simplified with OCSP stapling,

and:

5.4.  Certificate Revocation

   This section updates Section 5.4 of [RFC5216].

   While certificates may have long validity periods, there are a number
   of reasons (e.g. key compromise, CA compromise, privilege withdrawn,
   etc.) why client, server, or sub-CA certificates have to be revoked
   before their expiry date.  Revocation of the EAP server's certificate
   is complicated by the fact that the EAP peer may not have Internet
   connectivity until authentication completes.

   EAP-TLS peers and servers supporting TLS 1.3 MUST support Certificate
   Status Requests (OCSP stapling) as specified in [RFC6066] and
   Section 4.4.2.1 of [RFC8446].  When EAP-TLS is used with TLS 1.3, the
   peer and server MUST use Certificate Status Requests [RFC6066] for
   the server's certificate chain and the EAP peer MUST treat a
   CertificateEntry (except the trust anchor) without a valid
   CertificateStatus extension as invalid and abort the handshake with
   an appropriate alert.  When EAP-TLS is used with TLS 1.3, the server
   MUST check the revocation status of the certificates in the client's
   certificate chain.

   The OCSP status handling in TLS 1.3 is different from earlier
   versions of TLS, see Section 4.4.2.1 of [RFC8446].  In TLS 1.3 the
   OCSP information is carried in the CertificateEntry containing the
   associated certificate instead of a separate CertificateStatus
   message as in [RFC4366].  This enables sending OCSP information for
   all certificates in the certificate chain.


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

> 
> Alternatives:

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

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






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

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

[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] draft-ietf-emu-eap-tls13-11: OCSP Stapling

[Michael Richardson]

Hannes Tschofenig  wrote:
> Thanks for the question. I am objecting to the mandatory use of OCSP for 
TLS 1.3 in EAP-TLS.
> I am fine with having it optional.

okay, so it's not about the stapling, at all for you, it's about the OCSP 
itself.

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






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

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

[Oleg Pekar]

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



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

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



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


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

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

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

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

[Jorge Vergara]

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

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

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

Jorge Vergara


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



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

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

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

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

[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 
mailto:j...@salowey.net>> wrote:


On Thu, Oct 22, 2020 at 6:59 AM Oleg Pekar 
mailto:oleg.pekar.2...@gmail.com>> wrote:
Hi all,
Speaking about both errata 5127 and 5128, I think we need to align all key 
derivation calls in TEAP RFC with 

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

[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, 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) =
>>> 

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

[Oleg Pekar]

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

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

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

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

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

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

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

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

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

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

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

[Eliot Lear]

+1.  How does anyone even do OCSP without having first gotten onto the network?

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

Re: [Emu] Resolution of TEAP Errata 5767

[Oleg Pekar]

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

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

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

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

> I agree with all the proposed resolutions. For context, there was some
> prior discussion of this errata here:
> https://mailarchive.ietf.org/arch/msg/emu/K_XWBMevKNdxdWskK8RkBt1ZpSQ/
>
>
>
> Jorge Vergara
>
>
>
> *From:* Joseph Salowey 
> *Sent:* Wednesday, October 21, 2020 5:13 PM
> *To:* EMU WG ; Jouni Malinen ; Jorge Vergara <
> jover...@microsoft.com>; Oleg Pekar 
> *Subject:* Resolution of TEAP Errata 5767
>
>
>
> Errata 5767: https://www.rfc-editor.org/errata/eid5767
> 
> 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" 

Re: [Emu] Proposed resolution for TEAP errata 5765

[Oleg Pekar]

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

Maybe we should keep it mandatory?



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

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

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

[Alan DeKok]

On Oct 22, 2020, at 10:12 AM, Jorge Vergara 
 wrote:
> 
> My concern with this proposal of defining a new KDF is that it is a clear 
> breaking change to any implementation that may exist.

  I am wary of breaking existing and deployed implementations.

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

  TBH, there isn't a lot of point.  We should just document what 
implementations do today.  Then, suggest that everyone move to TLS 1.3, and 
define entirely new derivations there.

  Alan DeKok.

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

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

[Jorge Vergara]

My concern with this proposal of defining a new KDF is that it is a clear 
breaking change to any implementation that may exist.

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

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

Jorge Vergara

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

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

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

Then:
IMSK = First 32 octets of TEAP-PRF(EMSK, 
"teapbind...@ietf.org", 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?

Oleg


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

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

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

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


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

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

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

Jorge Vergara

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



On Wed, Oct 21, 2020 at 3:20 PM Jorge Vergara 
mailto:jover...@microsoft.com>> wrote:
In theory I agree this is a possible resolution. However, this doesn’t match 
any of the current TEAP 

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

[Oleg Pekar]

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

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

Then:
IMSK = First 32 octets of TEAP-PRF(EMSK, "teapbind...@ietf.org", 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?

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

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

[Jan-Frederik Rieckers]

Hi to all,

as an operator of a EAP-TLS server for eduroam at the University Bremen
I just want to give some of my thoughts here, feel free to read or
ignore them ;)

The eduroam environment is heavily used for BYOD, so we don't have any
opportunity to change certificates via a Device Management.
Our clients are researchers, employees, students, ... so we can't (and
won't) control all devices logging in to our network.
We have to use either a private CA (which brings its own problems) or we
use a public trust anchor (e.g. T-Telesec with the DFN-Intermediate for
most German universities).
The deployment is done either manually by the users or with help of
tools like eduroam CAT (cat.eduroam.org).

I have done some research regarding the revocation of certificates in
EAP-TLS and have come to the conclusion that, if a private key gets
compromised, we have no possibility to effectively revoke the
certificate in a way the clients would notice.

This is the result of different problems:

* Clients don't support OCSP Stapling
The only client platform with default OCSP Stapling enabled in the
Client Hello (that I'm aware of) is currently Apple devices.

* Servers don't support OCSP Stapling
FreeRADIUS 3.0 does not support OCSP Stapling (but FreeRADIUS 4.0 will
have support for it)
This is probably the software mostly used for eduroam.

* Clients don't support the MustStaple Certificate extension
I don't have enough knowledge about TLSv1.3 yet, but for <=TLSv1.2 OCSP
won't add much security, since the OCSP Stapling is not mandatory.
I will look into TLSv1.3 and MustStaple in near future, maybe someone
can give me a hint if MustStaple is also active for TLSv1.3?

All in all, I definitely think that making OCSP Stapling optional will
have a benefit on small devices, but especially for the diverse
environment of eduroam, making OCSP Stapling mandatory will increase the
overall security of this federation.
Maybe it might be a good idea to make OCSP Stapling mandatory for
EAP-TLS Servers?

Greetings
Janfred



signature.asc
Description: OpenPGP digital signature
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

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

[Hannes Tschofenig]

Hi Michael,

Thanks for the question. I am objecting to the mandatory use of OCSP for TLS 
1.3 in EAP-TLS.
I am fine with having it optional.

Mbed TLS is used in implementations of EAP-TLS and we have received little 
interest in OCSP support. The interest is so low that the proposed code was 
never merged.

Companies seem to use an alternative approach instead, namely to change 
certificates via a device management solution. After all, you will have to 
offer a solution anyway. You cannot just reject access to your backend 
authentication infrastructure and do nothing.

Do other EAP methods rely on OCSP?

Ciao
Hannes

-Original Message-
From: Michael Richardson 
Sent: Wednesday, October 21, 2020 6:46 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: OCSP Stapling


Hannes Tschofenig  wrote:
> 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.

Is it:
   1) there is no need for mandatory certificate revocation checking
   2) there is no need to make OCSP checking the mandatory method for 
certificate revocation checking

Are you objecting to:
   a) mandatory certificate revocation checking
   b) mandatory OCSP
   c) mandatory OCSP *stapling* when using OCSP

I think, if you the client (who has no Internet yet), is going to be able to do 
certificate revocation checking, then doing it via OCSP stapling is the right 
way to go.  It can't do ONLINE CSP, because it has no Internet.

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

--
Michael Richardson. o O ( IPv6 IøT consulting )
   Sandelman Software Works Inc, Ottawa and Worldwide
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