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

Yaron Sheffer <> Mon, 01 November 2010 09:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ACC6D3A679C; Mon, 1 Nov 2010 02:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -98.333
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DRrGi1RDJ7Vr; Mon, 1 Nov 2010 02:26:04 -0700 (PDT)
Received: from ( []) by (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;; 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;; 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 with SMTP id v5mr2656549wbw.189.1288603562405; Mon, 01 Nov 2010 02:26:02 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id a17sm4998655wbe.0.2010. (version=SSLv3 cipher=RC4-MD5); Mon, 01 Nov 2010 02:26:00 -0700 (PDT)
Message-ID: <>
Date: Mon, 01 Nov 2010 11:25:57 +0200
From: Yaron Sheffer <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Saint-Andre <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc:,, XMPP <>,
Subject: Re: [secdir] SecDir review of draft-ietf-xmpp-3920bis-17
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


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

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

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

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

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

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

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

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

>> - "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 ("Server
> Certificates") and ("Client Certificates")...
> ###
>  Server Certificates
>     For server certificates, the rules and guidelines defined in
>     [TLS-CERTS] apply, with the proviso that the XmppAddr identifier
>     specified under Section 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.
>  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.

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