Re: [Emu] New I-D: A new EAP method called EAP-FIDO

[Hannes Tschofenig]

Hi Jan,


you cannot complain about the use of TLS in EAP when the EAP method you
propose relies on TLS. The TLS-based authentication is an essential part
of the FIDO solution. Without TLS it is completely insecure.


Regarding the key extractor use you describe below: I don't remember
this technique being used by FIDO. I have worked in the FIDO Alliance in
the early days on U2F / UAF but might have missed some more recent
developments.


Regarding the benefit of FIDO: I don't think the "main benefit of using
FIDO is the ease of provisioning a credential to the supplicant". Once
you have an authenticated channel, it is trivial to provision new
credentials. There are hundreds of protocols that do that. IMHO the
benefit of FIDO is that you have an installed base of hardware tokens
that allow you to store these newly minted credentials.


On the security front I am wondering whether the introduction of this
use case weakens the use of FIDO for the web. In the web case, an
important aspect is to perform authentication and authorization of the
domain name with which the credentials are later utilized. For network
access authentication the domain authentication and authorization is, as
you have been mentioning in the draft and also in your emails, rather
weak. Have you looked into this aspect? Attacks that result from
cross-protocol use isn't uncommon.


Ciao

Hannes



Am 24.10.2023 um 12:22 schrieb Jan-Frederik Rieckers:

On 24.10.23 10:58, josh.howl...@gmail.com wrote:

It is good to see this work progressing.

1. I agree with Hannes' observation that it isn't necessary to
premise EAP-FIDO on the claimed weaknesses of other EAP methods.  I
suggest replacing paragraphs 2-5 with content summarising the
proposal. In particular I am surprised that the document doesn't
discuss (what I would consider to be) the main benefit of using FIDO:
the ease of provisioning a credential to the supplicant.


I must confess, the text is mainly driven by my bad experience from my
days as part of the eduroam administration team at the university of
Bremen, and my current experience with a change in the root
certificate for almost every eduroam IdP in Germany, because the
self-operated CA almost every institution used stopped issuing server
certificates and we are now migrating to a new CA provider.


The wording in the draft is a bit harsh, and I sincerely apologize to
everyone that felt offended by that wording, that wasn't my intention.
I'll adjust that for a future version of the draft.


There are several reasons to specify the EAP-TLS certificate
validation the way it is specified, and it works fine if the
configuration is pushed to the clients, i.e. by MDM mechanisms.
The spec leaves all degrees of freedom for server operators, and does
not have any external dependencies, which is great for managed devices.

But the moment you enter the BYOD world, users will get it wrong and
there is no default way that is secure. Admins need to publish the
information about CA and Server Name and need to rely on the user's
ability to configure this correctly. And server operators have no way
of verifying the configuration on client devices, unless they operate
a rogue AP and log which users log in there, to give them a slap on
the wrist.

And the reason that Android for a long time hat "Do not validate" as a
default setting for EAP-TTLS/EAP-PEAP is a symptom of the problem
here: It is much more easy to just disable the security checks than it
is to configure them correctly.


2. I am not persuaded by the two arguments given in section 6.3 for
not reusing existing tunnelled methods.


I'm open to discuss this with an open mind, the first draft is just
the way that I imagined it, if there are reasons to do it another way,
I'm not set on the current spec.


* Misconfiguration of server certificate validation parameters:
perhaps I am missing something, but in terms of the UI can't this be
solved by disabling the parameter options/fields if the EAP-FIDO
inner method is selected?


Definitely this could be done. Maybe I'm just too pessimistic here to
expect that UIs will get it wrong.


* Export of TLS material: I thought this TLS material is often
required by phase 2 of other tunnelled methods? E.g. for validating
cryptobindings.


I don't know exactly what you mean by that?
The current spec uses exported TLS material to generate the FIDO
challenge, so the FIDO-Auth is bound to the TLS tunnel.
One question would be if we can achieve the opoosite, that is: binding
the exported MSPPE-Keys to the FIDO auth too, not just the TLS tunnel.



I think there is an argument that defining EAP-FIDO as a method that
could be used within PEAP, TTLS and TEAP could drive adoption.

3. I have unsure about tying this specification so tightly to the
WebPKI. There is a tremendous convenience in using the WebPKI for
validating the server certificate, but the WebPKI is not a
well-defined concept. In practice, it is the bucket of CAs that my OS
vendor preinstalls 

Re: [Emu] draft-ietf-ace-wg-coap-eap

[Hannes Tschofenig]

Thanks for the pointer to the appendix.


If I understand the write-up correctly, then you are defining a new
version of PANA. The main difference is that PANA uses UDP to carry EAP
and this document uses CoAP over UDP to carry EAP.


Do I understand the use cases correctly?


Ciao
Hannes


Am 16.10.2023 um 11:37 schrieb Dan Garcia Carrillo:

Hi Hannes,

Thank you for your time to review the document.

Regarding your question, in the annex there are different use cases
about the usage of CoAP-EAP.

If you think there is some additional use case that should be
considered, please, let us know.

Best Regards.



El 13/10/23 a las 10:27, Hannes Tschofenig escribió:

Hi all,


I have read through  and was wondering what
use case motivated the work on EAP over CoAP.


Where is it planned to be used?


Ciao
Hannes


___
Emu mailing list
Emu@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/emu__;!!D9dNQwwGXtA!SDp1CT246dHVgSOcyJXTHJUhaEJclytG6kz6jKqO0J3iSG66HzTTcPeHvUhmIAYd6eanoezHBOdULk0cYE3YhKbjeval$





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

Re: [Emu] Network Access Authentication and Attestation

[Hannes Tschofenig]

Thanks, Josh.


There was some prior work done on this in the IETF and also in other
organizations (e.g. TCG). It may have been ahead of its time and many
years have passed since.


Ciao

Hannes


Am 13.10.2023 um 11:02 schrieb josh.howl...@gmail.com:

The Network Endpoint Assessment (NEA) Working Group worked on this problem:
https://datatracker.ietf.org/wg/nea/about/

Josh


-Original Message-
From: Emu  On Behalf Of Hannes Tschofenig
Sent: Friday, October 13, 2023 9:16 AM
To: emu@ietf.org
Subject: [Emu] Network Access Authentication and Attestation

Hi all,

in the AD review of the SUIT MUD draft, see
https://datatracker.ietf.org/doc/draft-ietf-suit-mud/ and
https://mailarchive.ietf.org/arch/msg/suit/xRT55NR6fAQuuSYmApXAdC-
zO8U/,
Roman noted that we are assuming that an EAT-based attestation mechanism
is available for network access authentication protocols.

While there has been talk about adding attestation to EAP methods, I am

not

aware of any work specifically in the EMU group.

Coincidently, we are working on a solution for adding attestation to TLS,

see

https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/, where we
define an extension that can be added on a need-by-need basis. It could

also

be incorporated into TLS-based EAP methods.

Has someone in the group considered the use of attestation for network
access and as part of TLS-based EAP methods in particular?

The use case is described in Section 2.1 of RFC 9334, see
https://datatracker.ietf.org/doc/html/rfc9334#name-network-endpoint-
assessment
The main benefit is there described as follows: "Remote attestation is

desired

to prevent vulnerable or compromised devices from getting access to the
network and potentially harming others."

We are happy to give a presentation or show our prototype at the

hackathon.

Ciao
Hannes

___
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] draft-ietf-ace-wg-coap-eap

[Hannes Tschofenig]

Hi all,


I have read through  and was wondering what
use case motivated the work on EAP over CoAP.


Where is it planned to be used?


Ciao
Hannes


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

[Emu] Network Access Authentication and Attestation

[Hannes Tschofenig]

Hi all,

in the AD review of the SUIT MUD draft, see
https://datatracker.ietf.org/doc/draft-ietf-suit-mud/ and
https://mailarchive.ietf.org/arch/msg/suit/xRT55NR6fAQuuSYmApXAdC-zO8U/,
Roman noted that we are assuming that an EAT-based attestation mechanism
is available for network access authentication protocols.

While there has been talk about adding attestation to EAP methods, I am
not aware of any work specifically in the EMU group.

Coincidently, we are working on a solution for adding attestation to
TLS, see
https://datatracker.ietf.org/doc/draft-fossati-tls-attestation/, where
we define an extension that can be added on a need-by-need basis. It
could also be incorporated into TLS-based EAP methods.

Has someone in the group considered the use of attestation for network
access and as part of TLS-based EAP methods in particular?

The use case is described in Section 2.1 of RFC 9334, see
https://datatracker.ietf.org/doc/html/rfc9334#name-network-endpoint-assessment
The main benefit is there described as follows: "Remote attestation is
desired to prevent vulnerable or compromised devices from getting access
to the network and potentially harming others."

We are happy to give a presentation or show our prototype at the hackathon.

Ciao
Hannes

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

Re: [Emu] draft-ietf-emu-bootstrapped-tls

[Hannes Tschofenig]

ed key with every hash
   algorithm that it uses in TLS and use that to quickly lookup the
   bootstrap key and generate the PSK.  Servers that choose not to
   employ this optimization will have to do a runtime check with every
   bootstrap key it holds against the identity the client provides.
"

TO:

"
3.  Bootstrapping in TLS 1.3

   TLS-POK leverages RFC 8773, which allows a server to authenticate
   with a combination of a certificate and an external pre-shared key.
   The external pre-shared key is imported using the PSK importer
   interface defined in RFC 9258 [RFC9258].

   The RFC 9258-defined PSK importer interface takes three inputs:

   - a so-called base key EPSK,
   - an External Identity (external_identity), and
   - an optional context.

   This specification does not use the context. The base key External
   PSK (EPSK) and the External Identity (external_identity) used by
   the RFC 9258-defined PSK importer interface are derived from the
   BSK public key, as described in Section 3.1.

   The BSK MUST be from a cryptosystem suitable for doing
   ECDSA.  As the BSK is an ASN.1 SEQUENCE SubjectPublicKeyInfo, the
   client presents this raw public key to the server, as specified in
   [RFC7250].

   The TLS PSK handshake gives the client proof that the server knows
   the BSK public key.  Certificate based authentication of the client
   to the server gives the server proof that the client knows the BSK
   private key.  This satisfies the proof of ownership requirements
   outlined in Section 1.

3.1.  Pre-Computation

   The following derivation steps are performed prior to the use of
   the PSK importer interface defined in [RFC9258]. As a result,
   a new base key EPSK (referred as epsk below) and a new external
   identity (epskid) are derived.

   The HKDF key derivation functions are defined in [RFC5869]
   and utilize the hash algorithm from the ciphersuite:

   epsk   = HKDF-Expand(HKDF-Extract(<>, BSK public key),
  "tls13-imported-bsk", L)
   epskid = HKDF-Expand(HKDF-Extract(<>, BSK public key),
  "tls13-bspsk-identity", L)
   where:
 - epsk is the EPSK Base Key later used with RFC 9258
 - epskid is the EPSK External Identity later used with RFC 9258
 - <> is a NULL salt
 - BSK public key is the DER-encoded ASN.1 subjectPublicKeyInfo
   representation of the BSK public key
 - L is the length of the digest of the underlying hash
   algorithm

   A performance versus storage tradeoff a server can choose is to
   precompute the identity of every bootstrapped key with every hash
   algorithm that it uses in TLS and use that to quickly lookup the
   bootstrap key and generate the PSK.  Servers that choose not to
   employ this optimization will have to do a runtime check with every
   bootstrap key it holds against the identity the client provides.
"


Let me know what you think.


Ciao
Hannes

Am 22.03.2023 um 20:12 schrieb Dan Harkins:


  Hi Hannes,

  Sorry for the delay in responding

On 3/4/23 9:31 AM, Hannes Tschofenig wrote:

Hi Owen, Hi Dan,

[snip]

Here is what I have expected to see in the draft given that RFC 9258
already defines the derivation of the epskx and the ipskx provided a few
inputs. Here is what the RFC says:


   epskx = HKDF-Extract(0, epsk)
   ipskx = HKDF-Expand-Label(epskx, "derived psk",
 Hash(ImportedIdentity), L)


  Yes, that takes the epsk and hashes it with the usage-specific
goo to create a binary blob with its entropy uniformly distributed
across a fixed number of bits.



IMHO you only need to define

(a) what the base epsk is, and

(b) how to populate the ImportedIdentity structure.


Regarding (a): You seem to be setting the base epsk (for the
HKDF-Extract function above) to the DER-encoded ASN.1
subjectPublicKeyInfo representation of the BSK public key (which is
externally provided, for example by scanning a QR code).

L is 32 since you seem to be mandating the use of HKDF-SHA256 as the
KDF.


  Yes, you're right. the espk can just be the DER-encoded
ASN.1 subjectPublicKeyInfo representation of the bootstrapping
key-- i.e. bskey.


Regarding (b): RFC 9258 defines the ImportedIdentity structure as:


struct {
   opaque external_identity<1...2^16-1>;
   opaque context<0..2^16-1>;
   uint16 target_protocol;
   uint16 target_kdf;
} ImportedIdentity;


You populate the ImportedIdentity structure based on the description in
Section 3.1 as follows:


- external_identity = epskid (which seems to be again the DER-encoded
ASN.1 subjectPublicKeyInfo representation of the BSK public key)
- context = "tls13-bsk"
- target_protocol = TLS1.3(0x0304)
- target_kdf = HKDF_SHA256(0x0001)


  That would not work for the security model we're using which is based
on the Resurrecting Duckling [1]. It is assumed that a server who has
knowledge of the client's bskey is the legit

[Emu] draft-ietf-emu-bootstrapped-tls

[Hannes Tschofenig]

Hi Owen, Hi Dan,


Thanks for the recent -02 draft update, which addresses a few of my
remarks in my review
https://mailarchive.ietf.org/arch/msg/emu/VNCAFb4BTTOib27s1gIXUOEn_ng/


My question about the relationship with RFC 9258 was not answered and
hence I am giving it another try.


Here is what I have expected to see in the draft given that RFC 9258
already defines the derivation of the epskx and the ipskx provided a few
inputs. Here is what the RFC says:


   epskx = HKDF-Extract(0, epsk)
   ipskx = HKDF-Expand-Label(epskx, "derived psk",
 Hash(ImportedIdentity), L)


IMHO you only need to define

(a) what the base epsk is, and

(b) how to populate the ImportedIdentity structure.


Regarding (a): You seem to be setting the base epsk (for the
HKDF-Extract function above) to the DER-encoded ASN.1
subjectPublicKeyInfo representation of the BSK public key (which is
externally provided, for example by scanning a QR code).

L is 32 since you seem to be mandating the use of HKDF-SHA256 as the KDF.

Regarding (b): RFC 9258 defines the ImportedIdentity structure as:


struct {
   opaque external_identity<1...2^16-1>;
   opaque context<0..2^16-1>;
   uint16 target_protocol;
   uint16 target_kdf;
} ImportedIdentity;


You populate the ImportedIdentity structure based on the description in
Section 3.1 as follows:


- external_identity = epskid (which seems to be again the DER-encoded
ASN.1 subjectPublicKeyInfo representation of the BSK public key)
- context = "tls13-bsk"
- target_protocol = TLS1.3(0x0304)
- target_kdf = HKDF_SHA256(0x0001)


With this approach the text at the beginning of Section 3.1 is not needed.


Tell me if I misreading the document and you are in fact adding another
layer of key derivation to produce the base epsk. If that's the case,
you might want to say why you are doing this.


Ciao

Hannes


PS: RFC 9258 also says that the ImportedIdentity.context MUST include a
channel binding. This appears to be missing. If you think it is
unnecessary, it might be worthwhile to state it.

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

Re: [Emu] Call for EMU agenda items for IETF 116

[Hannes Tschofenig]

Thanks for sharing the link to the OpenSSL implementation, Heikki.


FWIW there is another EMU draft that also relies on RFC 7250 support ->
draft-ietf-emu-bootstrapped-tls


Ciao

Hannes


Am 03.03.2023 um 10:16 schrieb Heikki Vatiainen:

On Thu, 2 Mar 2023 at 03:34, Meiling Chen
 wrote:

I noticed that Openssl 3.2 support for RFC7250 is being discussed.
Has it been supported now?


It seems OpenSSL 3.1 is going to be released later this month. Based
on the pull request related to the Raw Public Key support issue, it
still seems to be target for release 3.2 with plenty of current activity:
https://github.com/openssl/openssl/pull/18185

Related to implementations; for me OpenSSL support would be required
for an implementation. While this seems to be progressing, a client
implementation would be needed for testing since I work on the EAP
server side. Is there any news on the client side? For example, would
wpa_supplicant be a possible client? The IOT use case might be
something where a client could be based on wpa_supplicant.

Thanks,
Heikki

Best,
Meiling

*From:* Alexander Clouter 
*Date:* 2023-03-01 14:12
*To:* EMU WG 
*Subject:* Re: [Emu] Call for EMU agenda items for IETF 116
On Wed, 1 Mar 2023, at 01:44, Meiling Chen wrote:

I would like to discuss EAP-TLS-IBS this time, Since last
adoption process, we are still waiting for more people to be
interested.


I thought the hold up was OpenSSL does not support RFC7250
without patching?

https://github.com/openssl/openssl/issues/6929

This makes building and playing with an implementation difficult.

Get this solved and I suspect there will be a lot more active
interest.

Just my thoughts.

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



--
Heikki Vatiainen
h...@radiatorsoftware.com

___
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] draft-ietf-emu-bootstrapped-tls-01: Question about alignment with RFC 9258

[Hannes Tschofenig]

Hi all,

I have a question about the alignment between the text in Section 3.1 of 
draft-ietf-emu-bootstrapped-tls-01 and RFC 9258.

RFC 9258 describes how to import external PSKs for use with TLS 1.3.
It does so by defining a function with three inputs, namely an external 
identity, an EPSK, and an optional context. The output is then a derived epsk 
and an imported psk (ipsk). The identity of the ipsk is the serialized 
ImportedIdentity structure.
Section 5.1 of RFC 9258 defines the functions as follows:



   epskx = HKDF-Extract(0, epsk)

   ipskx = HKDF-Expand-Label(epskx, "derived psk",

 Hash(ImportedIdentity), L)

The epsk in RFC 9258 is defined as the a tuple of (Base Key, External Identity, 
Hash). I assume that the epsk parameter, which is input to the HKDF-Extract, is 
the private key.

Now, coming to draft-ietf-emu-bootstrapped-tls-01.

Here the derivations are defined as follows:

   epsk   = HKDF-Expand(HKDF-Extract(<>, bskey),
  "tls13-imported-bsk", L)
   epskid = HKDF-Expand(HKDF-Extract(<>, bskey),
  "tls13-bspsk-identity", L)
   where:
 - epsk is the EPSK Base Key
 - epskid is the EPSK External Identity
 - <> is a NULL salt
 - bskey is the DER-encoded ASN.1 subjectPublicKeyInfo
   representation of the BSK public key
 - L is the length of the digest of the underlying hash
   algorithm

Since the functions are different I am wondering whether the idea is to create 
another derivation before applying those inputs to the RFC 9258-defined 
functions. Is this the idea?

