IETF Logo Mail Archive

Re: [dispatch] draft-johansson-dispatch-dane-sip-01 - certificate validation

Michael Procter <michael@voip.co.uk> Sun, 26 January 2014 12:34 UTC

Return-Path: <michael@voip.co.uk>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43D0A1A0139 for <dispatch@ietfa.amsl.com>; Sun, 26 Jan 2014 04:34:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.579
X-Spam-Level:
X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCmrNLFgCT4J for <dispatch@ietfa.amsl.com>; Sun, 26 Jan 2014 04:34:16 -0800 (PST)
Received: from na3sys009aog134.obsmtp.com (na3sys009aog134.obsmtp.com [74.125.149.83]) by ietfa.amsl.com (Postfix) with SMTP id 62B821A0120 for <dispatch@ietf.org>; Sun, 26 Jan 2014 04:34:16 -0800 (PST)
Received: from mail-wg0-f49.google.com ([74.125.82.49]) (using TLSv1) by na3sys009aob134.postini.com ([74.125.148.12]) with SMTP ID DSNKUuUAxsFAFfF4ly9Urm/vhDGtEg1SBaPc@postini.com; Sun, 26 Jan 2014 04:34:15 PST
Received: by mail-wg0-f49.google.com with SMTP id a1so4667281wgh.16 for <dispatch@ietf.org>; Sun, 26 Jan 2014 04:34:13 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=mCo5pLSWPKlMciCi9wqGsb5TQTHe6s5dG09kBYs979I=; b=ay/yOPhpG4TGuWu4SKCevNd8i46V8DG/r04PJLWcXiCcr9kh9o0VgSNmoLLxuw27e9 3pAC2vonoFPCOUq7TjO/ARhmdbpDKYR2VqBkqBrT0EjeheYIKR5xgGdL3hYRrU/DOLwn UHvbru8kk5DQD0eHiAz001rsYg5iKqqXgEpkd+L2PyQAUBK+R+k9RPTyyxSCFMT2uSF5 XUulZ33X6DogY0N+R5Q6s0CDdSq5BO8VXwaiAcgNs7alJ1JqBPjakIN/dHtk2mPz9h4u OzwCcWIysOqUS689AaRwJNsyjeATIzjvm7V+KPSDMjs5VTJxWjMFKB5glzhRpzk+1RNC AXzQ==
X-Gm-Message-State: ALoCoQkoiR6bRomBo5x+Ccj4pS591LlWbjx/2Wc9tYlasdIpWF3xpvCBEjTGgOwhrJdQDfgeLuZiPzEyU1R9QOTzX/mr3zOXnAgg0uXxjaYRMiWzXn6rck94OJzGO3F+PqFXMcDYs6BufY0fmLwIbyqlvSvLm+5Q0Q==
X-Received: by 10.180.108.130 with SMTP id hk2mr8968387wib.16.1390739653305; Sun, 26 Jan 2014 04:34:13 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.108.130 with SMTP id hk2mr8968380wib.16.1390739653082; Sun, 26 Jan 2014 04:34:13 -0800 (PST)
Received: by 10.194.42.195 with HTTP; Sun, 26 Jan 2014 04:34:13 -0800 (PST)
In-Reply-To: <03326AC3-4A56-49C6-B68F-3A3F137A78B8@edvina.net>
References: <CAPms+wQC2KB4ymHxQfuf8HS9nsDPh33fAOA9BPHCT0qfxV7OhA@mail.gmail.com> <03326AC3-4A56-49C6-B68F-3A3F137A78B8@edvina.net>
Date: Sun, 26 Jan 2014 12:34:13 +0000
Message-ID: <CAPms+wQT5U_DdHGxc=C8oaBNfJkk-KfOHZ78=gRWirdpDRfyFA@mail.gmail.com>
From: Michael Procter <michael@voip.co.uk>
To: "Olle E. Johansson" <oej@edvina.net>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: IETF Dispatch <dispatch@ietf.org>
Subject: Re: [dispatch] draft-johansson-dispatch-dane-sip-01 - certificate validation
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Jan 2014 12:34:19 -0000

Rather than saying in section 8 that clients validate the certificate
"using RFC 5922 rules", it might be clearer to explicitly call out
which part of the RFC should be used.  Maybe something like:

   The client MUST
   determine the SIP domain identities in the server certificate using
   the procedure in Section 7.1 of RFC 5922.

   o  If there were no identities found in the server certificate, the
      server is not authenticated.

   o  If the domain extracted from the AUS matches any SIP domain
      identity obtained from the certificate when compared as described
      in Section 7.2 of RFC 5922, the server is authenticated for the domain.

(Text borrowed from RFC 5922 section 7.3 with light edits)

But that doesn't seem to agree with this statement:

On 26 January 2014 07:53, Olle E. Johansson <oej@edvina.net> wrote:
> A client
> compliant with this specification will look for the host name (SRV host)
> in the CN and a client following the SIP domain cert RFC will ignore
> the CN and only look into the SAN fields

RFC 5922 doesn't let you do that.  Section 7.1 bullet 2 states that
you may only examine the CN if there are no subjectAltNames present
(not just no matching subjectAltNames).  It also only permits you to
use a DNS name when there are no SIP URIs listed.

You might be better off not using any of the RFC 5922 rules at all!
Removing the RFC5922 references from the first paragraph of section 8
makes it look like:

   When using DANE-based validation the client validates the SRV
   hostname with the certificate.  A DANE-capable
   SIP implementation looks for the SRV hostname in the list of
   SubjAltName DNSName extension fields.  Only if there are no
   SubjAltName extension fields may the client look in the CN of the
   X.509 certificate.

That approach (not mentioning RFC 5922) seems to make sense and still
defends against the attack outlined in draft-ietf-dane-srv-03 section
10.3.

Best regards,

Michael

v2.23.0 | Report a Bug | By Email