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
>