Ciao
Hannes

PS: I noticed that in an earlier IETF presentation a point to a Github repo was 
provided. I looked at that code, which has now been reverted, and it did not 
match the content of the draft. Is there an implementation of this draft 
available somewhere?

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] draft-ietf-emu-bootstrapped-tls

[Hannes Tschofenig]

Thanks, Owen.

-Original Message-
From: Owen Friel (ofriel) 
Sent: Friday, December 16, 2022 12:31 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: RE: draft-ietf-emu-bootstrapped-tls

Thanks Hannes. These all make sense and are now all addressed in github and I 
will include in draft-02

And yes, the intention is that DPP is recommended for Wi-Fi as it also 
addresses the Wi-Fi SSID discovery problem. TLK-POK is recommended for wired. I 
have clarified this in the introduction.


-Original Message-
From: Emu  On Behalf Of Hannes Tschofenig
Sent: Tuesday 13 December 2022 10:14
To: emu@ietf.org
Subject: [Emu] draft-ietf-emu-bootstrapped-tls

Hi all,

I have a simple question regarding draft-ietf-emu-bootstrapped-tls-01

Do you see the scope of this specification limited to the use for wired network 
access? In Section 2.1 you describe the story as "use DPP if the device 
bootstraps against a Wi-Fi network, or TLS-POK if the device bootstraps against 
a wired network."

If that's the goal, I think it would be useful to move this text from Section 
2.1 into the introduction.

I was also wondering whether it would be better to change the title of the 
document from "Bootstrapped TLS Authentication" to something like "Bootstrapped 
TLS Authentication with Proof of Knowledge (TLS-POK)".

Minor remarks:

There is a reference to RFC 9528, which is marked as a broken reference. Most 
likely a typo and you mean RFC 9258 instead.

You say: "Device on-boarding protocols such as the Device Provisioning Profile 
[DPP], also referred to as Wi-Fi Easy Connect, address this use case but they 
have drawbacks." Then, you only mention one drawback. Maybe you want to mention 
other drawbacks.

The terminology section should contain the RFC 2119 boilerplate text.

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
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] draft-ietf-emu-bootstrapped-tls

[Hannes Tschofenig]

Hi all,

I have a simple question regarding draft-ietf-emu-bootstrapped-tls-01

Do you see the scope of this specification limited to the use for wired network 
access? In Section 2.1 you describe the story as "use DPP if the device 
bootstraps against a Wi-Fi network, or TLS-POK if the device bootstraps against 
a wired network."

If that's the goal, I think it would be useful to move this text from Section 
2.1 into the introduction.

I was also wondering whether it would be better to change the title of the 
document from "Bootstrapped TLS Authentication" to something like "Bootstrapped 
TLS Authentication with Proof of Knowledge (TLS-POK)".

Minor remarks:

There is a reference to RFC 9528, which is marked as a broken reference. Most 
likely a typo and you mean RFC 9258 instead.

You say: "Device on-boarding protocols such as the Device Provisioning Profile 
[DPP], also referred to as Wi-Fi Easy Connect, address this use case but they 
have drawbacks." Then, you only mention one drawback. Maybe you want to mention 
other drawbacks.

The terminology section should contain the RFC 2119 boilerplate text.

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

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

[Hannes Tschofenig]

Hi Meiling,

Maybe it would be useful to start working on a prototype implementation since 
this could give useful insight into the specification work.

Ciao
Hannes

From: Emu  On Behalf Of Meiling Chen
Sent: Thursday, May 5, 2022 5:15 AM
To: Joseph Salowey ; emu 
Subject: Re: [Emu] Call for Adaption for draft-chen-emu-eap-tls-ibs

Hi folks,
Thank you all for help!
Although the adoption was not success this time, all your suggestions have also 
been received which is very helpful to our draft.
I will continue to improve the draft and try to apply it in practice until it 
is perfect enough to become a working group item.

Best,
Meiling
From: Joseph Salowey
Date: 2022-05-04 11:10
To: EMU WG
Subject: Re: [Emu] Call for Adaption for draft-chen-emu-eap-tls-ibs
The chairs have reviewed the responses to the adoption call and they do not see 
enough interest from the working group to adopt this draft. Only a few active 
working group participants indicated they would review the draft.  The authors 
may take this draft to the independent submission process to get a draft 
published and codepoints assigned.

Thanks,

Joe and Mohit

On Sun, Apr 10, 2022 at 8:35 PM Joseph Salowey 
mailto:j...@salowey.net>> wrote:
This is an adoption call for EAP-IBS 
(https://datatracker.ietf.org/doc/draft-chen-emu-eap-tls-ibs/)
 as an EMU working group item.  Please respond to this call and answer the 
following questions by April 24, 2022:

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

2. Would you contribute by reviewing this document?
3. Would you contribute text to this document?

Thanks,

The Chairs
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] Call for Adaption for draft-chen-emu-eap-tls-ibs

[Hannes Tschofenig]

Like Russ, I am happy to review the draft and contribute suggestions.

Regarding: Do you think this draft should be an EMU working group Item?
I also do not object.

From: Emu  On Behalf Of Russ Housley
Sent: Wednesday, April 13, 2022 2:52 PM
To: Joe Salowey ; emu 
Subject: Re: [Emu] Call for Adaption for draft-chen-emu-eap-tls-ibs

1.  Not sure.  I do not object, but I am not sure how many people want to 
implement.

2.  I will review the ASN.1.  In fact, I already did so.

3.  I contributed corrections to the ASN.1.

Russ

From: Joseph Salowey
Date: 2022-04-11 11:35
To: EMU WG
Subject: [Emu] Call for Adaption for draft-chen-emu-eap-tls-ibs
This is an adoption call for EAP-IBS 
(https://datatracker.ietf.org/doc/draft-chen-emu-eap-tls-ibs/)
 as an EMU working group item.  Please respond to this call and answer the 
following questions by April 24, 2022:

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

2. Would you contribute by reviewing this document?
3. Would you contribute text to this document?

Thanks,

The Chairs

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] Working Group Last Call for TLS-based EAP types and TLS 1.3

[Hannes Tschofenig]

Maybe it is a terminology issue but TLS at least requires server-authentication.

From: Emu  On Behalf Of Heikki Vatiainen
Sent: Monday, March 7, 2022 2:41 PM
To: Alan DeKok 
Cc: EMU WG 
Subject: Re: [Emu] Working Group Last Call for TLS-based EAP types and TLS 1.3

On Fri, 4 Mar 2022 at 21:44, Alan DeKok 
mailto:al...@deployingradius.com>> wrote:

  I would argue that EAP-TTLS with only a client certificate doesn't make 
sense.  I'm not sure why it's in RFC 5281.  If you want to only use a client 
certificate, you should just use EAP-TLS.

  I suggest for this document that we just forbid the case of using only a 
client certificate with TTLS.

No objection from me - and it now appears to be in draft version -05. While 
there may have been client software that supported this, I have not seen any 
recent clients that support this. The only reason I mentioned this RFC 5281 
feature is that it's mentioned in the RFC, not that I have seen it used.

I noticed there's also a similar new paragraph in draft -05 for PEAP. This is a 
good and symmetrical clarification which I see being compatible with [MS-PEAP]. 
The document Microsoft maintains says very little about client certificates, 
basically just allowing them to be requested by the server. I don't see 
anything that changes the use of inner tunnel authentication by the use of them 
and now the draft confirms this.

Thanks,
Heikki
--
Heikki Vatiainen
h...@radiatorsoftware.com
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] I-D Action: draft-ietf-emu-eap-tls13-12.txt

[Hannes Tschofenig]

Hi Mohit,

I am not quite sure how the process for Github issues works in this group. It 
seems that you create the issues based on reviews, then you address them 
yourself in the draft and you then close the issue yourself.
Is this how it works?

Ciao
Hannes


-Original Message-
From: Emu  On Behalf Of Mohit Sethi M
Sent: Monday, November 9, 2020 2:08 PM
To: emu@ietf.org
Subject: Re: [Emu] I-D Action: draft-ietf-emu-eap-tls13-12.txt

Dear all,

We had submitted a new version before the deadline. This version should address 
most of the comments received during the last call. Here is the diff for your 
convenience:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-12.

In particular:

- we have removed some of text in the section on HRR and preventing 
fragmentation that was repeated from RFC8446 and
draft-ietf-emu-eaptlscert:
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/15

- we have tried to make the usage of EAP-TLS peer vs. EAP peer vs.
EAP-TLS client more consistent. Note that RFC5216 had used a mixture of these 
terms interchangeably. The terminology section now also says "The term EAP-TLS 
peer is used for the entity acting as EAP peer and TLS client.  The term 
EAP-TLS server is used for the entity acting as EAP server and TLS server.".

- we have now clarified the discrepancy between the "Commitment Message"
sending one byte of encrypted application data vs. the statement "EAP-TLS does 
not protect any application data" in Section 2.4.

- we have updated the text on revocation checking based on the recent 
discussion.

Let us know if there are some issues that still need to be addressed.

John and Mohit

On 11/3/20 12:26 AM, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the EAP Method Update WG of the IETF.
>
>  Title   : Using EAP-TLS with TLS 1.3
>  Authors : John Preuß Mattsson
>Mohit Sethi
> Filename: draft-ietf-emu-eap-tls13-12.txt
> Pages   : 30
> Date: 2020-11-02
>
> Abstract:
> This document specifies the use of EAP-TLS with TLS 1.3 while
> remaining backwards compatible with existing implementations of EAP-
> TLS.  TLS 1.3 provides significantly improved security, privacy, and
> reduced latency when compared to earlier versions of TLS.  EAP-TLS
> with TLS 1.3 further improves security and privacy by mandating use
> of privacy and revocation checking.  This document also provides
> guidance on authorization and resumption for EAP-TLS in general
> (regardless of the underlying TLS version used).  This document
> updates RFC 5216.
>
>
> 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-12
> https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-tls13-12
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eap-tls13-12
>
>
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at 
> tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
>
> ___
> 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] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Hannes Tschofenig]

FWIW there is a public Mbed TLS virtual workshop tomorrow (see 
https://www.trustedfirmware.org/meetings/mbed-tls-workshop/).
Those who care about any of these security features could join, and ask for the 
support of x, y and z.

Ciao
Hannes

From: Mohit Sethi M 
Sent: Monday, November 2, 2020 12:36 PM
To: Hannes Tschofenig ; Mohit Sethi M 
; Mohit Sethi M 
; emu@ietf.org
Subject: Re: [Emu] Making Security Practical ... was RE: Moving towards less 
security in 2020 - OCSP


Hi Hannes,
On 11/2/20 11:42 AM, Hannes Tschofenig wrote:
Hi Mohit,


> Et voilà, we seem to be moving towards a consensus!

That’s indeed exciting.



> PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its 
> high time.

Looking forward to it. I would then add the other pieces to TLS 1.3 to make it 
complete.



>  There have been several requests for this already for a few years: 
> https://github.com/ARMmbed/mbedtls/issues/880
3 questions about a feature in 5 years. For an open source project like Mbed 
TLS this is close to “zero interest”.

You are probably right here. This is the unfortunate reality for many open 
source projects. While writing some code with openssl, I (and others) had 
requested a feature to export x25519 public keys: 
https://github.com/openssl/openssl/pull/5520#issuecomment-391088904. Not sure 
how far that has come along.

--Mohit



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<mailto: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] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

[Hannes Tschofenig]

Thanks, Mohit, for the quick turn-over.

From: Mohit Sethi M 
Sent: Monday, November 2, 2020 12:21 PM
To: Hannes Tschofenig ; Mohit Sethi M 
; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


Done as suggested:

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/8e158b5dc06ab5efd06c130ceffefe8c0cdff8e0

--Mohit
On 11/2/20 11:16 AM, Hannes Tschofenig wrote:
Thanks, Mohit.

You could also delete the entire paragraph because it adds nothing to what is 
already said in the TLS 1.3 spec.
See https://github.com/hannestschofenig/draft-ietf-emu-eap-tls13/pull/1

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Monday, November 2, 2020 9:58 AM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


I now understand your issue with the sentence "An EAP-TLS peer and server 
SHOULD support the use of HelloRetryRequest message.". I guess there is no need 
for it, i.e., the section would be just fine without that sentence:
TLS 1.3 [RFC8446] defines that TLS servers can send a HelloRetryRequest message 
in response to a ClientHello if the server finds an acceptable set of 
parameters but the initial ClientHello does not contain all the needed 
information to continue the handshake.  One use case is if the server does not 
support the groups in the "key_share" extension, but supports one of the groups 
in the "supported_groups" extension.  In this case the client should send a new 
ClientHello with a "key_share" that the server supports.

As noted in Section 4.1.4 of [RFC8446], the server MUST provide the 
supported_versions extensions and SHOULD contain the minimal set of extensions 
necessary for the client to generate a correct ClientHello pair.  A 
HelloRetryRequest MUST NOT contain any extensions that were not first offered 
by the client in  its ClientHello, with the exception of optionally including 
the cookie extension.

The case of a successful EAP-TLS mutual authentication after the server has 
sent a HelloRetryRequest message is shown in Figure 8. Note the extra 
round-trip as a result of the HelloRetryRequest.

Commit on git: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d4ac353a90dc7466d6da9deb5f50f4eb7c585e9b

--Mohit
On 11/2/20 9:39 AM, Hannes Tschofenig wrote:
Hi Mohit,

I read Jim's email and he is not saying that you should make it an optional to 
support feature.

The issue is:

- are you trying to change the functionality of TLS 1.3 with this draft, and
- is there a good reason to do so?

In this case, the "SHOULD" statement gives an implementer absolutely not idea 
when or when it would be good to implement this feature.
Besides this, I don't even believe that the TLS 1.3 spec gives you that freedom 
for this specific feature anyway.

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

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



___

Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Hannes Tschofenig]

I agree with you, Eliot.

I don’t understand for what certificates we would be using OCSP in the EAP-TLS 
context, and what would happen if OCSP checks fail.

Ciao
Hannes

From: Eliot Lear 
Sent: Monday, November 2, 2020 12:27 PM
To: Hannes Tschofenig 
Cc: Mohit Sethi M ; emu@ietf.org
Subject: Re: [Emu] Making Security Practical ... was RE: Moving towards less 
security in 2020 - OCSP

Hi Hannes,

My concern is not about implementation.  At least for the sake of discussion, 
let us assume that we can get the code to where it needs to be.  The question 
is more about what happens when an OCSP server is unavailable, either to the 
client or to the server (stapled or otherwise).  What is expected of server 
behavior in such a case, and what is expected of client behavior?

Consider the scenario when you have the CA sitting off somewhere in the 
distance, and a power failure or other service interruption has occurred.  
Should the client refuse to come up because stapling didn’t happen?  Should old 
stapling information be retained, and what does that mean in the context of the 
nonce extension?  I had thought we said that this risk is mitigated by the 
choice of the deployment to include the OCSP extension information in the cert- 
or not.  At that point the deployment can make the decision.

Are we now saying otherwise?

Eliot

On 2 Nov 2020, at 09:08, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:

Hi Mohit,


  *   I think it is a reasonable compromise for servers to implement OCSP 
stapling. Clients can implement and use it, but they would be compliant even if 
they don't. So the updated text would be (as Joe wrote in his email):
“
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.
“

This sounds like a good compromise for me.

Ciao
Hannes

PS: Mohit, maybe you can help implement OCSP to EAP-TLS in Mbed TLS. I am 
looking forward to see OCSP supported added to EDHOC by John.

From: Emu mailto:emu-boun...@ietf.org>> On Behalf Of 
Mohit Sethi M
Sent: Saturday, October 31, 2020 2:15 PM
To: emu@ietf.org<mailto:emu@ietf.org>
Subject: [Emu] Moving towards less security in 2020 - OCSP

Dear all,
Sorry for the radio silence. I have over-committed myself to too many things. I 
think I have now read the entire discussion on OCSP.
EAP-TLS with TLS 1.3 is a working group document so the text will reflect 
whatever the working group wants. The authors and contributors are at the 
service of the working group. Obviously it is easy for us to simply change all 
MUSTs to MAYs, make everyone happy, and hand over the document to the IESG.
Yet, I think as a conscientious security person and individual contributor, I 
am saddened by the discussion thus far. To begin with, I assume that everyone 
knows the difference between OCSP and OCSP stapling. I also hope that everyone 
has read RFC 5216 (the previous EAP-TLS specification). In particular I hope 
that the working group has actually read section 5.4 on "Certificate 
Revocation" (https://tools.ietf.org/html/rfc5216#section-5.4). I copy the 
relevant text here for your convenience:

   EAP-TLS peer and server implementations MUST support the use of

   Certificate Revocation Lists (CRLs); for details, see Section 3.3 
of<https://tools.ietf.org/html/rfc3280#section-3.3>

   [RFC3280]<https://tools.ietf.org/html/rfc3280#section-3.3>.  EAP-TLS peer 
and server implementations SHOULD also

   support the Online Certificate Status Protocol (OCSP), described in

   "X.509 Internet Public Key Infrastructure Online Certificate Status

   Protocol - OCSP" [RFC2560<https://tools.ietf.org/html/rfc2560>].  OCSP 
messages are typically much smaller

   than CRLs, which can shorten connection times especially in

   bandwidth-constrained environments.
and

   For this reason, EAP-TLS peers and servers SHOULD implement

   Certificate Status Request messages, as described in "Transport Layer

   Security (TLS) Extensions", Section 3.6 of 
[RFC4366]<https://tools.ietf.org/html/rfc4366#section-3.6>.  To enable

   revocation checking in situations where servers do not support

   Certificate Status Request messages and network connectivity is not

   available prior to authentication completion, peer implementations

   MUST also support checking for certificate revocation after

   authentication completes and network connectiv

Re: [Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Hannes Tschofenig]

Hi Mohit,


> Et voilà, we seem to be moving towards a consensus!

That’s indeed exciting.



> PS: I would certainly like to help with getting OCSP in mbed TLS. I guess its 
> high time.

Looking forward to it. I would then add the other pieces to TLS 1.3 to make it 
complete.



>  There have been several requests for this already for a few years: 
> https://github.com/ARMmbed/mbedtls/issues/880
3 questions about a feature in 5 years. For an open source project like Mbed 
TLS this is close to “zero interest”.



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

Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

[Hannes Tschofenig]

Hi Mohit,

I have now read the email from Terry and he is not suggesting the original 
text. He is, in fact, correcting misleading text in your draft.

IMHO the entire text in Section 5.7 reads a bit like you are giving 
implementation guidance. That would be great if John or you had written such 
code. I don't know whether you have.
You are given the reader the impression that there is a problem with session 
resumption. I don't believe there is a problem and I gave you reasons in my 
email.

On the second topic. Here is my remark about the wrong reference and my 
suggestion to address it:

Section 5.10 says:
"
EAP-TLS implementations
   SHOULD mitigate known attacks and follow the recommendations in
   [RFC7525] and [I-D.ietf-tls-oldversions-deprecate].
"

