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

Peter Saint-Andre <stpeter@stpeter.im> Mon, 01 November 2010 20:19 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 333773A69A7; Mon, 1 Nov 2010 13:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.466
X-Spam-Level:
X-Spam-Status: No, score=-100.466 tagged_above=-999 required=5 tests=[AWL=0.467, BAYES_00=-2.599, 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 vgnYGvHubGWG; Mon, 1 Nov 2010 13:19:56 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7DB6A3A6A17; Mon, 1 Nov 2010 13:19:56 -0700 (PDT)
Received: from squire.local (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BF32440D1E; Mon, 1 Nov 2010 14:28:24 -0600 (MDT)
Message-ID: <4CCF20E7.30401@stpeter.im>
Date: Mon, 01 Nov 2010 14:19:51 -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>
In-Reply-To: <4CCE87A5.80701@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="------------ms050702010806010901070107"
X-Mailman-Approved-At: Mon, 01 Nov 2010 14:21:43 -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: Mon, 01 Nov 2010 20:19:59 -0000

On 11/1/10 3:25 AM, Yaron Sheffer wrote:
> Hi Peter,
> 
> Responding to the last part. Thanks for a constructive discussion.

I hope it's productive -- I was getting pretty tired on Friday night
when I wrote the last bits of Part 3, so I'm not sure I was fully
coherent. :)

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

Agreed. Adjusted text follows:

###

   2.  How a server processes stanzas sent to the bare JID
       <localpart@domainpart> has implications for directory harvesting,
       because if the server responds differently depending on whether
       there there is an account registered for that bare JID.

   3.  How a server processes stanzas sent to a full JID has
       implications for presence leaks, because an attacker could send
       requests to multiple full JIDs and receive different replies
       depending on whether the user has a device currently online at
       that full JID.  The use of randomized resourceparts (whether
       generated by the client or the server) significantly helps to
       mitigate this attack, so it is of somewhat lesser concern than
       the directory harvesting attack.

###

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

There's a lot of text to read, so that's fully understandable!

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

I'd prefer to add the text in only one place, and the best place seems
to be a new sentence at the end of the only paragraph in Section 10.5,
as follows:

###

10.5.  Local Domain

   If the hostname of the domainpart of the JID contained in the 'to'
   attribute matches one of the configured hostnames of the server, the
   server MUST first determine if the hostname is serviced by the server
   itself or by a specialized local service.  If the latter, the server
   MUST route the stanza to that service.  If the former, the server
   MUST proceed as follows.  However, the server MUST NOT route or
   "forward" the stanza to another domain because it is the server's
   responsibility to process all stanzas for which the domainpart of the
   'to' address matches one of the configured hostnames of the server
   (among other things, this helps to prevent looping).

###

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

Well, the "X" in XMPP stands for "extensible". We could always define an
XMPP extension for that feature. In fact, I think we could do it already
with XEP-0273 ("Stanza Interception and Filtering Technology"):

http://xmpp.org/extensions/xep-0273.html

But it's not part of the core.

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

Section 13.1 has this paragraph:

   This specification covers only the security of a direct XML stream
   between two servers or between a client and a server (cases #1 and
   #2), where each stream can be considered a single "hop" along a
   communication path.  The goal of security for a multi-hop path (cases
   #3 and #4), although very desirable, is out of scope for this
   specification.

The note in Section 13.4 expands on that, specifically with regard to
confidentiality and integrity (the topic of 13.4). That's the best place
I could find for it, but suggestions are welcome.

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

OK, done.

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

That does seem better. In my working copy that paragraph now reads:

###

   [STRONGSEC] defines "strong security" and its importance to
   communication over the Internet.  For the purpose of XMPP
   communication over client-to-server and server-to-server streams, the
   term "strong security" refers to the use of security technologies
   that provide both mutual authentication and integrity checking (e.g.,
   a combination of TLS encryption and SASL authentication using
   appropriate SASL mechanisms).  An implementation SHOULD make it
   possible for an end user or service administrator to provision a
   deployment with specific trust anchors for the certificate presented
   by a connecting entity (either client or server); when an application
   is thus provisioned, it MUST NOT use a generic PKI trust store to
   authenticate the connecting entity.  More detailed rules and
   guidelines regarding certificate validation are provided in the next
   section.

###

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

OK. I'd prefer not to perform major terminological surgery at this point...

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

Done.

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

I'll make sure to check with him about this before IESG review.

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

Agreed. I've removed that bullet.

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

###

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

Sentence removed.

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

Done.

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

In my working copy I now have:

   2.  Periodically query the Online Certificate Status Protocol [OCSP]
       responder listed in the Authority Information Access (AIA)
       extension of the certificate presented by the other party and any
       certificates on which that certificate depends (such as a root or
       intermediate certificate for a certification authority), and
       close the stream if any such certificate has been revoked, with a
       stream error of <reset/> (Section 4.8.3.16).  It is RECOMMENDED
       to query the OSCP responder 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.

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

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

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

OK.

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

True. I've removed those features.

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

I'll reply about this one separately, given the response from Florian
Zeitz on the XMPP WG list.

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

I've added the acronym on first use (Section 5.4.3).

>>> - 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. I'll add features for those and also think further about the
stream-level 'from' for client-to-server streams.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/