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

"Peck, Michael A" <mpeck@mitre.org> Tue, 26 March 2013 14:53 UTC

Return-Path: <mpeck@mitre.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2D73021F8A7E for <rtcweb@ietfa.amsl.com>; Tue, 26 Mar 2013 07:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 33uaRRDbXjhp for <rtcweb@ietfa.amsl.com>; Tue, 26 Mar 2013 07:53:24 -0700 (PDT)
Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org []) by ietfa.amsl.com (Postfix) with ESMTP id 5C7AC21F89E9 for <rtcweb@ietf.org>; Tue, 26 Mar 2013 07:53:23 -0700 (PDT)
Received: from smtpksrv1.mitre.org (localhost.localdomain []) by localhost (Postfix) with SMTP id EF6E91F0607 for <rtcweb@ietf.org>; Tue, 26 Mar 2013 10:53:22 -0400 (EDT)
Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org []) by smtpksrv1.mitre.org (Postfix) with ESMTP id C47B21F05A7 for <rtcweb@ietf.org>; Tue, 26 Mar 2013 10:53:22 -0400 (EDT)
Received: from IMCMBX04.MITRE.ORG ([]) by IMCCAS01.MITRE.ORG ([]) with mapi id 14.02.0342.003; Tue, 26 Mar 2013 10:52:59 -0400
From: "Peck, Michael A" <mpeck@mitre.org>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: Comments on draft-ietf-rtcweb-security-arch-06
Thread-Index: Ac4qMZmiR6FhwdAbSBuhEsh7BV5K/g==
Date: Tue, 26 Mar 2013 14:52:58 +0000
Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFDFC8E@IMCMBX04.MITRE.ORG>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321EFDFC8EIMCMBX04MITREOR_"
MIME-Version: 1.0
Subject: [rtcweb] Comments on draft-ietf-rtcweb-security-arch-06
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2013 14:53:26 -0000

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.

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