Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 02 November 2010 11:10 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0AB73A68B1; Tue, 2 Nov 2010 04:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.532
X-Spam-Level:
X-Spam-Status: No, score=-101.532 tagged_above=-999 required=5 tests=[AWL=1.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrAFSerJIcxR; Tue, 2 Nov 2010 04:10:43 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 06BDA3A687A; Tue, 2 Nov 2010 04:10:41 -0700 (PDT)
Received: by wwe15 with SMTP id 15so6810902wwe.13 for <multiple recipients>; Tue, 02 Nov 2010 04:10:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=3wjdbdMO8EglqtvMsIRyikEDWcg+DdPY/6Y59+IQfm8=; b=YVZZD6Ed7svyBwTq35WAuPPppLK5aBDdB4UEQuu1kiig6tHwAwtdq9cqQeSRo1upr0 +dYOhnm4ItfuV4oH2MODF1Ao1e5LD4eqNZ3qyxcql3I4HD08+5HtVw8tizSYb3g2RVqt Ixm2mwLF5HCl1pbMAXiklV4PHD+fJCkqAHLBo=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=VWLcuzT3udQRBGoyR/UCQSAMzZ0/E3XAc0ZHJpAeHnDYpwQBexAOZcxRDPK2Vsj4Gc adUyCB8AxydJDu563o8R9cqXRn2YcGC0KTPgkojyd8GqPLcNhBBmmY43NTHhId1Xr52s qUcgK8gHsckFG7umlUri8HJ4jFXCE0TekSwHU=
Received: by 10.227.155.15 with SMTP id q15mr2519906wbw.141.1288696245134; Tue, 02 Nov 2010 04:10:45 -0700 (PDT)
Received: from [10.0.0.2] (bzq-79-181-26-165.red.bezeqint.net [79.181.26.165]) by mx.google.com with ESMTPS id a17sm6197568wbe.6.2010.11.02.04.10.42 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 04:10:43 -0700 (PDT)
Message-ID: <4CCFF1B0.4080007@gmail.com>
Date: Tue, 02 Nov 2010 13:10:40 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF20E7.30401@stpeter.im>
In-Reply-To: <4CCF20E7.30401@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Nov 2010 11:10:50 -0000

Hi Peter,

please see my comments in-line. I have removed already-closed issues.

Thanks,
     Yaron

On 11/01/2010 10:19 PM, Peter Saint-Andre wrote:
> On 11/1/10 3:25 AM, Yaron Sheffer wrote:
> > Hi Peter,
> >
> > Responding to the last part. Thanks for a constructive discussion.
>
>
> >>> - 13.7.1.1: and most important, is the "relying party" (e.g. the 
> client)
> >>> required to check all these rules and fail validation if any of 
> them is
> >>> not met?
> >>
> >> As I understand it from my conversations with Sean when we were adding
> >> this text, these rules are not set in stone within RFC 5280 and
> >> therefore need to be specified by any technology that reuses PKIX. Our
> >> intent was that CAs would conform to these rules, not necessarily that
> >> replying parties would necessarily fail on validation if the rules were
> >> violated. Here again I'll check with Sean.
> >>
> > Please do. In particular, trusting a non-CA to sign certificates seems
> > to contradict the spirit of PKIX policies.
>
> Yes, I now see that you are right (see previous warning about lack of
> coherence). I've provisionally updated the relevant paragraph of Section
> 13.7.2 as follows, breaking it into bullets for easier readability:
>
> ###
>
>     For both server certificates and client certificates, the validating
>     entity MUST do the following:
>
>     1.  Attempt to verify the integrity of the certificate.
>
>     2.  Attempt to verify that the certificate has been properly signed
>         by the issuing Certificate Authority.
>
>     3.  Attempt to validate the full certification path.
>
>     4.  Check the rules for end entity public key certificates and
>         certification authority certificates specified under
>         Section 13.7.1.1 for the general case and under either
>         Section 13.7.1.2 or Section 13.7.1.2 for XMPP server or client
>         certificates, respectively.
>
>     5.  Check certificate revocation messages.
>
>     If any of those validation attempts fail, either entity MAY choose to
>     unilaterally terminate the session.
>
> ###
>
This is all fine, other than the last sentence. There's little security 
value (or performance value, for that matter) in "MUST check, but only 
MAY choose to fail". With possible minor exceptions, these rules are all 
security-critical.

>
> >>> - 13.7.2: a silly question, but anyway: where do you say that the
> >>> client's cert is correlated with the client's JID, as it appears 
> in the
> >>>   From line (when setting up the original stream and/or when 
> setting the
> >>> stream anew after TLS negotiation)?
> >>
> >> Few clients include the 'from' address on the stream header and we're
> >> not actively working to make sure they do, because what really matters
> >> is that the client authenticates using the credentials of a registered
> >> account.
> >>
> > Ahem, the client's 'from' attribute is a SHOULD (4.6.1).
>
> It is, but that's in an effort to move people in the right direction.
> This matter was very unclear in RFC 3920.
>
> >>> And vice versa, for the server cert
> >>> and the client's To header.
> >>
> >> For s2s communication, in essence (and using the terms of [TLS-CERTS])
> >> the initiating entity sets its reference identifier to the 'to' address
> >> it communicates in the initial stream header, and the receiving entity
> >> sets its reference identifier to the 'from' address communicated by the
> >> initiating entity in the initial stream header (i.e., the 'from' 
> address
> >> is the identity that the initiating entity is trying to assert). Per
> >> recent list discussion Jeff Hodges and I have added a note about 
> that to
> >> our working copy of draft-saintandre-tls-server-id-check.
> >>
> >> However, I agree that it would be helpful to mention this in 
> 3920bis, so
> >> I propose that we add some text to Sections 13.7.2.1 ("Server
> >> Certificates") and 13.7.2.2 ("Client Certificates")...
> >>
> >> ###
> >>
> >> 13.7.2.1.  Server Certificates
> >>
> >>      For server certificates, the rules and guidelines defined in
> >>      [TLS-CERTS] apply, with the proviso that the XmppAddr identifier
> >>      specified under Section 13.7.1.4 is allowed as a reference
> >>      identifier.
> >>
> >>      The identities to be checked are set as follows:
> >>
> >>      o  The initiating entity sets its reference identifier to the 'to'
> >>         address it communicates in the initial stream header; i.e., 
> this
> >>         is the identity it expects the receiving entity to provide in a
> >>         PKIX certificate.
> >>
> >>      o  The receiving entity sets its reference identifier to the 
> 'from'
> >>         address communicated by the initiating entity in the initial
> >>         stream header; i.e., this is the identity that the initiating
> >>         entity is trying to assert.
> >>
> >> 13.7.2.2.  Client Certificates
> >>
> >>      When an XMPP server validates a certificate presented by a client,
> >>      there are three possible cases, as discussed in the following
> >>      sections.
> >>
> >>      The identities to be checked are set as follows:
> >>
> >>      o  The client sets its reference identifier to the 'to' address it
> >>         communicates in the initial stream header; i.e., this is the
> >>         identity it expects the server to provide in a PKIX 
> certificate.
> >>
> >>      o  The server sets its reference identifier to the 'from' address
> >>         communicated by the initiating entity in the initial stream
> >>         header; i.e., this is the identity that the client is trying to
> >>         assert.
> >>
> >> ###
>
> Does that text seem helpful?
>
Yes, definitely.

> >>> - 13.8: "For both confidentiality and authentication with passwords" -
> >>> here you don't specify a TLS ciphersuite.
> >>
> >> RFC 5246 has TLS_RSA_WITH_AES_128_CBC_SHA as the mandatory-to-implement
> >> ciphersuite, so that seems appropriate here. Would you recommend
> >> something stronger, for example TLS_RSA_WITH_AES_256_CBC_SHA?
> >>
> > AES-128 is just fine. Actually there are major issues with AES-256. But
> > I think this document should specify a ciphersuite, rather than rely on
> > RFC 5246 for that. After all you are essentially profiling TLS.
>
> Done.
>
> There was talk in the XMPP WG of moving all MTI technologies out of the
> core spec so that they could be updated more frequently. Maybe we'll do
> that in the next revision cycle (which will result in a much smaller 
> diff).
>
I also think it's a good idea.