Re: [Emu] I-D Action: draft-ietf-emu-bootstrapped-tls-04.txt

[Owen Friel (ofriel)]

This has two updates:

1. reference https://datatracker.ietf.org/doc/html/draft-dekok-emu-eap-arpa-00 
and defines the username "tls-pok-dpp"

2. reference https://datatracker.ietf.org/doc/html/draft-ietf-tls-8773bis-01 
instead of https://datatracker.ietf.org/doc/html/rfc8773

Thanks,
Owen+Dan

-Original Message-
From: Emu  On Behalf Of internet-dra...@ietf.org
Sent: Sunday, January 28, 2024 1:23 PM
To: i-d-annou...@ietf.org
Cc: emu@ietf.org
Subject: [Emu] I-D Action: draft-ietf-emu-bootstrapped-tls-04.txt

Internet-Draft draft-ietf-emu-bootstrapped-tls-04.txt is now available. It is a 
work item of the EAP Method Update (EMU) WG of the IETF.

   Title:   Bootstrapped TLS Authentication with Proof of Knowledge (TLS-POK)
   Authors: Owen Friel
Dan Harkins
   Name:draft-ietf-emu-bootstrapped-tls-04.txt
   Pages:   13
   Dates:   2024-01-28

Abstract:

   This document defines a mechanism that enables a bootstrapping device
   to establish trust and mutually authenticate against a network.
   Bootstrapping devices have a public private key pair, and this
   mechanism enables a network server to prove to the device that it
   knows the public key, and the device to prove to the server that it
   knows the private key.  The mechanism leverages existing DPP and TLS
   standards and can be used in an EAP exchange.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-emu-bootstrapped-tls-04

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-bootstrapped-tls-04

Internet-Drafts are also available by rsync at:
rsync.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

[Emu] Experimental RFC 8773 normative reference in draft-ietf-emu-bootstrapped-tls

[Owen Friel (ofriel)]

Hi EMU Chairs,

draft-ietf-emu-bootstrapped-tls is proposed Standards Track and depends on RFC 
8773 which is Experimental.

Do we need to talk to TLS WG about changing RFC 8773 from Experimental? How 
does this process work?

Thanks,
Owen+Dan
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] eap.arpa domain in draft-ietf-emu-bootstrapped-tls

[Owen Friel (ofriel)]

Hi EMU Chairs,

I was looking to see if any minor updates are needed to 
draft-ietf-emu-bootstrapped-tls-03 before IETF 118 and WGLC.

There was one outstanding action from IETF 117:

Do we want to say there is an eap.arpa domain? Yes, but
not clear this draft is place to do that. Chairs to ask IAB to do
this.

Is there any clarity on this yet?
Thanks,
Owen+Dan
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] I-D Action: draft-ietf-emu-bootstrapped-tls-03.txt

[Owen Friel (ofriel)]

This version removed the redundant HKDF as discussed here 
https://mailarchive.ietf.org/arch/msg/emu/AYPFwb_fkSIY5Y2IoNFAbvgHQ3s/

And also incorporates much of Hannes' feedback here: 
https://mailarchive.ietf.org/arch/msg/emu/CR_deZDEQ7wsV6Gx9uyW-rUVCi0/

Thanks,
Owen

-Original Message-
From: Emu  On Behalf Of internet-dra...@ietf.org
Sent: Thursday, June 22, 2023 7:00 PM
To: i-d-annou...@ietf.org
Cc: emu@ietf.org
Subject: [Emu] I-D Action: draft-ietf-emu-bootstrapped-tls-03.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories. 
This Internet-Draft is a work item of the EAP Method Update (EMU) WG of the 
IETF.

   Title   : Bootstrapped TLS Authentication with Proof of Knowledge 
(TLS-POK)
   Authors : Owen Friel
 Dan Harkins
   Filename: draft-ietf-emu-bootstrapped-tls-03.txt
   Pages   : 12
   Date: 2023-06-22

Abstract:
   This document defines a mechanism that enables a bootstrapping device
   to establish trust and mutually authenticate against a network.
   Bootstrapping devices have a public private key pair, and this
   mechanism enables a network server to prove to the device that it
   knows the public key, and the device to prove to the server that it
   knows the private key.  The mechanism leverages existing DPP and TLS
   standards and can be used in an EAP exchange.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-bootstrapped-tls/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-emu-bootstrapped-tls-03

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-bootstrapped-tls-03

Internet-Drafts are also available by rsync at rsync.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

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

[Owen Friel (ofriel)]

Thanks Hannes for the detailed review, yes fully agree the language can be 
cleaned up in the draft,

I'll get a draft-ietf-emu-bootstrapped-tls-03 out before the next meeting.

Cheers,
Owen

-Original Message-
From: Hannes Tschofenig  
Sent: Tuesday 4 April 2023 15:51
To: Dan Harkins ; emu ; Owen Friel (ofriel) 

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

Hi Owen, Hi Dan,



thanks for the response and for the clarification.

Here is my proposal for improving the wording of the document.

First, there is a little bit of inconsistency in the terminology.

The Bootstrap Key (BSK) is defined as the public and private key pair.

In Section 2 you use the term "Bootstrap Key Pair" to refer to the public and 
the private key.

Here is my proposal:

FROM:

"
2.  Bootstrap Key Pair

The mechanism for on-boarding of devices defined in this document relies on 
bootstrap key pairs.  A client device has an associated elliptic curve (EC) 
bootstrap key pair (BSK).
"

TO:

"
2.  Bootstrap Key

The mechanism for on-boarding of devices defined in this document relies on the 
use of an elliptic curve (EC) bootstrap key (BSK).
"

Later an abbreviation for the BSK is used, namely BSKEY. I changed it for 
improved readability, as you can see below.


Section 2 defines the format of the BSK quite loosely as:

"
If the BSK
    public key, specifically the ASN.1 SEQUENCE SubjectPublicKeyInfo from
    [RFC5280], can be shared in a trustworthy manner with a TLS server, a
    form of "origin entity authentication" (the step from which all
    subsequent authentication proceeds) can be obtained.
"

Later, in Section 3, the encoding is phrased more directly as:

"
As the BSK is an ASN.1 SEQUENCE SubjectPublicKeyInfo, the
    client presents a raw public key certificate as specified in Using
    Raw Public Keys in TLS and DTLS [RFC7250].
"

I would therefore suggest to use the following wording in Section 2:

FROM:

"
If the BSK
    public key, specifically the ASN.1 SEQUENCE SubjectPublicKeyInfo from
    [RFC5280], can be shared in a trustworthy manner with a TLS server, a
    form of "origin entity authentication" (the step from which all
    subsequent authentication proceeds) can be obtained.
"

TO:

"
   The BSK public key MUST be encoded as the ASN.1 SEQUENCE 
SubjectPublicKeyInfo from
    [RFC5280] and if it can be shared in a trustworthy manner with a TLS 
server, a
    form of "origin entity authentication" (the step from which all
    subsequent authentication proceeds) can be obtained.
"

Regarding "origin entity authentication" I believe the correct wording is 
actually "entity authentication", if I consult the Handbook of Applied 
Cryptography (see https://cacr.uwaterloo.ca/hac/about/chap10.pdf).




My confusion was mainly about the text in Section 3. Here is some new wording. 
Note that I omitted the ImportedIdentity,

which I consider redundant since the epskid will, in form of the External 
Identity, become part of the ImportedIdentity of the

PSK importer interface.


FROM:
"
3.  Bootstrapping in TLS 1.3

    Bootstrapping in TLS 1.3 leverages Certificate-Based Authentication
    with an External Pre-Shared Key [RFC8773].  The External PSK (EPSK)
    is derived from the BSK public key, and the EPSK is imported using
    [RFC9258].  This BSK MUST be from a cryptosystem suitable for doing
    ECDSA.  As the BSK is an ASN.1 SEQUENCE SubjectPublicKeyInfo, the
    client presents a raw public key certificate as specified in Using
    Raw Public Keys in TLS and DTLS [RFC7250].

    The TLS PSK handshake gives the client proof that the server knows
    the BSK public key.  Certificate based authentication of the client
    by the server is carried out using the BSK, giving the server proof
    that the client knows the BSK private key.  This satisfies the proof
    of ownership requirements outlined in Section 1.

3.1.  External PSK Derivation

    An [RFC9258] EPSK is made up of the tuple of (Base Key, External
    Identity, Hash).  The EPSK is derived from the BSK public key using
    [RFC5869] with the hash algorithm from the ciphersuite:

    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

    The [RFC9258] ImportedIdentity structure is defined as:

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

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

[Owen Friel (ofriel)]

Yep thanks Hannes for the review. That optimizes the solution and removes the 
unnecessary hashing of the BSK. Looking at the history, that BSK hashing was 
there since a very early version of the draft before we incorporated RFC 9258, 
and it never occurred to us to optimize that out once we started using RFC 9258.

We missed the IETF 116 draft cutoff date, but will get draft-03 out after the 
meeting.
Thanks,
Owen

-Original Message-
From: Emu  On Behalf Of Dan Harkins
Sent: Wednesday 22 March 2023 19:12
To: Hannes Tschofenig ; emu 
Subject: Re: [Emu] draft-ietf-emu-bootstrapped-tls


   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 legitimate "owner" and is therefore authorized to 
provision/imprint it. So we can't send the bskey out naked in the ClientHello, 
we have to send out something derived from the bskey.

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

   Well, half of what's at the beginning of section 3.1 is still needed.
So what we're gonna do is change it to be:

     epsk = bskey
     epskid = HKDF-Expand(HKDF-Extract(<>, bskey), "tls13-bspsk-identity", L)

That way the raw DER-encoded ASN.1 will get hashed up by RFC 9258 to produce 
the imported key and that key will be identified by something that is not the 
raw DER-encoded ASN.1.

   regards,

   Dan.

   [1] https://www.cl.cam.ac.uk/~fms27/duckling/

--
"The object of life is not to be on the side of the majority, but to escape 
finding oneself in the ranks of the insane." -- Marcus Aurelius

___
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] I-D Action: draft-ietf-emu-bootstrapped-tls-02.txt

[Owen Friel (ofriel)]

This fixes a broken reference and cleans up some nits.
It also tightens up the language about how the TLS handshake operates.
It does not introduce any changes to the core algorithm at all.
Regards,
Owen

-Original Message-
From: Emu  On Behalf Of internet-dra...@ietf.org
Sent: Friday 10 February 2023 19:49
To: i-d-annou...@ietf.org
Cc: emu@ietf.org
Subject: [Emu] I-D Action: draft-ietf-emu-bootstrapped-tls-02.txt


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   : Bootstrapped TLS Authentication with Proof of 
Knowledge (TLS-POK)
Authors : Owen Friel
  Dan Harkins
  Filename: draft-ietf-emu-bootstrapped-tls-02.txt
  Pages   : 12
  Date: 2023-02-10

Abstract:
   This document defines a mechanism that enables a bootstrapping device
   to establish trust and mutually authenticate against a network.
   Bootstrapping devices have a public private key pair, and this
   mechanism enables a network server to prove to the device that it
   knows the public key, and the device to prove to the server that it
   knows the private key.  The mechanism leverages existing DPP and TLS
   standards and can be used in an EAP exchange.


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

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-emu-bootstrapped-tls-02

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-emu-bootstrapped-tls-02


Internet-Drafts are also available by rsync at rsync.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

Re: [Emu] More TEAP issues

[Owen Friel (ofriel)]

There are a few useful TLVs defined in 
https://datatracker.ietf.org/doc/html/draft-lear-eap-teap-brski-06

CSR Attributes as Eliot has mentioned, as well as e.g. Retry-After TLV which 
could be useful if the TEAP server has to communicate with a backend CA to get 
a PKCS#10 CSR signed.

There is also a cert issuance use case that 
https://www.rfc-editor.org/rfc/rfc7170#section-3.8.2 does not account for. The 
section recommends using tls-unique channel binding in the PKCS#10 CSR so that 
server can verify that the client holds the private key associated with the 
public key in the CSR. This assumes that the public/private keypair were used 
in the outer tunnel TLS handshake. This makes sense if a client is using an 
LDevID to establish the TEAP tunnel, and wants to reenroll to get a new LDevID 
that has the same keypair e.g. the cert is about to expire.

It does not account for the bootstrapping use case where a client has a 
manufacturing time installed IDevID and needs a deployment-specific LDevID for 
network access. It establishes the outer tunnel using the keys in its IDevID, 
but is sending a PKCS#10 CSR with different keys. Therefore the proposed 
tls-unique binding will fail. Maybe addressing this (and the various TLVs 
proposed in draft-lear-eap-teap-brski) is too much to bite off in rfc7170bis 
and we need to revisit and address in draft-lear-eap-teap-brski.

