Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
Yaron Sheffer <yaronf.ietf@gmail.com> Mon, 01 November 2010 09:26 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 ACC6D3A679C; Mon, 1 Nov 2010 02:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.333
X-Spam-Level:
X-Spam-Status: No, score=-98.333 tagged_above=-999 required=5 tests=[BAYES_50=0.001, SARE_FWDLOOK=1.666, 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 DRrGi1RDJ7Vr; Mon, 1 Nov 2010 02:26:04 -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 45DC13A67E5; Mon, 1 Nov 2010 02:26:02 -0700 (PDT)
Received: by wwe15 with SMTP id 15so5399565wwe.13 for <multiple recipients>; Mon, 01 Nov 2010 02:26:03 -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=1KdGXG9AwuEmV9e/86glbQf3+Y5BRGSKfL884aN8yKo=; b=tlRjfeYga6AVCGFAJ4eaBcfjVsiRZ8mmZ1cRZbKVIUDq2US7FvcaHO58zBnx3v+c2B 6LIsSxSYam9ubEAFULUuycXKrJo5D+SKr2uMfdmRM86dk8twI1vUYxzMt1HCiP+lJsmC Osqr44LDWqVN9jc31+VjUsCbhL1er3hli4efk=
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=c+uoK531nyCT2tBehU3R31ZmMcnNRisVmP/NgXxDvAzUzlg67fIcPqAbZ4wLMURW/H OVeL61wjikCQxukXVHa9e6N2ZSMamUkhhYtL3SqtFjC6nqw0yOWqKPua9Lgxog8/4Jp4 dSRMJ9Y7sECtT95M/kAlbDe44EzHtvbLzEZ3Q=
Received: by 10.227.156.69 with SMTP id v5mr2656549wbw.189.1288603562405; Mon, 01 Nov 2010 02:26:02 -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 a17sm4998655wbe.0.2010.11.01.02.25.59 (version=SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 02:26:00 -0700 (PDT)
Message-ID: <4CCE87A5.80701@gmail.com>
Date: Mon, 01 Nov 2010 11:25:57 +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>
In-Reply-To: <4CCBA7A9.7030506@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: Mon, 01 Nov 2010 09:26:05 -0000
Hi Peter, Responding to the last part. Thanks for a constructive discussion. Yaron On 10/30/2010 07:05 AM, Peter Saint-Andre wrote: > This is Part 3 of my reply, from the start of Section 10 through the end > of Section 15. This completes my reply to Yaron's security review. > > On 10/28/10 4:28 AM, Yaron Sheffer wrote: > >> - 10.2: "try many different resources", I suppose it is typically fewer >> than 10 per JID, which does not make the attack uninteresting. > > In my experience, few entities connect from more than three or four > devices at a time, although that might increase in the future. The use > of randomized resourceparts helps to mitigate the risk here (because an > attacker can't simply guess if the victim is at the "home" or "work" > resource or whatever) -- perhaps it would be good to mention that? Yes, this is more convincing than the current justification. > >> - 10.4.2: if the protocol supports routing, shouldn't we mention that >> there are cases where the IQ stanza will be forwarded to another server, >> not the one mentioned in the "To" header? And what about loop prevention? > > Could you clarify what you mean by "forward"? We don't have multi-hop > routing in XMPP, just direct server-to-server connections, so it's not > as if the stanza would be forwarded through multiple servers in order to > reach the destination domain. > Sorry, I misread the text. - New comment: 10.5.1 and 10.5.2 read funny. Without the context they both sound like "the server MUST handle the stanza, or not." I suggest to append to both sections: "The server MUST NOT route the stanza to another server". >> - 10.5.3.3: this is a strange rule. Does it mean that if I'm using a >> desktop (/desktop) and a mobile (/mobile), and I'm connected to the >> desktop, I cannot have messages targeted at my mobile be deferred (and >> stored somewhere) until I connect from that device? > > That feature is not part of XMPP. > Pity. I can see several use cases: deliver photos into a large screen, deliver messages in specific non-ASCII scripts to devices that can actually display them... > >> - 13.4: the security note is confusing, because it is unclear whether it >> has any normative status. Otherwise, it is almost trivial: of course you >> can provide these guarantees by different means. > > This security note provides truth in advertising: we don't want to > misrepresent the extent to which the use of TLS can protect stanzas, > since they can be routed or delivered outside the context of their > original stream. It does not use any normative keywords because it is > purely informative. Yes, but nothing in the Note or the preceding paragraph mentions end-to-end security. > >> - 13.4: the cipher suites are not just "nun-null". They MUST provide >> both confidentiality and integrity. > > Is this more accurate? > > The use of Transport Layer Security (TLS) with appropriate > ciphersuites provides a reliable mechanism to ensure the > confidentiality and integrity of data exchanged between a client and > a server or between two servers. > Yes. >> - 13.6: the out-of-band trust chain rule may be practical for >> server-to-server connections, but probably not for large client >> deployments and when certificates are sometimes rolled over. > > Do you think that we need to modify the text of that paragraph? > Maybe this would be more realistic: It SHOULD be possible to provision an implementation (in both c-to-s and s-to-s situations) with specific trust anchors for the opposite entity. When an application is thus provisioned, it MUST NOT use a generic PKI trust store to authenticate the opposite entity. >> - 13.7: terminology: "mutual authentication" describes authentication >> with client certs, just as much as it describes the server presenting a >> cert and the client authenticating with SASL. This also applies to 5.4.3. > > In this context we have always used the term "authentication" only with > regard to SASL. The use of SASL EXTERNAL with PKIX certificates enables > an entity to point back to a certificate it provided during TLS > negotiation, but in general we don't refer to TLS as an authentication > mechanism. I don't see an easy way to disambiguate the term here, but > suggestions are welcome. > Let's keep it then. >> - 13.7.1.1: The word "issuer" is ambiguous. It usually refers to a >> person/organization, but here you use it to refer to the certificate >> itself. How about replacing the heading of the second list by: "the >> following rules apply to issuer certificates, used to sign XMPP >> end-entity certificates"? > > I think the first and second headings are best phrased like this: > > The following rules apply to end entity public key certificates that > are issued to XMPP servers or clients: > > [...] > > The following rules apply to certification authority (CA) > certificates that are used by issuers of XMPP end entity > certificates: > > That way we are using the appropriate terminology from RFC 5280. > Yes. >> - 13.7.1.1: it's strange to specify the hash algorithm, but not the >> signature algorithm (RSA-512 anyone?) > > Ah, I got that text from Sean Turner (IIRC, we copied it from a > never-released version of draft-hildebrand-dna), and I'm pretty sure > that by "the hash algorithm for the signature" he meant the > signatureAlgorithm field from RFC 5280, as in this text from > draft-hildebrand-dna: > > The issuer MUST support signing attribute certificate with the PKCS > #1 version 1.5 signature algorithm with SHA-256, as specified in > [RFC4055]. > > Clearly something has been lost in translation. I'll check with Sean on > this point. > I'll defer to Sean. >> - 13.7.1.1: what are "access certificates"? Neither 5280 nor Google can >> help... > > s/access/attribute/ > >> And how can an issuer cert NOT be marked with the CA bit? > > The idea was that attribute certificates would be issued by non-CA > entities, such as organizations that wish to delegate an XMPP service to > a hosting provider. However, I think we should delete any mention of > attribute certificates because that was something we envisioned for use > in "domain name assertions" but the feature is far from well defined. > See here for more details: > > http://tools.ietf.org/id/draft-hildebrand-dna-00.txt > > http://tools.ietf.org/id/draft-ietf-xmpp-dna-00.txt > > http://www.ietf.org/id/draft-barnes-xmpp-dna-00.txt > > Therefore I propose that we remove these lines (where "access" really > should be "attribute", not that it matters if we remove the bullet): > > 6. For issuers of access certificates, the issuer's certificate MUST > NOT contain a basicConstraints extension with the cA boolean set > to TRUE. > Wow! This is very forward looking. Yes, the whole package should probably be removed from 3290bis and moved into a future update to this document. >> - 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. >> - 13.7.2: "An implementation MUST enable a human user to view >> information about the certification path." I'm afraid this is security >> theater, because 99.5% of your target population cannot understand this >> information. > > Do you recommend changing SHOULD to MUST, removing this text entirely, > or something else? > > I suppose that 0.5% could always view the path via a dedicated piece of > security software... I suggest to remove the text altogether. People will have debug tools, log files etc., we shouldn't specify them. > >> - 13.7.2.2.1, subcase #3: please mention that some servers will simply >> fail validation at this point, subject to their policy. I.e., some might >> insist on correct client certs. > > True. Does the following proposed text capture that point? > > Sub-Case #3: The server finds no XmppAddrs, or finds at least one > XmppAddr but the domainpart of the represented JID does not match > one of the configured hostnames of the server; the server MUST NOT > use the represented JID (if any) as the validated identity of the > client but instead MUST validate the identity of the client using > other means. If the identity cannot be so validated, depending on > local service policy the server MAY abort the validation process > and terminate the TLS negotiation. > Yes. >> - 13.7.2.3: "periodically query OCSP" - is there any guidance about the >> period? Is a recommended period specified in the cert or communicated by >> the OCSP responder? > > I don't see a way to specify this in the certificate, but it seems > reasonable to query at or near the time communicated via the nextUpdate > field received in the OCSP response or, if the nextUpdate field is not > set, to query every 24 hours. This is for long-lived streams > Can you add such text then? >> - 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). >> 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. > > ### > > >> - 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. > >> - 13.11: all three examples of "service unavailable" can be ruled out on >> an operational server. Are there no better examples? > > I don't see how they can be ruled out. > OK, I see your point now. >> - 15: The sasl-whitespace "feature" is not really a feature, because >> you'd fail any interoperability if you send whitespace during the SASL >> phase, right? Similarly tls-whitespace. > > I take it you mean they are "negative features" and interoperability > testing should focus on positive features. But isn't appropriate to > ensure compliance with a MUST NOT statement in the spec? > No, what I meant was: you don't need to test them especially, because the connection will break immediately. Just like you don't check that "streem" is spelled right. >> - 15: if we insist on PLAIN, I would expect a security-mti-auth-order >> feature, where the proposals are ordered right (i.e. with PLAIN at the >> end). > > I think it's better to remove TLS plus SASL PLAIN from the list of > mandatory-to-implement technologies. > OK. >> - 15: why is confidentiality-only a MUST? Is it widely deployed? Is it >> required for backward compatibility? > > It was required in RFC 3920 (with a different ciphersuite) and in > practice it is used in the case of TLS plus Server Dialback for s2s > communications. > OK >> By the way, please expand the >> acronym MTI somewhere. > > It's not used as an acronym, just as a string in some feature names. > Still, you want people to understand what it means. > >> - 15: I would expect one or a few features around validation of >> identities at the various layers, since we're spending much of the >> document on this issue. "tls-certs" is an important piece of that, but >> not the whole thing. > > I agree with you that the layering topics are important here. Do you > have specific suggestions? > - Server side: correlate cert-asserted client ID with "from". - Server: correlate "from" on stream to identity as authenticated by SASL. - Server: rewrite "from" on stanza to authenticated ID. - Client side: correlate cert-asserted server ID with "from". - Client: correlate "from" on stream to identity as authenticated by TLS certs and/or SASL. > Thanks again for your review. > > Peter >
- [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