[webauthn] Could not use Webauthn `PublicKeyCredential.create` when the RP ID is a Host string(ip). (#1358)

slayercat has just created a new issue for https://github.com/w3c/webauthn:

== Could not use Webauthn  `PublicKeyCredential.create`  when the RP ID is a Host string(ip). ==
# 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](https://html.spec.whatwg.org/multipage/origin.html#concept-origin-effective-domain):
> 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](https://w3c.github.io/webauthn/#relying-party)
> 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 at least a undefined behavior in the spec. I mean, the spec allows to defaultly set a `RPID` to a ip address when 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](https://bugs.chromium.org/p/chromium/issues/detail?id=1039981)

# 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


Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1358 using your GitHub account

Received on Thursday, 9 January 2020 02:57:47 UTC