-Original Message-
From: Emu  On Behalf Of Eliot Lear
Sent: Wednesday 30 November 2022 06:24
To: Joseph Salowey ; Alan DeKok 
Cc: EMU WG 
Subject: Re: [Emu] More TEAP issues

I'd support a revision as well.  See below:

On 30.11.22 02:14, Joseph Salowey wrote:
> [Joe] speaking as a participant, I'd be happy to assist with a 
> revision.  I think it is needed.  Most of the current errata are 
> tracked here - https://github.com/emu-wg/teap-errata/pulls. I think 
> the target would be to obsolete 7170 with a revision that just fixes 
> the errata and makes any needed clarifications.  We can also work on 
> posting the Errata, but the revised document would be more effective 
> at getting these issues fixed.

I'd also like to take some time to consider what additional TLVs may be 
required.  Right now there is an incongruence between TEAP and other protocols 
that sign certs in that there is no CSR attributes TLV.  There may be several 
others to consider.

Eliot

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

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

[Owen Friel (ofriel)]

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

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

Re: [Emu] Adoption call for EAP-DPP

[Owen Friel (ofriel)]

Thanks Michael.

Ok, we can look at a relay out and consider moving some of the EAP motivations 
in section 3 earlier in the document.

And agree, I think we can do a better job of linking the use of 
draft-ietf-tls-external-psk-importer to identify BSKs with the EAP handshake! 
We can fix that up in the next draft too.

Inline for more.

-Original Message-
From: Emu  On Behalf Of Michael Richardson
Sent: Tuesday 13 September 2022 12:13
To: Peter Yee ; emu@ietf.org
Subject: Re: [Emu] Adoption call for EAP-DPP


I have read draft-friel-tls-eap-dpp-05.
I have no objection to the WG working on such a thing, but I think that there 
is actually quite a lot of work left to do.

I think that the section 3, which explains the EAP connection (and the 
motivation for the work) should probably come before the extension and the 
cryptographic explanation!

I find the document quite weak even in section 3.
I think that the EAP server (Authentication Server) is meant to use the OOB 
public key to authenticate the new device.

I'm rather vague as to how the Authentication Server knows what identity to use 
to look the public key up, and how the privacy of this identity is preserved.

[ofriel] the draft-ietf-tls-external-psk-importer external_identity is HKDF 
derived from the BSK public key as outlined in 
https://datatracker.ietf.org/doc/html/draft-friel-tls-eap-dpp-05#section-2.1. 
This is included in the ImportedIdentity struct which is serialized into 
PskIdentity.identity in the PSK extension, all as per 
draft-ietf-tls-external-psk-importer. Only a server that knows the 
raw/cleartext BSK public key can complete the TLS PSK handshake. 


Does the device get any indication that it has been plugged into the correct 
network?  Is there any authenticatin of the Authentication Server?

[ofriel] The device and server are afforded the same levels of identity 
guarantees and authentication as Wi-Fi DPP. The network gets a guarantee that 
the device connecting knows the BKS private key. The device gets a guarantee 
that the network knows its BSK public key. Similar to Wi-Fi Easy Connect / DPP, 
proof of knowledge of the BSK public key is proof of ownership of the device.



While I acknowledge you are not trying to implement BRSKI (RFC8995) or SZTP 
(RFC8572), it would be good if your Security Considerations addressed some of 
the same issues that those documents deal with.



--
Michael Richardson , Sandelman Software Works  -= IPv6 
IoT consulting =-



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

Re: [Emu] Adoption call for EAP-DPP

[Owen Friel (ofriel)]

If necessary we can add clarifying text to the next draft to explain why Wi-Fi 
Easy Connect 2.0 section 2.3.5 “Wired-Only DPP” does not solve this wired 
onboarding problem. Hopefully there is no longer any confusion on this point as 
Dan has clarified here, and previously: 
https://mailarchive.ietf.org/arch/msg/emu/lboE_o4OfJJtUL_LA6psIpSuHZs/

Regards,
Owen

From: Emu  On Behalf Of Dan Harkins
Sent: Friday 9 September 2022 07:29
To: sarik...@ieee.org
Cc: emu@ietf.org
Subject: Re: [Emu] Adoption call for EAP-DPP


  Hi Behcet,
On 9/8/22 8:43 AM, Behcet Sarikaya wrote:
Hi Peter, Joe,

We made it clear that DPP R2 has already been published  with a name change:






 Wi-Fi Easy Connect™

Specification

Version 2.0


Wi-Fi Easy Connect is the new DPP, which the authors seemingly did not know 
about.

  Wi-Fi Easy Connect is the name of a certification program at the Wi-Fi 
Alliance
for devices that implement the DPP protocol.

  I am well aware of Wi-Fi Easy Connect (having invented the protocols that are 
used
in it and have contributed to development of the test plan). It seems that you 
aren't.


Also the problem that this draft deals with and also Elliott mentioned in his 
mail, Wi-Fi Easy Connect already solves it.

  That is not correct, this draft deals with on-boarding of wired devices on 
networks
that enforce security. Such networks enforce 802.1x and as soon as a device is 
plugged
into such a switch an EAP Identity-Request will be sent. No packets other than 
EAPoL are
allowed. Certainly no TCP frames encapsulating DPP messages! So it is not 
possible to
do any DPP-over-TCP (or if you will "Wi-Fi Easy Connect over TCP") in such a 
situation.

  Wi-Fi Easy Connect, which is a certification program, does not solve this 
problem. Neither
does the DPP protocol which Wi-Fi Easy Connect certifies compliance to.

  The issue that IP connectivity cannot be established until authentication and 
DPP-over-TCP
requires IP connectivity to perform authentication. It's a classic catch-22. 
Why don't you
see this obvious problem?

  regards,

  Dan.


Regards,
Behcet



On Wed, Sep 7, 2022 at 11:57 PM Peter Yee 
mailto:pe...@akayla.com>> wrote:
In retrospect, sending the call for adoption at the height of August
vacation season may not have guaranteed the most responses. To be honest,
the level of responses to this call has been a little light, so Joe and I
have decided to extend the call for adoption for one week from today.

We would really like to hear from anyone else who is interested in reviewing
and/or contributing to this specification or anyone who feels that it should
not be adopted. Please speak up by the 14th either way. This specification
would seemingly fit within the WG's existing charter, so let your voice be
heard!

Thanks,

Peter and Joe

-Original Message-
From: Peter Yee mailto:pe...@akayla.com>>
Sent: Tuesday, August 16, 2022 1:12 PM
To: 'emu@ietf.org' mailto:emu@ietf.org>>
Subject: Adoption call for EAP-DPP

This is an adoption call for EAP-DPP (draft-friel-tls-eap-dpp-05)[1]. This
document aligns with the charter item to "Define mechanisms by which EAP
methods can support creation of long-term credentials for the peer based on
initial limited-use credentials." The latest revision incorporates feedback
from both the TLS and EMU working groups. Please review and respond to the
list if you think this document is or is not an appropriate working group
item for EMU by September 1, 2022.

Thanks,

Peter and Joe

[1] https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/


___
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



--

"The object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." -- Marcus Aurelius
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] FW: New Version Notification for draft-friel-tls-eap-dpp-05.txt

[Owen Friel (ofriel)]

This update changes from using 
https://chris-wood.github.io/draft-tls-extensible-psks/draft-group-tls-extensible-psks.html
 to 
https://datatracker.ietf.org/doc/html/draft-ietf-tls-external-psk-importer-08 
as recommended by Chris Wood, as he is not currently progressing 
draft-group-tls-extensible-psks.

As Dan outlined at IETF113 
https://datatracker.ietf.org/meeting/113/materials/minutes-113-emu-01, 
draft-friel-tls-eap-dpp-02 proposed using 
https://datatracker.ietf.org/doc/html/draft-jhoyla-tls-extended-key-schedule-03 
 and was reviewed at TLS WG IETF110. TLS WG suggested using derived PSKs and 
RFC 8773 instead.

draft-friel-tls-eap-dpp-03 changed from using 
draft-jhoyla-tls-extended-key-schedule to using derived PSKs and RFC 8773 
instead, was reviewed at TLS WG IETF111, and the approach was validated by EKR 
https://datatracker.ietf.org/meeting/111/materials/minutes-111-tls-00.




-Original Message-
From: internet-dra...@ietf.org  
Sent: Thursday 26 May 2022 21:02
To: Dan Harkins ; Owen Friel (ofriel) 
Subject: New Version Notification for draft-friel-tls-eap-dpp-05.txt


A new version of I-D, draft-friel-tls-eap-dpp-05.txt has been successfully 
submitted by Owen Friel and posted to the IETF repository.

Name:   draft-friel-tls-eap-dpp
Revision:   05
Title:  Bootstrapped TLS Authentication
Document date:  2022-05-26
Group:  Individual Submission
Pages:  10
URL:https://www.ietf.org/archive/id/draft-friel-tls-eap-dpp-05.txt
Status: https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/
Htmlized:   https://datatracker.ietf.org/doc/html/draft-friel-tls-eap-dpp
Diff:   https://www.ietf.org/rfcdiff?url2=draft-friel-tls-eap-dpp-05

Abstract:
   This document defines a TLS extension that enables a server to prove
   to a client that it has knowledge of the public key of a key pair
   where the client has knowledge of the private key of the key pair.
   Unlike standard TLS key exchanges, the public key is never exchanged
   in TLS protocol messages.  Proof of knowledge of the public key is
   used by the client to bootstrap trust in the server.  The use case
   outlined in this document is to establish trust in an EAP server.


  


The IETF Secretariat


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

Re: [Emu] Short review of draft-friel-tls-eap-dpp-01

[Owen Friel (ofriel)]

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: 19 July 2021 00:40
To: EMU WG 
Subject: [Emu] Short review of draft-friel-tls-eap-dpp-01

  No major notes here.  There's still a lot of TBD in the document.  :)

NITS:

  Section 3 says:

  ... For
   unprovisioned devices that desire to take advantage of TLS-POK, there
   is no initial realm in which to construct an NAI (see [RFC4282]) so
   the initial EAP Identity response SHOULD contain simply the name
   "TLS-POK" in order to indicate to the Authenticator that an EAP
   method that supports TLS-POK SHOULD be started.

* RFC 4282 has been deprecated by RFC 7542

* There just might be a user with name "TLS-POK", so using bare names is likely 
not a good idea.

  After looking at this, EAP-NOOB, and my latest document, there seem to be 
some overlap with EAP identities.  EAP-NOOB suggests a ".arpa" realm.  It would 
be good to agree on, and use, a common naming scheme.

  My suggestion is to define "eap.arpa" for EAP purposes.  This realm would be 
defined to be handled locally at the EAP server.  i.e. never proxied.  And used 
only for provisioning purposes.

  We can then have:

* n...@eap.arpa for EAP-NOOB

* tls-...@eap.arpa for this document

* perhaps "provision...@eap.arpa for "I want a captive portal / provisioning 
network".  I have some updates pending to my document which discusses this 
concept.

  One issue we currently have today is that there's no standard way for an EAP 
client to say "I want network access, but I don't really care who it's from, 
and I don't really care to prove who I am".  This kind of authentication-less 
network access is still useful, as noted in the EAP-TLS 1.3 document.  Similar 
provisioning is in EAP-FAST and TEAP.

  I suspect that would be useful to have full network capabilities for 
provisioning.  While it can be nice to push all kinds of provisioning into an 
EAP method, TBH that seems like re-inventing the wheel.

[ofriel] the goal here is to push the provisioning info (e.g. CA roots, peer 
identity certs) inside TEAP using existing TEAP mechanisms e.g. Trusted Server 
Root, PKCS#7 TLVs. We are trying to avoid wheel reinvention. The novel bit here 
is the mutual authentication in the TLS stack based on the already defined 
Wi-Fi Alliance DPP bootstrap key.



  Instead, we could just have the EAP client go "I want access as @eap.arp" or 
maybe "provision...@eap.arpa".  It then gets a "captive portal" network, and 
can rely on the rest of the TCP/IP stack, and the web PKI to download complex 
provisioning data.

  From an implementation point of view, updating EAP clients and servers is 
hard.  It takes a long time for changes to be written, tested, and widely 
deployed.  In contrast, if the client had access to a provisioning network, it 
can be easier to write a simpler utility which downloads information.  Among 
other benefits, there is also a clear separation of roles between network 
access, and configuration changes.

  Alan DeKok.

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

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

Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

[Owen Friel (ofriel)]

Alan,
How should we interpret this in RFC 5216 
https://tools.ietf.org/html/rfc5216#section-2.1.1:

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


Does this statement pretty much precludes the certificateless TLS 1.2 
ciphersuites, i.e. the extern PSK ones from right?

Owen

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: 11 March 2020 19:26
To: John Mattsson 
Cc: Mohit Sethi M ; EMU WG 
Subject: Re: [Emu] Late WGLC Comment on draft-ietf-emu-eap-tls13

