Could not use Webauthn `PublicKeyCredential.create` when the RP ID is a Host string(ip).

[slayercat]

What's happening

In enterprise internal network which must access site via IP address, the Webauthn API will not work according to the specification.

Details

In the section 5.1.3: Create a New Credential: (ref: https://w3c.github.io/webauthn/#sctn-createCredential)

Note: An effective domain may resolve to a host, which can be represented in various manners, such as domain, ipv4 address, ipv6 address, opaque host, or empty host. Only the domain format of host is allowed here. This is for simplification and also is in recognition of various issues with using direct IP address identification in concert with PKI-based security.

But in enterprise internal network. It's really common to directly use IP address for accessing the site. Limit the access to domain will limit the Webauthn API usage in these scenario.

I've searched for the issues. Seems only #474 relates to it. But I could not found the reason for this decision except standard consistency with HSTS. And HSTS seems hard to work in enterprise internal network sites.

I think The Credential used in Webauthn is generated per-site. It will not involves the PKI architecture like CRL(Certification Revocation List) or other things that works with certificate. So the limit here we meet seems a little difficult to understand.

Besides, The spec says:

The effective domain of an origin origin is computed as follows:

1. If origin is an opaque origin, then return null.
2. If origin's domain is non-null, then return origin's domain.
3. Return origin's host[*].

And In Webauthn spec here

By default, the RP ID for a WebAuthn operation is set to the caller’s origin's effective domain. This default MAY be overridden by the caller, as long as the caller-specified RP ID value is a registrable domain suffix of or is equal to the caller’s origin's effective domain.

This limit we discusses here seems made a self-contradiction or a undefined behavior in the spec. I mean, the spec allows to defaultly set a RPID to a ip address, at the same time, we could not use it to CreateCredential.

Thanks for your time.

Browser implementation

• The Firefox and Edge will work with Webauthn. both RPID is null or RPID is a ipv4 string.
  • The Chrome will not work in such situation. Neither RPID is null nor ipv4 string. But when alias it using host file. It will work. Which discusses here

Reproduce Steps

1.open a site using a ip address. say: https://10.250.129.18:8888

2. execute this javascript snippet:(could use webdevtools to do this)

   
   const publicKeyCredentialCreationOptions = {
   challenge: Uint8Array.from(
       "randomStringFromServer", c => c.charCodeAt(0)),
   rp: {
       name: "Duo Security",
   },
   user: {
       id: Uint8Array.from(
           "UZSL85T9AFC", c => c.charCodeAt(0)),
       name: "lee@webauthn.guide",
       displayName: "Lee",
   },
   pubKeyCredParams: [{alg: -7, type: "public-key"}],
   authenticatorSelection: {
       authenticatorAttachment: "cross-platform",
   },
   timeout: 60000,
   attestation: "indirect"
   };

const credential = await navigator.credentials.create({ publicKey: publicKeyCredentialCreationOptions });

3.Alias `10.250.129.18` using a domain name(using hosts file is fine), and access it using domain name defined.  For example:  alias `10.250.129.18` using `test18`.  And access it via : `https://test18:8888` 
4.reexecute step2

[emlun]

I think The Credential used in Webauthn is generated per-site. It will not involves the PKI architecture like CRL(Certification Revocation List) or other things that works with certificate.

Credential keys indeed do not involve any conventional PKI, except for attestation certificates. However, the phishing protection relies on validating the RP ID, which in turn relies on the cert for the RP's domain and thus the PKI for those certs.

[equalsJeffH]

Yes, we could relax the above-cited RP ID definition in the webauthn spec such that any valid host string is allowed, which would allow valid IPv4-addresses or valid IPv6-addresses.

However, there would be practical deployment issues such as users having to register credential(s) with each "named-by-ip-address" server rather than being able to have a credential that is honored in "all of a domain", e.g., honored in all subdomains of example.com.

It would be interesting to hear feedback from Firefox and Edge regarding whether they are aware of any in-production usage of webauthn with named-by-ip-address servers and whether they have received issues/bugs as a result. @jcjones @akshayku

If the working group is inclined to alter this in the spec, I'd do it like so (modulo any errors in the below):

By default, the RP ID for a WebAuthn operation is set to the caller’s origin's effective domain, except that host values matching opaque host, or empty host are disallowed. This means that host values matching domain, IPv4 address, or IPv6 address are allowed, and such a host value's serialization matches a valid host string ([URL] describes the relation of host and valid host string).

This default MAY be overridden by the caller, as long as both of the below statements are true:

• the caller’s origin's effective domain is a valid domain, and
• the caller-specified RP ID value is a registrable domain suffix of or is equal to the caller’s origin's effective domain.

[slayercat]

Thanks, to all of you.

However, there would be practical deployment issues such as users having to register credential(s) with each "named-by-ip-address" server rather than being able to have a credential that is honored in "all of a domain", e.g., honored in all subdomains of example.com.

In my practice, most company has not adopted unified 3A （Authentication, Authorization and Accounting). And the IT foundation of these company built on commercial off-the-shelf (COTS) productions. In such a situation. These products must take care of there self's Authentication.

(And the end user must take care of their password either.)

The Webauthn adoption of these COTS product will help to change this situation. And products will not accept must be accessed by domain (And they could not predict which domain).

Hope this will help.

Thanks for your time.

[slayercat]

Hi,

I’m happy that the WG has discussed this issue.

For those interested, I’ll provide a test result of Firefox 72.0.1 and Edge 18362 using Windows problem step recorder (PSR).

Besides, I do not think the difference between browser implementation is the key point.

