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

2021-07-27 Thread 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

2020-03-11 Thread 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

2020-03-06 Thread 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

2020-01-07 Thread 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

2019-12-15 Thread 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

2019-11-19 Thread 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

2019-11-16 Thread 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

2019-11-16 Thread 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

2019-11-16 Thread 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

2019-11-16 Thread 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

2019-11-16 Thread 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

2019-11-11 Thread 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

2019-11-11 Thread 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)

2019-11-11 Thread 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

2019-11-07 Thread 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)

2019-11-07 Thread 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)

2019-11-07 Thread 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

2019-10-10 Thread 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

2019-09-19 Thread 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

2019-09-19 Thread 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

2019-09-18 Thread 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

2019-09-18 Thread 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

2019-09-18 Thread 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

2019-06-10 Thread 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

2018-07-25 Thread 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

2018-07-25 Thread 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