On Mar 11, 2020, at 4:01 AM, John Mattsson 
 wrote:
> 
> If I remember correctly, Bernard stated that the indroduction of PSK could 
> weaken the implementation and violate the security proofs of EAP-TLS. I don't 
> really agree with Bernard, but I am fine with resticting the type code 0x0D 
> to certificates only. I am not sure any proofs with TLS 1.1 would apply to 
> TLS 1.3 anyway as TLS 1.3 is basically a new protocol, reusing encoding and 
> IANA registers from the old version. 

  For what it's worth, RFC 5216 doesn't make any statement about PSK.  So on a 
first reading, there are currently no restrictions on using PSK with EAP-TLS, 
and TLS <= 1.2.

  There are multiple client / server implementations which support PSK for 
EAP-TLS.

  That being said, I'm OK with having one EAP type code for EAP-TLS (certs), 
and another for EAP-TLS (everything else)

  I would avoid having multiple EAP types.  That would bloat implementations.  
It's better to just let implementors / admins configure TLS parameters for one 
EAP type, instead of multiple  EAP types.

  Alan DeKok.

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

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

[Emu] FW: New Version Notification for draft-friel-tls-eap-dpp-00.txt

[Owen Friel (ofriel)]

All,

Dan and I have a new draft that describes how a mechanism similar to the Wi-Fi 
Alliance Device Provisioning Profile can be used on wired networks via proposed 
new TLS extensions, with those extensions being leveraged in an EAP 
transaction. Importantly, the DPP bootstrap key format, and thus the DPP QR 
label, can be reused for bootstrapping a thing on both wired and Wi-Fi networks.

There are changes  required to the TLS key schedule, so part of this work 
overlaps with draft-jhoyla-tls-extended-key-schedule.

We hope to remote present at both EMU and TLS.

Owen

-Original Message-
From: internet-dra...@ietf.org  
Sent: 07 March 2020 07:56
To: Dan Harkins ; Owen Friel (ofriel) 
Subject: New Version Notification for draft-friel-tls-eap-dpp-00.txt


A new version of I-D, draft-friel-tls-eap-dpp-00.txt has been successfully 
submitted by Owen Friel and posted to the IETF repository.

Name:   draft-friel-tls-eap-dpp
Revision:   00
Title:  Bootstrapped TLS Authentication
Document date:  2020-03-06
Group:  Individual Submission
Pages:  9
URL:
https://www.ietf.org/internet-drafts/draft-friel-tls-eap-dpp-00.txt
Status: https://datatracker.ietf.org/doc/draft-friel-tls-eap-dpp/
Htmlized:   https://tools.ietf.org/html/draft-friel-tls-eap-dpp-00
Htmlized:   https://datatracker.ietf.org/doc/html/draft-friel-tls-eap-dpp


Abstract:
   This document defines a TLS extension that enables a server to prove
   to a client that it has knowledge of the public key of a key pair
   where the client has knowledge of the private key of the key pair.
   Unlike standard TLS key exchanges, the public key is never exchanged
   in TLS protocol messages.  Proof of knowledge of the public key is
   used by the client to bootstrap trust in the server.  The use case
   outlined in this document is to establish trust in an EAP server.


  


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.

The IETF Secretariat


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

Re: [Emu] [lamps] EAP/EMU recommendations for client cert validation logic

[Owen Friel (ofriel)]

Thanks for the detailed reply Ryan. See line.

> -Original Message-

> 
> If an EAP server operator wants to use a public CA identity cert on their EAP
> server, what recommendations should we give to EAP clients so that the
> supplicant code can handle public or private CA issued EAP server identity in 
> a
> secure a fashion as possible?
> 
> Define “public CA” first, and it’ll be clearer that the question is really
> supplicant-specific.
> 
> That is, most definitions for “public CAs” come down to “I don’t want to think
> about / analyze the security or validation practices of the CA, I want my
> supplicant / software / hardware vendor to do it for me, against some criteria
> the vendor is responsible for, and hope it all works out”. To the extent TLS
> uses ‘public CAs’, it either boils down to the OS or browser vendors reaching
> rough (independent) consensus on who is worth trusting, or the vendor
> going along with everyone else’s decisions for cost (too expensive for the
> vendor to evaluate) or compatibility (everyone else trusts them and it’d
> break things if the vendor doesn’t) reasons.
 

[ofriel] That’s pretty much it. For supplicants running on standard OSes 
(Windows, MacOS, iOS, Android), they could use logic similar to Chromium (which 
you must be familiar with seeing as you helped write it: 
https://github.com/chromium/chromium/commit/36f20e46515ab61df4ae4af9655b647bf9a0ea5a#diff-fa455b6e65ab2ae19d64635ada88077e
 ) to ask the OS if a presented EAP cert is one issued by a public CA. This 
does mean that the supplicant is asking about Web TLS certs that Browsers 
trust. However, there are ample examples and support cases opened by operators 
who are trying to do exactly that – get a web PKI cert from a public 
TLS/Browser CA and deploy it on an EAP server. Is this recommended? Not really. 
Is it using a Web/TLS cert for a purpose its not strictly intended for? Yes. 
Does this happen in real deployments? Absolutely. How prevalent is it? I do not 
have that data.

> 
> Is the supplicant market likely to reach that consensus? It seems unlikely,
> unless and until you define the “thing everyone can and wants and needs to
> validate”, and that thing is either globally unique (like DNS) or sufficiently
> domain specific (e.g. Passpoint) that vendors can agree.
> 

[ofriel] I think the supplicants running on the main OSes would be happy to 
delegate the question of whether a CA is a ‘public CA’ to the OS. For 
manufacturers of things/embedded devices/etc. then its currently very much at 
the manufacturers discretion, and consensus here would be unlikely.

> If at some point in the future, public CAs are willing to issue certs with 
> some
> or all of the above fields, then what is the migration plan, what do we tell 
> EAP
> clients to do now, and how to they migrate their verification logic?
> 
> This statement similarly requires untangling. There are “public CAs” as “The
> set of keys/certificates used for authenticating particular services” and
> “public CAs” as the set of organizations that own/operate those keys.
> 
> The case of the former is extremely unlikely, as the industry is actively
> moving away from that approach to PKI, by trying to ensure separate keys
> for separate use cases or authentication realms, of which EAP would surely
> be. 
 
[ofriel] And by this you mean that a root CA will have e.g. one intermediate 
with EKUs of id-kp-serverAuth/id-kp-clientAuth, and a different intermediate 
with an EKU for id-kp-emailProtection, right? The logical extension here for 
EAP is yet another intermediate with an EKU for id-kp-eapOverLAN.

The case of the latter is already available from said organizations as part
> of “managed CA” or “private CA” offerings, which are operated by that public
> CA organization, but that’s effectively greenfield because you aren’t having
> to interoperate with any extant keys or certificate profiles.
> 


[ofriel] Right, but from a supplicant perspective (or in general for any client 
running on any OS e.g. Browser on Windows), there is zero difference between an 
operator who deploys and runs their own private CA, or takes a contract out 
with a public CA organization and gets them to run a managed/private CA on 
their behalf.

> The ideal experience would be along these lines for a client with real user
> interactions:
> - client connects to an EAP server
> - client prompts user for userId + realm and password
> - client verifies server cert has id-kp-eapOverLAN set
> 
> What assurance is this to provide?


[ofriel] To assure that the cert is for the intended purpose – 802.1X/EAP 
server auth. Just like other TLS/Browser clients checks for id-kp-serverAuth

> 
> - NAIRealm in cert matches user’s realm
> 
> This only works iff the NAIs are globally unique (e.g. map to DNS), which
> imposes requirements on NAIs that aren’t present in RFC 7542, and
> seemingly intentionally, compared to 4282.
> 
> - verify the cert signing chain
> 
> The reality 

[Emu] EAP/EMU recommendations for client cert validation logic

[Owen Friel (ofriel)]

Hi,

At ACME meeting at IETF106, the last discussion of the week was around EMU 
looking for recommendations for EAP client/peer/supplicant cert verification 
logic when the client is verifying the cert that the EAP server presents. 
Minutes here: https://datatracker.ietf.org/doc/minutes-106-acme/  The 
recommendation was to ask lamps. This was also discussed on EMU mailer 
recently..

Quoting some additional background that Alan gave on EMU mailer:


"Background:



a) the current practice in TLS-based EAP methods is to use certificates with 
"id-kp-serverAuth" OID set for Extended Key Usage.

b) many supplicants check for this OID, and refuse to perform authentication if 
it is missing

c) supplicants do not check DNS names or any other field in the certificates

d) as a result of this lack of verification, supplicants ship with all known 
CAs disabled for TLS-based EAP methods"

The key consideration is that RFCs that recommend cert fields for EAP servers 
that clients should check for are not currently issued by public CAs, and in 
some instances (e.g. SSID) ownership can often not be proven by CAs.

For example:

https://tools.ietf.org/html/rfc4334#section-2 id-kp-eapOverLAN EKU

https://tools.ietf.org/html/rfc4334#section-3 id-pe-wlanSSID

https://tools.ietf.org/html/rfc7585#section-2.2 NAIRealm

If an EAP server operator wants to use a public CA identity cert on their EAP 
server, what recommendations should we give to EAP clients so that the 
supplicant code can handle public or private CA issued EAP server identity in a 
secure a fashion as possible?

If at some point in the future, public CAs are willing to issue certs with some 
or all of the above fields, then what is the migration plan, what do we tell 
EAP clients to do now, and how to they migrate their verification logic?

The ideal experience would be along these lines for a client with real user 
interactions:
- client connects to an EAP server
- client prompts user for userId + realm and password
- client verifies server cert has id-kp-eapOverLAN set
- NAIRealm in cert matches user's realm
- verify the cert signing chain

The reality today is that if the server cert is issued by a public CA, then all 
that client can really check is:
- id-kp-serverAuth is set
- dNSName in cert matches user's realm
- verify the cert signing chain

We would like to document some recommendations for EAP clients and EAP 
operators so that public CAs could be used, and recommend checks for public vs. 
private CA issued EAP server certs.

It seems like logic should be something like:

- recommend EAP operators with private CA issued certs on their EAP servers set 
id-kp-eapOverLAN and NAIRealm set
- recommend EAP operators using public CAs get EAP server certs with 
id-kp-serverAuth and dNSName set
- recommend clients enable trust in public CAs
- recommend clients implement different cert verification logic depending on 
whether the EAP server cert is issued by a public CA or private CA
- for public CA certs, client checks that id-kp-serverAuth is set *and* dNSName 
matches user realm. If either check fails, reject.
- for private CA certs, client checks that id-kp-serverAuth or id-kp-eapOverLAN 
is set *and* NAIRealm matches user realm. If either check fails, reject.

- as a longer term goal see if public CAs will issue id-kp-eapOverLAN and 
NAIRealm. Although of course if some were to start doing this, then there is a 
migration challenge, and clients cannot make a hard check for these values 
against all public CAs. This doesn't really seem practical in the near term at 
all.

Note that for an IoT device, there is some work to do to define how to e.g. 
extend the RFC8366 so that it can specify the dNSName that devices should check 
for when verifying EAP identity where they EAP server uses a public CA. Some 
related options are outlined in 
https://tools.ietf.org/html/draft-friel-anima-brski-cloud-01.

Comments/thoughts?

Regards,
Owen








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

Re: [Emu] Best practices for supplicants and authenticators

[Owen Friel (ofriel)]

Assuming that NAIRealm is a registered domain as per RFC 7542, and thus public 
CAs can verify ownership, the goal / where we want to get to is:

- CA may be a public CA and thus public CAs can be enabled by default in 
supplicant config
- supplicant checks NAI Realm in the EAP identity cert matches that of the 
user's realm
- supplicant verifies id-kp-eapOverLAN is set

And also assuming that public CAs will not issue certs with an NAIRealm or 
id-kp-eapOverLAN bit. (This is certainly true for Let's Encrypt. See below for 
details.) And it could be years before public CAs do.

Does that mean there is an intermediate rollout phase where the supplicant 
checks that the realm the user enters matches a dNSName in the EAP cert?

The rollout / upgrade issue with this is of course if we give guidance that 
supplicants
(i) check that entered realm matches NAIRealm; and id-kp-eapOverLAN is set
If that fails then (ii) check that dNSName matches entered realm

at what point in time would supplicant behaviour ever change to remove the 
fallback to option (ii) and checking dNSName only?

As a data point on RFC 4985 and id-mod-dns-srv-name-93 (or RFC 6125 SRV-IDs): 
Public CAs generally don't issue these either, so the same issue with 
supplicants checking for NAIRealm or id-kp-eapOverLAN exists with 
id-mod-dns-srv-name-93 w.r.t. Public CAs.

Owen

P.S.: Let's Encrypt implementation is at: https://github.com/letsencrypt/boulder

