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/
- [secdir] SecDir review of draft-ietf-xmpp-3920bis… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Florian Zeitz
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Dave Cridland
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Jeffrey Hutzelman
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Kurt Zeilenga
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Yaron Sheffer
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] SecDir review of draft-ietf-xmpp-392… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Ben Campbell
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Matthew Wild
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Philipp Hancke
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint Andre
- Re: [secdir] [xmpp] SecDir review of draft-ietf-x… Peter Saint-Andre