[rtcweb] Comments on draft-ietf-rtcweb-security-arch-06

["Peck, Michael A" <[e-mail]>]

Section 5.6 defines a lightweight PKI of sorts, in that a third-party IdP asserts that an identity is associated with a public key fingerprint.

There are a couple of PKI things that seem to be missing.  I'm not sure that I know enough of the WebRTC context to judge if these pose potential problems or not, but they seem worth pointing out.

Revocation:
>From my reading of "API Requirement" under Section 5.5, there are valid use cases in which the same key pair will be used for multiple DTLS sessions, rather than a new key pair always generated for each DTLS session.  Should this document impose a requirement that there be a way to invalidate/revoke the IdP's assertion of the binding between the identity and public key fingerprint in case the private key is compromised, or at least contain a security consideration discussion of the threat?

Are there expected to be future documents profiling use of BrowserID/Persona, OAuth2, etc.?  That would seem to be the place to go into detail about how this should be handled since the specifics would vary.  For instance, from a quick skim of Persona, it looks like it attempts to mitigate this threat by requiring certificates to expire in 24 hours or less?  With OAuth2 this threat could be mitigated with a capability for the Authenticating Party to ask the Identity Provider to nullify the assertion.

Proof of Possession:
PKI enrollment protocols typically prove possession of the private key by signing a certificate request (containing the requested identity & public key) using that private key.  I see no such requirement in the draft.  Instead the input to the IdP is "an opaque value to be attested to" (section 5.6.4.1).  There seems to be potential for a substitution attack where someone else takes the fingerprint and gets an identity assertion for it, then can cause confusion over who the endpoints are.  Of course, that someone else doesn't have the private key so the real impact of this seems limited.  If fixing this is desirable, options may include one of:


a.       Ensure that the Authenticating Party puts its identity into the self-signed X.509 certificate and that the Relying Party verifies a match between the identity and the identity asserted by the IdP.


b.      Have the IdP ensure that the Authenticating Party's identity asserted in the self-signed certificate matches the identity that the IdP is asserting for the AP before the IdP provides an assertion.


c.       Rather than an "opaque value" in the AP's signing request to the IdP, put the requested identity in it (along with the public key), and sign the signing request using the private key corresponding to the requested public key.  The IdP would check the signature and make sure the requested identity matches what it plans to assert.