Interestingly, RFC 7525 does not talk about EAP (and instead focuses on 
applications like  HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the 
abstract). RFC 7525, for example, does not mandate OCSP. It also recommends 
RSA, which draft-ietf-emu-eaptlscert and this draft does not do. There seems to 
be contradiction here.

At a minimum, I would clarify in the introduction what the updates to RFC 5216 
are. This will help those implementers that focus on a variant of EAP-TLS that 
uses version 1.2. As mentioned above, I don't believe Sections 5.6 and 5.7 
belong to this document. Leave it in there if someone in the group gets paid by 
the number of published pages.

If you want to reference RFC 7525 you should say what recommendation you want 
to carry over. If you don't do that then the text should not be in 
contradiction of what is said in eap-tls13.

Given your email with the dramatic title "Moving towards less security in 
2020", I am surprised that the reference to known attacks and the deprecation 
of old TLS versions receives a "SHOULD" rather than a "MUST". Feels out of 
balance to me and this makes me believe that the update to RFC 5216 has not 
been given too much thoughts by the group and by the authors. My guess is that 
most implementers use the latest version of TLS 1.2 code already anyway, which 
comes with sensible defaults. Do you have a different experience?

Ciao
Hannes

From: Mohit Sethi M 
Sent: Monday, November 2, 2020 9:59 AM
To: Hannes Tschofenig ; Mohit Sethi M 
; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216


Hi Hannes,

As said, we added this text based on the request of working group members. 
There were comments and additions to this text by Terry Burton for example: 
https://mailarchive.ietf.org/arch/browse/emu/?q=Client%20re-validation%20of%20server%20authority%20information%20during%20resumption

We are happy to update the draft with whatever the working group decides.

About your comment "Most readers who focus on TLS 1.2 in EAP-TLS will never get 
to  see those because they are hidden in the document.". I certainly hope 
that's not true because: this draft updates RFC 5216, and, the abstract says 
"This document also provides guidance on authorization and resumption for 
EAP-TLS in general (regardless of the underlying TLS version used).  This 
document updates RFC 5216."

Could you also please clarify "You are referencing the wrong documents.". Thank 
you for being patient. :)

--Mohit
On 11/2/20 9:51 AM, Hannes Tschofenig wrote:
Hi Mohit,

I hope you understand that I am worried about three things in my email below:


  1.  You are putting text into an EAP method that applies to EAP itself. 
Nothing prevents the EMU group to work on a document that clarifies EAP usage 
in document that updates the EAP spec, if the described issue is important.
  2.  You are making changes to the use of TLS 1.2 in EAP-TLS in a document 
that focuses on TLS 1.3 use in EAP-TLS.
Most readers who focus on TLS 1.2 in EAP-TLS will never get to see those 
because they are hidden in the document.
  3.  You are referencing the wrong documents.

If you look at this case as a working group chair then you might see the points 
I am trying to get across.

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:06 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Updates RFC 5216


Hi Hannes,

This text and guidance was specifically requested by working group members like 
Alan. Unless the text is wrong, I don't see any point in removing it. Other 
TLS-based EAP methods are obviously free to use parts of this text relevant to 
them. Note that their resumption and authorization might be even more complex 
as some decisions may depend on the inner authentication method.

--Mohit
On 10/21/20 12:00 PM, Hannes Tschofenig wrote:
Hi all,

the draft says it updates the earlier EAP-TLS version and claims that the 
updates are related to

* Section 5.6 Authorization
* Section 5.7 Resumptio

Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

[Hannes Tschofenig]

Thanks, Mohit.

You could also delete the entire paragraph because it adds nothing to what is 
already said in the TLS 1.3 spec.
See https://github.com/hannestschofenig/draft-ietf-emu-eap-tls13/pull/1

Ciao
Hannes


From: Mohit Sethi M 
Sent: Monday, November 2, 2020 9:58 AM
To: Hannes Tschofenig ; Mohit Sethi M 
; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


I now understand your issue with the sentence "An EAP-TLS peer and server 
SHOULD support the use of HelloRetryRequest message.". I guess there is no need 
for it, i.e., the section would be just fine without that sentence:
TLS 1.3 [RFC8446] defines that TLS servers can send a HelloRetryRequest message 
in response to a ClientHello if the server finds an acceptable set of 
parameters but the initial ClientHello does not contain all the needed 
information to continue the handshake.  One use case is if the server does not 
support the groups in the "key_share" extension, but supports one of the groups 
in the "supported_groups" extension.  In this case the client should send a new 
ClientHello with a "key_share" that the server supports.

As noted in Section 4.1.4 of [RFC8446], the server MUST provide the 
supported_versions extensions and SHOULD contain the minimal set of extensions 
necessary for the client to generate a correct ClientHello pair.  A 
HelloRetryRequest MUST NOT contain any extensions that were not first offered 
by the client in  its ClientHello, with the exception of optionally including 
the cookie extension.

The case of a successful EAP-TLS mutual authentication after the server has 
sent a HelloRetryRequest message is shown in Figure 8. Note the extra 
round-trip as a result of the HelloRetryRequest.

Commit on git: 
https://github.com/emu-wg/draft-ietf-emu-eap-tls13/commit/d4ac353a90dc7466d6da9deb5f50f4eb7c585e9b

--Mohit
On 11/2/20 9:39 AM, Hannes Tschofenig wrote:
Hi Mohit,

I read Jim's email and he is not saying that you should make it an optional to 
support feature.

The issue is:

- are you trying to change the functionality of TLS 1.3 with this draft, and
- is there a good reason to do so?

In this case, the "SHOULD" statement gives an implementer absolutely not idea 
when or when it would be good to implement this feature.
Besides this, I don't even believe that the TLS 1.3 spec gives you that freedom 
for this specific feature anyway.

Ciao
Hannes


From: Mohit Sethi M 
<mailto:mohit.m.se...@ericsson.com>
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig 
<mailto:hannes.tschofe...@arm.com>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

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

[Emu] Making Security Practical ... was RE: Moving towards less security in 2020 - OCSP

[Hannes Tschofenig]

Hi Mohit,


  *   I think it is a reasonable compromise for servers to implement OCSP 
stapling. Clients can implement and use it, but they would be compliant even if 
they don't. So the updated text would be (as Joe wrote in his email):
“
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.
“

This sounds like a good compromise for me.

Ciao
Hannes

PS: Mohit, maybe you can help implement OCSP to EAP-TLS in Mbed TLS. I am 
looking forward to see OCSP supported added to EDHOC by John.

From: Emu  On Behalf Of Mohit Sethi M
Sent: Saturday, October 31, 2020 2:15 PM
To: emu@ietf.org
Subject: [Emu] Moving towards less security in 2020 - OCSP


Dear all,

Sorry for the radio silence. I have over-committed myself to too many things. I 
think I have now read the entire discussion on OCSP.

EAP-TLS with TLS 1.3 is a working group document so the text will reflect 
whatever the working group wants. The authors and contributors are at the 
service of the working group. Obviously it is easy for us to simply change all 
MUSTs to MAYs, make everyone happy, and hand over the document to the IESG.

Yet, I think as a conscientious security person and individual contributor, I 
am saddened by the discussion thus far. To begin with, I assume that everyone 
knows the difference between OCSP and OCSP stapling. I also hope that everyone 
has read RFC 5216 (the previous EAP-TLS specification). In particular I hope 
that the working group has actually read section 5.4 on "Certificate 
Revocation" (https://tools.ietf.org/html/rfc5216#section-5.4). I copy the 
relevant text here for your convenience:

   EAP-TLS peer and server implementations MUST support the use of

   Certificate Revocation Lists (CRLs); for details, see Section 3.3 
of

   [RFC3280].  EAP-TLS peer 
and server implementations SHOULD also

   support the Online Certificate Status Protocol (OCSP), described in

   "X.509 Internet Public Key Infrastructure Online Certificate Status

   Protocol - OCSP" [RFC2560].  OCSP 
messages are typically much smaller

   than CRLs, which can shorten connection times especially in

   bandwidth-constrained environments.
and

   For this reason, EAP-TLS peers and servers SHOULD implement

   Certificate Status Request messages, as described in "Transport Layer

   Security (TLS) Extensions", Section 3.6 of 
[RFC4366].  To enable

   revocation checking in situations where servers do not support

   Certificate Status Request messages and network connectivity is not

   available prior to authentication completion, peer implementations

   MUST also support checking for certificate revocation after

   authentication completes and network connectivity is available, and

   they SHOULD utilize this capability by default.

So we were already saying "SHOULD" for OCSP in 2008 when RFC 5216 was 
published. And now 12/13 years later, some people in the working group are 
suggesting to make the security stance weaker. For what? Some speculative 
insecure future deployments? Please note that EAP-TLS is currently implemented 
in billions of devices and used in many high security deployments.

It is very surprising to see Hannes wanting to water down security and get rid 
of the text on OCSP. He wrote "I do not understand certificate revocation 
checking is a topic specific to the use of TLS 1.3 in EAP-TLS.". Well, as you 
see, RFC 5216 has quite detailed guidelines on certificate revocation checking 
with CRLs and OCSP so I don't see any sensible reason on why an update to it 
should not contain relevant text. Michael wrote " we are under no additional 
compulsion to support revocation than we were before." Do you see the problem 
here given the text in RFC 5216 shown above?

While Elliot and Hannes have been vocal about their views, we also saw feedback 
from Janfred explaining the situation without OCSP in a live network like 
eduroam: 
https://mailarchive.ietf.org/arch/msg/emu/X9Mm24LSzaq63bHSvmkBbiSsrJc/. He ends 
his email with

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.

Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

[Hannes Tschofenig]

Hi Mohit,

I read Jim's email and he is not saying that you should make it an optional to 
support feature.

The issue is:

- are you trying to change the functionality of TLS 1.3 with this draft, and
- is there a good reason to do so?

In this case, the "SHOULD" statement gives an implementer absolutely not idea 
when or when it would be good to implement this feature.
Besides this, I don't even believe that the TLS 1.3 spec gives you that freedom 
for this specific feature anyway.

Ciao
Hannes


From: Mohit Sethi M 
Sent: Saturday, October 31, 2020 6:04 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec


Hi Hannes,

Jim Schaad had asked for this: 
https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M/

It is still optional to use. The figure only shows what the exchange would look 
like if a HRR was sent by the server.

--Mohit
On 10/21/20 12:16 PM, Hannes Tschofenig wrote:
Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

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

[Hannes Tschofenig]

Hi Joe,

Thanks for the quick response.

[Joe] If the server is offering an expired or revoked certificate then that 
needs to be remedied on the server.

Where do you believe the value of OCSP comes into the picture for this EAP-TLS 
use case and what actions need to be taken when a notification of a 
revoked/expired certificate shows up?

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

draft-ietf-emu-eap-tls13 also makes changes to TLS 1.2 in EAP-TLS. It updates 
the content of the original RFC. This was surprising to me as well.
In that spirit it wouldn’t be unnatural to also require OCSP there and to apply 
that to all EAP methods that use TLS.

Note that I am not recommending it but it shows the inconsistency in the 
approach being taken today.

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

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

[Hannes Tschofenig]

Hi Joe,

a few remarks below.


On Fri, Oct 23, 2020 at 12:38 AM Hannes Tschofenig 
mailto: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?


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?

Ciao
Hannes

Ciao
Hannes

From: Joseph Salowey mailto:j...@salowey.net>>
Sent: Thursday, October 22, 2020 11:12 PM
To: Eliot Lear 
mailto:40cisco@dmarc.ietf.org>>
Cc: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>; 
emu@ietf.org<mailto: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 
mailto: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 
mailto:hannes.tschofe...@arm.com>> 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<mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org<mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu
IMPORTANT NOTICE: The contents of this email and any attachment

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

[Hannes Tschofenig]

Hi Alan,


>  However, in the absence of another specification, we need to say *something* 
> for EAP-TLS.

Why doesn't the group write that other document? There are several other EAP 
methods that use certificates as well.

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

>  I think that the topics are related.  But draft-ietf-emu-eap-tls13 is more 
> about the protocol, and draft-ietf-emu-eaptlscert is more about deployment 
> considerations.

The scope of draft-ietf-emu-eaptlscert is whatever you want it to be. 
Currently, it is a mixture of deployment suggestions and the use of TLS 
extensions.
Maybe that scope is wrong but has probably grown organically.

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

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

[Hannes Tschofenig]

Hi Joe,

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

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?

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.

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 
mailto: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 
mailto:hannes.tschofe...@arm.com>> 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<mailto:Emu@ietf.org>
https://www.ietf.org/mailman/listinfo/emu

___
Emu mailing list
Emu@ietf.org<mailto: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] 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

[Emu] draft-ietf-emu-eap-tls13-11: Conformance with the TLS 13 Spec

[Hannes Tschofenig]

Hi all,

Section 2.1.6 says:

"
   An EAP-TLS peer and server SHOULD support the use of
   HelloRetryRequest message.
"

My understanding of the TLS 1.3 specification is that the HelloRetryRequest is 
not an optional-to-implement message but it is only optional to use.

Is there a reason to deviate from the TLS 1.3 specification? Is there any 
reason to talk about the HRR message? The purpose of the message is given in 
the TLS 1.3 spec and whether you use it or not is up to the deployment.

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] draft-ietf-emu-eap-tls13-11: Repetition of Text

[Hannes Tschofenig]

Hi all,

the draft contains a number of cases where text from the TLS 1.3 specification 
or other specifications is repeated. Often, only fragments are used, which can 
easily fool the reader into believing that the omitted parts do not apply. 
Hence, I would avoid the repetition where not strictly necessary.

Here are two examples:

Section 2.1.6:

"
   As noted in Section 4.1.4 of [RFC8446],
   the server MUST provide the supported_versions extensions and SHOULD
   contain the minimal set of extensions necessary for the client to
   generate a correct ClientHello pair.  A HelloRetryRequest MUST NOT
   contain any extensions that were not first offered by the client in
   its ClientHello, with the exception of optionally including the
   cookie extension.
"

Section 2.1.9:

"
To avoid fragmentation, it
   is RECOMMENDED to keep the sizes of client, server, and trust anchor
   certificates small and the length of the certificate chains short.
   In addition, it is RECOMMENDED to use mechanisms that reduce the
   sizes of Certificate messages.

   While Elliptic Curve Cryptography (ECC) was optional for earlier
   version of TLS, TLS 1.3 mandates support of ECC (see Section 9 of
   [RFC8446]).  To avoid fragmentation, the use of ECC in certificates,
   signature algorithms, and groups are RECOMMENDED when using EAP-TLS
   with TLS 1.3 or higher.  At a 128-bit security level, this reduces
   public key sizes from 384 bytes (RSA and DHE) to 32-64 bytes (ECDHE)
   and signatures from 384 bytes (RSA) to 64 bytes (ECDSA and EdDSA).
   An EAP-TLS deployment MAY further reduce the certificate sizes by
   limiting the number of Subject Alternative Names.

   Endpoints SHOULD reduce the sizes of Certificate messages by omitting
   certificates that the other endpoint is known to possess.  When using
   TLS 1.3, all certificates that specifies a trust anchor may be
   omitted (see Section 4.4.2 of [RFC8446]).  When using TLS 1.2, only
   the self-signed certificate that specifies the root certificate
   authority may be omitted (see Section 7.4.2 of [RFC5246]).  EAP-TLS
   peers and servers SHOULD support and use the Cached Information
   Extension as specified in [RFC7924].  EAP-TLS peers and servers MAY
   use other extensions for reducing the sizes of Certificate messages,
   e.g. certificate compression [I-D.ietf-tls-certificate-compression].

   For a detailed discussion on reducing message sizes to prevent
   fragmentation, see [I-D.ietf-emu-eaptlscert].
"

This entire text should be replaced by a reference to 
[I-D.ietf-emu-eaptlscert], which offers a more detailed discussion.
It makes no sense to just copy a fragment of the text here, particularly when 
we are talking about a document from the same working group written by the same 
authors.

An small error in the text above: trust anchors are not exchanged in the TLS 
handshake.

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] draft-ietf-emu-eap-tls13-11: Fuzzy statements

[Hannes Tschofenig]

Hi all,

There are plenty of places in the draft where statements are made in a somewhat 
sloppy manner.

Section 5.1:

" TLS 1.3 increases the number of
  cryptographic parameters that are negotiated in the handshake.
"

Increases the number of parameters compared to what?

Section 5.1:

"
TLS 1.3 forbids all algorithms with known
   weaknesses including 3DES, CBC mode, RC4, SHA-1, and MD5.  TLS 1.3
   only supports cryptographic algorithms offering at least 112-bit
   security, see [RFC8446].
"

Most of those algorithms have been depreciated also with TLS 1.2
I would instead say that TLS 1.3 only uses AEAD ciphers.

 Section 2.5:

"
The Commitment Message is
   an encrypted TLS record with application data 0x00 (i.e. a TLS record
   with TLSPlaintext.type = application_data, TLSPlaintext.length = 1,
   and TLSPlaintext.fragment = 0x00).
"

Adding the note about TLSPlaintext.type, TLSPlaintext.length, and 
TLSPlaintext.fragment is not helpful given that both plaintext TLS records as 
well as encrypted TLS records use these structures. There is also a mistake in 
there because the TLSInnerPlaintext.type contains the application_data type (of 
course the TLSCiphertext.opaque_type also contains the application_data).

Introduction:
"
Privacy is mandatory ...
"

It depends what you call "privacy". TLS 1.3 offers a range of features that 
increase privacy protection but not all of them are mandatory to use. Example: 
record padding

In Section 2.1.8 you talk about privacy and say:

"
   TLS 1.3 significantly improves privacy when compared to earlier
   versions of TLS by forbidding cipher suites without confidentiality
   and encrypting large parts of the TLS handshake including the
   certificate messages.
"

This list is not exhaustive when it comes to the privacy features in TLS 1.3, 
as you know. If you think it is worthwhile to highlight the privacy features 
then why not list all of them?


Section 2.1.1:

"
SessionID is deprecated in TLS 1.3 and the EAP
   server SHALL ignore the legacy_session_id field if TLS 1.3 is
   negotiated.
"

This is misleading because the EAP server does not look into the TLS handshake 
messages.
Additionally, the session ID is not deprecated - it is a legacy feature that is 
used in the backwards compatibility mode.
FWIW you are not saying anything about the backwards compatibility mode and 
hence I believe you are not using it. That's something that has to be made more 
explicit.

Section 2.1.3:

"
The TLS PSK identity is typically derived by
   the TLS implementation and may be an opaque blob without a routable
   realm.  The TLS PSK identity is therefore in general unsuitable for
   deriving a NAI to use in the Identity Response.
"

There is no requirement in the TLS 1.3 spec that a PSK identity has to be in a 
NAI format. Hence, most implementations will not produce one in a NAI format. 
It can still be used to derive a NAI in an Identity Response if you stick a 
@realm to it at a different layer.

Section 2.1.6:

"
   TLS 1.3 [RFC8446] defines that TLS servers can send a
   HelloRetryRequest message in response to a ClientHello if the server
   finds an acceptable set of parameters but the initial ClientHello
   does not contain all the needed information to continue the
   handshake.