You can see the only allowed KeyUsage and ExtKeyUsage bits here:

https://github.com/letsencrypt/boulder/blob/master/cmd/gen-ca/main.go#L318

https://github.com/letsencrypt/boulder/blob/master/cmd/cert-checker/main.go#L303



-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: 18 November 2019 14:18
To: EMU WG 
Subject: [Emu] Best practices for supplicants and authenticators

  After the meeting earlier today, I made some notes on best practices for 
supplicants and authenticators.  I think it would be useful to have an official 
WG document which gives guidance.

Background:

a) the current practice in TLS-based EAP methods is to use certificates with 
"id-kp-serverAuth" OID set for Extended Key Usage.
b) many supplicants check for this OID, and refuse to perform authentication if 
it is missing
c) supplicants do not check DNS names or any other field in the certificates
d) as a result of this lack of verification, supplicants ship with all known 
CAs disabled for TLS-based EAP methods

  If the supplicants did ship with root CAs enabled, then because of the lack 
of validation in (c), the supplicants would hand over user credentials to any 
authenticator who has a properly signed certificate.  This is wrong, and is why 
all of the root CAs are disabled.

  It would be useful to simplify the user experience when working with EAP-TLS. 
 It would also be useful to reduce security issues.  This is where a new 
document is needed.  I believe that the standards exist to support these goals. 
 However, there's a lack of guidance around using these standard.  It would be 
good to document current practices, and then give guidance on how to upgrade to 
better practices.

  I'll start off describing the end goal, and then discuss how we can get there.

  The goal is to have certificates which contain the id-kp-eapOverLAN OID (RFC 
4334), and either the NAIRealm OID (RFC 7585), or a similar one dedicated to 
TLS-based EAP authentication.  Supplicants can use these fields to verify that 
the certificate is both intended to be used for TLS-based EAP authentication, 
and that the certificate is for a given realm.

  The end user experience *should* be something like:

* connect to a system which uses 802.1X authentication (SSID, wired, etc)
* prompt the user for full credentials (user id + realm / password)
* validate that the server certificate has the id-kp-eapOverLAN OID set, AND 
that the NAIRealm OID matches the user's realm
* validate the certificate chain

  If those validation steps succeed, then the supplicant could send the users 
credentials over the EAP method.  I think that this extra validation means that 
supplicants can trust known root CAs by default.  Which makes the user 
experience much better.

  Since the certificates do not currently contain these fields, and supplicants 
don't check them, we need an upgrade path.

  The first step is to suggest that admins generate certificates with the above 
fields.  This likely means that certificate authorities will be asked to sign 
certs with the NAIRealm OID, which they might not do.  This limitation is less 
of a problem in a roaming federation like Eduroam, where they are their own CA.

  The next step is to suggest that supplicant vendors upgrade their systems to 
allow the id-kp-eapOverLAN OID, *or* the id-kp-serverAuth in server 
certificates.  That is a simple change, and shouldn't have any negative affects.

  Supplicants can also be upgraded to check the NAIRealm.  If the field does 
not match the users realm, then 

Re: [Emu] Presentations for IETF 106

[Owen Friel (ofriel)]

Joe, Mohit,

Somewhat disorganised and late request: there appears to be time in the agenda 
at the end for a 10 min update on:

Title: ACME Integrations
Drafts: draft-friel-acme-integrations, draft-friel-acme-subdomains
Time: 10 minutes

Currently doing slides on the plane..

-Original Message-
From: Emu  On Behalf Of Joseph Salowey
Sent: 14 November 2019 23:12
To: EMU WG 
Subject: [Emu] Presentations for IETF 106

If you are on the agenda [1] for IETF 106 in Singapore please send your slides 
to mailto:emu-cha...@ietf.org as soon as possible as the meeting is on Monday.  
Failure to send your slides before the day of the meeting may result in your 
presentation being pushed to the end of the agenda.  

[1] (https://datatracker.ietf.org/meeting/106/materials/agenda-106-emu-00)
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Owen Friel (ofriel)]

-Original Message-
From: Alan DeKok  
Sent: 16 November 2019 14:29
To: Owen Friel (ofriel) 
Cc: Jan-Frederik Rieckers ; emu@ietf.org
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

On Nov 16, 2019, at 7:59 AM, Owen Friel (ofriel)  wrote:
> [ofriel] this seems like something reasonable, but that's more a general 
> deployment recommendation: ensure that the identity/realm of EAP servers is 
> different from the identity/domain of webservers within an org. Therefore in 
> the absence of an NAIRealm or id-kp-eapOverLAN extension in a cert,  clients 
> can still distinguish between the two. Users point their Browser clients 
> point to 'example.org' and wi-fi supplications are configured to look for 
> 'radius.exampe.org'.
> 
> The supplicant logic for verifying EAP server identity (assuming it already 
> knows the root CA and a realm/domain string) could be check for NAIRealm 
> first, then check for id-kp-eapOverLAN, then check for a dnsName.

  There is currently no document which offers guidance for implementors.  
There's just common practice, and various standards.  Which are unfortunately 
different.  Even worse, it's not clear how these practices interact, or how we 
should migrate from existing practice to using the standards.

  I think it would be useful for this WG to have a document which gives these 
guidelines.

[ofriel] Happy to help put a strawman for that together, along with some 
recommendations for the other PSK ambiguity.

  Aln DeKok.

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

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Owen Friel (ofriel)]

The CA/Browser forum has concrete guidelines on address, email, domain 
verification outlined here.

https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.6.pdf

All public CAs should follow these, or face blacklisting. CAs don’t want to 
risk being the next Symantec.

" 3.2.2.1. Identity
 If the Subject Identity Information is to include the name or address of an 
organization, the CA SHALL verify the identity and address of the organization 
and that the address is the Applicant’s address of existence or operation. The 
CA SHALL verify the identity and address of the Applicant using documentation 
provided by, or through communication with, at least one of the following:
1. A government agency in the jurisdiction of the Applicant’s legal creation, 
existence, or recognition;
2. A third party database that is periodically updated and considered a 
Reliable Data Source;
3. A site visit by the CA or a third party who is acting as an agent for the 
CA; or
4. An Attestation Letter.
The CA MAY use the same documentation or communication described in 1 through 4 
above to verify both the Applicant’s identity and address.
Alternatively, the CA MAY verify the address of the Applicant (but not the 
identity of the Applicant) using a utility bill, bank statement, credit card 
statement, government-issued tax document, or other form of identification that 
the CA determines to be reliable. "

" 3.2.2.3. Verification of Country
If the subject:countryName field is present, then the CA SHALL verify the 
country associated with the Subject using one of the following: (a) the IP 
Address range assignment by country for either (i) the web site’s IP address, 
as indicated by the DNS record for the web site or (ii) the Applicant’s IP 
address; (b) the ccTLD of the requested Domain Name; (c) information provided 
by the Domain Name Registrar; or (d) a method identified in Section 3.2.2.1. 
The CA SHOULD implement a process to screen proxy servers in order to prevent 
reliance upon IP addresses assigned in countries other than where the Applicant 
is actually located. "

There is also a bunch of stuff in there about emails including:

" 3.2.2.4.4 Constructed Email to Domain Contact
Confirm the Applicant's control over the FQDN by (i) sending an email to one or 
more addresses created by using 'admin', 'administrator', 'webmaster', 
'hostmaster', or 'postmaster' as the local part, followed by the at-sign ("@"), 
followed by an Authorization Domain Name, (ii) including a Random Value in the 
email, and (iii) receiving a confirming response utilizing the Random Value. "

-Original Message-
From: Emu  On Behalf Of Michael Richardson
Sent: 13 November 2019 23:27
To: emu@ietf.org
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS



On 2019-11-13 7:40 a.m., Alan DeKok wrote:
> On Nov 12, 2019, at 3:13 PM, Cappalli, Tim (Aruba)  wrote:
>> How does a public CA prove ownership of an SSID?
>   Do public CAs *always* verify addresses and/or telephone numbers, which are 
> normally included in certificates?

They are?  I've rarely seen it.
I think that if it's in the certificate, then they have verified them.
I can remember in the bad old days providing CAs with notorized articles of 
incorporation, etc.
I haven't done that this decade though, and I haven't seen that kind of info.
CAs won't include anything they can't verify.

>   Do public CAs verify that email addresses in the certificate work?

yes, they do by sending a challenge to it.
>   Do public CAs verify that the OIDs in the certificate match the intended 
> use-cases?

Most won't include OIDs.
>   Is there a global registry of SSIDs which the public CA could use to verify 
> the SSID?

No, SSIDs are a local matter.
One could (and I do), use FQDNs as the SSID.

That's the only way I can see this working.

___
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] Idea: New X509 Extension for securing EAP-TLS

[Owen Friel (ofriel)]

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: 12 November 2019 16:32
To: Jan-Frederik Rieckers 
Cc: emu@ietf.org
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS



> 
> The Problem with dNSNames is that they are also used in other contexts 
> (mainly HTTPS).

  They're also domain names, not realms.  A particular certificate may be valid 
for authenticating uses to the realm "example.org".  That same certificate may 
not be valid for the main web site for "example.org".

  This means that domain names are a hint, but not authoritative.  Only the 
NAIRealm field would be authoritative.  i.e. "this certificate really is for 
users authenticating to a realm".

> There would be the possibility to define a specific prefix to bind it 
> to a Realm without having the certificate being valid for the HTTPS 
> host (e.g. eap-tls.uni-bremen.de for the realm
> uni-bremen.de) but I don't see the advantage in that.
> This will probably don't really lead to a change in the supplicants 
> implementations.

  A common short-hand is for certificates to use the "radius" subdomain.  e.g. 
"radius.example.org".  While not perfect, it's something.

[ofriel] this seems like something reasonable, but that's more a general 
deployment recommendation: ensure that the identity/realm of EAP servers is 
different from the identity/domain of webservers within an org. Therefore in 
the absence of an NAIRealm or id-kp-eapOverLAN extension in a cert,  clients 
can still distinguish between the two. Users point their Browser clients point 
to 'example.org' and wi-fi supplications are configured to look for 
'radius.exampe.org'.

The supplicant logic for verifying EAP server identity (assuming it already 
knows the root CA and a realm/domain string) could be check for NAIRealm first, 
then check for id-kp-eapOverLAN, then check for a dnsName.

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

Re: [Emu] Idea: New X509 Extension for securing EAP-TLS

[Owen Friel (ofriel)]

-Original Message-
From: Emu  On Behalf Of Michael Richardson
Sent: 12 November 2019 09:20
To: emu@ietf.org
Subject: Re: [Emu] Idea: New X509 Extension for securing EAP-TLS



On 2019-11-12 7:15 a.m., Owen Friel (ofriel) wrote:
> This is also related to ongoing anima discussions about RFC 8366, and how it 
> can bootstrap trust when the pinned domain cert is a public PKI CA, and not a 
> private CA, and hence additional domain (or realm or FQDN) info is also 
> needed in order for the peer to verify the identity of the server.

While I'm familiar with this conversation, which I'm right now inspired to call 
the the "Maria" problem ("How do solve a problem like Maria.  How do you a 
cloud certificate and pin it down?")

I don't really understand what it has to do with the problem of an EAP client, 
**which is not doing initial onboarding**, to validate a certificate that it 
has received as part of EAP-TLS*.

[ofriel] whether its first time bootstrap or subsequent EAP authentication, the 
EAP server is going to present the same identity cert to the client, and that 
could be signed by a public CA, and in both scenarios (bootstrap and 
reauthenticate) the client needs to know what identity to look for in the 
server cert.


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

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Owen Friel (ofriel)]

> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: 08 November 2019 12:43
> To: Joseph Salowey 
> Cc: EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Nov 7, 2019, at 11:08 PM, Joseph Salowey  wrote:
> > [Joe] How about
> > "If an implementation supports an external PSK it MUST provide a way to
> configure the realm so it can create an Anonymous NAI to send in the EAP-
> Identity response.  An EAP-TLS 1.3  implementation MUST NOT copy the PSK-ID
> into the EAP-Identity response. "
> 
>   That's good.

[ofriel]  Is the primary reason they MUST NOT be copied because of encoding 
differences? UTF-8 vs. TLS raw bytes?

On the privacy aspect, as the TLS PSK ID is sent unprotected and unencrypted in 
cleartext in the ClientHello, what information leakage are we preventing by not 
sending that same data in cleartext in the Identity Response?

Note that TLS1.3 PSK IDs are different to TLS1.3 client certs: PSK IDs are sent 
in cleartext in the ClientHello, client certs are sent encrypted inside the 
client's second flight. PSK IDs are not protected, client certs are (assuming 
of course that the client can validate the server identity when the server 
sends its first flight to the client).


