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

Peter Saint-Andre <stpeter@stpeter.im> Tue, 02 November 2010 12:06 UTC

Return-Path: <stpeter@stpeter.im>
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 2EC0C3A68D2; Tue, 2 Nov 2010 05:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level:
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 dFo0ZqShYzTi; Tue, 2 Nov 2010 05:06:46 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 551AE3A676A; Tue, 2 Nov 2010 05:06:46 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8177340D1E; Tue, 2 Nov 2010 06:15:24 -0600 (MDT)
Message-ID: <4CCFFED7.70208@stpeter.im>
Date: Tue, 02 Nov 2010 06:06:47 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF20E7.30401@stpeter.im> <4CCFF1B0.4080007@gmail.com>
In-Reply-To: <4CCFF1B0.4080007@gmail.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010104080901090304050100"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
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 12:06:48 -0000

On 11/2/10 5:10 AM, Yaron Sheffer wrote:
> 
> On 11/01/2010 10:19 PM, Peter Saint-Andre wrote:
>> On 11/1/10 3:25 AM, Yaron Sheffer wrote:
>>
>> >>> - 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.

Very true. At the least, SHOULD is much more appropriate, and even then
there are, as you say, only some possible minor exceptions (which I
think are RECOMMENDED in the profile, e.g., including the address of an
OCSP responder).

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

It seems a bit late in this revision cycle to do that, but as mentioned
I think we'll be working on 3920ter after a year or more of experience
with the spec you've reviewed (and after we've had a chance to fix up
the address format based on the results of the PRECIS WG), so I think
that would be a good time to help ensure the longevity of the specs by
moving the MTI security technologies into a "living document". I don't
know if any other application protocols have done that, but I'll ask the
Security ADs for advice about how we might proceed when the time comes.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/