"

The TLS specification also says that this message can be used for DDoS 
mitigation. I think that DDoS mitigation is a valid use case in an EAP-based 
deployment.

Section 2.1.7:

"
  Many client certificates
   contains an identity such as an email address, which is already in
   NAI format.  When the client certificate contains a NAI as subject
   name or alternative subject name, an anonymous NAI SHOULD be derived
   from the NAI in the certificate, see Section 2.1.8.
"

>From where do you get the impression that "many client certificates" contain 
>an identity, such as an email address?
Why does it matter whether the NAI is contained in the subject name or in the 
alt subject name?
You refer to Section 2.1.8 regarding how to derive a anonymous NAI from the 
certificate and I couldn't find the text.


"
   As the certificate messages in TLS 1.3 are encrypted, there is no
   need to send an empty certificate_list and perform a second handshake
   for privacy (as needed by EAP-TLS with earlier versions of TLS).
"

Most readers are probably not familiar with the problem you are describing here.
Also, this issue is not specific to EAP-TLS; the same approach has been used in 
TLS (prior to 1.3) in general.

"   When EAP-TLS is used with TLS version 1.3 or higher the EAP-TLS peer
   and EAP-TLS server SHALL follow the processing specified by the used
   version of TLS.
"

This statement is obvious and does not say much. What else do you want to do?

"
   For TLS 1.3 this means that the EAP-TLS peer only
   sends an empty certificate_list if it does not have an appropriate
   certificate to send, and the EAP-TLS server MAY treat an empty
   certificate_list as a terminal condition.
"

In 

[Emu] draft-ietf-emu-eap-tls13-11: Editorial

[Hannes Tschofenig]

Hi all,

there are lots of editorial bugs in the text. I noticed many missing commas, 
missing articles, etc.

I know that the RFC Editor does a great job in correcting all of those errors 
but we have to do our work as well.

It would also be good to be consistent with the terms. How do you want to want 
to distinguish between EAP-TLS based on RFC 5216 and EAP-TLS with TLS 1.3? 
Sometimes it is possible to understand this from the context because certain 
features are not available in TLS 1.2 or have different names but it will help 
those who are less familiar with the history of TLS to be precise.

The terms EAP-TLS peer, EAP-TLS, and EAP peer seem to be used interchangeably. 
It would be good to use the terms consistently.

Here is an example from Section 5.8:

"
EAP peers SHOULD use record padding, see
   Section 5.4 of [RFC8446] to reduce information leakage of certificate
   sizes.
"

In this example the reader is asked to understand that we are not talking about 
the EAP layer, nor about EAP-TLS with RFC 5216 but about the client and the 
server of EAP-TLS with TLS 1.3.

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

[Hannes Tschofenig]

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] draft-ietf-emu-eap-tls13-11: Updates RFC 5216

[Hannes Tschofenig]

Hi all,

the draft says it updates the earlier EAP-TLS version and claims that the 
updates are related to

* Section 5.6 Authorization
* Section 5.7 Resumption

The content of Section 5.6 actually does not relate to EAP-TLS but is generic 
to all EAP methods. I don't think it even belongs in an EAP method document.

The content of Section 5.7 claims that there are aspects of resumptions that 
are not described in the earlier version of EAP-TLS. The focus is then on the 
way how the cached data is stored, an implementation-specific aspect, that is 
not specific to EAP-TLS because the concept of caching is used by other EAP 
methods too. Then, there is a threat presented whereby the authorization 
information changes between the full handshake and the resumption handshake. I 
believe that this is not a threat that is unique to EAP-TLS because this can 
happen even when there is no resumption. Nothing prevents you from checking 
authorization again when you do resumption though and even during an ongoing 
session. I would argue that there is a lot of text in there that has nothing to 
do with EAP-TLS but rather concerns the whole system in which EAP is used. If 
this is indeed a problem, I believe it should be covered in a separate 
document. I don't think it is a problem because extensions for RADIUS and 
Diameter have been developed to address this issue to revoke authorization 
during the lifetime of a session.

Here is where it gets confusing. The introduction says "This document defines 
how to use EAP-TLS with TLS 1.3 (or higher) and does not change how EAP-TLS is 
used with older versions of TLS." To me, this does not sound like an update.

Reading more carefully one can notice that the actual update to EAP-TLS is 
hidden in Section 5.8 "Privacy Considerations" and Section 5.10 "Discovered 
Vulnerabilities".

Section 5.8 says:
"
   it is RECOMMENDED for EAP peers to not use EAP-TLS with
   TLS 1.2 and static RSA based cipher suites without privacy.  This
   implies that an EAP peer SHOULD NOT continue the handshake if a TLS
   1.2 EAP server responds to an empty certificate message with a TLS
   alert message.
"

Section 5.10 says:
"
EAP-TLS implementations
   SHOULD mitigate known attacks and follow the recommendations in
   [RFC7525] and [I-D.ietf-tls-oldversions-deprecate].
"

Interestingly, RFC 7525 does not talk about EAP (and instead focuses on 
applications like  HTTP, SMTP, IMAP, POP, SIP, and XMPP, as noted in the 
abstract). RFC 7525, for example, does not mandate OCSP. It also recommends 
RSA, which draft-ietf-emu-eaptlscert and this draft does not do. There seems to 
be contradiction here.

At a minimum, I would clarify in the introduction what the updates to RFC 5216 
are. This will help those implementers that focus on a variant of EAP-TLS that 
uses version 1.2. As mentioned above, I don't believe Sections 5.6 and 5.7 
belong to this document. Leave it in there if someone in the group gets paid by 
the number of published pages.

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] draft-ietf-emu-eap-tls13-11: Commitment Message

[Hannes Tschofenig]

Hi all,



in an earlier email on this topic John wrote "I don't see why anybody would get 
the impressions that the application data would be unencrypted, all application 
data in TLS 1.3 is encrypted."



Even in the latest version of the draft (version -11) I can still find text 
that says the contrary.



Section 2.4:



"

   While EAP-TLS does not protect any application data, the negotiated

   cipher suites and algorithms MAY be used to secure data as done in

   other TLS-based EAP methods.

"



Section 2.1.1:



"

   After the TLS handshake has completed

   and all Post-Handshake messages have been sent, the EAP server sends

   EAP-Success.

"



Even the figure that follows this statement shows that this is not true because 
there is still the Commitment Message.



Can you see how this is confusing?



I had suggested to add a note to the introduction to make it clear that the 
Commitment Message is one of the two things that changed with this draft. (The 
other aspect is the changed key exporting.)



Currently, the important information on how the Commitment Message works is 
buried in a section called EAP State Machines when nothing in the draft can 
possibly change the EAP state machine.



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] draft-ietf-emu-eap-tls13-11

[Hannes Tschofenig]

Hi all,

Roman asked me to look at draft-ietf-emu-eap-tls13-11.

I have carefully read through the document and I will post my reviews in 
separate emails.
There are still lots of room for improvement.

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

Re: [Emu] draft-ietf-emu-eaptlscert-04

[Hannes Tschofenig]

Thanks for the quick turn-over-time.

Looks good to me.

-Original Message-
From: Mohit Sethi M 
Sent: Monday, June 15, 2020 11:31 AM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eaptlscert-04

Hi Hannes,

Thanks for the follow up. I have submitted a new version which should
address your concerns. Here is a diff for your convenience:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-05

Please see in-line for details.

I believe that the draft is now ready for publication.

--Mohit

On 6/10/20 12:02 PM, Hannes Tschofenig wrote:
> Thanks for the update.
>
> A few more minor comments on -04:
>
> Section 4.1:
>
> "TLS 1.3 [https://tools.ietf.org/html/rfc8446] requires implementations to 
> support ECC."
>
> This is only true absent an application profile defining something else.
> The UTA group has just adopted a WG item that defines such a profile.
>
> Hence, I suggest to add the remark about the profile. Something like
>
> "In the absence of an application profile standard specifying
> otherwise, a TLS 1.3-compliant application must support ECC."
Done!
>
> 4.2.  Updating TLS and EAP-TLS Code
>
> Why are you calling the section "updating code"? The suggestion in 4.2.1 does 
> not require code update and whether something requires a code update depends 
> what you have in the code already. Maybe you just need to enable the feature. 
>  Updating the code is also a negative aspect because you are likely going to 
> update the code on a regular basis anyway to fix bugs and to support new 
> algorithms. Luckily TLS has the extension negotiation built-in and hence you 
> can detect and negotiate new features on the fly.
I agree that all code indeed should be updated to fix bugs and
vulnerabilities. However, updating applications and certificates is
certainly different from updating the underlying TLS library and EAP
implementation. Administrators in enterprise environments (where EAP-TLS
is widely used) have great control over when and how the server and
client updates are rolled out. The categorization in section 4 should
help administrators to decide how to avoid the fragmentation problem.
Whether it is issuing new certificates, updating the access points, or
updating the TLS and EAP-TLS implementation. Nonetheless, I have added
the following text: "This section discusses how the fragmentation
problem can be avoided by updating the underlying TLS or EAP-TLS
implementation. Note that in many cases the new feature may already be
implemented in the underlying library and simply needs to be taken into
use."
>
> 4.2.4.  Caching Certificates
>
> "The extension however necessitates a successful full handshake before any 
> caching."
>
> This is not true. The spec defines a way to populate the cache by running a 
> full handshake.
> However, you could also populate the cache by out-of-band means, for example 
> by pre-distributing certs.
>
> The mechanism to re-run the handshake to populate the cache is, however, a 
> safe fallback in case configuration changes and the pre-distributed certs 
> become invalid. It is better to have a fallback.
>
> I thought I made that comment before.

You had raised this issue before and I had responded to you before. Here
is the response again:

Where does RFC 7924 (https://tools.ietf.org/html/rfc7924) talk about
populating the cache with an out-of-band mechanism? The text in Section
1 of RFC 7924 clearly states that:  "This specification defines a TLS
extension that allows a client and a server to exclude transmission
information cached in an earlier TLS handshake.". Notice the "earlier
TLS handshake" part. I certainly refuse to add or describe new
functionality which isn't discussed in the original RFC.

>
> 4.2.3.  Compact TLS 1.3
>
> You are still stating "This naturally means that cTLS is not interoperable 
> with previous versions of the TLS protocol."
>
> cTLS is a compression of TLS, which means that you can fall-back to TLS, if 
> the other peer does not support cTLS. As mentioned in my previous email, I 
> don't understand why you are mentioning this aspect at all given that this 
> document is about certificate size reduction.
I understand your desire of making cTLS look good. I am not sure how
hiding the information that cTLS doesn't interoperate with older
versions of TLS helps. Anyhow, I have removed that sentence since
progressing the draft at this is stage is more important than arguing
over one sentence.
>
> Raw Public Keys
>
> I wonder whether you should mention the possibility to use RPKs 
> (https://tools.ietf.org/html/rfc7250) in Section 4.1.2 because those would be 
> a fairly obvious choice in EAP-TLS given that we are talking about a nailed 
> up connection between t

Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

[Hannes Tschofenig]

Hi Mohit,

See below. Thanks for your super quick response.


From: Mohit Sethi M 
Sent: Tuesday, June 16, 2020 12:25 PM
To: Hannes Tschofenig ; Mohit Sethi M 
; emu@ietf.org
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13


Hi Hannes,
On 6/16/20 12:37 PM, Hannes Tschofenig wrote:
Hi Mohit,

I had a chance to read through the emails you provided. A good discussion.

I can offer three solutions:


  1.  Use EAP-Success / EAP-Failure as an indication for the completion of the 
exchange, even if it is not a reliable notification mechanism. If the EAP peer 
does not receive the NewSessionTicket message then it does not matter because 
it is optional to use anyway. It will be a failure case anyway if the 
EAP-Success / EAP-Failure got lost. They EAP peer may not even know whether the 
exchange was successful despite correctly processing TLS handshake messages.
I am uncomfortable doing this without updating RFC 3748. Not only will we be 
violating RFC 3748, we would still have the problem of peer uncertainty about 
the next message. It could be a NewSessionTicket or EAP-Success/Failure.

[Hannes] What is done in EAP today?


  1.  Demand that the NewSessionTicket is sent immediately after the Finished, 
very much like you currently demand that the Commitment Message is attached to 
the last message.

I assume that you imply immediately after the server has sent its TLS Finished 
(and not after the server has received the TLS Finished from the peer)? Are you 
also implying that a NewSessionTicket should always be sent out, regardless of 
whether a server wants or supports resumption? What if the server is issuing 
several tickets?

[Hannes] I would leave it as an option to send a NewSessionTicket but it is 
sent then it has to be in the last message. Here is the exchange:

Case 1: NewSessionTicket Message Sent

EAP Peer  EAP 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,
   TLS NewSessionTicket)
EAP-Response/
EAP-Type=EAP-TLS
   (TLS Certificate,
TLS CertificateVerify,
TLS Finished)>
 <   EAP-Success

Case 2: No ticket sent



EAP Peer  EAP 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-Success



  1.  Use the Commitment Message as an application layer payload (encrypted as 
it should be). (Note that this has nothing to do with early data.) If the 
OpenSSL spec does not support an application layer message from the server 
right after the finish then it is not compliant to the TLS 1.3 RFC.



How would that work? How can server send encrypted applicat

Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13

[Hannes Tschofenig]

Hi Mohit,

I had a chance to read through the emails you provided. A good discussion.

I can offer three solutions:


  1.  Use EAP-Success / EAP-Failure as an indication for the completion of the 
exchange, even if it is not a reliable notification mechanism. If the EAP peer 
does not receive the NewSessionTicket message then it does not matter because 
it is optional to use anyway. It will be a failure case anyway if the 
EAP-Success / EAP-Failure got lost. They EAP peer may not even know whether the 
exchange was successful despite correctly processing TLS handshake messages.


  1.  Demand that the NewSessionTicket is sent immediately after the Finished, 
very much like you currently demand that the Commitment Message is attached to 
the last message.


  1.  Use the Commitment Message as an application layer payload (encrypted as 
it should be). (Note that this has nothing to do with early data.) If the 
OpenSSL spec does not support an application layer message from the server 
right after the finish then it is not compliant to the TLS 1.3 RFC.


The current solution in the draft, for example, does not work with Mbed TLS 
because you cannot tell the stack to suddenly bypass the encryption layer 
(after successfully establishing it) to send a plaintext message.

Ciao
Hannes

From: Mohit Sethi M 
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13


Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken to 
avoid changes to the underlying TLS implementation while also avoiding changes 
to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP-TLS 
is non-trivial. See his email here: 
https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. 
Essentially, TLS 1.3 allows a server to send a Post-Handshake message with a 
NewSessionTicket at any time. However, in EAP-TLS this is not possible. The TLS 
tunnel is torn down after authentication. John notes in his response to Jouni 
(https://mailarchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in 
TLS the connection is assumed to stay open for a long time after the client 
sends Finished, in EAP the connection is assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra round trip 
and left the peer uncertain about the next message 
(https://tools.ietf..org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni 
highlighted this uncertainty for a peer: " the peer has no idea whether the 
NewSessionTicket is delivered after ClientFinished. In other words, the next 
message in the sequence could be either continuation of EAP-TLS method or 
EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that 
purpose?". See RFC 3748 (https://tools.ietf.org/html/rfc3748) which says the 
following:

   Implementation Note: Because the Success and Failure packets are not

   acknowledged, they are not retransmitted by the authenticator, and

   may be potentially lost.  A peer MUST allow for this circumstance as

   described in this note.
and

 On the peer, after success result indications have been exchanged by

   both sides, a Failure packet MUST be silently discarded.  The peer

   MAY, in the event that an EAP Success is not received, conclude that

   the EAP Success packet was lost and that authentication concluded

   successfully.

Thus, EAP-Success cannot be used as a reliable notification mechanism. Till 
version 05 of the document, we used an empty application data record as a 
notification of the last handshake message. The text said:

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, Jouni in a later response 
(https://mailarchive.ietf.org/arch/msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted 
that such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL 
is not willing to send such an empty TLSPlaintext structure. SSL_write() has 
following to say : 'You should not call SSL_write() with num=0, it will return 
an error. SSL_write_ex() can be called with num=0, but will not send 
application data to the peer.'"

Therefore, the text was later updated to:

 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 sending a Commitment Message.  The Commitment Message is

   a TLS record with application data 0x00 (i.e.

Re: [Emu] draft-ietf-emu-eap-tls13-09

[Hannes Tschofenig]

This is, of course, a decision of the group and the main use cases of a 
TLS-based EAP method is in the use of public key-based authentication.
Technically, there is, however, no reason why this wouldn’t work.

Ciao
Hannes

From: Mohit Sethi M 
Sent: Monday, June 15, 2020 3:51 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] draft-ietf-emu-eap-tls13-09


Hi Hannes,
On 6/12/20 11:29 AM, Hannes Tschofenig wrote:

A short follow-up on my own review:



I wrote:



"

Pre-Shared Key (PSK) authentication SHALL NOT be used except

   for resumption.

"

What you want to say that that EAP-TLS MUST NOT use external PSKs. I wonder why 
you want to rule that use case out? It is a perfectly fine use case for TLS 1.3 
and there is even the possibility to use PSK with ECDHE. What is the motivation?



I noticed now that the working group had a discussion about this already and 
that there is a new document being published specifically focused on 
EAP-TLS-PSK-based authentication. Hence, ignore the second part of my comment.

Indeed. There has been lots of discussion on this topic. To summarize:

RFC 5216 explicitly required certificate based TLS authentication with the 
following text:

   If the EAP server is not resuming a previously established session,

   then it MUST include a TLS server_certificate handshake message, and

   a server_hello_done handshake message MUST be the last handshake

   message encapsulated in this EAP-Request packet.



   The certificate message contains a public key certificate chain for

   either a key exchange public key (such as an RSA or Diffie-Hellman

   key exchange public key) or a signature public key (such as an RSA or

   Digital Signature Standard (DSS) signature public key).
Bernard Aboba opined that external PSK based authentication shouldn't be added 
to EAP-TLS in this update. Instead a separate document (with a separate EAP 
method type) should do that. Hence, we now have: 
https://tools.ietf.org/html/draft-mattsson-emu-eap-tls-psk-00. For reference, 
here are some email conversations containing discussion on this topic:

- https://mailarchive.ietf.org/arch/msg/emu/FtxRJHTjzSY0yVdVr8Vjyk9D-vk/
- https://mailarchive.ietf.org/arch/msg/emu/CRh3VXLDnpJFFIbHWJAjiOgfzAg/
- https://mailarchive.ietf.org/arch/msg/emu/nYrIA4PKqk2mrUoNvAtFh7S-Xb8/
- https://mailarchive.ietf.org/arch/msg/emu/hVG357HXqvy0EjZ2yrOLdspH53o/

--Mohit





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<mailto: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] Commitment Message in draft-ietf-emu-eap-tls13

[Hannes Tschofenig]

Hi Mohit,

Thanks for the super-detailed response.

Give me till tomorrow to parse your response. Glad to hear that you talked 
about this topic already.

Ciao
Hannes

From: Mohit Sethi M 
Sent: Monday, June 15, 2020 3:52 PM
To: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] Commitment Message in draft-ietf-emu-eap-tls13


Hi Hannes,

Unfortunately you are wrong here. The design decision was in fact taken to 
avoid changes to the underlying TLS implementation while also avoiding changes 
to RFC 3748. To summarize:

Jouni Malinen pointed out that mapping session resumption of TLS 1.3 to EAP-TLS 
is non-trivial. See his email here: 
https://mailarchive.ietf.org/arch/msg/emu/SBdblHmLQTbBwoZHK8Rih-g5ne8/. 
Essentially, TLS 1.3 allows a server to send a Post-Handshake message with a 
NewSessionTicket at any time. However, in EAP-TLS this is not possible. The TLS 
tunnel is torn down after authentication. John notes in his response to Jouni 
(https://mailarchive.ietf.org/arch/msg/emu/nNUw61cTvHgWj8F0sOVRoICUzlk/) "in 
TLS the connection is assumed to stay open for a long time after the client 
sends Finished, in EAP the connection is assumed to be closed shortly after."

An earlier cleaner way of sending NewSessionTicket required an extra round trip 
and left the peer uncertain about the next message 
(https://tools.ietf..org/html/draft-ietf-emu-eap-tls13-00#section-2.1.1). Jouni 
highlighted this uncertainty for a peer: " the peer has no idea whether the 
NewSessionTicket is delivered after ClientFinished. In other words, the next 
message in the sequence could be either continuation of EAP-TLS method or 
EAP-Success". You ask "why cannot the EAP-Success or EAP-Failure serve that 
purpose?". See RFC 3748 (https://tools.ietf.org/html/rfc3748) which says the 
following:

   Implementation Note: Because the Success and Failure packets are not

   acknowledged, they are not retransmitted by the authenticator, and

   may be potentially lost.  A peer MUST allow for this circumstance as

   described in this note.
and

 On the peer, after success result indications have been exchanged by

   both sides, a Failure packet MUST be silently discarded.  The peer

   MAY, in the event that an EAP Success is not received, conclude that

   the EAP Success packet was lost and that authentication concluded

   successfully.

Thus, EAP-Success cannot be used as a reliable notification mechanism. Till 
version 05 of the document, we used an empty application data record as a 
notification of the last handshake message. The text said:

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, Jouni in a later response 
(https://mailarchive.ietf.org/arch/msg/emu/WA8OREhTsF8JEPvaixGoCwmd1qY/) noted 
that such behavior is non-trivial to achieve with OpenSSL. He notes " OpenSSL 
is not willing to send such an empty TLSPlaintext structure. SSL_write() has 
following to say : 'You should not call SSL_write() with num=0, it will return 
an error. SSL_write_ex() can be called with num=0, but will not send 
application data to the peer.'"

Therefore, the text was later updated to:

 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 sending a Commitment Message.  The Commitment Message is

   a TLS record with application data 0x00 (i.e. a TLS record with

   TLSPlaintext.type = application_data, TLSPlaintext.length = 1, and

   TLSPlaintext.fragment = 0x00).  Note that the length of the plaintext

   is greater than the corresponding TLSPlaintext.length due to the

   inclusion of TLSInnerPlaintext.type and any padding supplied by the

   sender.  EAP server implementations MUST set TLSPlaintext.fragment to

   0x00, but EAP peer implementations MUST accept any application data

   as a Commitment Message from the EAP server to not send any more handshake 
messages.


There is still a challenge in scenarios where a server chooses not to issue any 
NewSessionTicket. In this email: 
https://mailarchive.ietf.org/arch/msg/emu/PgGjhmafbbSJCcQctDsFw7AvNmU/ Jouni 
notes this problem:

I did see some issues when OpenSSL 1.1.1 when disabling sending of

session tickets, though. The current draft indicates that the empty

Application Data payload would be send out in the same EAP packet with

the server's Finished message, i.e., before the server having

authenticated the peer. And this would be done without the peer having

used TLS early data (which is explicitly dis

[Emu] draft-ietf-emu-eap-tls13-09

[Hannes Tschofenig]

Hi all,

I took a quick look at the -09 draft.

Here are a few comments.



1.  Introduction

The text in the introduction is confusing. To be honest, this document is 
actually not needed because TLS allows you to negotiate version and features.. 
Obviously, the introduction does not say that and instead dances around the 
reason of why this document is needed by saying TLS 1.3 made a lot of changes 
but then concludes everything is backwards compatible.

In more details, the first paragraph is fine. It talks about where EAP-TLS is 
used.

Then, the second paragraph says:

"

   TLS 1.3 is in large parts a complete

   remodeling of the TLS handshake protocol including a different

   message flow, different handshake messages, different key schedule,

   different cipher suites, different resumption, different privacy

   protection, and record padding.


This means that significant parts of

   the normative text in the previous EAP-TLS specification 
[RFC5216]

   are not applicable to EAP-TLS with TLS 1.3 (or higher).  Therefore,

   aspects such as resumption, privacy handling, and key derivation need

   to be appropriately addressed for EAP-TLS with TLS 1.3 (or higher).

"

The change from 1.2 to 1.3 is certainly larger than the change from 1.1. to 1.2.

For the user of the EAP method not much has changed though. In fact, you can 
seamless switch from one version of TLS to the next version.

In fact, you say that in the next paragraph:

"

   While this document updates EAP-TLS 
[RFC5216], it remains backwards

   compatible with it and existing implementations of EAP-TLS.
"

In the last paragraph you say:

"
   Privacy is mandatory and achieved without any additional round-trips,
   revocation checking is mandatory and easy with OCSP stapling, and TLS
   1.3 introduces more possibilities to reduce fragmentation when
   compared to earlier versions of TLS.
"

You have some specific features in mind when you talk about "privacy" and I 
wonder what those are.

In what sense is revocation checking mandatory? OCSP stapling has been a 
feature before.

What is this issue about fragmentation? As you know from your work on the other 
document, fragmentation is really introduced by certificates. The certificate 
format in TLS 1.3 has not changed.

Before you answer these questions look at my suggestion below.

I would delete large part of the introduction and basically leave the first 
paragraph intact and then add the following sentences:

"

EAP-TLS [RFC5216] references TLS 1.0 
[RFC2246] and TLS 1.1 
[RFC4346],

but works perfectly also with TLS 1.2 
[RFC5246].  TLS 1.0 and 1.1 are

formally deprecated and prohibited to negotiate and use

[I-D.ietf-tls-oldversions-deprecate].
  Weaknesses found in TLS 1.2,

as well as new requirements for security, privacy, and reduced

latency has led to the specification of TLS 1.3 
[RFC8446], which

obsoletes TLS 1.2 [RFC5246].

This specification updates RFC 5216 and updates the description to
cover TLS 1.3. Security and privacy considerations of this EAP method
are updated to reflected the improved security and privacy functionality
of TLS 1.3.
"

Section 2.1

Delete this paragraph. It does not say much.


   TLS 1.3 changes both the message flow and the handshake messages

   compared to earlier versions of TLS.  Therefore, much of Section 
2.1

   of [RFC5216] does not apply 
for TLS 1.3 (or higher).

Section 2.1.1


   Many client certificates

   contains an identity such as an email address, which is already in

   NAI format.

A NAI looks like an email address but actually isn't.


"

   The EAP server MUST authenticate with a certificate and SHOULD

   require the EAP peer to authenticate with a certificate.
"

You might want to mention the emergency services use case here. You do much 
later in the document but I believe this is the first occurrence of the 
server-side only authentication concept.


"

Pre-Shared Key (PSK) authentication SHALL NOT be used except

   for resumption.
"

What you want to say that that EAP-TLS MUST NOT use external PSKs. I wonder why 
you want to rule that use case out? It is a perfectly fine use case for TLS 1.3 
and there is even the possibility to use PSK with ECDHE. What is the motivation?

"

SessionID is deprecated in TLS 1.3 and the EAP

   server SHALL ignore the legacy_session_id field if TLS 1.3 is

   negotiated.
"

I am curious why you are pointing out this change in TLS 1.3. Yes, the session 
id field has been deprecated and the 

[Emu] Commitment Message in draft-ietf-emu-eap-tls13

[Hannes Tschofenig]

Hi all,

This has probably been discussed extensively in the EMU group. I am sorry to 
bring it up again but I believe this is a bad design decision. I raised it in 
my short review just sent to the list but I believe it is worthwhile to point 
it out separately.

draft-ietf-emu-eap-tls13 introduces a new message to EAP-TLS, namely the 
Commitment Message. This requires extra code in an implementation because the 
normal behavior would be to run a TLS stack and then send encrypted data.
EAP-TLS does, however, not send application data*. This message changes this. 
Not only does it not send encrypted application data it requires an 
implementation to transmit a plaintext application data record after the 
application traffic secret has been created and before that application traffic 
secret is used to protect post handshake messages. This will make it difficult 
to re-use an off-the-shelf TLS 1.3 stack.


There is very little motivation about this message other than



"

   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 sending a Commitment Message.

"

I might miss something important here but why cannot the EAP-Success or 
EAP-Failure serve that purpose?

Here are two examples to explain what I mean:


  1.  Failed exchange



EAP Peer  EAP 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-Request/

EAP-Type=EAP-TLS

 <  (TLS Fatal Alert)

EAP-Response/

EAP-Type=EAP-TLS >

 <   EAP-Failure



  1.  Successful Exchange with Post-Handshake NewSession Ticket


EAP Peer  EAP 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 NewSessionTicket,

 

 <   EAP-Success


Ciao
Hannes

(*): FWIW Post handshake messages are protected with the application traffic 
secrets.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and 

Re: [Emu] draft-ietf-emu-eap-tls13-09

[Hannes Tschofenig]

A short follow-up on my own review:

I wrote:

> "
> Pre-Shared Key (PSK) authentication SHALL NOT be used except
>for resumption.
> "
> What you want to say that that EAP-TLS MUST NOT use external PSKs. I wonder 
> why you want to rule that use case out? It is a perfectly fine use case for 
> TLS 1.3 and there is even the possibility to use PSK with ECDHE. What is the 
> motivation?

I noticed now that the working group had a discussion about this already and 
that there is a new document being published specifically focused on 
EAP-TLS-PSK-based authentication. Hence, ignore the second part of my comment.

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] draft-ietf-emu-eaptlscert-04

[Hannes Tschofenig]

Thanks for the update.

A few more minor comments on -04:

Section 4.1:

"TLS 1.3 [https://tools.ietf.org/html/rfc8446] requires implementations to 
support ECC."

This is only true absent an application profile defining something else.
The UTA group has just adopted a WG item that defines such a profile.

Hence, I suggest to add the remark about the profile. Something like

"In the absence of an application profile standard specifying
otherwise, a TLS 1.3-compliant application must support ECC."

4.2.  Updating TLS and EAP-TLS Code

Why are you calling the section "updating code"? The suggestion in 4.2.1 does 
not require code update and whether something requires a code update depends 
what you have in the code already. Maybe you just need to enable the feature.  
Updating the code is also a negative aspect because you are likely going to 
update the code on a regular basis anyway to fix bugs and to support new 
algorithms. Luckily TLS has the extension negotiation built-in and hence you 
can detect and negotiate new features on the fly.

4.2.4.  Caching Certificates

"The extension however necessitates a successful full handshake before any 
caching."

This is not true. The spec defines a way to populate the cache by running a 
full handshake.
However, you could also populate the cache by out-of-band means, for example by 
pre-distributing certs.

The mechanism to re-run the handshake to populate the cache is, however, a safe 
fallback in case configuration changes and the pre-distributed certs become 
invalid. It is better to have a fallback.

I thought I made that comment before.

4.2.3.  Compact TLS 1.3

You are still stating "This naturally means that cTLS is not interoperable with 
previous versions of the TLS protocol."

cTLS is a compression of TLS, which means that you can fall-back to TLS, if the 
other peer does not support cTLS. As mentioned in my previous email, I don't 
understand why you are mentioning this aspect at all given that this document 
is about certificate size reduction.

Raw Public Keys

I wonder whether you should mention the possibility to use RPKs 
(https://tools.ietf.org/html/rfc7250) in Section 4.1.2 because those would be a 
fairly obvious choice in EAP-TLS given that we are talking about a nailed up 
connection between the EAP peer and the EAP server. This would obviously reduce 
the overhead associated with certificates considerably.

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

Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

[Hannes Tschofenig]

Thanks for the update, Mohit.

A few minor remarks:

FROM:

"
   TLS certificates in EAP deployments can be relatively large, and the
   certificate chains can be long.
"

TO:

"
   Certificates in EAP deployments can be relatively large, and the
   certificate chains can be long.
"

Reason: Certificates are large and there is nothing in TLS that contributes to 
the size.

In Section 4 I would state the obvious to the reader: Keep the certificate size 
small by not stuffing lots of fields in it and keep the chain short.
A common reason why these certs are long is because developers don't understand 
that they do not need to map the organizational hierarchy to a CA hierarchy.
This is the simplest approach to reduce the size of certificates sent over the 
wire.

Regarding 4.2.3.  Compact TLS 1.3

   [I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and
   reduces the message size of the protocol by removing obsolete
   material and using more efficient encoding.  This naturally means
   that cTLS is not interoperable with previous versions of the TLS
   protocol.  It also defines a compression profile with which either
   side can define dictionary of "known certificates".  Thus, cTLS can
   provide another mechanism for EAP-TLS deployments to reduce the size
   of messages and avoid excessive fragmentation.

The point for mentioning cTLS was related to the certificate compression. I 
would therefore change the paragraph to:

4.2.3.  Compact TLS 1.3

   [I-D.ietf-tls-ctls] defines a "compact" version of TLS 1.3 and
   reduces the message size of the protocol by removing obsolete
   material and using more efficient encoding.  It also defines a
   compression profile with which either  side can define dictionary
   of "known certificates".

I wonder whether you want to mention also 
https://tools.ietf.org/html/draft-tschofenig-tls-cwt-01 and 
https://tools.ietf.org/html/draft-mattsson-tls-cbor-cert-compress-00?
Since those are still individual drafts you could point out that those are work 
in progress.

Ciao
Hannes

-Original Message-
From: Mohit Sethi M 
Sent: Saturday, May 9, 2020 10:49 AM
To: Hannes Tschofenig ; Michael Richardson 
; emu@ietf.org
Subject: Re: [Emu] My review ... was RE: I-D Action: 
draft-ietf-emu-eaptlscert-02.txt

Hi Hannes,

I have submitted a new version of the draft which I believe addresses your 
concerns. Here is a diff for your convenience:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-03

While Alan and Jouni have already provided excellent answers to most of your 
comments, in-line you can find a few more clarifications for the changes I made.

--Mohit

On 3/24/20 10:00 AM, Hannes Tschofenig wrote:
> Hi Michael, Hi draft authors,
>
>> I was surprised to get to the end of the document without any suggestions 
>> about sending certificates by reference rather than value.
> Having seen this statement from Michael I have reviewed the document. Two 
> generic observations about the draft:
>
> 1) Many statements are made about deployments and no references are provided. 
> To improve quality of the write-up I would strongly suggest to add such 
> references, as you would have to do with an academic publication as well.
>
> 2) A few techniques are missing (Certificate URLs and cTLS) and TLS Cached 
> Info was wrongly interpreted.  They actually relate to the remark from 
> Michael.
>
>> TLS certificates are often relatively large, and the certificate
>>chains are often long.
> I think this statement is in general incorrect. You could say that in 
> deployment X certificates have size X and the chain is Y long.
>
>
>> Also,
>>   from deployment experience, EAP peers typically have longer
>>certificate chains than servers.
> I would like a reference to be included here. Theoretically, it makes
> no sense to have a certificate chain for an EAP peer to have a longer
> certificate chain than a server given a EAP peer talks to one EAP server.
>
> In network access authentication it is not only about authentication but the 
> most important part is authorization. Hence, you pretty much always have a 
> one-to-one relationship between the EAP peer and the EAP server. There are no 
> good reasons to have complex CA hierarchies here.
>
>> This is because EAP peers often
>>   follow organizational hierarchies and tend to have many intermediate
>>certificates.  Thus, EAP-TLS authentication usually involve
>>significantly more octets than when TLS is used as part of HTTPS.
> I think it would make sense to explain this organizational hierarchy
> aspect in a bit more detail.
>
>> The EAP fragment size
>>   in typical deployments is just 1020 - 1500 octets.
> Reference for the 1500 octets.
Added that this limitation come from E

[Emu] eap-noob

[Hannes Tschofenig]

Hi all

I read through draft-aura-eap-noob-08 during the call for adoption.

The draft acknowledges that the concept of "onboarding" is a new term for an 
old concept, namely network access authentication.
I like the draft from that point of view.

The content looks fine good and the design is well described. There is a formal 
analysis available and sample code available.

I believe it would be good to note that the solution does not support any form 
of cloning prevention because the device is assumed to be "blank" from the 
point of view of keying material.

I was wondering about one aspect, and maybe I missed it somewhere: what are you 
actually authenticating?
The identifier for the client is assigned by the EAP server. The server is also 
unknown at the start of the protocol.

I also got the impression that the authors are not entirely sure about 
repeating the OOB step. Earlier in the document it sounds like the authors do 
not really like the idea to repeat it and then later in the document they 
acknowledge that it will be necessary to deal with it anyway. Am I reading 
in-between the lines here?

There is also a not-so-bright side of this draft: the deployment. The solution 
places many constraints on potential solutions, the authors have little 
influence on the deployment environment, the use of EAP is not that common in 
IoT communication technologies, there are many other competing solutions, etc.

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

Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

[Hannes Tschofenig]

Thanks, Jouni. That's a good clarification.

-Original Message-
From: Jouni Malinen 
Sent: Saturday, March 28, 2020 9:26 AM
To: Alan DeKok 
Cc: Hannes Tschofenig ; emu@ietf.org
Subject: Re: [Emu] My review ... was RE: I-D Action: 
draft-ietf-emu-eaptlscert-02.txt

On Tue, Mar 24, 2020 at 10:08:06AM -0400, Alan DeKok wrote:
> On Mar 24, 2020, at 4:00 AM, Hannes Tschofenig  
> wrote:
> >> For example, many EAP authenticator (access point) implementations
> >> will drop an EAP session if it has not finished after
> >>  40 - 50 round-trips.
> >
> > Is there a reference that could be included?
>
>   References to hostap source code.

hostapd has a limit in the EAP server role on the number of round trips (and 
wpa_supplicant in the EAP peer role). However, there is no such limit in the 
EAP authenticator role, i.e., hostapd as the access point forwarding EAP to an 
external RADIUS authentication server does not place such a constraint on the 
exchange.

--
Jouni MalinenPGP id EFC895FA
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] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

[Hannes Tschofenig]

Hi Alan

Thanks a lot for your comments. I guess you understand that I am always a bit 
nervous when the results of non-public conversations dictate the problem space. 
I have seen it often enough that people have made their measurements wrong, had 
wrong configuration, or had simply misunderstood concepts.

It sounds like we need a "myth-busting" document. Of course, it isn't certain 
whether the decision makers will indeed read RFCs but it would be worthwhile a 
try.

Also it appears that the authors could do something really actionable here, 
namely to update the hostap code to update the roundtrip limit.

Ciao
Hannes

PS: Why aren't you a co-author on this document? You know more about this than 
anyone else.

-Original Message-
From: Alan DeKok 
Sent: Tuesday, March 24, 2020 3:08 PM
To: Hannes Tschofenig 
Cc: Michael Richardson ; emu@ietf.org
Subject: Re: [Emu] My review ... was RE: I-D Action: 
draft-ietf-emu-eaptlscert-02.txt

On Mar 24, 2020, at 4:00 AM, Hannes Tschofenig  
wrote:
> Having seen this statement from Michael I have reviewed the document. Two 
> generic observations about the draft:
>
> 1) Many statements are made about deployments and no references are provided. 
> To improve quality of the write-up I would strongly suggest to add such 
> references, as you would have to do with an academic publication as well.

  The issue is that deployment issues are usually discussed privately.  One 
public link is this:

http://freeradius.1045715.n5.nabble.com/Free-Radius-problem-with-sending-large-certificate-chains-using-EAP-TLS-td2780319.html

>> TLS certificates are often relatively large, and the certificate
>> chains are often long.
>
> I think this statement is in general incorrect. You could say that in 
> deployment X certificates have size X and the chain is Y long.

  Maybe "can be large" and "can be long".  It's difficult to get quantitative 
numbers here.  I didn't instrument my software to send statistics back to a 
central collector. :(

>
>> Also,
>> from deployment experience, EAP peers typically have longer
>> certificate chains than servers.
>
> I would like a reference to be included here. Theoretically, it makes
> no sense to have a certificate chain for an EAP peer to have a longer
> certificate chain than a server given a EAP peer talks to one EAP server.

  The peer often has a client certificate.  So it's chain can be one longer 
than the server in some cases.

> In network access authentication it is not only about authentication but the 
> most important part is authorization. Hence, you pretty much always have a 
> one-to-one relationship between the EAP peer and the EAP server. There are no 
> good reasons to have complex CA hierarchies here.

  Please tell that to corporations.  :(

  I can't count how many times I've had to tell people "the technology doesn't 
support that", when they explain their business requirements.  It is often 
difficult to get people to understand that their preferred process / methods 
are simply impossible to implement in the real world.

>> This is because EAP peers often
>> follow organizational hierarchies and tend to have many intermediate
>> certificates.  Thus, EAP-TLS authentication usually involve
>> significantly more octets than when TLS is used as part of HTTPS.
>
> I think it would make sense to explain this organizational hierarchy
> aspect in a bit more detail.

  I'm not sure what else could be said here.

>> The EAP fragment size
>> in typical deployments is just 1020 - 1500 octets.
>
> Reference for the 1500 octets.

  Ethernet maximum packet size...

>> For example, many EAP authenticator (access point) implementations
>> will drop an EAP session if it has not finished after
>>  40 - 50 round-trips.
>
> Is there a reference that could be included?

  References to hostap source code.

>> However, deployment
>>  experience has shown that these jumbo frames are not always
>> implemented correctly.
>
> Add a reference here.

  Private communication.  :(

  i.e. I've mediated calls between multiple large companies all pointing the 
finger at each other when things don't work.  The solution was to point out 
that one particular networking box was simply dropping jumbo EAPoL frames.  
Names will not be used here.

>> RADIUS can generally transport only about 4000 octets of EAP in a
>> single message.
>
> How was this number constructed?

  4K RADIUS maximum packet size.  Minus 20 bytes for the RADIUS header 
overhead, 18 for Message-Authenticator, and  for whatever other 
random things the AP vendor includes in packets.

> I am also wondering what you are trying to say here with this
> sentence. Are you saying that you have seen deployments for network access 
> authenticat

Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

[Hannes Tschofenig]

Hi Eliot,

I consider the enterprise and the university case as a roaming model. From an 
EAP method point of view there is IMHO little difference between the roaming 
and the non-roaming case: the EAP exchange always runs between the EAP peer on 
the device and the EAP server.

The IoT case is different because it falls more in the category of  home WiFi 
usage. This doesn’t really use EAP in my understanding.

Ciao
Hannes

From: Eliot Lear 
Sent: Tuesday, March 24, 2020 10:24 AM
To: Hannes Tschofenig 
Cc: Michael Richardson ; emu@ietf.org
Subject: Re: [Emu] My review ... was RE: I-D Action: 
draft-ietf-emu-eaptlscert-02.txt

Hi Hannes


On 24 Mar 2020, at 10:08, Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>> wrote:

Hi Eliot

You bring up a good point, namely the deployment environment. Are we are 
talking about an IoT, an enterprise deployment environment or something else? 
Clearly there will be differences. Reading through the text my impression was 
that this is about an enterprise (or university) deployment environment. I 
might, however, be on the wrong track here.

Since we’re talking about EAP, I can think of a few cases:


  *   Classic enterprise/university case, IoT or not.  I was ASSUMING IoT 
because my brain goes to IOT, but I don’t think it has to be so.
  *   There is also a wifi roaming device model, where EAP might be used in 
various service provider or federated environments a’la Eduroam or similar.  
Today this is NOT a big IoT space, but soon?

The one place this is not a big deal at the moment is in the home, as 
WPA-Personal/PAE is the norm.

One additional question is how big the impact is between wired and wireless.  
Obviously with the former you worry less about interference and drops.

Eliot




Having the references to where deployment problems with large 
certificates/certificate chains occur would shine light on this aspect.

Ciao
Hannes

From: Eliot Lear mailto:l...@cisco.com>>
Sent: Tuesday, March 24, 2020 10:02 AM
To: Hannes Tschofenig 
mailto:hannes.tschofe...@arm.com>>
Cc: Michael Richardson mailto:mcr+i...@sandelman.ca>>; 
emu@ietf.org<mailto:emu@ietf.org>
Subject: Re: [Emu] My review ... was RE: I-D Action: 
draft-ietf-emu-eaptlscert-02.txt

Good morning Hannes







Also,
from deployment experience, EAP peers typically have longer
 certificate chains than servers.

I would like a reference to be included here. Theoretically, it makes no sense 
to
have a certificate chain for an EAP peer to have a longer certificate chain 
than a server
given a EAP peer talks to one EAP server.

In network access authentication it is not only about authentication but the 
most important part is authorization. Hence, you pretty much always have a 
one-to-one relationship between the EAP peer and the EAP server. There are no 
good reasons to have complex CA hierarchies here.

Not sure I entirely understand you.  A few places are promoting new roots for 
manufacturers.  And so the initial chain for a peer might look like 
CA-Root->CA-Intermediate->Mfg  Root->Mfg Intermediate->Device.  I think it may 
be possible to remove one of the intermediates, but probably not both.  It 
seems to me that this is an onboarding problem, and the best way to reduce the 
cert chain size on a day to day basis would be to swap out for an operational 
cert where the trust anchor is within the enterprise.  That means you get one 
of those Big Fat transactions and then things settle down, and that transaction 
may be handled specially anyway.

One comment I have in the draft relates to this text:

   o  Extensions are necessary to comply with [RFC5280], but the vast
  majority are optional.  Include only those that are necessary to
  operate.

This statement is just a little too general.  It very much depends WHICH 
certificate we are discussing.  If it is a manufacturer certificate, as long as 
you can roll to an enterprise cert, then who cares?  If it is an enterprise 
certificate, then we have to look more closely.

So for instance, as Hannes mentions, authorization is a big issue.  Some of 
that can be done outside of the certificate using ACE or similar, but some may 
need to be present in the cert.  What we would rather not have is people 
working the SAN to introduce authorization attributes.

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

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

Re: [Emu] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

[Hannes Tschofenig]

Hi Eliot

You bring up a good point, namely the deployment environment. Are we are 
talking about an IoT, an enterprise deployment environment or something else? 
Clearly there will be differences. Reading through the text my impression was 
that this is about an enterprise (or university) deployment environment.. I 
might, however, be on the wrong track here.

Having the references to where deployment problems with large 
certificates/certificate chains occur would shine light on this aspect.

Ciao
Hannes

From: Eliot Lear 
Sent: Tuesday, March 24, 2020 10:02 AM
To: Hannes Tschofenig 
Cc: Michael Richardson ; emu@ietf.org
Subject: Re: [Emu] My review ... was RE: I-D Action: 
draft-ietf-emu-eaptlscert-02.txt

Good morning Hannes





Also,
from deployment experience, EAP peers typically have longer
 certificate chains than servers.

I would like a reference to be included here. Theoretically, it makes no sense 
to
have a certificate chain for an EAP peer to have a longer certificate chain 
than a server
given a EAP peer talks to one EAP server.

In network access authentication it is not only about authentication but the 
most important part is authorization. Hence, you pretty much always have a 
one-to-one relationship between the EAP peer and the EAP server. There are no 
good reasons to have complex CA hierarchies here.

Not sure I entirely understand you.  A few places are promoting new roots for 
manufacturers.  And so the initial chain for a peer might look like 
CA-Root->CA-Intermediate->Mfg  Root->Mfg Intermediate->Device.  I think it may 
be possible to remove one of the intermediates, but probably not both.  It 
seems to me that this is an onboarding problem, and the best way to reduce the 
cert chain size on a day to day basis would be to swap out for an operational 
cert where the trust anchor is within the enterprise.  That means you get one 
of those Big Fat transactions and then things settle down, and that transaction 
may be handled specially anyway.

One comment I have in the draft relates to this text:

   o  Extensions are necessary to comply with [RFC5280], but the vast
  majority are optional.  Include only those that are necessary to
  operate.

This statement is just a little too general.  It very much depends WHICH 
certificate we are discussing.  If it is a manufacturer certificate, as long as 
you can roll to an enterprise cert, then who cares?  If it is an enterprise 
certificate, then we have to look more closely.

So for instance, as Hannes mentions, authorization is a big issue.  Some of 
that can be done outside of the certificate using ACE or similar, but some may 
need to be present in the cert.  What we would rather not have is people 
working the SAN to introduce authorization attributes.

Eliot
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] My review ... was RE: I-D Action: draft-ietf-emu-eaptlscert-02.txt

[Hannes Tschofenig]

Hi Michael, Hi draft authors,

> I was surprised to get to the end of the document without any suggestions 
> about sending certificates by reference rather than value.

Having seen this statement from Michael I have reviewed the document. Two 
generic observations about the draft:

1) Many statements are made about deployments and no references are provided. 
To improve quality of the write-up I would strongly suggest to add such 
references, as you would have to do with an academic publication as well.

2) A few techniques are missing (Certificate URLs and cTLS) and TLS Cached Info 
was wrongly interpreted.  They actually relate to the remark from Michael.

> TLS certificates are often relatively large, and the certificate
>   chains are often long.

I think this statement is in general incorrect. You could say that in 
deployment X certificates have size X and the chain is Y long.


> Also,
>  from deployment experience, EAP peers typically have longer
>   certificate chains than servers.

I would like a reference to be included here. Theoretically, it makes no sense 
to
have a certificate chain for an EAP peer to have a longer certificate chain 
than a server
given a EAP peer talks to one EAP server.

In network access authentication it is not only about authentication but the 
most important part is authorization. Hence, you pretty much always have a 
one-to-one relationship between the EAP peer and the EAP server. There are no 
good reasons to have complex CA hierarchies here.

> This is because EAP peers often
>  follow organizational hierarchies and tend to have many intermediate
>   certificates.  Thus, EAP-TLS authentication usually involve
>   significantly more octets than when TLS is used as part of HTTPS.

I think it would make sense to explain this organizational hierarchy aspect in 
a bit
more detail.

> The EAP fragment size
>  in typical deployments is just 1020 - 1500 octets.

Reference for the 1500 octets.


> For example, many EAP authenticator (access point)
>  implementations will drop an EAP session if it has not finished after
>   40 - 50 round-trips.

Is there a reference that could be included?

> However, deployment
>   experience has shown that these jumbo frames are not always
>  implemented correctly.

Add a reference here.

> RADIUS can generally transport only about 4000
>  octets of EAP in a single message.

How was this number constructed?

>   A certificate chain (called a certification path in [RFC5280]) can
>   have 2 - 6 intermediate certificates between the end-entity
>   certificate and the trust anchor [RFC5280].

The PKIX reference here is misleading. I think you included it to refer to the 
terms but it sounds like the statement that
the chain can have 2-6 intermediate CA certificates.

I would add the terms to the terminology section and remove the PKIX reference 
here.

I am also wondering what you are trying to say here with this sentence. Are you 
saying that you have seen deployments
for network access authentication that have up to 6 intermediate CA 
certificates in the chain?


> 3.  Experience with Deployments

>   Most common access point implementations drop EAP sessions that do
>   not complete within 50 round-trips.

This sentence is a repetition.

> This means that if the chain is
>  larger than ~ 60 kB, EAP-TLS authentication cannot complete
>  successfully in most deployments.

Regarding the 60 kB certificate chain: Should this be an indication to someone 
deploying
the technology for access network authentication that something has gone wrong?

Is this someone you have observed or is this just a theoretical statement? I 
hope it is the latter.


4.2.1.  Pre-distributing and Omitting CA Certificates


> When using TLS 1.3, all certificates that
> specify a trust anchor known by the other endpoint may be omitted
> (see Section 4.4.2 of [RFC8446]).  When using TLS 1.2 or earlier,
> only the self-signed certificate that specifies the root certificate
> authority may be omitted (see Section 7.4.2 of [RFC5246]

These sentences sound strange.

In TLS (and probably other protocols) it makes no sense to distribute the
trust anchors in the protocol itself (because then they wouldn't serve as an
anchor for trust).

It is my understanding that the TLS 1.3 spec does not require you
to send intermediate CA certificates if they have been provisioned to the peer
out-of-band already. The text in the TLS 1.2 spec is a bit fuzzy and calls out 
that the
self-signed root certificate MAY be omitted but it does not say anything about 
omitting
the other certs.

>4.2.2.  Caching Certificates

There seems to be the misconception that TLS Cached Info requires a full 
exchange to work.
It is the other way around:  If you pre-distribute certificates upfront then 
there is no need
to exchange the certs again. You could just send the fingerprints right away.

A spec, however, has to also cover the bootstrapping problem.

> 4.2.5.  Using Fewer Intermediate Certificates

>   

Re: [Emu] draft-cakulev-emu-eap-ibake

[Hannes Tschofenig]

Hi Violeta, 

On Jan 12, 2012, at 8:41 PM, Cakulev, Violeta (Violeta) wrote:

 Hannes,
 Indeed the I-D currently states Standards Track RFC, but as my original email 
 stated, we are trying to get WG's comments and opinion on the direction we 
 should take. Certainly, if emu WG is not interested we will change the 
 intended status.
 
I personally believe that you will not get the necessary support from the EMU 
working group to get the charter changed and the group interested in IBE. 
I can tell you that I will not spend my time on it. 

My reasons are being less excited are: 
* Identity based crypto as a technology does not really solve a problem. (In 
case you are going to ask: yes I looked it some time ago when I tried to 
figure out what value it provides for some IETF protocols. And guess what - I 
couldn't find any benefits.)
* ETSI wants it is not a good reason for me todo anything.
* I have so many other great documents to review. 
* The IPR situation with identity based crypto makes me feel uneasy. 

 As for 'where to specify it', other standard bodies are still looking to IETF 
 to publish IP-based protocols/methods instead of specifying it in the 
 appendix, which is the reason you've observed it many times in IETF.

For specifications where the policies for extending protocol requires you to 
come to the IETF then you should obviously do that. In case of EAP methods that 
is not needed. That's great - you should be celebrating. If you look around 
there are a couple of other technologies ETSI has been working on where the 
IETF was not involved, such as extensions to Diameter in form of new AVPs and 
new Diameter applications. They had no problems with that either. 

I would even say that specifications should only be published in the IETF 
stream if there is interest by IETF participants. An example from a different 
area: I have seen requests for MIKE key exchange protocols coming to the IETF 
where there was absolutely not interest in the IETF but the policy for new 
MIKEY extension required IETF Standards Track specifications. This lead to the 
publication of specifications that barely anyone reviewed and nobody wants 
(other than the authors). Needless to say that I have my doubts about the 
bright deployment future of these protocols. 

Ciao
Hannes

PS: Consider my public feedback as a friendly advice that will help you save a 
few years of work.

 
 -Violeta
 
 
 -Original Message-
 From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net]
 Sent: Thursday, January 12, 2012 12:43 PM
 To: Cakulev, Violeta (Violeta)
 Cc: Hannes Tschofenig; Tschofenig, Hannes (NSN - FI/Espoo); emu@ietf.org
 Subject: Re: [Emu] draft-cakulev-emu-eap-ibake
 
 Hi Violeta,
 
 I am unfortunately familiar with the details of the ETSI Machine-to-Machine 
 specifications to judge whether your draft meets their design requirements 
 and fits into their architecture. I am sure lots of experts in ETSI have 
 looked at this problem and have made a thoughtful decision. I wish them good 
 luck deploying all their stuff.
 
 Having said that I feel that you are likely going into a problem that I have 
 observed many times in the IETF: folks typically want to understand the 
 problem they are trying to solve and they tend to be unsatisfied with the 
 response ETSI needs it..
 
 Luckily things are looking good for you: If you do not seek publication of 
 this EAP method as a Standards Track RFC then the process is fairly simple. 
 In fact, you do not even go through the IETF to get a method ID. You can just 
 dump the draft text into the appendix of the ETSI specification, drop IANA a 
 mail, and you are done with it.
 
 The story is quite different if you want to get this standardized as a 
 Standards Track RFC (which is what your draft currently says).
 
 Ciao
 Hannes
 
 On Jan 12, 2012, at 5:57 PM, Cakulev, Violeta (Violeta) wrote:
 
 Hannes,
 Thanks for the comments/opinions.
 
 While soliciting comments from CORE on EAP-IBAKE and bootstrapping in 
 general would be most certainly helpful, ETSI M2M already concluded 
 discussions on the choice of bootstrapping methods.
 Both stage 2 (ETSI 102 690) and stage 3 (ETSI 102 921) are frozen and new 
 methods will not be taken into consideration for rel. 1.
 
 Given that EAP-IBAKE is a bootstrapping method in these specifications, we 
 are trying to ensure appropriate review and timely publication of EAP-IBAKE 
 I-D.
 
 Regards,
 
 -Violeta
 
 -Original Message-
 From: Tschofenig, Hannes (NSN - FI/Espoo) [mailto:hannes.tschofe...@nsn.com]
 Sent: Thursday, January 12, 2012 10:23 AM
 To: Cakulev, Violeta (Violeta); emu@ietf.org
 Subject: RE: [Emu] draft-cakulev-emu-eap-ibake
 
 Hi Violeta,
 
 I believe it would be useful to solicit comments from a working group
 like CORE, who works on this smart object space. In that group folks had
 come up with their ideas on how to bootstrap security for these types of
 devices. Of course, it has nothing to-do with identity

Re: [Emu] Crypto Binding: MITM and draft-ietf-emu-eap-tunnel-method

[Hannes Tschofenig]

Hi Sam, 

let us start with the problem description: You claim that EAP peer 
implementations use PK-based authentication but do not do certificate 
validation. This obviously introduces attacks (regardless of channel bindings, 
or crypto bindings). 

Any evidence that this is really a problem? And if it is a problem why that 
cannot be fixed with a software update. If you chose a specific EAP method then 
you obviously have to deploy the necessary credentials and parameters at both 
end points in order for it to work. 

Ciao
Hannes

PS: You are sometimes a bit relaxed with your terminology. Whenever you talk 
about client and server you need to qualify that further because there are 
multiple clients and servers involved in this three party exchange. 

On Jan 11, 2012, at 10:33 PM, Sam Hartman wrote:

 
 I'd like to thank Margaret Wasserman for coming up with a series of
 proposed attacks that lead to the following comments.
 
 
 In the context of implementing channel binding and a system that takes
 advantage of it, I've been focusing on MITM attacks. I'd like to give a
 example of the sorts of attacks that are worrying me.  I thought these
 were supposed to be solved by crypto binding, but I no longer think that
 existing implementation of crypto binding are strong enough.
 
 First, in a channel binding world, some NASes are significantly more
 trusted than others. In my ABFAB world that's especially true.
 
 We have clients using EAP-TTLS as a tunnel method with some inner
 password method (MSCHAPv2, some PAKE method, whatever. We'll assume that
 it generates a key.) We're adding support the EAP-TTLS for channel
 binding. That's realistic and is consistent with the approach we've been
 trying to standardize. We want the tunnel methods to support channel
 binding and perform the channel binding exchange there so we don't have
 to modify all EAP methods. NEA needs something similar for data they
 plan to transport over EAP.
 
 Consider a compromised print server. It would like to impersonate
 someone's bank. (In an ABFAb world, EAP is used for things other than
 network access. I can construct a network access version of this attack
 if you'd like too.)
 
 The print server  impersonates the bank enough to get the client to
 connect to it. It then starts authentication. We're using ABFAB to
 authenticate the client to the server and the server to the client. The
 user indicates their home realm in an identity response. 
 The print server, like the bank is a valid participant in the AAA
 fabric. So it sends an access-request to the home EAP server and gets a
 method request.
 
 In this attack the home EAP server uses TTLS. However the print server
 wants to MITM the TTLS tunnel.  So, while the print server sends the
 first TTLS packet towards the client, it sends a EAP NACK towards the
 home EAP server requesting the appropriate inner password method.
 
 So, we start to establish a EAP tunnel between the client and the print
 server and an inner method between the client and the home EAP server.
 Things will fail if the client validates the tunnel certificate.
 
 However if the client goes forward,  then the authentication will
 succeed at the inner method level.
 
 Then, assuming we're using TTLSv1, the client will do crypto
 binding. Intuitively you'd kind of think that crypto binding would help
 here; I'll discuss in a bit whether it's supposed to. It's quite clear
 it doesn't though. Crypto binding uses the MSK of the inner method for
 the binding. However, as part of the access-accept, the home EAP server
 discloses the MSK to the print server.  So, the print server has the
 material it needs to perform crypto binding and the generate the final
 MSK.
 
 Then the client performs channel binding to confirm that it's talking to
 the bank. The print server  is happy to tell the client that the print
 server is in fact a bank, so the attack succeeds.
 
 For the most part, this is a classic compound authentication attack. If
 the inner method had not been offered outside the tunnel, the attack
 generally would not be possible. If different credentials are used, when
 the method is used inside a tunnel vs outside the attack is not
 possible. As stated earlier, this particular instance of the attack  is
 not possible if the client verifies the TTLS certificate. There are also
 ABFAB-specific mitigations that do not generally apply to network
 access.
 
 However, the client does have a secure connection to the home EAP
 server. Intuitively, we do not actually need to require checking the
 certificate to provide security against this. If the credential is weak
 and can be attacked with a passive dictionary attack, then other attacks
 may be possible if the client does not check the certificate. However if
 we're using a good PAKE method as an inner method and only using the
 tunnel for carrying tunneled attributes such as channel binding, there's
 absolutely no reason the security of the system needs to depend 

Re: [Emu] Draft agenda for IETF 74

[Hannes Tschofenig]

Hi Alan, 

a few questions inline. What is more important for me is what we could at
best accomplish during the meeting. 

  The following is the draft agenda for IETF 74.  Please email 
the chairs for any concerns or updates.



Blue sheets and Agenda updates
5 minutes

draft-ietf-emu-eaptunnel-req-02.txt
60 minutes

Do we really need 60 minutes for this document? 
What are the open issues with this document? (sorry if I haven't paid close
attention). 



draft-clancy-emu-chbind-04.txt
25 minutes

I guess this is now draft-ietf-emu-chbind-00
I see TBDs in the document - are those the only open issues? 



draft-clancy-emu-aaapay-01.txt
10 minutes

I understand the issue of defining channel bindings.
draft-ietf-emu-chbind-00 does this but it does not define payloads. 
Do we really need to split this aspect into separate drafts? 

The aspect of having the possibility to carry an opaque blob in EAP (based
on a Diameter AVP) format is a totally different subject. 


 draft-sheffer-emu-eap-eke-01
10 minutes

This is a document that has a relationship to a charter item :-)
 

Ciao
Hannes


Closing comments
10 minutes
___
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] Review of draft-ietf-emu-eap-gpsk-08 (1st round of comments)

[Hannes Tschofenig]

Hi Pasi,

thanks for the new round of comments.

[EMAIL PROTECTED] wrote:

Charles Clancy wrote:

  

See comments inline.  An updated draft will be released shortly.
Also note that the new draft addresses Dan's comments about
resistance to dictionary attack.  



Thanks for the update! I have some additional comments (see below),
but they should be easy to address.

  

S4, EAP_Method_Type refers to the integer value of the IANA
allocated EAP Type code, ...to the EAP type code (1 byte),
specified in Section XX?
  

I don't think it's ever been clear how to reference the IANA
allocated EAP type code in an I-D before it's been allocated.  These
are things that would be fixed by the RFC Editor or in AUTH48, once
IANA has allocated the type code.



For clarity, I'd still suggest adding the (1 octet) part (although
someone reading RFC 3748 will of course figure out that it's 1 octet).

  

Does this sound better:

EAP_Method_Type refers to the 1-octet IANA allocated EAP Type code value.



S6 and elsewhere: Several places in the document assume that KS
(key size of the ciphersuite) is always the same as the MAC output
length.  This would make it difficult to define ciphersuites based
on e.g. AES-CMAC-256. If this restriction is intentional (and WG
is happy with it), at the very least it needs to be emphasized
much more.
  

I'm not sure what AES-CMAC-256 means.  RFC 4493 defines CMAC
specifically for 128 length AES, so if you wanted to something
involving 256, you'd need to define exactly what AES-CMAC-256 was,
and I imagine it would have a 256-bit input and a 256-bit output.
Regardless, I added a statement in the key derivation section saying
the input and output lengths of your ciphersuite must be equal.



As Dan Harkins already pointed out, NIST 800-38B does define CMAC 
for 256-bit AES, with 256-bit key and 128-bit output.


So hardcoding this assumption in EAP-GPSK seems to limit the future
algorithm agility somewhat -- is the WG sure this is an acceptable
limitation?

(If this limitation is kept, I'd suggest mentioning in Section 2
that KS is not only the key size, but also MAC output length.)

  

This seems to require a separate discussion on the list.


S5 and S8.2 are not consistent about ciphersuite formatting (is
enterprise number 3 or 4 octets; if you're not sure, suggest
doing what RFC3748 did)
  

Fixed (should be 4).



  
Figure 3 in S6 still assumes it's 3.


  

Fixed the figure.


+++-+--++
| CSuite/| KS | Encryption  | Integrity /  | Key Derivation |
| Specifier  || | KDF MAC  | Function   |
+++-+--++
| 0x0001 | 16 | AES-CBC-128 | AES-CMAC-128 | GKDF   |
+++-+--++
| 0x0002 | 32 | NULL| HMAC-SHA256  | GKDF   |
+++-+--++



S8.4, text and bit diagram are not consistent about whether
enterprise code is 3 or 4 bytes
  

Text consistent with length 4 enterprise code.



The 1st figure (now in S9.4) still shows 3 octets; so does the text 
at end of S9.4, and IANA considerations text for PData/Specifier.


  

Done.


S9, If the MAC validation fails, the server MUST transmit a
GPSK-Fail message specifying Authentication Failure and discard
the received packet. Not quite sure what discard the received
packet here exactly means in the context of EAP state machine (If
the server sends a reply, it's not discarding the packet as such).
  

Fixed.



It seems this text was not changed at all? 

  

Done.

Interoperability requires the ability to enter same PSK in 
both client and server. See e.g. RFC4306 S2.15 and RFC4279 S5.4 
for examples of management interface requirements.
  

Added.



The text (Section 5) should probably say something about non-ASCII
characters, especially since NAIs can contain them (and IETF policies
usually require dealing with non-ASCII in strings handled by ordinary
users -- RFC4306/4279 are probably mostly for admins).

Maybe SHOULD support non-ASCII, with pointer to detailed instructions 
in Section 2.4 of RFC 4282?



  


Fixed.



Addtional comments:

S2, PL: would help reading if it said PL must be = KS (it's said
in S6, but this assumption is already needed in S4).
  

Done.


S3, should also mention GPSK-Fail and GPSK-Protected-Fail messages
for completeness (in additino to GPSK-1...4).
  

Ok.


S4, how is PL encoded when input to KDF? (1 octet, 2 octets?)

  

2 octets.



S9.3, from the ID_Client length - from the ID_Peer length

  

OK


S11, GPSK-3 and GPSK-Fail are distinct message Op-Codes, so showing
e.g. EAP-Request/GPSK-3 (GPSK-Fail (PSK Not Found or Authentication
Failure)) is confusing. Should be just EAP-Request/GPSK-Fail 

  

OK

S12.1, the references to sections 11.* should be to 12.* (and some 
of the subsection 

Re: [Emu] new I-D on password-authenticated EAP method

[Hannes Tschofenig]

To continue on the previous discussions about this subject (with a 
different subject):

a) I believe the document does not do a good job in describing where you 
plan to use this method in comparison to the already ongoing work on 
tunneled mechanisms.

To quote Bernard on a previous mailing list thread (see mail thread 
about Thoughts on Password-based EAP Methods from March 2007, at 
http://www.ietf.org/mail-archive/web/emu/current/msg00476.html)

  I am concerned that by defining yet another password-based
  authentication mechanism,



I understood that Bernard has a different opinion now and maybe his comment was 
influenced in other ways back then in the style of 
... there we discussed tunneled methods and not password based methods in 
general ... 


b) Assuming that bullet (a) provides a reasonable argument I believe 
that the suggested approach is wrong.

Ciao
Hannes

Dan Harkins wrote:
   Hello,

   There's a new I-D in the Internet-Drafts database called
 draft-harkins-emu-eap-pwd-00.txt. It describes a new method
 for authentication using only a password. It provides resistance
 to active attack, passive attack, and dictionary attack. It
 also provides forward secrecy and an authenticated key (not just
 a shared key between authenticated entities).

   Please take a look and send comments to the authors.

   regards,

   Dan.



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

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

Re: [Emu] EMU Charter revision

[Hannes Tschofenig]

Hi Bernard,

Bernard Aboba wrote:
 Zero knowledge is definitely crypto-intensive.  For example, to get both 
 privacy and strong password protection, at least two DHs are required. 

 However, there are circumstances where server-side certificates aren't 
 acceptable.  Even in today, many/(most?) EAP deployments do not involve 
 certificates (e.g. LEAP, FAST). 
The good thing is that the approach would work with even a self-signed 
certificate since there is a big difference between the certificates 
used in the Web environment and for network access. In the former case 
you want to make sure that the browser with any webserver on the 
Internet. This is an any-to-any relationship. For network access you 
have a many-to-one relationship.

   Even if zero knowledge isn't used on an ongoing basis (out of concern for 
 load, for example), it still can be useful for initial provisioning.
Provisioning the initial security is an entirely different problem. EAP 
is the wrong way todo that.
See for example the interesting work done in the KEYPROV working group.

   For example, EAP FAST provisioning is vulnerable to man-in-the-middle 
 attack or dictionary attack, which could be removed with use of zero 
 knowledge algorithms.
   
Need to look at this aspect of the draft again.

Ciao
Hannes

 Subject: AW: [Emu] EMU Charter revision
 Date: Fri, 22 Feb 2008 15:34:56 +0100
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]; emu@ietf.org










 Hi Bernard,
  
 a question your excitment regarding strong password based EAP 
 method. 
  
 Why do you think they are useful? There are other ways (and they 
 are deployed already) that can accomplish the same result without going 
 along the SRP  co track. 
 Is it because you expect performance improvements or because the 
 crypto-mechanisms look nicer? 
  
 I cannot quite understand the motivation. 
  
 Ciao
 Hannes

   
   
   Von: [EMAIL PROTECTED] 
   [mailto:[EMAIL PROTECTED] Im Auftrag von ext Bernard 
   Aboba
 Gesendet: Donnerstag, 21. Februar 2008 21:54
 An: 
   emu@ietf.org
 Betreff: Re: [Emu] EMU Charter 
   revision


   I also do NOT approve of the current charter revision, for several 
   reasons:

 a.  The Charter text contains statements that are no 
   longer true.  For example:
 Most of these methods are proprietary methods and only a few methods 
 are documented in RFCs.

 The following EAP methods are now documented in RFCs:

 EAP-TLS (RFC 2716)
 EAP-SIM (RFC 4186)
 EAP-AKA (RFC 4187)
 EAP-PAX (RFC 4746)
 EAP-SAKE (RFC 4763)
 EAP-PSK (RFC 4764)
 EAP-POTP (RFC 4793)
 EAP-FAST (RFC 4851)
 EAP-IKEv2 (RFC 5106)

 9 methods claiming to satify RFC 4017 critieria is more than a few. 

 b. The Charter requires support for Channel Bindings without doing the
 preparatory work to define how Channel Bindings works.  Either the
 requirement should be removed, or a work item should be added to 
 better define the approach to Channel Bindings. 

 c. The text on tunnel methods does not provide enough guidance to avoid
 potentially fruitless arguments.  So far, the EMU WG has not been able
 to come to consensus on selection of one of the existing tunneling
 protocols, and efforts to design yet another tunneling protocol 
 haven't gotten very far either.  I'd like to see more specific 
 language that would make it clear that work on improving existing
 tunneling protocols is within scope, and also that the EMU WG,
 if it cannot come to consensus on a single protocol, can proceed to 
 work on one or more protocols with significant support.  

 d. Password-based methods.  While I can understand the desire to limit the
 number of charter items, I do agree with Dan that work on weak-password
 methods is important.  With some of the IPR obstacles likely to fall by
 the wayside in coming years, it is time for the IETF to re-visit its policy
 on inclusion of zero knowledge algorithms within standards track documents. 
 Dan 
   Harkins said:

  Hi Joe,

   I do NOT approve of the current charter revision, specifically the
 change that says the password-based method can only be via the
 tunneled method. I do approve of the inclusion of tunneled methods
 in the charter though and would be willing to contribute as a
 reviewer.

   regards,

   Dan.
 On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey) wrote:
   
 The response to the charter revision has been underwhelming.  I am a bit
 concerned that we do not have enough participation to complete the
 tunnel method work (most of the recent discussion has been about other
 methods).

 I would like to get an idea of the number working group members that
 approve of working on the tunnel method items and are able to
 participate in the development of requirements and specifications as
 contributors and/or reviewers.

 Please respond to this message and state whether you approve of the
 current charter revision and what capacity you would be willing to
 contribute towards tunneled method development: contributor, reviewer 

Re: [Emu] EMU Charter revision

[Hannes Tschofenig]

Hi Dan,

you are asking me which EAP methods support weak passwords?

If so, here are a few examples:
* TTLS
* PEAP
* EAP-PAX
* EAP-FAST
* EAP-IKEv2

Please note that I am not against doing the work; I would just like to 
understand what the main motivation is.

Ciao
Hannes

Dan Harkins wrote:
   Hi Hannes,

   What are these methods? And is their security completely based
 on an assumption that the one deploying this method is following
 some strict regime (e.g. no weak passwords)?

   regards,

   Dan.

 On Fri, February 22, 2008 6:34 am, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
   
 Hi Bernard,

 a question your excitment regarding strong password based EAP method.

 Why do you think they are useful? There are other ways (and they are
 deployed already) that can accomplish the same result without going
 along the SRP  co track.
 Is it because you expect performance improvements or because the
 crypto-mechanisms look nicer?

 I cannot quite understand the motivation.

 Ciao
 Hannes

 

  Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im
 Auftrag von ext Bernard Aboba
  Gesendet: Donnerstag, 21. Februar 2008 21:54
  An: emu@ietf.org
  Betreff: Re: [Emu] EMU Charter revision


  I also do NOT approve of the current charter revision, for
 several reasons:

  a.  The Charter text contains statements that are no longer
 true.  For example:

  Most of these methods are proprietary methods and only a few
 methods
  are documented in RFCs.

  The following EAP methods are now documented in RFCs:

  EAP-TLS (RFC 2716)
  EAP-SIM (RFC 4186)
  EAP-AKA (RFC 4187)
  EAP-PAX (RFC 4746)
  EAP-SAKE (RFC 4763)
  EAP-PSK (RFC 4764)
  EAP-POTP (RFC 4793)
  EAP-FAST (RFC 4851)
  EAP-IKEv2 (RFC 5106)

 



  9 methods claiming to satify RFC 4017 critieria is more than a
 few.

  b. The Charter requires support for Channel Bindings without
 doing the
  preparatory work to define how Channel Bindings works.  Either
 the
  requirement should be removed, or a work item should be added to

  better define the approach to Channel Bindings.

  c. The text on tunnel methods does not provide enough guidance
 to avoid
  potentially fruitless arguments.  So far, the EMU WG has not
 been able
  to come to consensus on selection of one of the existing
 tunneling
  protocols, and efforts to design yet another tunneling
 protocol
  haven't gotten very far either.  I'd like to see more specific
  language that would make it clear that work on improving
 existing
  tunneling protocols is within scope, and also that the EMU WG,
  if it cannot come to consensus on a single protocol, can proceed
 to
  work on one or more protocols with significant support.

  d. Password-based methods.  While I can understand the desire to
 limit the
  number of charter items, I do agree with Dan that work on
 weak-password
  methods is important.  With some of the IPR obstacles likely to
 fall by
  the wayside in coming years, it is time for the IETF to re-visit
 its policy
  on inclusion of zero knowledge algorithms within standards
 track documents.
  Dan Harkins said:

   Hi Joe,


I do NOT approve of the current charter revision, specifically
 the
  change that says the password-based method can only be via the
  tunneled method. I do approve of the inclusion of tunneled
 methods
  in the charter though and would be willing to contribute as a
  reviewer.

regards,

Dan.
  On Tue, February 19, 2008 11:14 am, Joseph Salowey (jsalowey)
 wrote:
   The response to the charter revision has been underwhelming.
 I am a bit
   concerned that we do not have enough participation to complete
 the
   tunnel method work (most of the recent discussion has been
 about other
   methods).
  
   I would like to get an idea of the number working group
 members that
   approve of working on the tunnel method items and are able to
   participate in the development of requirements and
 specifications as
   contributors and/or reviewers.
  
   Please respond to this message and state whether you approve
 of the
   current charter revision and what capacity you would be
 willing to
   contribute towards tunneled method development: contributor,
 reviewer or
   not able to contribute.
  
   I have submitted an internet draft attempt at an outline of
 requirements
   for tunneled methods
  
 (http://www.ietf.org/internet-drafts/draft-salowey-emu-eaptunnel-req-00.
   txt) that I hope can provided a starting point for discussions
 on the
   list and in the Philadelphia meeting.
  
   Thanks,
  
   Joe


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

 


 

Re: [Emu] Draft Agenda for IETF-71

[Hannes Tschofenig]

 + Channel Bindings (20 min)
  - draft-clancy-emu-chbind-00.txt
  - draft-clancy-emu-aaapay-00.txt

   
I haven't seen these documents and I cannot find them either

do you have pointers to them?


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

[Emu] Next Steps on Passwd-based EAP Methods

[Hannes Tschofenig]

Hi all,

before we spend more time considering EAP tunneling methods like PEAP 
and TTLS I would like to hear the opinion of our ADs on this subject.
So far, the working assumption was that EAP methods that tunnel EAP are 
outside the scope of the working group. These statements were also 
repeated during the IETF#68 EMU WG meeting by our ADs.


We seem to change the assumptions on the fly.

Ciao
Hannes


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

Re: [Emu] Thoughts on Password-based EAP Methods

[Hannes Tschofenig]

I see it a bit differently since I was at many EAP meetings where EAP 
method authors wanted to work on standards track EAP methods.


Ciao
Hannes

Bernard Aboba wrote:
Part of the problem with EAP methods is that people should have 
started to standardize them within the IETF several years ago. 
Unfortunately, there was no interest by some of the EAP method 
authors nor from the EAP WG chairs to allow that.


In fact, the IETF was on track to standardize EAP methods back as 
recently as 2001, within the PPPEXT WG.  It was as part of that 
program that EAP-TLS was first published as an Experimental RFC, and 
EAP-TTLSv0 was put on the standards track.


The decision to remove standards track EAP methods from the PPPEXT WG 
charter was made by the IESG, not by the authors of EAP methods, or 
the EAP WG chairs.  As I recall, there was considerable opposition to 
that decision at the time.




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



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

Re: [Emu] Next Steps on Passwd-based EAP Methods

[Hannes Tschofenig]

I also need to say that at the IETF#68 EMU WG meeting the discussions in 
the room where pretty positive for moving forward with a simple 
password-based EAP method using TLS without another EAP encapsulation on 
top of TLS. I also got the impression after the session that the people 
in the room where happy with the tentative decisions we made. I had a 
clear picture in mind how to move forward with the work on this topic.


I only recall a single person in the room that raised some concerns.

Ciao
Hannes

PS: To clarify my position: I also have no problem with working on 
TTLSv1 (as I expressed on the DT mailing list). This would, however, 
require the TLS working group to work on the TLS Inner Application, 
which I also think is useful. This approach was, however, ruled out by 
the ADs.


Hannes Tschofenig wrote:

Hi all,

before we spend more time considering EAP tunneling methods like PEAP 
and TTLS I would like to hear the opinion of our ADs on this subject.
So far, the working assumption was that EAP methods that tunnel EAP 
are outside the scope of the working group. These statements were also 
repeated during the IETF#68 EMU WG meeting by our ADs.


We seem to change the assumptions on the fly.

Ciao
Hannes


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



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

Re: [Emu] Re: Thoughts on Password-based EAP Methods

[Hannes Tschofenig]

I am not surprised to hear that EAP method authors agree that no further 
EAP methods should be developed.
Part of the problem with EAP methods is that people should have started 
to standardize them within the IETF several years ago. Unfortunately, 
there was no interest by some of the EAP method authors nor from the EAP 
WG chairs to allow that.


But if some (unknown) customers say that they do not want more EAP 
methods then Sam will have to change his mind. At the last IETF meeting 
he ruled out the usage of TTLS, for example.


I hope that the some people can change their mind with regard to the 
applicability statement of EAP usage in TLS so quickly as well


~snip~


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

Re: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?

[Hannes Tschofenig]

We discussed this already several times and this lead me to work on a 
draft together with Thomas Otto:


http://tools.ietf.org/id/draft-otto-emu-eap-tls-psk-02.txt

Ciao
Hannes

Narayanan, Vidya wrote:

All,
I have a question on support for the TLS PSK ciphersuites in EAP-TLS.
Looking at the message flow in section 2.1.1, I don't see any reason why
the TLS PSK ciphersuites, as specified in RFC4279, cannot be used with
it, but, the optional TLS elements are not immediately clear from it and
hence, the question. 


Thanks,
Vidya

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



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

Re: [Emu] WGLC: Review of draft-ietf-emu-eap-gpsk-03

[Hannes Tschofenig]

Hi Vidya,

just a quick comment.

Narayanan, Vidya wrote:

All,
I reviewed the document and unfortunately, don't feel it is ready for
publication yet. I will only get into the meta issues here - nits can be
addressed later. 

Major Comments: 
---

1. Overall, I'm looking for a compelling reason to have another EAP
method and I found none in the document. For instance, all the design
goals listed seem to be satisfied by EAP-TLS-PSK (inclusion of protected
payloads can be done as an extension to TLS as well). And, given that
EAP-TLS-PSK is an incremental change to EAP-TLS, it would be much more
compelling to use EAP-TLS-PSK than EAP-GPSK. So, is there at least one
design goal of GPSK that cannot be met by other methods? 

  


You must be kidding.

We worked on this several months within a design team. The design team 
concluded that a new EAP method is the right direction. Then, the result 
of the design team was confirmed by working group a long time ago.


Now, in WGLC you raise your voice although you and Lakshminath actively 
participate in the working group (with Lakshminath even being a design 
team member).


I will address your comments after I recovered from a flu.

Ciao
Hannes



2. Are the EAP and GPSK headers integrity protected? The SEC_SK
construction in various places does not seem to imply so - I don't think
that is the intention, as those headers must be integrity protected. 


3. The message, GPSK-4, seems to be there since an EAP Response is
needed after an EAP Request. However, this seems to lead to a couple of
things - a) a potentially empty message sent with a MAC (what is the MAC
calculated on?), b) having the client to reflect back a failure message
in the event of a failure. I think if the EAP and GPSK headers are
protected with a MAC, we should be okay with this. 