> 
> > If someone thinks there is a need to allow the PSK-ID to be copied then the
> phrase could be extended with " unless there is prior knowledge that this will
> have an acceptable impact to privacy and the use case supports Identity
> responses that are not in the form of an NAI.
> 
>   ... and the PSK identity is compatible with the requirements of the EAP 
> Identity
> field, i.e. UTF-8.
> 
> > [Joe] The TLS 1.3 base spec teats certificate auth and external PSK auth as
> mutually exclusive for a particular handshake.   I do not think it restricts a
> particular server from supporting both external PSK and certificate
> authentication for separate connections.

[ofriel] Right.

> 
>   OK.  I'm back to "how do you tell?"

[ofriel]  You can of course trivially tell the difference between an extern PSK 
and a cert based auth - the ClientHellos are different.

This is a different question to the difference between an extern PSK and a 
resumption PSK. That is implementation specific and not defined in TLS1.3

> 
>   If the document suggests that plain PSK is OK, it would be very useful to
> describe the impact of that.  What does an implementation do?  How should
> administrators tell PSK identities apart?  If the EAP authenticator can't 
> control
> the derivation of PSK identities for resumption, is it even possible to have
> manually provisioned PSKs?

[ofriel] I agree some implementation advice would be good here. Should this be 
in EAP, or should we push for a TLS1.3 errata? It's the same advice that a 
standard TLS1.3 server implementor needs. OpenSSL for example defines its own 
resumption format, and provides a callback hook to check for extern PSKs, and 
it looks like OpenSSL lets the application check for an extern PSK match first 
before checking its internal resumption cache: 
https://github.com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1093.
 But of course that is TLS stack specific. We would need to document guidance 
olong the lines of checking for TLS stack behaviour.

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

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

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Owen Friel (ofriel)]

> -Original Message-
> From: Alan DeKok 
> Sent: 07 November 2019 17:48
> To: Owen Friel (ofriel) 
> Cc: Joseph Salowey ; draft-ietf-emu-eap-tl...@ietf.org;
> John Mattsson ; Michael
> Richardson ; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel)  wrote:
> > [ofriel] TLS1.3 explicitly does not allow both PSK and certs simultaneously.
> draft-ietf-tls-tls13-cert-with-extern-psk does, but that’s Experimental. I 
> don't
> think TLS with extern PSK is really intended for Web/Browser HTTPS
> connections. Its more for devices/things which are preprovisioned with the
> extern PSK.
> 
>   Then the EAP-TLS document should disallow it, too.  If TLS 1.3 doesn't 
> support
> it, I don't see how something built on top of TLS 1.3 can support it.

[ofriel]  TLS1.3 does not allow both PSK and cert based auth simultaneously on 
the same TLS session. It does allows support of both PSK and cert based auth on 
the same server, just on different TLS sessions. What 
draft-ietf-tls-tls13-cert-with-extern-psk does is allow both PSK and cert based 
auth simultaneously on the same TLS session. I can see how my statement was 
confusing, apologies.

> 
> > In TLS1.3, by design the protocol does not differentiate between resumption
> and external PSKs, and says nothing about PSK ID format, as commented here
> https://mailarchive.ietf.org/arch/msg/tls/Q5K8HSPPgLRojQwXbV4ZTIxBIH0 ,
> https://mailarchive.ietf.org/arch/msg/tls/X_z8pc3oS2Au7KajjMhlWhP1UPc
> 
>   Which is fine.  I'm happy to have PSKs be anything.  The caveat is that we 
> then
> MUST forbid the PSKs from being copied to the EAP Identity field.  So the EAP-
> TLS document has to make a recommendation.
> 
> > And its application specific how the two are differentiated, the spec says
> nothing about it:
> https://mailarchive.ietf.org/arch/msg/tls/btLnZERYv8GJJ2PFUksjNsDyv8o
> >
> > I still don't get why EAP-TLS1.3 should place restrictions on use of TLS1.3.
> Surely it should be an EAP server implementation decision on whether to 
> support
> that feature or not, but we should not preclude a specific EAP server
> implementation from supporting extern PSK by disallowing it in the spec. If a
> particular EAP server does not want to support extern PSK - that’s fine.
> 
>   Then we need to give guidance on what implementors and administrators
> should do.  Even if it means adding text saying "you can do certs OR PSK, but
> NOT BOTH".
[ofriel] You can do certs or PSK on the same TLS server, just not on the same 
TLS session. Unless draft-ietf-tls-tls13-cert-with-extern-psk became a thing.
> 
>   Alan DeKok.

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

Re: [Emu] EAP questions (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

[Owen Friel (ofriel)]

> -Original Message-
> From: Alan DeKok 
> Sent: 07 November 2019 17:43
> To: Owen Friel (ofriel) 
> Cc: Joseph Salowey ; draft-ietf-emu-eap-tl...@ietf.org;
> EMU WG ; John Mattsson
> ; Michael Richardson
> 
> Subject: Re: EAP questions (RE: [Emu] POST WGLC Comments draft-ietf-emu-
> eap-tls13)
> 
> On Nov 7, 2019, at 12:30 PM, Owen Friel (ofriel)  wrote:
> >> [Joe]  Is EAP Identity Synonymous with the NAI?
> >
> > [ofriel] I'd also like to definitively understand this. Neither RFC3748 or
> RFC7542 are clear on this. Should this be an errata to clarify.. somewhere?
> 
>   The EAP Identity can largely be anything, so long as it is UTF-8.
> 
>  The *recommendation* in RFC 7542 is to make it an NAI.  But that isn't
> mandated anywhere.
> 
>   I'm not sure there's any errata required.

[ofriel] On reading RFC 7542 again, I certainly agree with the sentiment that 
the NAI is recommended for EAP identity, but I don't see that actually being 
explicitly definitively stated anywhere in the document.

> 
> > Two other questions on RFC3748. Section 5.1 states:
> > "  It is RECOMMENDED that the Identity Response be used primarily for
> >  routing purposes and selecting which EAP method to use. "
> >
> > Is it defined anywhere how the Identity is used for EAP method selection?
> 
>   It is absolutely not mentioned anywhere.  For the simple reason that EAP
> provides for method negotiation.  We don't need to overload the Identity 
> field.

[ofriel] then why does https://tools.ietf.org/html/rfc3748#section-5.1 
explicitly state " It is RECOMMENDED that the Identity Response be used 
primarily for routing purposes and selecting which EAP method to use."

It explicitly states: "selecting which EAP method to use "

Should there be an errata for RFC 3748 to remove the last few words from that 
sentence: "and selecting which EAP method to use"?

And the "EAP provides for method negotiation" is via Nak messages, Ok, then my 
confusion was on the EAP method selection statement in section 5.1.

> 
>   The issue we're running into here is not about EAP method selection.  It's 
> about
> *TLS* method selection (PSK vs certs).  And that officially has little to do 
> with
> EAP.

[ofriel]  Sure, but that's not what I am getting at, I was asking about EAP 
method selection and my confusion between the statements in sections 
5.1/Identity and 5.3/Nak.
> 
> > Or is this EAP method specific and should be defined in the method specific
> draft?
> 
>   No EAP document should recommend overloading Identity in order to do EAP
> method selection.
> 
> > E.g. we have documented in https://tools.ietf.org/html/draft-lear-eap-teap-
> brski-05#section-5 that:
> >
> > "   A device that has not been bootstrapped at all SHOULD send an
> >   identity of teap-bootstrap@TBD1. "
> >
> > If we register that "teap-bootstrap@TBD1" with IANA, then it could be the
> mechanism by which the peer tells the server that it wants to use TEAP. If the
> server does not support TEAP, it will return an error response.
> 
>   The discussion prior to IETF 105 was that we should use the ".arpa" domain:
> https://www.iana.org/domains/arpa  That domain is explicitly intended for this
> kind of negotiation.
> 
>   Note that using ".arpa" still isn't EAP method selection.  It's instead 
> signalling
> something else.
> 
> > For routing, the Identity provided includes a realm and it could be 
> > anonymous:
> e.g. "@example.com". If the server cannot route to that domain, it returns an
> error.
> 
>   i.e. an EAP Failure message.
> 
> > EAP provides no mechanism to return an error code to the peer. How could we
> signal in EAP the error difference between routing vs EAP method unsupported
> failures? Or can we at all?
> 
>   EAP provides for a NAK for negotiation, and a Notification packet for 
> signalling
> errors or messages. Unfortunately, most supplicants don't support 
> Notification.
> And the ones that do won't show Notification messages to the end user.

[ofriel] Ok, thanks.

> 
>   Alan DeKok.

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

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Owen Friel (ofriel)]

> -Original Message-
> From: Emu  On Behalf Of Joseph Salowey
> Sent: 31 October 2019 04:45
> To: Alan DeKok 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson
> ; Michael Richardson
> ; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> 
> On Wed, Oct 30, 2019 at 4:12 AM Alan DeKok
>  wrote:
> On Oct 30, 2019, at 5:02 AM, Eliot Lear  wrote:
> > A fair argument, if it can be made, and I am not convinced it has been fully
> expressed, is the idea that there is no context by which one can separate fast
> restart and initial authentication.  This is Alan’s concern.  I’m not saying 
> it’s
> without merit, but what I cannot yet see is whether it is an implementation 
> or a
> protocol matter.
> 
>   I believe it's a protocol matter.  In TLS 1.3, PSK handshakes are the same 
> as
> resumption handshakes.
> 
>   It's not clear to me how this issue was addressed when using TLS 1.3 with
> HTTPS.  But I do believe it's an issue there, too.
> 
> [Joe] Can you elaborate on what the issue is?  I think most TLS deployments
> operate in either a certificate based mode or a PSK mode, but not both at the
> same time.

[ofriel] TLS1.3 explicitly does not allow both PSK and certs simultaneously. 
draft-ietf-tls-tls13-cert-with-extern-psk does, but that’s Experimental. I 
don't think TLS with extern PSK is really intended for Web/Browser HTTPS 
connections. Its more for devices/things which are preprovisioned with the 
extern PSK.

In TLS1.3, by design the protocol does not differentiate between resumption and 
external PSKs, and says nothing about PSK ID format, as commented here 
https://mailarchive.ietf.org/arch/msg/tls/Q5K8HSPPgLRojQwXbV4ZTIxBIH0 , 
https://mailarchive.ietf.org/arch/msg/tls/X_z8pc3oS2Au7KajjMhlWhP1UPc 

And its application specific how the two are differentiated, the spec says 
nothing about it: 
https://mailarchive.ietf.org/arch/msg/tls/btLnZERYv8GJJ2PFUksjNsDyv8o

I still don't get why EAP-TLS1.3 should place restrictions on use of TLS1.3. 
Surely it should be an EAP server implementation decision on whether to support 
that feature or not, but we should not preclude a specific EAP server 
implementation from supporting extern PSK by disallowing it in the spec. If a 
particular EAP server does not want to support extern PSK - that’s fine.

> 
>   As an additional note, I believe it's also important that 
> draft-dekok-emu-tls-
> eap-types be published at the same time as the EAP-TLS document.  The only
> unknown there is FAST and TEAP.  I'm happy to remove them from the
> document.
> 
>   But at this point it's not even a WG document.  There's not even consensus 
> that
> the document necessary, which surprises me rather a lot.  Because password-
> based EAP methods are *much* more wide-spread than EAP-TLS.
> 
>   If the IETF publishes EAP-TLS without simultaneously rev'ing TTLS and PEAP, 
> it
> will not only look bad, it will *be* bad.  And the industry press will 
> (rightfully)
> lambast the standards process.
> 
> [Joe] We need people to contribute to the document.  If we are going to 
> publish
> a document through the working group it needs to at least to include TEAP.   I
> know there are folks on this list who are implementing.  They need to step up
> and help with this document and the TEAP errata.
> 
>   Alan DeKok.
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu

