Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
Peter Saint-Andre <stpeter@stpeter.im> Sat, 30 October 2010 05:04 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 E5E043A681D; Fri, 29 Oct 2010 22:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.57
X-Spam-Level:
X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 4tHjQZkKBQv1; Fri, 29 Oct 2010 22:04:00 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AEAC63A67A5; Fri, 29 Oct 2010 22:04:00 -0700 (PDT)
Received: from squire.local (dsl-251-219.dynamic-dsl.frii.net [216.17.251.219]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 63C0840BB9; Fri, 29 Oct 2010 23:14:12 -0600 (MDT)
Message-ID: <4CCBA7A9.7030506@stpeter.im>
Date: Fri, 29 Oct 2010 23:05:45 -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>
In-Reply-To: <4CC9503D.2000809@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="------------ms030901010109050600060007"
X-Mailman-Approved-At: Mon, 01 Nov 2010 08:18:58 -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: Sat, 30 Oct 2010 05:04:03 -0000
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? > - 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. > - 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. > - 13.4: "for the ensuring" -> "for ensuring" (or: to ensure). Fixed. > - 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. > - 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. > - 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? > - 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. > - 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. > - 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. > - 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. > - 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. > - 13.7.1.2.2: enabling entity -> enabling entities. > - 13.7.1.4: "conjuction" misspelled. Typos fixed. Maybe it would be helpful for me to finally run this document through a spell-checker... > - 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... > - 13.7.2.2.1: "MUST either validate" - incomplete sentence (and > actually, at a sensitive point in the text). Here "either" is extraneous because it is an artifact of an earlier version of the spec. Much earlier: http://tools.ietf.org/id/draft-saintandre-rfc3920bis-05.txt > - 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. > - 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 > - 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. > 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: I suggest to add (here or elsewhere): "All password-based > mechanisms are susceptible to password guessing attacks, and therefore > the authenticator MUST implement common rate-limiting mitigations." I think the right place is Section 13.9.4 ("Use of SASL"). Added. > - 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? > - 13.8: the note kind of implies that PLAIN is preferable to DIGEST-MD5, > which is clearly not the case. Clearly not, and that was unintentional. I think it is better to limit this note strictly to the interoperability issue here (see also the next section)... Interoperability Note: The use of the SCRAM-SHA-1 or SASL-SCRAM- SHA-1-PLUS mechanism replaces the SASL DIGEST-MD5 mechanism as XMPP's mandatory-to-implement password-based method for authentication only, and the use of TLS plus either of those SCRAM variants replaces TLS plus DIGEST-MD5. For backward-compatibility with existing deployed infrastructure, implementations are encouraged to continue supporting the DIGEST-MD5 mechanism as specified in [DIGEST-MD5], however there are known interoperability issues with DIGEST-MD5 that make it impractical in the long term. > - 13.9.4: why is SASL-PLAIN singled out here? Other mechanisms are > susceptible to off-line password guessing when used without TLS > confidentiality, which is not a trivial attack but still a significant > risk. You're right. I propose that we split up the text a bit here (e.g., the text about PLAIN in fact talks mostly about TLS verification)... So, add the following modified paragraph to Section 13.9.4 ("Use of SASL"): The use of the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS mechanisms is strongly preferred over the SASL PLAIN mechanism because of their superior security properties, and TLS plus SASL PLAIN is intended to be a fallback only for implementations that do not yet support SCRAM. Implementations MUST NOT use the SASL PLAIN without confidentiality and integrity protection via TLS. For additional security considerations related to these SASL mechanisms, see [SCRAM] and [PLAIN]. Then add the following modified paragraph to Section 13.9.5 ("Use of TLS"): To prevent man-in-the-middle attacks, the TLS client (which might be an XMPP client or an XMPP server) MUST verify the certificate of the TLS server and MUST check its understanding of the server hostname against the server's identity as presented in the TLS Certificate message (for details, see [TLS-CERTS]. > - 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. > - 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? > - 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. > - 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. > By the way, please expand the > acronym MTI somewhere. It's not used as an acronym, just as a string in some feature names. > - 15: and hey, there's no feature defined for TLS+SCRAM+? Isn't this the > one we want/expect to be deployed? There is a feature for security-mti-auth-scram, which includes both variants. I propose that we change the feature definition to: Feature: security-mti-auth-scram Description: Support the SASL Salted Challenge Response mechanism for authentication only or confidentiality and authentication (this implies support for both the SCRAM-SHA-1 and SCRAM-SHA-1- PLUS variants). Section: Section 13.8 Roles: Client MUST, Server MUST. > - 15: stanza-* features - if you have an XML schema, can't you just say > that conformance to the schema is REQUIRED and eliminate all this stuff? > Given that these are MUSTs, not SHOULDs, a formal specification is so > much easier to validate. This does *not* contradict the fact that > runtime validation is optional. I suppose, but it seems useful for interoperability testing purposes (which we do plan to pursue more rigorously) to define the more specific features specified throughout the spec with regard to stanza syntax and semantics. > - 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? Thanks again for your review. 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