4. Is there a reference to GKDF? I'm wondering why we are advocating the
use of hash functions as KDFs instead of HMACs. I have more questions on
the derivation of MK and other keys, but, I'll wait for the
clarification on GKDF before I ask those. 


5. Is the PK always derived? Having a PK for the case where the
encryption algorithm is NULL (in Ciphersuite 2, for instance), doesn't
seem to be of any value. This actually brings up a question on the need
to define the KDFs the way this document has. For instance, the 2*KS
value seems to be there to determine the KDF length, with the assumption
that the encryption and integrity key lengths required for the
ciphersuites are equal. A better construction seems to be along the
lines of IKEv2's prf+, that can produce keys of variable lengths. Was
this considered and if so, why was the GKDF construction as defined seen
as a better way to go? 


Not-so-major Comments:

6. The document seems to re-naming some EAP terminology. I don't think
there is a need to do that. 


7. Section 8 says Any packet that cannot be parsed by the EAP client or
the EAP server MUST be silently discarded - this seems to be defining
EAP behavior. In other words, if the packet cannot even be parsed as a
GPSK packet, EAP will be discarding that packet, not GPSK. 


Thanks,
Vidya

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



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

[Emu] EAP-GPSK Draft Update

[Hannes Tschofenig]

Hi all,

based on the feedback of Victor and Jouni we have updated the draft.