[Emu] EAP questions (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

[Owen Friel (ofriel)]

> -Original Message-
> From: Emu  On Behalf Of Joseph Salowey
> Sent: 03 November 2019 18:31
> To: Alan DeKok 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG ; John
> Mattsson ; Michael
> Richardson 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> On Fri, Nov 1, 2019 at 4:08 AM Alan DeKok
>  wrote:
> On Nov 1, 2019, at 6:15 AM, John Mattsson
>  wrote:
> > I strongly support working group adoption of draft-dekok-emu-tls-eap-types.
> Can we make sure to get this document going, I agree that this is a very 
> needed
> draft. I think it should include updates for everything people wants to use. 
> I do
> not think draft-ietf-emu-eap-tls13 strictly have to wait for 
> draft-dekok-emu-tls-
> eap-types, but draft-dekok-emu-tls-eap-types should be published shortly 
> after.
> 
>   I will do an update to my document shortly.
> 
>   I also added an issue with the EAP-TLS document on GitHub.  The suggestion 
> is
> to add text which explains how (and why) the EAP Identity is chosen during
> resumption:
> 
> ---
> The EAP Identity used in resumption SHOULD be the same EAP Identity as was
> used during the original authentication. This requirement allows EAP packets 
> to
> be routable through an AAA infrastructure to the same destination as the
> original authentication.
> 
> 
> The alternative is to derive the EAP Identity from the identity used inside 
> of TLS.
> This derivation is common practice when using certificates, and works because
> the "common name" field in the certificate is typically compatible with EAP, 
> and
> it contains a routable identifier such as an email address. This practice 
> cannot be
> used for resumption, as the PSK identity may be a binary blob, and it might 
> not
> contain a routable realm as suggested by RFC 7542.
> 
> [Joe] Do implementations use the whole common name or just the domain
> portion.  Using the whole common name is not advisable with TLS 1.3.
> 
> In some cases, the PSK identity is derived by the underlying TLS 
> implementation,
> and cannot be controlled by the EAP authenticator. These limitations make the
> PSK identity unsuitable for use as the EAP Identity.
> 
> [Joe]  Is EAP Identity Synonymous with the NAI?

[ofriel] I'd also like to definitively understand this. Neither RFC3748 or 
RFC7542 are clear on this. Should this be an errata to clarify.. somewhere?


Two other questions on RFC3748. Section 5.1 states:
"  It is RECOMMENDED that the Identity Response be used primarily for
  routing purposes and selecting which EAP method to use. "

Is it defined anywhere how the Identity is used for EAP method selection? Or is 
this EAP method specific and should be defined in the method specific draft?

 E.g. we have documented in 
https://tools.ietf.org/html/draft-lear-eap-teap-brski-05#section-5 that:

"   A device that has not been bootstrapped at all SHOULD send an
   identity of teap-bootstrap@TBD1. "

If we register that "teap-bootstrap@TBD1" with IANA, then it could be the 
mechanism by which the peer tells the server that it wants to use TEAP. If the 
server does not support TEAP, it will return an error response.

For routing, the Identity provided includes a realm and it could be anonymous: 
e.g. "@example.com". If the server cannot route to that domain, it returns an 
error.

EAP provides no mechanism to return an error code to the peer. How could we 
signal in EAP the error difference between routing vs EAP method unsupported 
failures? Or can we at all?



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

[Emu] TLS1.3 and TEAP (RE: POST WGLC Comments draft-ietf-emu-eap-tls13)

[Owen Friel (ofriel)]

> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: 01 November 2019 11:08
> To: John Mattsson 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; Michael Richardson
> ; John Mattsson
> ; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Nov 1, 2019, at 6:15 AM, John Mattsson 
> wrote:
> > I strongly support working group adoption of draft-dekok-emu-tls-eap-types.
> Can we make sure to get this document going, I agree that this is a very 
> needed
> draft. I think it should include updates for everything people wants to use. 
> I do
> not think draft-ietf-emu-eap-tls13 strictly have to wait for 
> draft-dekok-emu-tls-
> eap-types, but draft-dekok-emu-tls-eap-types should be published shortly 
> after.
> 
>   I will do an update to my document shortly.

[ofriel] Question to the WG: should the TEAP changes for TLS1.3 be included in 
draft-dekok-emu-tls-eap-types? Or in draft-lear-eap-teap-brski - and note that 
the title is changed to " TEAP Update and Extensions for Bootstrapping "? Or 
potentially both? Eliot, Nancy and I had planned on adding TLS1.3 updates to 
draft-lear-eap-teap-brski, but haven't got it done yet.

> 
>   I also added an issue with the EAP-TLS document on GitHub.  The suggestion 
> is
> to add text which explains how (and why) the EAP Identity is chosen during
> resumption:
> 
> ---
> The EAP Identity used in resumption SHOULD be the same EAP Identity as was
> used during the original authentication. This requirement allows EAP packets 
> to
> be routable through an AAA infrastructure to the same destination as the
> original authentication.
> 
> The alternative is to derive the EAP Identity from the identity used inside 
> of TLS.
> This derivation is common practice when using certificates, and works because
> the "common name" field in the certificate is typically compatible with EAP, 
> and
> it contains a routable identifier such as an email address. This practice 
> cannot be
> used for resumption, as the PSK identity may be a binary blob, and it might 
> not
> contain a routable realm as suggested by RFC 7542.
> 
> In some cases, the PSK identity is derived by the underlying TLS 
> implementation,
> and cannot be controlled by the EAP authenticator. These limitations make the
> PSK identity unsuitable for use as the EAP Identity.
> ---
> 
>   Alan DeKok.
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

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

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Owen Friel (ofriel)]

From: Emu  On Behalf Of John Mattsson
Sent: 10 October 2019 09:30
To: Mohit Sethi M ; Eliot Lear 
Cc: draft-ietf-emu-eap-tl...@ietf.org; John Mattsson 
; EMU WG 
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Mohit Sethi M mohit.m.se...@ericsson.com 
wrote:

I think these are mostly TLS questions that would not be specific for 
EAP-TLS-PSK

> For example: the current TLS 1.3 spec requires external PSKs to be 
> provisioned for a specific hash function.

Yes, but if there is no specific hash function, SHA-256 is used as a default.

>Then there is also the discussion on how does a server handle external PSK vs. 
>PSK for resumption? They will clearly be >in different parts of the stack: 
>external PSKs with the EAP server and resumptions PSKs with the TLS server 
>library.
>Also, should a server issue resumption PSKs when the original authentication 
>is based on an external PSK. The only >benefit would be that it would make 
>tracking of peers/clients much harder.


[ofriel] I wouldn’t say that the only benefit is to make tracking of 
peers/clients harder. A server could use PSK for initial auth, and then issue 
local credentials for the thing within the EAP tunnel. The thing can now be let 
on the network immediately, and on subsequent reboots/reauths/reconnects can 
use its locally issued credential. In either scenario (initial bootstrap or 
subsequent reauth using the local credential), the server may issue resumption 
PSKs.


Yes, but I do not see how EAP would differ from any other TLS deployment with 
external PSK.


[ofriel] Agree. I do not see why EAP should place artificial constraints on 
TLS. I cannot see a good reason why an EAP-TLS implementation couldn’t be coded 
to have the same flexibility as any other TLS1.3 server. A particular EAP 
implementation could of course choose not to support authentication PSKs, but 
it seems a mistake to prohibit this in the specification.


>There is ongoing work in the TLS working group but the question is how long 
>should we wait: 
>https://tools.ietf.org/html/>draft-ietf-tls-external-psk-importer-01

I see no reason to wait for that draft. What 
draft-ietf-tls-external-psk-importer does is to allow a single external PSK to 
be used to negotiate both TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384. 
Most IoT would not want to negotiate AES-256 and SHA-384, and those who want 
(like e.g. US government devices using the CSNA suite) would probably not want 
to negotiate AES-128 and SHA-256. draft-ietf-tls-external-psk-importer fills a 
gap in the TLS 1.3 protocol, but is not a game changer in any way.

John

From: Mohit Sethi M 
mailto:mohit.m.se...@ericsson.com>>
Date: Thursday, 10 October 2019 at 10:03
To: Eliot Lear mailto:l...@cisco.com>>, John Mattsson 
mailto:john.matts...@ericsson.com>>
Cc: 
"draft-ietf-emu-eap-tl...@ietf.org" 
mailto:draft-ietf-emu-eap-tl...@ietf.org>>, 
John Mattsson 
mailto:john.mattsson=40ericsson@dmarc.ietf.org>>,
 EMU WG mailto:emu@ietf.org>>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13


I wouldn't say that TLS 1.3 is wrong but there is some stuff that could benefit 
from further clarification. For example: the current TLS 1.3 spec requires 
external PSKs to be provisioned for a specific hash function. Then there is 
also the discussion on how does a server handle external PSK vs. PSK for 
resumption? They will clearly be in different parts of the stack: external PSKs 
with the EAP server and resumptions PSKs with the TLS server library. Also, 
should a server issue resumption PSKs when the original authentication is based 
on an external PSK. The only benefit would be that it would make tracking of 
peers/clients much harder.

There is ongoing work in the TLS working group but the question is how long 
should we wait: 
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-01

--Mohit
On 10/10/19 10:51 AM, Eliot Lear wrote:
I do think this is where we can make TEAP’s sweet spot.  But we should avoid 
differences in TLS implementations between TEAP and EAP-TLS.  That just 
complicates libraries.  And it’s for that same reason that I’m just a bit 
nervous about us constraining TLS 1.3.  Put another way: before we do so we 
have to answer this question: what is so different about EAP than other TLS 
applications?  If the answer is “nothing” for a particular case, then either we 
have it wrong or TLS 1.3 has it wrong, and we should sort that.

Eliot



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

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Owen Friel (ofriel)]

> -Original Message-
> From: John Mattsson 
> Sent: 19 September 2019 11:04
> To: Owen Friel (ofriel) ; Jim Schaad
> ; 'Alan DeKok' 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> I am starting to come down on the side the EAP-TLS PSK should be specified.
> 
> - I think EAP-PSK should be phased out like all other methods not giving PFS.
> - The security of the Dragonfly handshake used in EAP-PWD (and WPA3)
> seems quite shaky ( https://eprint.iacr.org/2019/383 ), but I have not looked
> into the details.
> 
> - An EAP password method for the future should likely use the PAKE that
> CFRG will soon standardize.
> - EAP methods should in the future support some PQC key exchange.
> 
> TLS will very likely get support for both the CFRG PAKE and PQC key
> exchange algorithms. I am not sure the EAP group want to spend time
> updating either EAP-PSK or ESP-PWD. Unless there are other benefits with
> EAP-PSK or EAP-PWD, I think standardizing EAP-TLS PSK makes a lot of sense.

Right, we have already started a couple of drafts along these lines, but are in 
a holding pattern now until CFRG are done:

https://tools.ietf.org/html/draft-barnes-tls-pake-04
https://tools.ietf.org/html/draft-sullivan-tls-opaque-00


> 
> I also note that, EAP-PSK is experimental and EAP-PWD is informal. Unless
> IETF thinks PSK and passwords should not be used (which does certainly not
> seem to be the case as TLS 1.3 is including PSK and CFRG is standardizing
> password based AKE) I think that EMU should make some PSK and password
> based method Standards Track. At the moment EAP-TLS 1.3 looks like the
> best choice.
> 

Additionally, we have had early discussions about updating TEAP RFC7170 to 
explicitly handle TLS 1.3, these updates could possibly be incorporated into 
https://tools.ietf.org/html/draft-lear-eap-teap-brski-04 , which is more and 
more looking like a general TEAP extensions / update draft, not a BRSKI 
specific draft.

And FYI, some movement has been made on TEAP with experimental support added to 
wpa_supplicant https://w1.fi/cgit/hostap/plain/wpa_supplicant/ChangeLog 


> Jim wrote:
> > and more to do with the security properties of the EAP method.
> 
> If that is seen as a problem, standardizing a separate Type-Code for EAP-TLS
> with PSK authentication would solve the problem.
> 
> /John
> 
> -Original Message-
> From: "Owen Friel (ofriel)" 
> Date: Thursday, 19 September 2019 at 11:17
> To: Jim Schaad , 'Alan DeKok'
> 
> Cc: "draft-ietf-emu-eap-tl...@ietf.org"  tl...@ietf.org>, 'EMU WG' 
> Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Resent
> from:  Resent to: John Mattsson
> ,  Resent date:
> Thursday, 19 September 2019 at 11:17
> 
> 
> 
> > -Original Message-
> > From: Jim Schaad 
> > Sent: 19 September 2019 07:28
> > To: 'Alan DeKok' ; Owen Friel (ofriel)
> > 
> > Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' 
> > Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> >
> > I am going to come down on the side of no PSK should not be supported.
> > However my issues have nothing to do with how things are implemented
> > and more to do with the security properties of the EAP method.
> >
> > When you use certificates, there is no leakage of who the client is as 
> this
> is
> > encrypted by TLS.  When you use a restore session ticket, it is 
> possible to
> limit
> > the number of times that the ticket can be used (for example once).
> > The PSK identity is public and unprotected so it can be used to track.  
> If
> one is
> > using PSK for the purpose of authentication then that value will always 
> be
> > visible to intermediate parties for the purpose of tracking.
> > This can be slightly mitigated by using restore session tickets with 
> PSK,
> but
> > you are going to send that PSK identifier over the wire many times.
> 
> The IoT use case is to use the PSK one time for authentication during
> bootstrapping, then get credentialed, and thereafter use a certificate for
> subsequent EAP authentications. The bootstrap PSK enables proof of
> possession i.e. the thing will only bootstrap against a network that knows its
> PSK.
> 
> >
> >
> > This is just informational and can be ignored:
> >
> > My current favorite way to deal with PSK/ticket identifiers is with
> > encryption:
> >
> > 32 bytes of index into table
> > 32 bytes of date information
> > 32 bytes o

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Owen Friel (ofriel)]