I suggest the Webauthn shell works with IP address site because it’s common in real life. For example, a firewall / router / switch config page could use Webauthn for authentication, but they are not likely to have a domain name.

Notice that there’s some difficulty to correctly deploy an internal DNS sever like elundberg said (And some DNS service provider won’t respond to DNS queries that result in non-routable IP addresses.). And the more Webauthn require, the harder it is to become popular.

Besides, I think the spec could distinguish between domain RPID and the IP address RPID. in case of domain, we could have a credential that is honored in all subdomains (and a LDAP or AD server might be required to do so).

I sincerely hope that you will reconsider your decision.

Attachments: firefox_webauthn_PSR.zip edge_webauthn_PSR.zip test.html.txt

[nadalin]

@akshayku To report back on what Edge does

[jcjones]

On today's WebAuthn call, I made the argument that since IP addresses are frowned upon for PKI certificates, they should be frowned upon here. However, further investigation shows that the Secure Contexts spec doesn't outlaw use on IPs as I suspected.

I don't know that WebAuthn actually has any real need to be more strict than Secure Contexts, but I do feel that if we want to support IP addresses, in addition to language updates like @equalsJeffH suggests above, we should consider:

1) Adding Web Platform Tests using IP addresses, because I'm honestly surprised this works as-is in Firefox 2) Adding an implementation note to the security considerations that relying on Secure Contexts built upon enterprise PKIs should include the trust model of the enterprise PKI in their planning of whether a WebAuthn host can be considered trustworthy. Whether it's an IP-address certificate, or self-signed certs, all Secure Contexts can say is that a host is "potentially trustworthy" for a reason.

[jcjones]

From the 19 Feb 2020 call -

This issue will be resolved by: 1) @jcjones adding a web platform test showing that IP addresses are prohibited 2) @jcjones filing a bug against Firefox to disable use of WebAuthn for IP addresses, to comply with the spec

[equalsJeffH]

on 2020-02-19 call:

• @akshay says he might be supportive of trying "ip address" out behind a flag, but doesnt think useful for users, so would not do it
• we decided that we are going to close this issue, the spec is already nominally clear that ip addresses are not permitted in RP IDs
• @jcjones volunteers to write WPTs to test out this restriction.

[jcjones]

Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1616675

[jcjones]

It doesn't appear that Web Platform tests can meaningfully test WebAuthn from an IP address. Blast, foiled again.

[equalsJeffH]

closing per https://github.com/w3c/webauthn/issues/1358#issuecomment-588453167

[jbhanks]

on 2020-02-19 call:

* @akshay says he might be supportive of trying "ip address" out behind a flag, but doesnt think useful for users, so would not do it

* we decided that we are going to close this issue, the spec is already nominally clear that ip addresses are not permitted in RP IDs

* @jcjones volunteers to write WPTs to test out this restriction.

Very irritating decision, of course it would useful. For example, I am building an CMS/admin panel webapp that I will use to manage multiple websites. As the sole user the webapp, there is no reason for me to buy a domain, and I would rather not advertise its existence by giving it a name.

I don't see why people and organizations wouldn't want to use webauthn to protect their private assets.

[emlun]

On most operating systems you can work around this by adding an entry to the local hosts file, for example /etc/hosts on Unix-like systems. Then you can use that like any other domain on those clients with that hosts file entry, you don't need to buy a publicly-available domain.

Note that you will also need an HTTPS certificate for the server; you can use OpenSSL to create a self-signed certificate or a private CA to issue the certificate from (see for example OpenSSL Cookbook). For example:

$ openssl ecparam -genkey -name secp256r1 | openssl ec -out ./server.key
$ openssl req -new -x509 -days 365 -key ./server.key -out ./server.crt -subj "/O=My Organisation/OU=Admin panel/CN=admin-panel.internal" -addext "subjectAltName = DNS:admin-panel.internal"

[slayercat]

Now, not only due to the issues pointed out by this issue, but also because Chrome has stopped supporting self-signed certificates for Webauthn, Webauthn has become even more challenging to adopt in this scenario.

I understand the commitment to security that the specification standards advocate for, but the applicability for enterprise users in this particular context is indeed difficult to meet with the existing standards.

Of course, this is just a complaint, and the specific implementation still depends on your decisions.

[timcappalli]

@slayercat that link from Chrome specifically says:

Chrome will stop allowing WebAuthn requests on websites with TLS certificate errors

If the self-signed certificate is trusted by the browser (e.g. installed), you will not get a certificate error.

[slayercat]

@slayercat that link from Chrome specifically says:

Chrome will stop allowing WebAuthn requests on websites with TLS certificate errors

If the self-signed certificate is trusted by the browser (e.g. installed), you will not get a certificate error.

Thank you for your response. Yes, you are absolutely right. Whether it's deploying domains, modifying hosts files, issuing certificates, or trusting certificates for internal sites, regardless of whether they are self-signed certificates or not, for large IT companies, these processes are well-established, especially with the assistance of Microsoft Windows domain controllers.

However, on the other hand, for small and medium-sized enterprises, deploying domains or modifying hosts for each endpoint, issuing certificates, and trusting them can pose certain challenges. Each business product that wants to use WebAuthn would require related processes, and not all out-of-the-box devices, such as firewalls, have the capability to modify certificates.

The internet doesn't have as many complexities in this regard. But governing the internal network of an enterprise will present some challenges for the adoption of WebAuthn in this scenario.

I believe there are many who can relate to this, and we hope that WebAuthn continues to improve until the day when someone starts considering enterprise users on intranets, especially those of small and medium-sized enterprises.