Please find the updated draft here:
http://www.tschofenig.com/svn/draft-clancy-emu-eap-gpsk/draft-ietf-emu-eap-gpsk-03.txt 



We believe that the draft is ready for WGLC.

Ciao
Hannes



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

Re: [Emu] GPSK Issue - Identity in key derivation

[Hannes Tschofenig]

Hi Joe,

this was recorded as issue#4:

http://www.tschofenig.com:8080/eap-gpsk/issue4

I think that we should put a separator in there.

Ciao
Hannes


Joseph Salowey (jsalowey) schrieb:

There currently is no separator between the identities in the GPSK key
derivation which means that 'a || bc' and 'ab || c' would produce same
keys.  It seems this can be addressed by including the length as part of
the identity or inserting a delimiter between identities. 


It seems that including the lengths as part of the identity would be
fine.  Any objections?

Thanks,

Joe

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





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

Re: [Emu] GPSK Issue - Identity in key derivation

[Hannes Tschofenig]

We could also use the null character as separator.


Ciao
Hannes

M. Vanderveen schrieb:
I have heard from folks who actually implemented such key derivations 
that the null character would work just as well.


*/Joseph Salowey (jsalowey) [EMAIL PROTECTED]/* wrote:

There currently is no separator between the identities in the GPSK key
derivation which means that 'a || bc' and 'ab || c' would produce same
keys. It seems this can be addressed by including the length as part of
the identity or inserting a delimiter between identities.

It seems that including the lengths as part of the identity would be
fine. Any objections?

Thanks,

Joe

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



Do you Yahoo!?
Get on board. You're invited 
http://us.rd.yahoo.com/evt=40791/*http://advision.webevents.yahoo.com/mailbeta 
to try the new Yahoo! Mail.





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



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

[Emu] EAP-GPSK: Ciphersuites

[Hannes Tschofenig]

Hi all,

the current version of the document
http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01.txt
still supports AES-EAX:

   +---++-+---++
   | CSuite/   | KS | Encryption  | Integrity | Key Derivation |
   | Specifier || |   | Function   |
   +---++-+---++
   | 0x01  | 16 | AES-EAX-128 | AES-CMAC-128  | GKDF-128   |
   +---++-+---++

At the IETF#66 EMU meeting AES CCM was suggested.

Later, it got the impression that AES-CBC was more appreciated. Should 
we update the draft with AES-CBC?


Ciao
Hannes


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

Re: [Emu] Review of draft-clancy-emu-eap-shared-secret-01

[Hannes Tschofenig]

Hi Michaela,


M. Vanderveen wrote:
I agree with Lakshminath regarding the point about having actual 
ciphersuites in a different RFC, so they can be updated.


I don't agree. Why would this be useful? You then have to read two 
documents to implement the EAP method. It would be the same as putting 
the packet format in another document.


New ciphersuites can be added later. They would be in a separate document.

 
Personally I'm somewhat disappointed that AES-EAX was chosen, even 
though it's fame is that is simpler than CCM, which is what 802.11i 
proposes. Not having participated in the discussions on algorithm 
selection, I am wondering if anybody have given thought to what can be 
done to help the power and memory-limited mobile, who now has to have 
*hardware* to please everybody: the EAP for network access, SAP 4-way 
handshake for link-layer access, MobileIP for mobility, VPN to sooothe 
operator concerns, etc, to name a few possibilities. Not all of these 
must be done in hw, of course. What do the implementors have to say 
about these?
There was a discussion about this issue during today's meeting. There 
was indeed tendency to avoid EAX usage and focus on CCM instead.


Ciao
Hannes

 
Michaela


*/Lakshminath Dondeti [EMAIL PROTECTED]/* wrote:

 
  EAP-GPSK offers cryptographic flexibility. At the beginning, the
  EAP server selects a set of cryptographic algorithms and key
  sizes, a so called ciphersuite. The current version of EAP-GPSK
  comprises two ciphersuites, but additional ones can be easily
  added.

Do we mean server proposes a suite of algms and the client selects
one? We probably need to think about the ciphersuite thing a
bit. Perhaps the IKEv2 like approach of the base protocol nailed
down in a document and have a living RFC that updates ciphersuites
as necessary.


Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta. 
http://us.rd.yahoo.com/evt=42241/*http://advision.webevents.yahoo.com/handraisers 






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



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

Re: [Emu] EAP-GPSK comments

[Hannes Tschofenig]

Hi Jouni,

thanks for the detailed comments. Please find my response inline:

Jouni Malinen wrote:

draft-clancy-emu-eap-shared-secret-00.txt

KDFData:

What defines the arbitrary data (KDFData_Client and KDFData_Server)
that is to be included in the KDF? What is this used for? Chapter 7.4
defines a mechanism for server and peer to send Extra KDF Data to
allow binding data into the key derivation process. However, that
looks like any data could be sent and the server/peer would just
include it as a seed for KDF. Wouldn't this data need to be specified
somehow and used for something else than just an arbitrary seeding
material (e.g., export an identity or whatever else could be bound
here). The current draft does not seem to describe clearly how this is
to be used.


The idea was that you would bind some data that is being exchanged 
between the peer and the server to the keys by including them into the 
key derivation function.


I never saw this functionality being useful but some design team members 
liked it. It was added very late in the draft writing process. Hence, I 
guess there are some loose ends.


I personally wouldn't mind removing it again. I am missing the uses cases.



7.4: If multiple entries are specified in a single PD_Payload with
PData/Specifier 3, then the first field must be used.
Is there any case where there would be more than one such entry?
Shouldn't that be just specified as an invalid message (MUST silently
ignore the packet?) instead of ignoring the extra entries that should
not have been there in the first place.

Chapter 4 seems to concatenate KDFData_Client and KDFData_Server into
the generic MSK and EMSK derivation. However, the cipher suite
specific derivation (6.1.3 and 6.2.3) does not. Was that on purpose?



This question is related to the previous one.

The reason for not including the KDFDATA into all KDFs is that we need 
the keys before the KDFDATA is exchanged.



Added an issue for this aspect:
http://www.tschofenig.com:8080/eap-gpsk/issue3




ID Server/Client in key derivation:

Variable length ID_Server and ID_Client are concatenated in MK and
KDF_out derivation. This means that there is no explicitly specified
boundary between these fields and different values can produce same
keys (e.g., 'a || bc' and 'ab || c' would produce same keys). Should
ID_Server/Client length be prefixed as 16-bit value before the ID
value to make Server/Client ID boundary explicit? Alternatively 0x00
could be used as a delimiter (assuming it is not allowed in either ID
string).

Do you see an attack if we don't use a delimiter?

Added an issue:
http://www.tschofenig.com:8080/eap-gpsk/issue4




Failure reporting:

What is the server/peer to do when something fails? For example, what
if GPSK-1 does not include a supported ciphersuite.  What would peer
send in response? There does not seem to be an error message defined
for this purpose. Similar comments applies to other messages, i.e.,
behavior for error cases should be defined.



There is a mandatory to implement ciphersuite (i.e., Ciphersuite 1) and 
hence this case cannot happen.


Do you have other failure cases in mind?






GKDF-X(Y, Z) definition (Chap. 5):

s%n = int( X / size ) + 1%n = int( (X + size - 1) / size)%
 (previous version would have one extra operation if X mod size = 0)

Need to define how many octets are used for i and X in input to MAC_Y.
Is this two octets in network byte order?


I am not so sure to what text you are referring.




Input to Integrity MAC (6.1.2 and 6.2.2):

SEC_SK is the definition of how plaintext + MAC are concatenated, so
it does not look like the correct input for MAC. Should Value of
SEC_SK in message GPSK-# be replaced with Payload of message
GPSK-#? Based on other parts of the draft, it looks like this input
should be the data following OP-Code in the message.



We could make the definition of SEC more clear, namely:


   SEC_X(Y):

  SEC is a function that provides integrity protection based on the 
chosen ciphersuite. The function SEC uses the algorithm defined by the 
selected ciphersuite and applies it to the message content Y with key X. 
As an output the message returns Y concatenated with MAC_X(Y).



SEC is used in the protocol in message 2,3 and 4.

Here is message 2:

   GPSK-2:

  SEC_SK(ID_Client, ID_Server, RAND_Client, RAND_Server,
  CSuite_List, CSuite_Sel [, ENC_PK(PD_Payload_1), ... ] )

Regarding the text in 6.2.2:

 The following instantiation is used: AES-128-CMAC(SK, Input) denotes
   the MAC of Input under the key SK.

   where Input refers to the following content:
   o  Value of SEC_SK in message GPSK-2
   o  Value of SEC_SK in message GPSK-3
   o  Value of SEC_SK in message GPSK-4

This would now produce

ID_Client, ID_Server, RAND_Client, RAND_Server, CSuite_List, CSuite_Sel 
[, ENC_PK(PD_Payload_1), ... ] || AES-128-CMAC(SK,
ID_Client, ID_Server, RAND_Client, RAND_Server, CSuite_List, CSuite_Sel 
[, ENC_PK(PD_Payload_1), ... ] )


We could 

[Emu] Fwd: [Emudt] Formal Verification of EAP-GPSK

[Hannes Tschofenig]

Here is a forward from the EMU DT mailing list where I mentioned that we 
did a formal analysis for EAP-GPSK.

As we update the protocol I will also reapply it again.

Ciao
Hannes

-Ursprüngliche Nachricht-
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im 
Auftrag von Tschofenig, Hannes

Gesendet: Freitag, 26. Mai 2006 11:21
An: [EMAIL PROTECTED]
Betreff: [Emudt] Formal Verification of EAP-GPSK

Hi all,

to verify that we did not miss a severe (and potentially obvious)
security bug we ran the EAP-GPSK protocol against the AVISPA tools. The
tool could not spot problems with the protocol. (Note that does not mean
that it is correct.)

The HLPSL file can be found here:
http://www.tschofenig.com/TEMP/EMU/gpsk-Input.hlpsl

The language is similar to the one used in CASPER.
The security goal that was specified was authentication with the
Dolev-Yao intruder model being used.

More info about AVISPA can be found here:
http://www.avispa-project.org/

Some useful documents are:

* The High Level Protocol Specification Language
http://www.avispa-project.org/delivs/2.1/d2-1.pdf

* The Intermediate Format
http://www.avispa-project.org/delivs/2.3/d2-3.pdf

* HLPSL Tutorial
http://www.avispa-project.org/package/tutorial.pdf

* User Manual   
http://www.avispa-project.org/package/user-manual.pdf

Ciao
Hannes

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

Re: [Emu] EMU PSK opaque blogs

[Hannes Tschofenig]

Bernard,

now I got your point :-)


Took a little bit longer


Hannes Tschofenig wrote:

Hi Bernard,


we did not know how the server identity should look like.
Hence, we just said that it is a blog. I guess the same approach was 
used in PAX.


Ciao
Hannes

Bernard Aboba wrote:


Just a random comment:

Server identity as an opaque blog.

Many blogs are in fact quite opaque, but do we really need to force 
the user to read an opaque blog as part of the protocol? :)




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





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





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