> -Original Message-
> From: Jim Schaad 
> Sent: 19 September 2019 07:28
> To: 'Alan DeKok' ; Owen Friel (ofriel)
> 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' 
> Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> I am going to come down on the side of no PSK should not be supported.
> However my issues have nothing to do with how things are implemented
> and more to do with the security properties of the EAP method.
> 
> When you use certificates, there is no leakage of who the client is as this is
> encrypted by TLS.  When you use a restore session ticket, it is possible to 
> limit
> the number of times that the ticket can be used (for example once).
> The PSK identity is public and unprotected so it can be used to track.  If 
> one is
> using PSK for the purpose of authentication then that value will always be
> visible to intermediate parties for the purpose of tracking.
> This can be slightly mitigated by using restore session tickets with PSK, but
> you are going to send that PSK identifier over the wire many times.

The IoT use case is to use the PSK one time for authentication during 
bootstrapping, then get credentialed, and thereafter use a certificate for 
subsequent EAP authentications. The bootstrap PSK enables proof of possession 
i.e. the thing will only bootstrap against a network that knows its PSK.

> 
> 
> This is just informational and can be ignored:
> 
> My current favorite way to deal with PSK/ticket identifiers is with
> encryption:
> 
> 32 bytes of index into table
> 32 bytes of date information
> 32 bytes of SIV (synthetic IV)
> 
> Encrypt the first two items using the SIV.  You can then have multiple keys 
> for
> decryption.  One for PSKs and a resolving one for session tickets.  If the
> identifier does not decrypt then you reject.  Otherwise you look at the date
> information and the index in the table for the secret information.
> 
> It is even possible to play games with AAD to do things like scope the tickets
> up front - if you put in the name/address of the NAS then you have a
> prescreen on where the ticket can be used.
> 
> Jim
> 
> 
> 
> 
> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: Wednesday, September 18, 2019 2:59 PM
> To: Owen Friel (ofriel) 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel)  wrote:
> > Giving some implementation guidance seems appropriate here. Naively,
> > one
> could envisage the implementation simply having a DB table for extern PSKs
> and a table that holds NewSessionTickets. An implementation could simply
> check the extern PSK table using the PskIdentity.identity, and if no match is
> found then check the NewSessionTickets table.
> 
>   Which works, but should be called out in the draft.
> 
>   And what is to prevent the system from generating conflicting PSK
> identities?  i.e. I don't control OpenSSL.  From what I see, TLS 1.3 
> resumption
> means that OpenSSLL will choose whatever PSK identity it deems fit.
> 
>   As an implementor and/or admin, how do I choose *pre-provisioned* PSK
> identities which won't conflict with the ones OpenSSL choose?
> 
> > The default OpenSSL NSK ticketId is 32 bytes long
> https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86a
> d1fa4c
> 8de9/include/openssl/ssl3.h#L127 so something has gone seriously wrong if
> there is a clash (poor randoms, etc.).
> 
>   i.e. "pick a long string and that should be good enough".
> 
>   If that really is the guidance, then this should also be called out in the 
> draft.
> PSK identities MUST be long (ideally 32 octets or more), and MUST be
> generated from a CSPRNG.
> 
>   Which then leads to the question of what will the poor user enter in a UI?
> If "end users" shouldn't be doing this, the draft also needs to call that out.
> 
> > Well, more precisely, the PSK identity is visible in the ClientHello,
> > not
> the actual PSK of course.
> 
>   Sure.
> 
> > And the PSK *must not* be a user-manageable string such as the
> >> NAI.  On the other hand, if the PSK is sent after encryption begins,
> >> then the PSK *should* be a user-manageable string such as an NAI.
> >
> > https://tools.ietf.org/html/rfc8446#section-2.2 also states:
> > ...
> > so TLS-PSK is not suitable for a user entered low entropy password. We
> > need a PAKE for that (c.f. the ongoing CFRG PAKE assessment)
> 
>   Sure.
> 
> > There are some use cases Eliot and I are looking at related to IoT
> onboarding where a TLS-PSK 

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Owen Friel (ofriel)]

And one other draft of interest: 
https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-00

> -Original Message-
> From: Emu  On Behalf Of Owen Friel (ofriel)
> Sent: 18 September 2019 22:42
> To: Alan DeKok ; John Mattsson
> 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> 
> > -Original Message-
> > From: Alan DeKok 
> > Sent: 18 September 2019 14:40
> > To: John Mattsson 
> > Cc: Owen Friel (ofriel) ; draft-ietf-emu-eap-
> > tl...@ietf.org; EMU WG 
> > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> >
> >
> >
> > > On Sep 18, 2019, at 9:21 AM, John Mattsson
> >  wrote:
> > >
> > > If I understand you correctly Alan, your implementation would have
> > different databases (one resumption DB and one external PSK DB) and
> > you do not want to do two database lookups.
> >
> >   It's more about what *can* be done.  RFC 8446 Section 8.1 and 8.2
> > talk about using multiple DBs, too.
> >
> > > The format of the PSKidentities is free for the deployment to decide
> > > upon
> > and the resumption PSKs can be completely be determined by the EAP-TLS
> > implementation. Your implementation could for example put a message
> > authentication code inside the PSK identity. The MAC would be
> > calculated with a symmetric key the EAP server has randomly generated
> > by itself. I think that would solve your problem.
> >
> >   I suggest giving guidance to implementors.  Otherwise the issue is
> > open to implementation-defined behaviour, which is problematic.
> 
> Giving some implementation guidance seems appropriate here. Naively, one
> could envisage the implementation simply having a DB table for extern PSKs
> and a table that holds NewSessionTickets. An implementation could simply
> check the extern PSK table using the PskIdentity.identity, and if no match is
> found then check the NewSessionTickets table. The default OpenSSL NSK
> ticketId is 32 bytes long
> https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86a
> d1fa4c8de9/include/openssl/ssl3.h#L127 so something has gone seriously
> wrong if there is a clash (poor randoms, etc.). An additional layer of
> protection is provided by the PskBinderEntry as this is a HMAC derived using
> the PSK as one input, so the server even if there happened to be an identity
> clash, the binders will not match.
> 
> Implementations should also note
> https://tools.ietf.org/html/rfc8446#appendix-E.6.
> 
> >
> >   If PSKs are used only for resumption, the the format doesn't matter.
> > If PSKs are used for both authentication *and* resumption, then I
> > strongly recommend giving guidance.
> >
> >   For example, RFC 8446 Section 4.1.2 says:
> >
> >   struct {
> >   opaque identity<1..2^16-1>;
> >   uint32 obfuscated_ticket_age;
> >   } PskIdentity;
> >
> >   i.e. the PSK identity is an opaque binary string.  How is the user
> > supposed to enter a binary string into a "username" field in their
> > GUI?  What are the recommended formats?
> >
> >   If the ClientHello isn't encrypted, then the PSK is visible to
> > anyone (I believe).
> 
> Well, more precisely, the PSK identity is visible in the ClientHello, not the
> actual PSK of course.
> 
> And the PSK *must not* be a user-manageable string such as the
> > NAI.  On the other hand, if the PSK is sent after encryption begins,
> > then the PSK *should* be a user-manageable string such as an NAI.
> 
> https://tools.ietf.org/html/rfc8446#section-2.2 also states:
> 
> "   Note:  When using an out-of-band provisioned pre-shared secret, a
>   critical consideration is using sufficient entropy during the key
>   generation, as discussed in [RFC4086].  Deriving a shared secret
>   from a password or other low-entropy sources is not secure.  A
>   low-entropy secret, or password, is subject to dictionary attacks
>   based on the PSK binder.  The specified PSK authentication is not
>   a strong password-based authenticated key exchange even when used
>   with Diffie-Hellman key establishment.  Specifically, it does not
>   prevent an attacker that can observe the handshake from performing
>   a brute-force attack on the password/pre-shared key. "
> 
> so TLS-PSK is not suitable for a user entered low entropy password. We need
> a PAKE for that (c.f. the ongoing CFRG PAKE assessment)
> 
> 
> >
> >   I see it being useful for EAP-TLS to allow PSK auth

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Owen Friel (ofriel)]

> -Original Message-
> From: Alan DeKok 
> Sent: 18 September 2019 14:40
> To: John Mattsson 
> Cc: Owen Friel (ofriel) ; draft-ietf-emu-eap-
> tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> 
> > On Sep 18, 2019, at 9:21 AM, John Mattsson
>  wrote:
> >
> > If I understand you correctly Alan, your implementation would have
> different databases (one resumption DB and one external PSK DB) and you
> do not want to do two database lookups.
> 
>   It's more about what *can* be done.  RFC 8446 Section 8.1 and 8.2 talk
> about using multiple DBs, too.
> 
> > The format of the PSKidentities is free for the deployment to decide upon
> and the resumption PSKs can be completely be determined by the EAP-TLS
> implementation. Your implementation could for example put a message
> authentication code inside the PSK identity. The MAC would be calculated
> with a symmetric key the EAP server has randomly generated by itself. I think
> that would solve your problem.
> 
>   I suggest giving guidance to implementors.  Otherwise the issue is open to
> implementation-defined behaviour, which is problematic.

Giving some implementation guidance seems appropriate here. Naively, one could 
envisage the implementation simply having a DB table for extern PSKs and a 
table that holds NewSessionTickets. An implementation could simply check the 
extern PSK table using the PskIdentity.identity, and if no match is found then 
check the NewSessionTickets table. The default OpenSSL NSK ticketId is 32 bytes 
long 
https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86ad1fa4c8de9/include/openssl/ssl3.h#L127
 so something has gone seriously wrong if there is a clash (poor randoms, 
etc.). An additional layer of protection is provided by the PskBinderEntry as 
this is a HMAC derived using the PSK as one input, so the server even if there 
happened to be an identity clash, the binders will not match.

Implementations should also note 
https://tools.ietf.org/html/rfc8446#appendix-E.6. 

> 
>   If PSKs are used only for resumption, the the format doesn't matter.  If 
> PSKs
> are used for both authentication *and* resumption, then I strongly
> recommend giving guidance.
> 
>   For example, RFC 8446 Section 4.1.2 says:
> 
>   struct {
>   opaque identity<1..2^16-1>;
>   uint32 obfuscated_ticket_age;
>   } PskIdentity;
> 
>   i.e. the PSK identity is an opaque binary string.  How is the user supposed 
> to
> enter a binary string into a "username" field in their GUI?  What are the
> recommended formats?
> 
>   If the ClientHello isn't encrypted, then the PSK is visible to anyone (I
> believe).  

Well, more precisely, the PSK identity is visible in the ClientHello, not the 
actual PSK of course.

And the PSK *must not* be a user-manageable string such as the
> NAI.  On the other hand, if the PSK is sent after encryption begins, then the
> PSK *should* be a user-manageable string such as an NAI.

https://tools.ietf.org/html/rfc8446#section-2.2 also states:

"   Note:  When using an out-of-band provisioned pre-shared secret, a
  critical consideration is using sufficient entropy during the key
  generation, as discussed in [RFC4086].  Deriving a shared secret
  from a password or other low-entropy sources is not secure.  A
  low-entropy secret, or password, is subject to dictionary attacks
  based on the PSK binder.  The specified PSK authentication is not
  a strong password-based authenticated key exchange even when used
  with Diffie-Hellman key establishment.  Specifically, it does not
  prevent an attacker that can observe the handshake from performing
  a brute-force attack on the password/pre-shared key. "

so TLS-PSK is not suitable for a user entered low entropy password. We need a 
PAKE for that (c.f. the ongoing CFRG PAKE assessment)


> 
>   I see it being useful for EAP-TLS to allow PSK authentication.  I just want 
> to
> be sure I know what that means, and what the impacts are.

There are some use cases Eliot and I are looking at related to IoT onboarding 
where a TLS-PSK authentication has definite value, and we really don't want to 
see this avenue closed off in EAP. Happy to provide any suggestions on 
Implementation Notes to your draft.

> 
> > I do not see how an attacker could do anything. an attacker can
> definitely reuse any PSK identity, but would not have the corresponding PSK
> and the ClientHello would therefore not be accepted. The worst thing an
> attacker could do is to replay a ClientHello, then the handshake would fail
> then the EAP server verifies the Finished message.

And note https://tools.ietf.org/html/rfc8446#appendix-E.6 where there is 
guidanc

Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

[Owen Friel (ofriel)]

> -Original Message-
> From: Emu  On Behalf Of Alan DeKok
> Sent: 12 September 2019 16:28
> To: John Mattsson 
> Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG 
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> On Sep 12, 2019, at 10:55 AM, John Mattsson
>  wrote:
> >
> >> See Section 2.1.2.  TLS 1.3 uses PSK for resumption.  As a result, we
> *cannot* use PSK for >authentication in EAP-TLS.
> >
> > I don't understand why this could not be done. My view is that allowing PSK
> authentication would be quite easy.
> 
>   How would systems tell the difference between "raw" PSK and
> "resumption" PSK?
> 
>   When allowing resumption, the server has sent a PSK identity in a
> NewSessionTicket message.  The client caches this and re-uses this.  But the
> client signals that it is performing resumption via the act of using PSK.  
> There's
> nothing else.
> 
>   Which means that if PSK was allowed, the server can't look at the packets to
> distinguish resumption from "raw" PSK.  Instead, the server has to look at 
> it's
> resumption cache which may be in a DB.

The server can use the PskIdentity in the PreSharedKeyExtension to 
differentiate between an offline PSK used for authentication vs. a PSK 
established via NewSessionTicket.

There should be no problem here, and the statement

" Pre-Shared Key (PSK) authentication SHALL NOT be used except
   for resumption. "

should be updated to clarify.

> 
> >>> While there is the EAP-PSK method, I would much rather use EAP-TLS
> with PSK because it >provides identity protection and perfect forward
> secrecy, unlike EAP-PSK.
> >>
> >> Use EAP-PWD for that.
> >
> > Standardizing EAP-TLS should only be done if it has some significant
> advantages over EAP-PWD, and there are people wanting to implement and
> use it. 3GPP is e.g. adding  identity protection and perfect forward secrecy 
> to
> EAP-AKA instead.
> 
>   I would prefer to forbid PSK in EAP-TLS.
> 
>   Alan DeKok.
> 
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu

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

Re: [Emu] teap-brski

[Owen Friel (ofriel)]

-Original Message-
From: Emu  On Behalf Of Dan Harkins
Sent: 06 June 2019 15:13
To: an...@ietf.org; emu@ietf.org
Subject: [Emu] teap-brski





  Hello,



  In a private thread on teap-brski the topic of co-location of the TEAP server 
and the BRSKI registrar was brought up. It was suggested that the discussion 
move to these lists to get more input from the experts.



  In draft-lear-eap-teap-brski-02 the architecture shows a the TEAP server and 
the BRSKI registrar as separate while mentioning that they can be co-located.

The following assumes they are not co-located.



  The BRSKI pledge in this draft is called a "device" and the device 
establishes a provisional TLS connection (through TEAP) to the TEAP server over 
802.1X or something similar. The device does not connect to the registrar. The 
device then creates a voucher request and sends it to the TEAP server using a 
newly defined TEAP TLV. The registrar signs the request, forwards it onto a 
MASA, and sends the voucher it gets back from the MASA to the device using 
another newly defined TEAP TLV.



  So the question is, will this even work? If the TEAP server and BRSKI 
registrar are separate entities then the voucher will include the TEAP server's 
EE certificate but it will be signed by the registrar's EE certificate. From my 
admittedly limited understanding of BRSKI I think the MASA will reject this 
voucher request because it fails the "proximity" check (if I understand the 
proximity check correctly). The MASA will treat the registrar as a 
man-in-the-middle.



  BRSKI folks: is this correct? Will a voucher request be rejected from a 
deployment like this?



[ofriel] I believe this will fail the proximity check as outlined in 
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-5.5.5



However, there is an interesting definition in 
https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-20#section-3.4



leaf prior-signed-voucher-request {

  type binary;

  description

"If it is necessary to change a voucher, or re-sign and

 forward a voucher that was previously provided along a

 protocol path, then the previously signed voucher SHOULD be

 included in this field.



 For example, a pledge might sign a voucher request

 with a proximity-registrar-cert, and the registrar

 then includes it in the prior-signed-voucher-request field.

 This is a simple mechanism for a chain of trusted

 parties to change a voucher request, while

 maintaining the prior signature information.



 The Registrar and MASA MAY examine the prior signed

 voucher information for the

 purposes of policy decisions. For example this information

 could be useful to a MASA to determine that both pledge and

 registrar agree on proximity assertions. The MASA SHOULD

 remove all prior-signed-voucher-request information when

 signing a voucher for imprinting so as to minimize the

 final voucher size.";

}



Most notable: “This is a simple mechanism for a chain of trusted parties to 
change a voucher request, while maintaining the prior signature information.”



So with some extra definition, one could envisage the TEAP server signing the 
Voucher request using its cert and including the Pledge’s voucher request in 
its prior-signed-voucher-request and sending it to the RA, and then the RA in 
turn signing the request using its own cert, and including the TEAP server’s 
voucher request in its prior-signed-voucher-request. The pledge could also 
assert the TEAP EE cert in its voucher request, with the TEAP server asserting 
the RA’s cert in its voucher request. The MASA could in theory then validate 
the full chain of trust back.



Now, that’s reading a lot into that one statement, and the rest of BRSKI 
certainly doesn’t describe operation like that, and its far easier to mandate 
that the TEAP server *is* the Registrar.







  EMU folks: if the answer from the BRSKI folks is that this doesn't work then 
is there any sort of weird tunneling or "phase 2" trickery that can be added to 
TEAP to get this to work or should we just explicitly state that the TEAP 
server and the registrar are the same entity (they authenticate with the same 
certificate)?



  Thanks,



  Dan.





___

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] Comments on draft-lear-eap-teap-brski

[Owen Friel (ofriel)]

Thanks Alan. These suggestions make sense and will help clear up the confusion. 
They can be incorporated in draft-01.

-Original Message-
From: Emu  On Behalf Of Alan DeKok
Sent: Saturday 21 July 2018 15:12
To: emu@ietf.org
Subject: [Emu] Comments on draft-lear-eap-teap-brski

  One of the confusions from the meeting was "How can a device authenticate via 
802.1X if it doesn't trust the network?"

  I think the confusion is due to terminology.  The discussion in the meeting, 
and in the draft was about the device "authenticating" to the network during 
initial bootstrapping.  The authors may correct me if I'm wrong, but this step 
is really "provisioning".

  i.e. the device gets on the network without authenticating itself in the 
traditional sense (password, certificate, etc.)

  The document isn't clear on this, which makes it more difficult to understand.

  From Section 3.1 of the document:

   The device establishes an outer TEAP tunnel with the TEAP server and
   does not validate the server certificate.

  I would also add that the TEAP server does not authenticate the device (as 
such).  Instead, this step is about provisioning.

  Continuing from Section 3.1:

   The device sends a BRSKI-RequestVoucher TLV to the TEAP server.  The
   TEAP server forwards the RequestVoucher message to the MASA server,
   and the MASA server replies with a signed voucher.  The TEAP server
   sends a BRSKI-Voucher TLV to the device.

   If the MASA server does not issue a signed voucher, the TEAP server
   sends an EAP-Error TLV with a suitable error code to the device.

  It would help to say that neither the TEAP server nor the MASA server has (as 
yet) authenticated the device.  Which means that the device has established a 
secure tunnel to an unknown endpoint.  That endpoint may later reject the 
device, at which point the device tries another SSID.

  As a practical example, there may be two businesses who wish to install WiFi 
cameras.  Each business has their own SSID.  Any new device will randomly 
connect to one of the SSIDs.  If the device is known (somehow) to the business, 
it will be provisioned and allowed onto the network.  If the device is not 
known, it will be rejected, and will try the other SSID.

  I think it would help future discussions to consistently refer to this phase 
as "provisioning", and not "authentication".

  i.e. "the device provisionally connects to the 802.1X network".  Or "the 
device connects to the 802.1X network for initial provisioning".

  Once the device is provisioned, it can "authenticate" to the 802.1X network 
as normal.  i.e. from Section 3.1 again:

   Once step 5 is complete, the device has completed the BRSKI flow and
   has established trust with the network.

  I would add "the device can then perform normal 802.1X authentication with 
it's provisioned credentials, and with the provisioned network information."

  From section 4.1:

If the client is bootstrapping and has
   not yet completed a BRSKI flow, it will not have trust anchors
   installed yet, and thus will not be able to validate the server's
   certificate.

  It would help instead to use consistent terminology:

If the client is in the provisioning phase and has
   not yet completed a BRSKI flow, it will not have trust anchors
   installed yet, and thus will not be able to validate the server's
   certificate.


  And the same applies later:

   It is recommended that the client validate the certificate presented
   by the server in the server's Certificate message, but this may not
   be possible for bootstrapping clients that do not have appropriate
   trust anchors installed yet.

to:

   It is recommended that the client validate the certificate presented
   by the server in the server's Certificate message, but this may not
   be possible for clients which have not yet been provisioned with
   the appropriate trust anchors.

  The referenced IDs use the term bootstrapping", 
(ietf-anima-bootstrapping-keyinfra).  But RFC 7170 (TEAP) uses "bootstrapping" 
once, and "provisioning" many times.

  My $0.02 is that "provisioning" is clearer in this context than 
"bootstrapping".

  Alan DeKok.

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

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

Re: [Emu] Re-Charter Considerations

[Owen Friel (ofriel)]

From: Emu  On Behalf Of Dr. Pala
Sent: Friday 20 July 2018 23:21
To: emu@ietf.org
Subject: [Emu] Re-Charter Considerations


Hi Emu-ers,

I wanted to follow up the discussion from today's meeting. In particular, there 
is some work that has been proposed that might require re-chartering as 
indicated by Ekr and supported by the Chair(s).

I would like to push forward the request for re-chartering, in particular, I 
would like to add the definition of one (or more) EAP-based credentials 
provisioning mechanisms that would fit many use cases that we are currently 
working on in different organizations.

In particular, the use cases that I am referring to are the following:

  *   Cellular Networks. The provisioning of Certificates (or other 
credentials) to enable the use of EAP methods in different environments (e.g., 
CBRS Alliance, MutleFire, etc.) has been a problem that the current ecosystem 
have not addressed efficiently. The use of OSU servers and the complexity (and 
associated risks) of allowing (partial) IP access to non-authenticated devices 
has limited the possibility for in-line provisioning of devices. The use of an 
EAP-based mechanism that can be used for credentials provisioning (and renewal) 
would greatly improve the feasibility of in-band credentials deployment. This 
authentication mechanism would improve the possibility to use 4G\LTE (and 
future 5G) networks for IoT credentials management which, today, seems to be 
ignored because of the complexity required on the device.

  *   Cable Networks. With the deployment of the new DOCSIS 3.1 FDX 
specifications and its newly defined support for EAP authentication via X.509 
certificate throughout the whole ecosystem, the ability to provide an EAP-based 
mechanism that can be used for credentials provisioning and renewal, would 
greately improve the feasibility of in-band credentials deployment also in this 
case and the possibility to further secure the infrastructure by allowing for 
better certificates management (i.e., renewal, deployment, etc.)

  *802.1x / WBA / HS2.0. Also in these ecosystems, the possibility to 
provision (and re-provision) dynamically credentials opens up the possibility 
for more secure management of identities. As in the previous use-cases, the 
management directly at layer 2 allows for a simple (and extensible :D) approach 
to credentials provisioning for devices.

Therefore, counting the fact that all these ecosystems are looking at a 
standardized / common solution to solve the same issue, I think it is the right 
time to evaluate the possibility to work on this important aspect.

In my opinion, the WG should open up to evaluate the possibility to work on the 
standardization of EAP-based provisioning mechanisms that would allow for 
easier management options safer life-cycles of device and subscribers 
credentials.

On the need to re-charter, I would like to point out that this type of work has 
been done in the past, therefore is not a completely new territory (i.e., TEAP 
/ EST).

[ofriel] Agreed. TEAP already supports provisioning mode of operation, and 
provisioning of PAC, certificates and server trusted roots:

   3.8.1.  PAC 
Provisioning  . . . . . . . . . . . . . . . . . .  
21

   3.8.2.  Certificate 
Provisioning within the Tunnel  . . . . .  
22

   3.8.3.  Server 
Unauthenticated Provisioning Mode  . . . . . .  
23


   4.2.16. PKCS#7 TLV  
. . . . . . . . . . . . . . . . . . . . .  
53

   4.2.17. PKCS#10 TLV 
. . . . . . . . . . . . . . . . . . . . .  
54

   4.2.18. 
Trusted-Server-Root TLV . . . . . . . . . . . . . . .  
55

So while provisioning is out of scope of the current charter, it must have 
previously been in scope during TEAP standardisation. For the specific ANIMA 
use case we had in mind, we proposed reusing existing TEAP Provisioning Mode, 
PKCS enrolment, and Trusted-Server-Root provisioning, and extending that to 
support the ANIMA BRSKI specifics.





What we need now is the possibility to address (a) the bootstrapping problem, 
and (b) the need for supporting additional provisioning protocols that address 
different ecosystems (i.e., simpler approaches that can be implemented in 
sub-systems like micro-controllers - this would facilitate the integration of 
credentials management independent from the application layer / wifi module / 
etc.), and (c) the possibility of defining