From yaronf.ietf@gmail.com  Mon Nov  1 02:26:05 2010
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
>

From j.schoenwaelder@jacobs-university.de  Mon Nov  1 02:46:29 2010
Return-Path: <j.schoenwaelder@jacobs-university.de>
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 0ADD03A67B3; Mon,  1 Nov 2010 02:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.649
X-Spam-Level: 
X-Spam-Status: No, score=-99.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, 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 TWpAD-upXWCa; Mon,  1 Nov 2010 02:46:28 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 0C4BE3A67E5; Mon,  1 Nov 2010 02:46:28 -0700 (PDT)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8D1B6C004A; Mon,  1 Nov 2010 10:46:28 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id apx8iRs+fsEk; Mon,  1 Nov 2010 10:46:27 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6539FC0051; Mon,  1 Nov 2010 10:46:24 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 49EFE158C311; Mon,  1 Nov 2010 10:46:24 +0100 (CET)
Date: Mon, 1 Nov 2010 10:46:24 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: iesg@ietf.org, secdir@ietf.org, draft-cheshire-dnsext-nbp.all@tools.ietf.org
Message-ID: <20101101094624.GC29846@elstar.local>
Mail-Followup-To: iesg@ietf.org, secdir@ietf.org, draft-cheshire-dnsext-nbp.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [secdir] secdir review of draft-cheshire-dnsext-nbp-09.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
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:46:29 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The informational draft discusses requirements for a IP replacement of
AppleTalk's Name Binding Protocol (NBP). As an individual submission,
there is likely little value in commenting on the content. However, I
would have appreciated if the authors would have discussed security as
a requirement for an NBP replacement. I know that flexible discovery
is often pretty much as odd with security, having "security measures
appropriate to the environment in which" an NBP replacement "will be
used" could have been an explicit requirement.

Editorial nit:

On page 9, the DNS name "printer1.ietf.org" should probably changed to
"printer1.example.com".

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

From tony.li@tony.li  Thu Oct 28 15:08:46 2010
Return-Path: <tony.li@tony.li>
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 9CD7E3A659C for <secdir@core3.amsl.com>; Thu, 28 Oct 2010 15:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.987
X-Spam-Level: 
X-Spam-Status: No, score=-101.987 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, SARE_SUB_RAND_LETTRS4=0.799, 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 bSSC2P1y5ukR for <secdir@core3.amsl.com>; Thu, 28 Oct 2010 15:08:43 -0700 (PDT)
Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 7C4223A657C for <secdir@ietf.org>; Thu, 28 Oct 2010 15:08:43 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta04.westchester.pa.mail.comcast.net with comcast id QMJo1f0021GhbT854NAdC1; Thu, 28 Oct 2010 22:10:37 +0000
Received: from dhcp-171-70-15-200.cisco.com ([171.70.15.200]) by omta07.westchester.pa.mail.comcast.net with comcast id QNA71f00n4Jz5er3TNAEyx; Thu, 28 Oct 2010 22:10:30 +0000
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Tony Li <tony.li@tony.li>
In-Reply-To: <Pine.WNT.4.64.1010281239580.836@SMURPHY-LT.columbia.ads.sparta.com>
Date: Thu, 28 Oct 2010 15:10:06 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <CEC2EE1B-BEF7-45AD-973A-09F9C016DADD@tony.li>
References: <Pine.WNT.4.64.1010281239580.836@SMURPHY-LT.columbia.ads.sparta.com>
To: Sandra Murphy <Sandra.Murphy@sparta.com>
X-Mailer: Apple Mail (2.1081)
X-Mailman-Approved-At: Mon, 01 Nov 2010 08:18:58 -0700
Cc: secdir@ietf.org
Subject: Re: [secdir] comments on draft-irtf-rrg-recommendation-14
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: Thu, 28 Oct 2010 22:08:46 -0000

Hi Sandy,

Thank you very much for your comments.  We will be acting on them =
shortly.

For the sake of optimizing your (secdir) future expenditure of time and =
energy, I'd strongly suggest that you take a look at the LISP and ILNP =
drafts.

I know that ILNP is under (nearly continuous) evolution, and ILNP will =
be coming out as an experimental RFC first, and subject to future =
evolution.

Thanks again,
Tony


On Oct 28, 2010, at 10:27 AM, Sandra Murphy wrote:

>=20
> I have reviewed this document as part of the security directorate's =
ongoing effort to review all IETF documents being processed by the IESG. =
These comments were written primarily for the benefit of the security =
area directors.  Document editors and WG chairs should treat these =
comments just like any other last call comments.
>=20
> I unfortunately was off-net for a few days and got to this assignment =
rather late.  The document is long and covers a broad swath of material =
and I was not able to cover it deeply.
>=20
> This document is a product of the rrg IRTF working group.  It =
summarizes 15 different proposals for a new routing and addressing =
architecture for the Internet, with short summaries, critiques and =
rebuttals for each, and gives a final recommendation to the IETF for =
future direction.
>=20
> With the breadth of scope of the document, there is no way for me to =
review each proposal's documents for security considerations.
>=20
> The security considerations of *this* document itself is quite terse:
>=20
> 20. Security Considerations
>=20
>   All solutions are required to provide security that is at least as
>   strong as the existing Internet routing and addressing architecture.
>=20
> Given the widely reported weakness of the "existing Internet routing =
and addressing architecture", this is a low bar indeed.  There are =
attempts in progress to attempt to improve the security of the Internet =
routing and addressing architecture.  I do not know what to suggest if =
these improvements leave the Internet with stronger security than is =
provided by these proposals.
>=20
> The summaries of the different proposals devote little attention to =
the infrastructure security ramifications of the proposal.  Given the =
stated goal, perhaps no attention was necessary.
>=20
> Many of these proposals include an encapsulation system, presenting =
the expected difficulties with end system authentication, filtering =
systems at boundaries, etc.  Some proposals addressed these concerns.  I =
am not sure if the security considerations section meant that the =
proposals were required to avoid weakening the end-host security =
protections already provided (ipsec, NAT, whatever).
>=20
> The rrg wg came to consensus that a fundamental architectural feature =
is a separation of locator and identifier for any node.  Many of the =
discussed alternatives include a mapping system that produce a locator =
for a given destination identifier.
>=20
> The mapping system would seem to be a very likely point of =
vulnerability, permitting traffic redirection for data exposure or =
blackholing, etc. Many proposals suggest a hierarchic architecture of =
the mapping system for scaling purposes.  I would presume that an =
authorization scheme for the mapping system would be essential, and that =
the hierarchy would be an important aspect of that scheme.  Of course, I =
can't tell much at this level of detail about how and if each proposals =
addresses this.  (One of the recommendations suggests communicating =
mapping info through bgp - I can not say at this point whether the SIDR =
suggestions for improving bgp security would be applicable.)
>=20
> --Sandy
>=20
> Nits:
>=20
>   PMTUD  Path Maximum Transmission Unit Discovery: The process or
>      mechanism that determines the largest packet that can be sent
>      between a given source and destination with being either i)
>      fragmented (IPv4 only), or ii) discarded (if not fragmentable)
>      because it is too large to be sent down one link in the path from
>      the source to the destination.
>=20
> It should say "*without* being either", right?  A long sentence so I =
may have lost my place.
>=20
>=20
> Several of the comments start using terms that are part of the wg =
deliberations, I'm sure.  But it makes reading the discussions and =
critiques obtuse.  In particular, "Core-Edge Separation" and "Core-Edge =
Elimination" seems to a well understood concept in the wg.  It needs to =
be defined somewhere.  A web search found references in some conference =
papers and in rrg mailing lists.


From nomcom2010@gmail.com  Thu Oct 28 20:59:13 2010
Return-Path: <nomcom2010@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 A6D2B3A69EC; Thu, 28 Oct 2010 20:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.643
X-Spam-Level: 
X-Spam-Status: No, score=-103.643 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, 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 WeRYbBOUTwUi; Thu, 28 Oct 2010 20:59:12 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 80ABA3A680E; Thu, 28 Oct 2010 20:59:11 -0700 (PDT)
Received: by qyk1 with SMTP id 1so5829892qyk.10 for <multiple recipients>; Thu, 28 Oct 2010 21:01:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=SGIwT1Hf5VGLR+RTMpiG3/diVhRiCweq4JVck5hf97Q=; b=DXHggXYmK5fmd/FnJyglfcK42Utp3XuX8hB61Mab2XGcZGWZMaW7N8OVpcggMWuN6c 8PTtXkmZZtRX4hhkETyRo5dAUGTLFXwQ2tj1JBbsixa64YWNZHz1M4aoES4AUQnLFdg1 ZLS7D7VVZLWZJWEmLduZ0ADdNl4FPpc/4PhTg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; b=ZDo2XpXLGJQu0PBiScEYI6DDdXw4hEXOfahqdZkxbvkwKqUYJ507ITZu6F2F+8TR95 Wa2lyHqg27Hau3p5bcKKkVVhrtfAC2Sg1joCqY0UEulEKVtdDkQR23Dsrd3lLy9iATA8 pnK2dFCwU0U+qCXVv3sIuClPKW0sVIlbXuqts=
MIME-Version: 1.0
Received: by 10.229.96.130 with SMTP id h2mr10143109qcn.284.1288324864439; Thu, 28 Oct 2010 21:01:04 -0700 (PDT)
Sender: nomcom2010@gmail.com
Received: by 10.220.72.74 with HTTP; Thu, 28 Oct 2010 21:01:04 -0700 (PDT)
Date: Thu, 28 Oct 2010 21:01:04 -0700
X-Google-Sender-Auth: ChdaKG7zm8SnWLZ8AiqdYXSvobk
Message-ID: <AANLkTiks2yJRqM1br1i3MrxV=7qfpu_RaUs1iMWCQCSq@mail.gmail.com>
From: NomCom-Chair <nomcom-chair@ietf.org>
To: nomcom-chair@ietf.org
Content-Type: multipart/alternative; boundary=001636426cebe675f90493b98147
X-Mailman-Approved-At: Mon, 01 Nov 2010 08:18:58 -0700
Subject: [secdir] Invitation to provide IETF Nominee Feedback
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: Fri, 29 Oct 2010 03:59:13 -0000

--001636426cebe675f90493b98147
Content-Type: text/plain; charset=ISO-8859-1

Nomcom 2010-2011 requests your input on the willing nominees for the
IETF open positions.

We request that as much as possible, comments are provided within two
weeks of the receipt of this email.  Please provide comments as soon as
possible and no later than November 12th.  Comments received after the
Beijing meeting may receive less consideration, although we will make every
effort to consider any and all input.

The feedback form is available at the following URL:
  https://wiki.tools.ietf.org/group/nomcom/10/input/

Note, you must have an IETF tools login to respond to this invitation.
If you do not have one,
    http://www1.tools.ietf.org/newlogin
can be used to get one.

The web-based feedback tool gives the NomCom an automated process for
collecting input on the nominees.  Your input will be encrypted before
it is stored by the feedback tool, and can only be decrypted by the NomCom.


When you access the feedback form, you will see a list of all of the
willing nominees.  By clicking on a nominee's name, you will be presented
with a text-input form into which you can type your input.

While we encourage feedback through the form, you may send feedback to
the nomcom list, nomcom10@ietf.org, directly.

Community feedback is essential for the nomcom process to be effective.
Notes on comparison of nominees to each other are also useful to the
nomcom. You are also encouraged to provide notes on how a nominee
satisfies the IESG/IAB/IAOC's desired expertise; if you feel that the
nominee has a different set of skills necessary for the job and those
skills are different from the posted requirements, please provide
details.

If you prefer to provide anonymous input, please send it directly to
the nomcom chair, Tom Walsh, or any other member of the nomcom and
request them to anonymize your input.  All information provided to the
nomcom and the sources of such information are confidential.
Thanks in advance for your feedback.

Regards,
Thomas Walsh
NomCom 2010-11 nomcom10@ietf.org
nomcom-chair@ietf.org

--001636426cebe675f90493b98147
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>Nomcom 2010-2011 requests your input on the willing nominees for the <br=
>IETF open positions.</p>
<p>We request that as much as possible, comments are provided within two <b=
r>weeks of the receipt of this email.=A0 Please provide comments as soon as=
 <br>possible and no later than November 12th.=A0 Comments received after t=
he <br>
Beijing meeting may receive less consideration, although we will make every=
 <br>effort to consider any and all input.</p>
<p>The feedback form is available at the following URL:<br>=A0 <a href=3D"h=
ttps://wiki.tools.ietf.org/group/nomcom/10/input/">https://wiki.tools.ietf.=
org/group/nomcom/10/input/</a></p>
<p>Note, you must have an IETF tools login to respond to this invitation. <=
br>If you do not have one, <br>=A0=A0=A0 <a href=3D"http://www1.tools.ietf.=
org/newlogin">http://www1.tools.ietf.org/newlogin</a><br>can be used to get=
 one.</p>

<p>The web-based feedback tool gives the NomCom an automated process for <b=
r>collecting input on the nominees.=A0 Your input will be encrypted before =
<br>it is stored by the feedback tool, and can only be decrypted by the Nom=
Com.=A0 </p>

<p>When you access the feedback form, you will see a list of all of the <br=
>willing nominees.=A0 By clicking on a nominee&#39;s name, you will be pres=
ented <br>with a text-input form into which you can type your input.=A0 </p=
>

<p>While we encourage feedback through the form, you may send feedback to <=
br>the nomcom list, <a href=3D"mailto:nomcom10@ietf.org">nomcom10@ietf.org<=
/a>, directly.</p>
<p>Community feedback is essential for the nomcom process to be effective. =
<br>Notes on comparison of nominees to each other are also useful to the <b=
r>nomcom. You are also encouraged to provide notes on how a nominee <br>
satisfies the IESG/IAB/IAOC&#39;s desired expertise; if you feel that the <=
br>nominee has a different set of skills necessary for the job and those <b=
r>skills are different from the posted requirements, please provide <br>
details.</p>
<p>If you prefer to provide anonymous input, please send it directly to <br=
>the nomcom chair, Tom Walsh, or any other member of the nomcom and <br>req=
uest them to anonymize your input.=A0 All information provided to the <br>
nomcom and the sources of such information are confidential. <br>Thanks in =
advance for your feedback. </p>
<p>Regards, <br>Thomas Walsh<br>NomCom 2010-11 <a href=3D"mailto:nomcom10@i=
etf.org">nomcom10@ietf.org</a> <br><a href=3D"mailto:nomcom-chair@ietf.org"=
>nomcom-chair@ietf.org</a></p>
<p><br>=A0</p>

--001636426cebe675f90493b98147--

From stpeter@stpeter.im  Thu Oct 28 20:59:29 2010
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 2FD473A69FA; Thu, 28 Oct 2010 20:59:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level: 
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 o9674M9fU3De; Thu, 28 Oct 2010 20:59:26 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 27A623A680E; Thu, 28 Oct 2010 20:59:26 -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 C939840BB9; Thu, 28 Oct 2010 22:09:29 -0600 (MDT)
Message-ID: <4CCA470B.20601@stpeter.im>
Date: Thu, 28 Oct 2010 22:01:15 -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.11) Gecko/20101013 Thunderbird/3.1.5
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="------------ms070600050905090708010909"
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: Fri, 29 Oct 2010 03:59:29 -0000

This is a cryptographically signed message in MIME format.

--------------ms070600050905090708010909
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for your careful and thorough review. To maintain forward
momentum, this is Part 1 of my reply, up through the end of Section 4. I
shall endeavor to reply regarding the remainder of your review in the
next 24-48 hours.

[Copying xmpp@ietf.org to keep the WG in the loop...]

On 10/28/10 4:28 AM, Yaron Sheffer wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the IESG=
=2E
> These comments were written primarily for the benefit of the security
> area directors.  Document editors and WG chairs should treat these
> comments just like any other last call comments.
>=20
> The document updates RFC 3920, which is the definition of the core XMPP=

> real-time messaging protocol. It should be noted the instant messaging
> and presence are layered on top of this protocol, and specified separat=
ely.
>=20
> General
>=20
> The document is initially intimidating, because of its length. But it i=
s
> extremely well written (for which I would like to thank the editor) and=

> well organized. So overall, a good read.

Thanks.

> I have not found anything that I consider a glaring security hole. But
> this is a layered security architecture (application layer =3D=3D XMPP =
core
> =3D=3D SASL =3D=3D TLS) which is not easy to do right. Hence the large =
number of
> comments and questions below.
>=20
> I also appreciate the open discussion of the existing implementations
> and their security issues (e.g. "server dialback", shiver). I hope this=

> document results in a security improvement in real deployments.

We hope so!

> Detailed Comments
>=20
> Note: these comments are based on rev -17 of the draft. This only
> matters as far as section numbers, with the only security-relevant
> change in -18 being a useful note on end-to-end protection.
>=20
> - 1.3: Implementation note: I suggest adding something like "Solutions
> specified in this document offer a significantly better level of securi=
ty."

True. In my working I've added this sentence (including a forward
reference to the discussion of strong security):

   The solutions specified in this document offer a significantly
   stronger level of security (see also Section 13.6).

> - 3.3: why do we not recommend to use TLS (stateless) session resumptio=
n
> for reconnection?

Your suggestion is a good one.

The XMPP WG and broader XMPP developer community have had some
discussions about methods for "quick reconnect". These would involve the
use of TLS session resumption, pipelining of requests from the
initiating entity to the receiving entity, perhaps some SASL tricks (see
for example draft-cridland-sasl-tls-sessions-00), etc. Those discussions
are rather preliminary at this time, however I think we can safely
recommend the use TLS session resumption.

I propose that we add the following paragraph at the end of Section 3.3:

   It is RECOMMENDED to make use of TLS session resumption [TLS-RESUME]
   when reconnecting.  A future version of this document, or a separate
   specification, might provide more detailed guidelines regarding
   methods for speeding the reconnection process.

> - 4.2.5 the access control rule at the bottom of this section makes
> sense. Why why does it explicitly not apply to elements other than XML
> stanzas? Are there cases where you negotiate TLS with someone other tha=
n
> the server? You can even imagine weird tunneling attacks using this
> "feature".
> - 4.2.5: "other than itself" - am I really allowed to send "message"
> stanzas from one resource of a JID to another resource of the same JID,=

> before feature negotiation and before TLS negotiation?

I now see that the following paragraph is poorly phrased:

   The initiating entity MUST NOT attempt to send XML stanzas
   (Section 8) to entities other than itself (i.e., the client's
   connected resource or any other authenticated resource of the
   client's account) or the server to which it is connected until stream
   negotiation has been completed.  Even if the initiating entity does
   attempt to do so, the receiving entity MUST NOT accept such stanzas
   and MUST return a <not-authorized/> stream error.  This rule applies
   to XML stanzas only (i.e., <message/>, <presence/>, and <iq/>
   elements qualified by the content namespace) and not to XML elements
   used for stream negotiation (e.g., elements used to complete TLS
   negotiation (Section 5) or SASL negotiation (Section 6)).

There are several points that could be clarified here:

1. You can't send non-stanzas to other entities because (as XMPP is
currently defined) only stanzas have 'to' addresses. The XML elements
that we use for things like TLS negotiation and SASL negotiation are not
addressable to other entities (e.g., a remote server or client) but only
to the server to which a client has connected, so we don't need to
mention them in this paragraph.

2. However, that's contingent on how XMPP is currently defined, i.e., we
assume that there are only stanzas and stream-negotiation elements. This
leaves a bit of a loophole for elements that don't fit in either of
those buckets, e.g., sending <foo:bar to=3D'baz'/> from the client. Is th=
e
server supposed to route or deliver that element to baz? I would say no.
Someone could write a server that allows the communication of arbitrary
XML elements over XML streams, but that's not what 3920bis defines. So I
think we need to tighten that up, although this paragraph is not the
place to do so (I think it belongs in Section 4.7.3 "Other Namespaces").

3. Yes, a server might allow a client to communicate with its bare JID
or other full JIDs after it has authenticated but before it has bound a
resource (e.g., to send a service discovery request so it can discover
which other resources are currently connected). This is not an important
"feature" by any means, but as far as I can see it does not open any
security holes as long as the server requires authentication first. Thus
the phrase "until stream negotiation has been completed" in the quoted
paragraph is misleading.

Taking these considerations together, I propose the following modified
paragraph at the end of Section 4.2.5:

   An initiating entity MUST NOT attempt to send data to entities
   other than itself (i.e., the bare JID of the user's account) or the
   server to which it has connected until it has authenticated with the
   receiving entity.  If the initiating entity attempts to do so, the
   receiving entity MUST NOT accept such data and MUST close the stream
   with a <not-authorized/> stream error.

Then I propose that we modify Section 4.7.4 as follows:

###

4.7.3.  Other Namespaces

   Either party to a stream MAY send data qualified by namespaces other
   than the content namespace and the streams namespace.  For example,
   this is how data related to TLS negotiation and SASL negotiation are
   exchanged, as well as XMPP extensions such as Stream Management
   [XEP-0198] and Server Dialback [XEP-0220].  (For historical reasons,
   some server implementations expect a declaration of the 'jabber:
   server:dialback' namespace on server-to-server streams, as explained
   in [XEP-0220].)

   However, an XMPP server MUST NOT route or deliver data received over
   an input stream if that data is (a) qualified by another namespace
   and (b) addressed to an entity other than the server, unless the
   other party to the output stream over which the server would send the
   data has explicitly negotiated or advertised support for receiving
   arbitrary data from the server.  This rule is included because XMPP
   is designed for the exchange of XML stanzas (not arbitrary XML data),
   and because allowing an entity to send arbitrary data to other
   entities could significantly increase the potential for exchanging
   malicious information.  As an example of this rule, the server
   hosting the example.net domain would not route the following first-
   level XML element from <romeo@example.net> to <juliet@example.com>:

     <ns1:foo xmlns:ns1=3D'http://example.org/ns1'
              from=3D'romeo@example.net/resource1'
              to=3D'juliet@example.com'>
       <ns1:bar/>
     </ns1:foo>

   This rule also applies to first-level elements that look like stanzas
   but that are improperly namespaced and therefore really are not
   stanzas at all (see also Section 4.7.4), for example:

     <ns2:message xmlns:pre=3D'http://example.org/ns2'
                  from=3D'romeo@example.net/resource1'
                  to=3D'juliet@example.com'>
       <body>hi</body>
     </ns2:message>

   Upon receiving arbitrary first-level XML elements over an input
   stream, a server MUST either ignore the data or return a stream
   error, which SHOULD be <unsupported-stanza-type/>.

###

> - 4.2.6: why do we even allow non-SASL protected server-to-server
> communication?

Because, in practice, most existing services end up using Server
Dialback, not TLS + SASL EXTERNAL with PKIX certificates.

> - 4.3: How is TLS negotiated for the additional streams?=20

Each stream is separately secured.

> How is it bound
> to the SASL negotiation that (apparently) only takes place once?

It isn't, because each stream is separately secured (preferably by means
of TLS + SASL).

I propose that we clarify these matters by modifying the following
paragraphs from Section 4.3 ("Directionality"):

###

4.3.  Directionality

   An XML stream is always unidirectional, by which is meant that XML
   stanzas can be sent in only one direction over the stream (either
   from the initiating entity to the receiving entity or from the
   receiving entity to the initiating entity).

   Depending on the type of session that has been negotiated and the
   nature of the entities involved, the entities might use:

   o  Two streams over a single TCP connection, where the security
      context negotiated for the first stream is applied to the second
      stream.  This is typical for client-to-server sessions, and a
      server MUST allow a client to use the same TCP connection for both
      streams.

   o  Two streams over two TCP connections, where each stream is
      separately secured.  In this approach, one TCP connection is used
      for the stream in which stanzas are sent from the initiating
      entity to the receiving entity, and the other TCP connection is
      used for the stream in which stanzas are sent from the receiving
      entity to the initiating entity.  This is typical for server-to-
      server sessions.

   o  Multiple streams over two or more TCP connections, where each
      stream is separately secured.  This approach is sometimes used for
      server-to-server communication between two large XMPP service
      providers; however, this can make it difficult to maintain
      coherence of data received over multiple streams in situations
      described under Section 10.1, which is why a server MAY return a
      <conflict> stream error to a remote server that attempts to
      negotiate more than one stream (as described under
      Section 4.8.3.3).

   This concept of directionality applies only to stanzas and explicitly
   does not apply to first-level children of the stream root that are
   used to bootstrap or manage the stream (e.g., first-level elements
   used for TLS negotiation, SASL negotiation, Server Dialback
   [XEP-0220], and Stream Management [XEP-0198]).

   The foregoing considerations imply that while completing STARTTLS
   negotiation (Section 5) and SASL negotiation (Section 6) two servers
   would use one TCP connection, but after the stream negotiation
   process is done that original TCP connection would be used only for
   the initiating server to send XML stanzas to the receiving server.
   In order for the receiving server to send XML stanzas to the
   initiating server, the receiving server would need to reverse the
   roles and negotiate an XML stream from the receiving server to the
   initiating server over a separate TCP connection.

###

> - 4.4: this section appears to tie the two streams in the opposite
> directions together - when you close one you expect the other guy to
> close the other ASAP. But what is the behavior for "multiple streams
> over multiple connections" (Sec. 4.3)?

That is an excellent question. Section 4.4 currently assumes that there
is a defined pairing of streams because that is what happens in well
over 99% of the cases (I'd venture to guess that using multiple streams
over multiple TCP connections is extremely rare and happens only for
some high-volume server-to-server links). IMHO we don't have enough
experience with this case to recommend server behavior, although it
would be good to gather feedback from any service providers who are
using multiple streams over multiple TCP connections. Therefore I
propose that we modify Section 4.4 as follows:

###

   If the parties are using either two streams over a single TCP
   connection or two streams over two TCP connections, the entity that
   sends the closing stream tag SHOULD behave as follows:

   1.  Wait for the other party to also close its stream before
       terminating the underlying TCP connection(s); this gives the
       other party an opportunity to finish transmitting any data in the
       opposite direction before the TCP connection(s) is terminated.

   2.  Refrain from initiating the sending of further data over that
       stream but continue to process data sent by the other entity
       (and, if necessary, react to such data).

   3.  Consider both streams to be void if the other party does not send
       its closing stream tag within a reasonable amount of time (where
       the definition of "reasonable" is a matter of implementation or
       deployment).

   4.  After receiving a reciprocal closing stream tag from the other
       party or waiting a reasonable amount of time with no response,
       terminate the underlying TCP connection(s).

   If the parties are using multiple streams over multiple TCP
   connections, there is no defined pairing of streams and therefore the
   behavior is a matter for implementation.

###

> - 4.4: what about orderly tear-down of the TLS association ("closure
> alert")?

Sending of the closure alert is mandated by RFC 4346. Do you think it is
necessary (or would be helpful) to call it out in the specification of
an application protocol that re-use TLS?

I note that Section 7.2.1 ("Closure Alerts") of RFC 4346 states in part:

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended.  If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation MAY choose to close the
   transport without waiting for the responding close_notify.  No part
   of this standard should be taken to dictate the manner in which a
   usage profile for TLS manages its data transport, including when
   connections are opened or closed.

I note also that rule #2 in Section 4.4 of 3920bis states:

   2.  Refrain from initiating the sending of further data over that
       stream but continue to process data sent by the other entity
       (and, if necessary, react to such data).

This implies that the entity that is closing the stream might send more
data and certaily might receive data (on the other stream). Thus I think
we do need to clarify use of closure alerts. I propose adding the
following security note to Section 4.4:

      Security Note: In accordance with Section 7.2.1 of [TLS], to help
      prevent a truncation attack the party that is closing the stream
      MUST send a TLS close_notify alert and MUST receive a responding
      close_notify alert from the other party before closing the
      underlying TCP connection(s).

> - 4.8.3.12: does not-authorized only refer to stream-level, rather than=

> stanza-level errors? Are there cases when I am authorized to send some
> stanza types but not others?

There are three <not-authorized/> error conditions, each qualified by a
different namespace:

1. The stream error condition is triggered by trying to send data before
completing authentication.

2. The SASL error condition is triggered by providing a bad username or
incorrect credentials.

3. The stream error condition is triggered by attempting to complete an
application-layer action that requires authentication (e.g., attempting
to join a password-protected chatroom without providing the password).

A server could restrict a user's ability to send different types of
stanzas (e.g., a presence-only XMPP service could return a stanza error
if a user attempts to send a <message/> stanza, but in that case it's a
service-wide policy and the <not-allowed/> stanza error condition is
more appropriate). In general, the <not-authorized/> stanza error
condition implies that the sender could do *something* to modify the
data it sent in order to prove that it is in fact authorized to perform
the action requested in the stanza (e.g., include a password in the
chatroom join request).

> - 4.8.3.14 remote-connection-failed has dubious security benefit (why
> tell the world that your RADIUS server is down), compared to reusing
> internal-error.

It's not an internal error because the source of the failure is a remote
entity. As far as I know, this error condition has been used only in the
context of server dialback (in the case where a stream error occurs
between the Receiving Server and the Authoritative Server), but we've
tried to scrub the-protocol-that-shall-not-be-named from 3920bis
wherever possible; doing so in here has led to confusion on your part so
I propose that we might want to modify the description, as so:

   The server is unable to properly connect to a remote entity that is
   needed for authentication or authorization (e.g., in certain
   scenarios related to Server Dialback [XEP-0220]); this condition is
   not to be used when the cause of the error is within the
   administrative domain of the XMPP service provider, in which case the
   <internal-server-error/> condition is more appropriate.

> - 4.8.3.16: shouldn't we say that "reset" (when the stream is encrypted=
)
> also applies to the higher layers, i.e. encryption and authentication
> should be performed again?

Good point. I propose that we modify the description as follows:

   The server is closing the stream because it has new (typically
   security-critical) features to offer, because the keys or
   certificates used to establish a secure context for the stream have
   expired or have been revoked during the life of the stream
   (Section 13.7.2.3), because the TLS sequence number has wrapped
   (Section 5.3.5), etc.  The reset applies to the stream and to any
   security context established for that stream (e.g., via TLS and
   SASL), which means that encryption and authentication need to be
   negotiated again for the new stream (e.g., TLS session resumption
   cannot be used).

> - 4.8.3.18: what are the security implications of a "redirect"?=20

Of <see-other-host/>? Seemingly underspecified. :(

> Should
> the client apply the same policy, e.g. for using TLS, as for the
> original server?=20

Yes.

> Which "to" identity to use?=20

The 'to' address of the initial stream header would still be the DNS
domain name of the XMPP service to which the initiating entity is trying
to connect (see also draft-saintandre-tls-server-id-check).

> Can redirection occur
> before the recipient is even authenticated?

Yes.

I propose that we modify the description as follows:

   The server will not provide service to the initiating entity but is
   redirecting traffic to another host under the administrative control
   of the same service provider.  The XML character data of the <see-
   other-host/> element returned by the server MUST specify the
   alternate hostname or IP address at which to connect, which MUST be a
   valid domainpart or a domainpart plus port number (separated by the
   ':' character in the form "domainpart:port").  If the domainpart is
   the same as the source domain, derived domain, or resolved IP address
   to which the initiating entity originally connected (differing only
   by the port number), then the initiating entity SHOULD simply attempt
   to reconnect at that address.  Otherwise, the initiating entity MUST
   resolve the hostname specified in the <see-other-host/> element as
   described under Section 3.2.

I also propose that we add the following paragraph to the end of the
section:

   When negotiating a stream with the host to which it has been
   redirected, the initiating entity MUST apply the same policies it
   would have applied to the original connection attempt (e.g., a policy
   requiring TLS), MUST specify the same 'to' address on the initial
   stream header, and MUST verify the identity of the new host using the
   same reference identifier(s) it would have used for the original
   connection attempt (in accordance with [TLS-CERTS].  Even if
   receiving entity returns a <see-other-host/> error before the
   confidentiality and integrity of the stream have been established
   (thus introducing the possibility of a denial of service attack), the
   fact that the initiating entity needs to verify the identity of the
   XMPP service based on the same reference identifiers implies that the
   initiating entity will not connect to a malicious entity; however, to
   reduce the possibility of a denial of service attack, the receiving
   entity SHOULD NOT return a <see-other-host/> error until after the
   stream has been protected (e.g., via TLS).

> - 4.9: Don't we resend the "stream" header again after completing the
> TLS negotiation (Sec. 4.2.3).

For sure. I propose that we change this:

   [ ... channel encryption ... ]

   [ ... authentication ... ]

   [ ... resource binding ... ]

to:

   [ ... stream negotiation ... ]

### END OF PART 1 ###




--------------ms070600050905090708010909
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy
OTA0MDExNVowIwYJKoZIhvcNAQkEMRYEFI548q4VdTGXvoVAhzeVI3S9ohzwMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBGUzbsB8s9UU5j2utJ/+/q3/ZOPjOniqF7+MpKMWjULVeTVyCD+RxY6Bpq
hLxX/ZLHficwNNwKagv+h6KMfcbTEbjidOFUU/EWLjCwNq0Tuy9ls2kTZp3QrWO/U0QmKY30
5PRHUzSSEBM9vJMaGfPkfnwpTgkX4YhoiZZ/XnG0DaoN5dE12EE9B+dmNyI2uM8EfQl2jiPO
+fuTWgBLq79OqKwLowfHuZDjpf3w2HOJ1n50Xm7SqDjP0CBeWKI74JernvOBDuZ903eZMCvn
cQDAudIXGeDfJ+BOYh8trEkG3UwRRo1UA2FdXHAR8VZcsdd3IhVhoIpLNg6g3mo6+WK2AAAA
AAAA
--------------ms070600050905090708010909--

From stpeter@stpeter.im  Fri Oct 29 07:18:13 2010
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 01C083A69C0; Fri, 29 Oct 2010 07:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level: 
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 sw6ZnErT3syV; Fri, 29 Oct 2010 07:18:11 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 521733A67E3; Fri, 29 Oct 2010 07:18:08 -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 A80AE40BB9; Fri, 29 Oct 2010 08:28:15 -0600 (MDT)
Message-ID: <4CCAD810.4060508@stpeter.im>
Date: Fri, 29 Oct 2010 08:20:00 -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> <4CCA470B.20601@stpeter.im> <4CCA7BED.1020907@gmail.com>
In-Reply-To: <4CCA7BED.1020907@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="------------ms070005020305010703010505"
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: Fri, 29 Oct 2010 14:18:13 -0000

This is a cryptographically signed message in MIME format.

--------------ms070005020305010703010505
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Yaron, a few additional comments and text proposals inline.

On 10/29/10 1:46 AM, Yaron Sheffer wrote:
> Hi Peter,
>=20
> On 10/29/2010 06:01 AM, Peter Saint-Andre wrote:
>> Thanks for your careful and thorough review. To maintain forward
>> momentum, this is Part 1 of my reply, up through the end of Section 4.=
 I
>> shall endeavor to reply regarding the remainder of your review in the
>> next 24-48 hours.
>>
> Thanks a lot for using my comments and misunderstandings to improve the=

> document.
>=20
> I have removed pieces of this mail where I fully accept your
> response/changes.
>=20
>>> - 4.3: How is TLS negotiated for the additional streams?
>>
>> Each stream is separately secured.
>>
>>> How is it bound
>>> to the SASL negotiation that (apparently) only takes place once?
>>
>> It isn't, because each stream is separately secured (preferably by mea=
ns
>> of TLS + SASL).
>>
>> I propose that we clarify these matters by modifying the following
>> paragraphs from Section 4.3 ("Directionality"):
>>
>> ###
>>
>> 4.3.  Directionality
>>
>>     An XML stream is always unidirectional, by which is meant that XML=

>>     stanzas can be sent in only one direction over the stream (either
>>     from the initiating entity to the receiving entity or from the
>>     receiving entity to the initiating entity).
>>
>>     Depending on the type of session that has been negotiated and the
>>     nature of the entities involved, the entities might use:
>>
>>     o  Two streams over a single TCP connection, where the security
>>        context negotiated for the first stream is applied to the secon=
d
>>        stream.  This is typical for client-to-server sessions, and a
>>        server MUST allow a client to use the same TCP connection for b=
oth
>>        streams.
>>
>>     o  Two streams over two TCP connections, where each stream is
>>        separately secured.  In this approach, one TCP connection is us=
ed
>>        for the stream in which stanzas are sent from the initiating
>>        entity to the receiving entity, and the other TCP connection is=

>>        used for the stream in which stanzas are sent from the receivin=
g
>>        entity to the initiating entity.  This is typical for server-to=
-
>>        server sessions.
>>
>>     o  Multiple streams over two or more TCP connections, where each
>>        stream is separately secured.  This approach is sometimes used =
for
>>        server-to-server communication between two large XMPP service
>>        providers; however, this can make it difficult to maintain
>>        coherence of data received over multiple streams in situations
>>        described under Section 10.1, which is why a server MAY return =
a
>>        <conflict>  stream error to a remote server that attempts to
>>        negotiate more than one stream (as described under
>>        Section 4.8.3.3).
>>
>>     This concept of directionality applies only to stanzas and explici=
tly
>>     does not apply to first-level children of the stream root that are=

>>     used to bootstrap or manage the stream (e.g., first-level elements=

>>     used for TLS negotiation, SASL negotiation, Server Dialback
>>     [XEP-0220], and Stream Management [XEP-0198]).
>>
>>     The foregoing considerations imply that while completing STARTTLS
>>     negotiation (Section 5) and SASL negotiation (Section 6) two serve=
rs
>>     would use one TCP connection, but after the stream negotiation
>>     process is done that original TCP connection would be used only fo=
r
>>     the initiating server to send XML stanzas to the receiving server.=

>>     In order for the receiving server to send XML stanzas to the
>>     initiating server, the receiving server would need to reverse the
>>     roles and negotiate an XML stream from the receiving server to the=

>>     initiating server over a separate TCP connection.
>>
> Perhaps add a final sentence: "This separate TCP connection is then
> secured using a new round of TLS and/or SASL negotiation."

Yes, that's good. Paragraph updated with your text.

>> ###
>>
>>> - 4.8.3.18: what are the security implications of a "redirect"?
>>
>> Of<see-other-host/>? Seemingly underspecified. :(
>>
>>> Should
>>> the client apply the same policy, e.g. for using TLS, as for the
>>> original server?
>>
>> Yes.
>>
>>> Which "to" identity to use?
>>
>> The 'to' address of the initial stream header would still be the DNS
>> domain name of the XMPP service to which the initiating entity is tryi=
ng
>> to connect (see also draft-saintandre-tls-server-id-check).
>>
>>> Can redirection occur
>>> before the recipient is even authenticated?
>>
>> Yes.
>>
>> I propose that we modify the description as follows:
>>
>>     The server will not provide service to the initiating entity but i=
s
>>     redirecting traffic to another host under the administrative contr=
ol
>>     of the same service provider.  The XML character data of the<see-
>>     other-host/>  element returned by the server MUST specify the
>>     alternate hostname or IP address at which to connect, which MUST b=
e a
>>     valid domainpart or a domainpart plus port number (separated by th=
e
>>     ':' character in the form "domainpart:port").  If the domainpart i=
s
>>     the same as the source domain, derived domain, or resolved IP addr=
ess
>>     to which the initiating entity originally connected (differing onl=
y
>>     by the port number), then the initiating entity SHOULD simply atte=
mpt
>>     to reconnect at that address.  Otherwise, the initiating entity MU=
ST
>>     resolve the hostname specified in the<see-other-host/>  element as=

>>     described under Section 3.2.
>>
>> I also propose that we add the following paragraph to the end of the
>> section:
>>
>>     When negotiating a stream with the host to which it has been
>>     redirected, the initiating entity MUST apply the same policies it
>>     would have applied to the original connection attempt (e.g., a pol=
icy
>>     requiring TLS), MUST specify the same 'to' address on the initial
>>     stream header, and MUST verify the identity of the new host using =
the
>>     same reference identifier(s) it would have used for the original
>>     connection attempt (in accordance with [TLS-CERTS].  Even if
>>     receiving entity returns a<see-other-host/>  error before the
>>     confidentiality and integrity of the stream have been established
>>     (thus introducing the possibility of a denial of service attack), =
the
>>     fact that the initiating entity needs to verify the identity of th=
e
>>     XMPP service based on the same reference identifiers implies that =
the
>>     initiating entity will not connect to a malicious entity; however,=
 to
>>     reduce the possibility of a denial of service attack, the receivin=
g
>>     entity SHOULD NOT return a<see-other-host/>  error until after the=

>>     stream has been protected (e.g., via TLS).
>>
> ... and the sending entity SHOULD maintain a running redirect counter,
> and give up after a certain number of successive redirects.
>=20
> Also, the mitigation you propose in the last sentence only helps if "An=

> entity MAY have a policy where it only accepts <see-other-host> element=
s
> from authenticated peers.

Thanks. I propose that we change this paragraph to:

   When negotiating a stream with the host to which it has been
   redirected, the initiating entity MUST apply the same policies it
   would have applied to the original connection attempt (e.g., a policy
   requiring TLS), MUST specify the same 'to' address on the initial
   stream header, and MUST verify the identity of the new host using the
   same reference identifier(s) it would have used for the original
   connection attempt (in accordance with [TLS-CERTS].  Even if
   receiving entity returns a <see-other-host/> error before the
   confidentiality and integrity of the stream have been established
   (thus introducing the possibility of a denial of service attack), the
   fact that the initiating entity needs to verify the identity of the
   XMPP service based on the same reference identifiers implies that the
   initiating entity will not connect to a malicious entity; however, to
   reduce the possibility of a denial of service attack, the receiving
   entity SHOULD NOT return a <see-other-host/> error until after the
   stream has been protected (e.g., via TLS) and the receiving entity
   MAY have a policy of following redirects only if it has authenticated
   the receiving entity.  In addition, the initiating entity SHOULD give
   up after a certain number of successive redirects (e.g., at least 2
   but no more than 5).

>>> - 4.9: Don't we resend the "stream" header again after completing the=

>>> TLS negotiation (Sec. 4.2.3).
>>
>> For sure. I propose that we change this:
>>
>>     [ ... channel encryption ... ]
>>
>>     [ ... authentication ... ]
>>
>>     [ ... resource binding ... ]
>>
>> to:
>>
>>     [ ... stream negotiation ... ]
>>
> I'm not sure. Since we start the example with two <stream> elements, it=

> would make sense to show the additional (4?) <stream> elements further
> down. Although the "simple" examples would no longer fit a page. Maybe
> add a "really simple" example with no security?

These examples are included to provide a high-level illustration of what
a session would look like, so I think eliding the whole stream
negotiation process is fine. However, I think it would be good to add a
forward reference to Section 9 so that the reader knows where to go for
detailed examples. Thus propose modifying the first paragraph of Section
4.9 as follows:

   This section contains two highly simplified examples of a stream-
   based connection between a client and a server; these examples are
   included for the purpose of illustrating the concepts introduced thus
   far, but the reader needs to be aware that these examples elide many
   details (see Section 9 for more complete examples).

Peter

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




--------------ms070005020305010703010505
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy
OTE0MjAwMFowIwYJKoZIhvcNAQkEMRYEFPHBfB0oSXpNVeGAWNkz9M+oiW1lMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCjhJTVa7prCPwSx0+o1VaEwrj13cokHUeJ8s1EQvcAL4uis/uEKjYQKVzu
YvM02uj0yiy7EINZuyVYEZDQpCJHoB4MAGBFC+YoocP58dAvGbcVVSvte6Q+QE9hPOjOPYi4
XUse+BI1WqKila3ey7Srqr2Gk0gJSKZIai1PGsXRezSV3qKY4tXIWL0HdUlOgqmtaa72yuDK
rnPjHVfEWgq+QNrrX8cWDJau6/zqLpWPqS+6bt2PE26b//vh/atNKjLt0Av+XGC62zoAGjgJ
03bmVM2zpqOy/9EVExqdoNEHlrKnpY1nYixuXLr4m7onMfg4HeGrZavzRBN49fiu/YSdAAAA
AAAA
--------------ms070005020305010703010505--

From stpeter@stpeter.im  Fri Oct 29 07:40:10 2010
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 76A8D3A69CB; Fri, 29 Oct 2010 07:40:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.569
X-Spam-Level: 
X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 g8yMWcqlooAw; Fri, 29 Oct 2010 07:40:08 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9E6EC3A6A10; Fri, 29 Oct 2010 07:40:06 -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 6F83040BB9; Fri, 29 Oct 2010 08:50:14 -0600 (MDT)
Message-ID: <4CCADD37.7070402@stpeter.im>
Date: Fri, 29 Oct 2010 08:41:59 -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> <4CCA470B.20601@stpeter.im> <4CCA7BED.1020907@gmail.com> <4CCAD810.4060508@stpeter.im> <4CCAD98E.1040300@gmail.com>
In-Reply-To: <4CCAD98E.1040300@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="------------ms070706020401050000000805"
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: Fri, 29 Oct 2010 14:40:10 -0000

This is a cryptographically signed message in MIME format.

--------------ms070706020401050000000805
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Excellent. I'll try to finish Part 2 today.

On 10/29/10 8:26 AM, Yaron Sheffer wrote:
> Hi Peter,
>=20
> I'm fine with your proposals.
>=20
> Thanks,
>     Yaron
>=20
> On 10/29/2010 04:20 PM, Peter Saint-Andre wrote:
>> Hi Yaron, a few additional comments and text proposals inline.
>>
>> On 10/29/10 1:46 AM, Yaron Sheffer wrote:
>>> Hi Peter,
>>>
>>> On 10/29/2010 06:01 AM, Peter Saint-Andre wrote:
>>>> Thanks for your careful and thorough review. To maintain forward
>>>> momentum, this is Part 1 of my reply, up through the end of Section
>>>> 4. I
>>>> shall endeavor to reply regarding the remainder of your review in th=
e
>>>> next 24-48 hours.
>>>>
>>> Thanks a lot for using my comments and misunderstandings to improve t=
he
>>> document.
>>>
>>> I have removed pieces of this mail where I fully accept your
>>> response/changes.
>>>
>>>>> - 4.3: How is TLS negotiated for the additional streams?
>>>>
>>>> Each stream is separately secured.
>>>>
>>>>> How is it bound
>>>>> to the SASL negotiation that (apparently) only takes place once?
>>>>
>>>> It isn't, because each stream is separately secured (preferably by
>>>> means
>>>> of TLS + SASL).
>>>>
>>>> I propose that we clarify these matters by modifying the following
>>>> paragraphs from Section 4.3 ("Directionality"):
>>>>
>>>> ###
>>>>
>>>> 4.3.  Directionality
>>>>
>>>>      An XML stream is always unidirectional, by which is meant that =
XML
>>>>      stanzas can be sent in only one direction over the stream (eith=
er
>>>>      from the initiating entity to the receiving entity or from the
>>>>      receiving entity to the initiating entity).
>>>>
>>>>      Depending on the type of session that has been negotiated and t=
he
>>>>      nature of the entities involved, the entities might use:
>>>>
>>>>      o  Two streams over a single TCP connection, where the security=

>>>>         context negotiated for the first stream is applied to the
>>>> second
>>>>         stream.  This is typical for client-to-server sessions, and =
a
>>>>         server MUST allow a client to use the same TCP connection
>>>> for both
>>>>         streams.
>>>>
>>>>      o  Two streams over two TCP connections, where each stream is
>>>>         separately secured.  In this approach, one TCP connection is=

>>>> used
>>>>         for the stream in which stanzas are sent from the initiating=

>>>>         entity to the receiving entity, and the other TCP connection=
 is
>>>>         used for the stream in which stanzas are sent from the
>>>> receiving
>>>>         entity to the initiating entity.  This is typical for
>>>> server-to-
>>>>         server sessions.
>>>>
>>>>      o  Multiple streams over two or more TCP connections, where eac=
h
>>>>         stream is separately secured.  This approach is sometimes
>>>> used for
>>>>         server-to-server communication between two large XMPP servic=
e
>>>>         providers; however, this can make it difficult to maintain
>>>>         coherence of data received over multiple streams in situatio=
ns
>>>>         described under Section 10.1, which is why a server MAY
>>>> return a
>>>>         <conflict>   stream error to a remote server that attempts t=
o
>>>>         negotiate more than one stream (as described under
>>>>         Section 4.8.3.3).
>>>>
>>>>      This concept of directionality applies only to stanzas and
>>>> explicitly
>>>>      does not apply to first-level children of the stream root that =
are
>>>>      used to bootstrap or manage the stream (e.g., first-level eleme=
nts
>>>>      used for TLS negotiation, SASL negotiation, Server Dialback
>>>>      [XEP-0220], and Stream Management [XEP-0198]).
>>>>
>>>>      The foregoing considerations imply that while completing STARTT=
LS
>>>>      negotiation (Section 5) and SASL negotiation (Section 6) two
>>>> servers
>>>>      would use one TCP connection, but after the stream negotiation
>>>>      process is done that original TCP connection would be used only=

>>>> for
>>>>      the initiating server to send XML stanzas to the receiving serv=
er.
>>>>      In order for the receiving server to send XML stanzas to the
>>>>      initiating server, the receiving server would need to reverse t=
he
>>>>      roles and negotiate an XML stream from the receiving server to =
the
>>>>      initiating server over a separate TCP connection.
>>>>
>>> Perhaps add a final sentence: "This separate TCP connection is then
>>> secured using a new round of TLS and/or SASL negotiation."
>>
>> Yes, that's good. Paragraph updated with your text.
>>
>>>> ###
>>>>
>>>>> - 4.8.3.18: what are the security implications of a "redirect"?
>>>>
>>>> Of<see-other-host/>? Seemingly underspecified. :(
>>>>
>>>>> Should
>>>>> the client apply the same policy, e.g. for using TLS, as for the
>>>>> original server?
>>>>
>>>> Yes.
>>>>
>>>>> Which "to" identity to use?
>>>>
>>>> The 'to' address of the initial stream header would still be the DNS=

>>>> domain name of the XMPP service to which the initiating entity is
>>>> trying
>>>> to connect (see also draft-saintandre-tls-server-id-check).
>>>>
>>>>> Can redirection occur
>>>>> before the recipient is even authenticated?
>>>>
>>>> Yes.
>>>>
>>>> I propose that we modify the description as follows:
>>>>
>>>>      The server will not provide service to the initiating entity
>>>> but is
>>>>      redirecting traffic to another host under the administrative
>>>> control
>>>>      of the same service provider.  The XML character data of the<se=
e-
>>>>      other-host/>   element returned by the server MUST specify the
>>>>      alternate hostname or IP address at which to connect, which
>>>> MUST be a
>>>>      valid domainpart or a domainpart plus port number (separated by=

>>>> the
>>>>      ':' character in the form "domainpart:port").  If the
>>>> domainpart is
>>>>      the same as the source domain, derived domain, or resolved IP
>>>> address
>>>>      to which the initiating entity originally connected (differing
>>>> only
>>>>      by the port number), then the initiating entity SHOULD simply
>>>> attempt
>>>>      to reconnect at that address.  Otherwise, the initiating entity=

>>>> MUST
>>>>      resolve the hostname specified in the<see-other-host/> =20
>>>> element as
>>>>      described under Section 3.2.
>>>>
>>>> I also propose that we add the following paragraph to the end of the=

>>>> section:
>>>>
>>>>      When negotiating a stream with the host to which it has been
>>>>      redirected, the initiating entity MUST apply the same policies =
it
>>>>      would have applied to the original connection attempt (e.g., a
>>>> policy
>>>>      requiring TLS), MUST specify the same 'to' address on the initi=
al
>>>>      stream header, and MUST verify the identity of the new host
>>>> using the
>>>>      same reference identifier(s) it would have used for the origina=
l
>>>>      connection attempt (in accordance with [TLS-CERTS].  Even if
>>>>      receiving entity returns a<see-other-host/>   error before the
>>>>      confidentiality and integrity of the stream have been establish=
ed
>>>>      (thus introducing the possibility of a denial of service
>>>> attack), the
>>>>      fact that the initiating entity needs to verify the identity of=

>>>> the
>>>>      XMPP service based on the same reference identifiers implies
>>>> that the
>>>>      initiating entity will not connect to a malicious entity;
>>>> however, to
>>>>      reduce the possibility of a denial of service attack, the
>>>> receiving
>>>>      entity SHOULD NOT return a<see-other-host/>   error until after=

>>>> the
>>>>      stream has been protected (e.g., via TLS).
>>>>
>>> ... and the sending entity SHOULD maintain a running redirect counter=
,
>>> and give up after a certain number of successive redirects.
>>>
>>> Also, the mitigation you propose in the last sentence only helps if "=
An
>>> entity MAY have a policy where it only accepts<see-other-host>  eleme=
nts
>>> from authenticated peers.
>>
>> Thanks. I propose that we change this paragraph to:
>>
>>     When negotiating a stream with the host to which it has been
>>     redirected, the initiating entity MUST apply the same policies it
>>     would have applied to the original connection attempt (e.g., a pol=
icy
>>     requiring TLS), MUST specify the same 'to' address on the initial
>>     stream header, and MUST verify the identity of the new host using =
the
>>     same reference identifier(s) it would have used for the original
>>     connection attempt (in accordance with [TLS-CERTS].  Even if
>>     receiving entity returns a<see-other-host/>  error before the
>>     confidentiality and integrity of the stream have been established
>>     (thus introducing the possibility of a denial of service attack), =
the
>>     fact that the initiating entity needs to verify the identity of th=
e
>>     XMPP service based on the same reference identifiers implies that =
the
>>     initiating entity will not connect to a malicious entity; however,=
 to
>>     reduce the possibility of a denial of service attack, the receivin=
g
>>     entity SHOULD NOT return a<see-other-host/>  error until after the=

>>     stream has been protected (e.g., via TLS) and the receiving entity=

>>     MAY have a policy of following redirects only if it has authentica=
ted
>>     the receiving entity.  In addition, the initiating entity SHOULD g=
ive
>>     up after a certain number of successive redirects (e.g., at least =
2
>>     but no more than 5).
>>
>>>>> - 4.9: Don't we resend the "stream" header again after completing t=
he
>>>>> TLS negotiation (Sec. 4.2.3).
>>>>
>>>> For sure. I propose that we change this:
>>>>
>>>>      [ ... channel encryption ... ]
>>>>
>>>>      [ ... authentication ... ]
>>>>
>>>>      [ ... resource binding ... ]
>>>>
>>>> to:
>>>>
>>>>      [ ... stream negotiation ... ]
>>>>
>>> I'm not sure. Since we start the example with two<stream>  elements, =
it
>>> would make sense to show the additional (4?)<stream>  elements furthe=
r
>>> down. Although the "simple" examples would no longer fit a page. Mayb=
e
>>> add a "really simple" example with no security?
>>
>> These examples are included to provide a high-level illustration of wh=
at
>> a session would look like, so I think eliding the whole stream
>> negotiation process is fine. However, I think it would be good to add =
a
>> forward reference to Section 9 so that the reader knows where to go fo=
r
>> detailed examples. Thus propose modifying the first paragraph of Secti=
on
>> 4.9 as follows:
>>
>>     This section contains two highly simplified examples of a stream-
>>     based connection between a client and a server; these examples are=

>>     included for the purpose of illustrating the concepts introduced t=
hus
>>     far, but the reader needs to be aware that these examples elide ma=
ny
>>     details (see Section 9 for more complete examples).
>>
>> Peter
>>


--------------ms070706020401050000000805
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy
OTE0NDE1OVowIwYJKoZIhvcNAQkEMRYEFOkp6poJSR1NW9ULPlUd/3SzVhCXMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQAGavQt5vtkxiEIfVK+55FPFk4XT7e7zzRW2HhaZEpR6Fgm+/foIjAAK/7H
in6aEQkFGLGpL4HQqlVa+uZHXrYL6O9RY6VDBVUi9jC5qobwoRA1BVMCCb2oK822hWYfkOsD
tvERWLv/LHvlyQj5UOsulrIo1BfPh7S9dMoyUSIqmKzfmeNbc0+M5YaXn1duW2QztqWluVuy
/xTD3VshHY9JSV88RRoqni6W5PjQtQFuEJ1vuJf/xRZVEyTbL772+WGdkt5TZCweKFaEcNru
XHVwsHaRBOCIkzjgedxR/Qt6r6xaKJzfS8MC5UvCJuySL3F7PSDqrFyw9fUN06M7/gntAAAA
AAAA
--------------ms070706020401050000000805--

From stpeter@stpeter.im  Fri Oct 29 11:30:33 2010
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 4B7793A6A4E; Fri, 29 Oct 2010 11:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.593
X-Spam-Level: 
X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, 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 0oGs961vXcsF; Fri, 29 Oct 2010 11:30:28 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 72E713A6A43; Fri, 29 Oct 2010 11:30:28 -0700 (PDT)
Received: from squire.local (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1523140BB9; Fri, 29 Oct 2010 12:40:36 -0600 (MDT)
Message-ID: <4CCB1334.3030203@stpeter.im>
Date: Fri, 29 Oct 2010 12:32:20 -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="------------ms020301030306050504050409"
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: Fri, 29 Oct 2010 18:30:33 -0000

This is a cryptographically signed message in MIME format.

--------------ms020301030306050504050409
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

This is Part 2 of my reply, from the start of Section 5 through the end
of Section 9. I should be able to address the remainder (Section 10
through Section 15) in Part 3.

On 10/28/10 4:28 AM, Yaron Sheffer wrote:

> - 5.3.5: the text mentions that client certificates are "sufficiently
> rare", which is a pity because they do make sense for server-to-server
> interaction. So I suggest to promote renegotiation from OPTIONAL to
> RECOMMENDED.

A bit of background: by client certificates we mean end-user
certificates (XMPP client, not TLS client). PKIX certificates are more
common for XMPP servers, but unfortunately they are still far from
ubiquitous. The XMPP Standards Foundation even ran an intermediate CA
for a few years (under the StartCom root) to help seed the network,
which helped us work out bugs in many codebases but still didn't result
in wide adoption. Many service admins still think that PKI is "too hard"
or "too expensive" (despite the fact that our ICA gave out free
certificates, and StartCom continues to do so).

The XMPP WG had a discussion about TLS renegotiation, starting here:

http://www.ietf.org/mail-archive/web/xmpp/current/msg01146.html

At one point we banned TLS renegotiation entirely, then we weighed the
benefits and the costs (including code complexity) and concluded that it
was appropriate to make support strictly optional in XMPP, given how
rarely it would be needed. Simon Josefsson suggested during the WG
discussion that we document our reasons, which we've done in Section
5.3.5. If you do not find those reasons compelling, the WG needs to
either explain itself more clearly or realize that it is wrong. :)

> - 5.3.6: extensions may be out of scope. But I think we need to include=

> a few words re: the TLS version, at least to prohibit SSL 3.0.

In fact, discussions within the XMPP WG are what led to this:

https://datatracker.ietf.org/doc/draft-ietf-tls-ssl2-must-not/

However, it seems there is not yet consensus to prohibit SSL 3.0 in the
TLS WG. Are you suggesting that the XMPP WG go where the TLS WG has not
gone?

> - 5.4.1: don't you have to declare version >=3D 1.0 if you simply suppo=
rt
> this draft? Same question in 6.4.1.

Yes. The mentions in 5.4.1 and 6.4.1 are artifacts of RFC 3920, when the
'version' attribute was new. I've removed those clauses in both sections.=


> - 5.4.3.1: why is the initiator required to present a certificate "So
> that mutual authentication will be possible"? There are many other ways=

> of ensuring mutual auth. I suggest to reword as "mutual certificate
> authentication".

Done.

> - Global replace TLS "cipher" -> "ciphersuite".

Done.

> - 5.4.3.1, bullet 5: actually, based on the "from" attribute that the
> receiving entity has just sent.

You refer to this text:

   5.  The receiving entity SHOULD choose which certificate to present
       based on the 'to' attribute of the initial stream header.

I'm not quite sure about your recommendation. Practically speaking I
think it doesn't make a difference, because the two will be the same
unless the receiving entity does not service the domainpart specified by
the initiating entity (in which case the parties won't end up
negotiating TLS anyway, since the receiving entity will close the
stream). However, the 'to' address of the initial stream header seems
like a "purer" indication of the initiating entity's "reference
identifier" (in the language of [TLS-CERTS]).

> - 5.4.3.3: where do we say that both sides must validate the "to" and
> "from" identities in view of the identities presented at the TLS layer
> (if any)?

Section 13.7.2 ("Certificate Validation"). There is a forward reference
in bullet 4 of Section 5.4.3.3:

   4.  The initiating entity MUST validate the certificate to determine
       if the TLS negotiation will succeed; see Section 13.7.2 regarding
       certificate validation procedures.

Perhaps it would be easier to read if we switched bullets 4 and 5 in
that section?

Also, the bullet about validation probably also needs to say that if the
initiating entity presents a certificate then the receiving entity needs
to also perform validation. Do you agree?

> - 6.3.2: do you restart the stream twice, once after TLS and once after=

> SASL??

Yes. We defined it that way in RFC 3920 because it was our understanding
of TLS and SASL that we needed to flush the previous security context in
both cases because either one of those technologies might result in
negotiation of a security layer. If we were defining things anew at this
point, we would probably remove the stream restarts, but I think it's
probably too late to do that now. (Perhaps that will be part of our work
on "quick reconnect" or streamlined stream negotiation.)

> - 6.3.3: shouldn't we simply "MUST NOT" the PLAIN mechanism?

Yes. Done.

> - 6.3.7: and what is the identity used for server-to-server auth? Also,=

> it is very uncommon to consider the password as part of the identity.

I think we acquired this notion from a misreading of RFC 4422. Looking
at that specification again, I see that it refers to "credentials" as
consisting (in some SASL mechanisms) of a simple username / password,
whereas the authentication identity would be the simple username. I
propose modifying the offending paragraph as follows:

   Some SASL mechanisms (e.g., CRAM-MD5, DIGEST-MD5, and SCRAM) specify
   that the authentication identity used in the context of such
   mechanisms is a "simple user name" (see Section 2 of [SASL] as well
   as [SASLPREP]).  The exact form of the simple user name in any
   particular mechanism or deployment thereof is a local matter, and a
   simple user name does not necessarily map to an application
   identifier such as a JID or JID component (e.g., a localpart).
   However, in the absence of local information provided by the server,
   an XMPP client SHOULD assume that the authentication identity for
   such a SASL mechanism is a simple user name equal to the localpart of
   the user's JID.

> - 6.4.4: isn't it inconsistent that SASL aborts are converted into XMPP=

> failures, but TLS failures are not?

I don't think so. TLS is a layer unto itself, and the STARTTLS feature
in XMPP is merely a way of triggering the underlying TLS negotiation (we
don't represent all the TLS bits in XMPP syntax). By contrast, there is
no special SASL layer to invoke, so all of the protocol bits to
negotiate SASL happen using XMPP syntax.

> - 7.7.2.2: the preferred option #1, while reasonable in itself, does no=
t
> allow the client to determine its own policy (whether it wants multiple=

> sessions from multiple devices or not).

If the client wants multiple sessions from multiple devices, it can
generate a unique resourcepart for each device or ask the server to do
so on its behalf.

> - 8.1.1.2: any validated domain -> any validated subdomain.

We've gone through some effort to scrub the term "subdomain" from the
spec (you'll notice it was used more frequently in RFC 3920) because of
ambiguities surrounding that term. This is connected to the common XMPP
practice of server-side components that offer services in addition to or
on top of the core XMPP router. Consider an XMPP service whose canonical
DNS domain name is "im.example.com"; that service might offer add-on
services such as groupchat rooms (say, "rooms.example.com") and
publish-subscribe (say, "pubsub.example.com"). Nothing says that such
add-on services need to be subdomains of the canonical DNS domain name
for the service, but RFC 3920 implied such a necessity, leading to
confusion among server developers and service administrators.

> - 8.3.1, rule #2: if the error is a result of something gone bad with
> the addresses, then simply swapping "to" and "from" may not be
> appropriate, and may even be a security issue.

I suppose that is possible. I propose modifying the rule as follows:

   2.  The error stanza SHOULD simply swap the 'from' and 'to' addresses
       from the generated stanza, unless doing so would result in an
       information leak (see under Section 13.10) or other breach of
       security.

> - Same, rule #6, the recipient MUST NOT include the original XML if it'=
s
> not well formed, right?

True. Or if it is otherwise harmful. I propose modifying the rule as
follows:

   6.  The entity that returns an error stanza MAY include the original
       XML sent so that the sender can inspect and, if necessary,
       correct the XML before attempting to resend (however, this is a
       courtesy only and the originating entity MUST NOT depend on
       receiving the original payload); naturally, the entity MUST NOT
       include the original data if it not well-formed XML, violates the
       XML restrictions of XMPP (see under Section 11.1, or is otherwise
       harmful (e.g, exceeds a size limit).

> - 8.3.2: MUST NOT... be presented to the human user - this is impossibl=
e
> to enforce, and most likely will not be followed. Moreover, there's a
> reason why we include a language tag. I suggest to tone it down a bit.

I suppose SHOULD NOT is fine. The error message shown to the user is
supposed to be based on the defined condition, not some random text
placed in the <text/> element (even if language-tagged).

> - 8.3.3.11: what are "improper credentials"? It sounds like we are not
> differentiating the conditions of authentication failure vs.
> authorization failure.

As an example, if a client attempts to join a password-protected
chatroom without providing a password, the chatroom service will return
a <not-authorized/> stanza error. It will return the same error if the
client attempts to join a password-protected chatroom but provides the
wrong password. Is there a need to differentiate between these two cases?=


> - 8.3.3.14: the "security note" doesn't makes sense to me - no matter
> what error code is returned, the sender has gained information that we
> don't want to provide. The note should say something along the lines of=
:
> such services must not be available to entities that cannot be trusted
> with knowing the status of an arbitrary recipient. See also 8.3.3.20.

It's not necessarily true that the sender has gained information that we
don't want to provide. In RFC 3920 (and 3920bis), we have the concept of
presence subscriptions. If the sender is authorized to know the
recipient's network availability (via presence subscription), then it is
perfectly legitimate for the recipient's server to tell the sender that
the recipient is now offline. Perhaps a reference to 3920bis would clear
this up. I propose modifying the note as follows:

      Security Note: An application MUST NOT return this error if doing
      so would provide information about the intended recipient's
      network availability to an entity that is not authorized to know
      such information (for details, refer to the discussion of presence
      subscriptions in [XMPP-IM]); instead it MUST return a <service-
      unavailable/> stanza error.

> - 8.3.3.15: Are there no security implications to redirection at the
> stanza level?

Good point, there certainly might be. If the sender is attempting to
join a chatroom at rooms.example.com and the service redirects the
request to conference.example.net, the client might want to ask the
sender if the redirect is acceptable before proceeding (e.g., because
the redirected service might have different security policies). I
propose adding the following security note:

      Security Note: An application receiving a stanza-level redirect
      SHOULD warn a human user of the redirection attempt and request
      approval before proceeding to communicated with the entity whose
      URI or IRI is contained in the XML character data of the
      <redirect/> element, because that entity might have a different
      identity or might enforce different security policies.  However,
      the end-to-end authentication or signing of XMPP stanzas could
      help to mitigate this risk, since it would enable the sender to
      determine if the entity to which it has been redirected has the
      same identity as the entity it originally attempted to contact.

> - 8.3.3.18: The "wait" error type might not be appropriate for some
> situations, e.g. authentication issues.

True. I propose changing it to:

   A remote server or service specified as part or all of the JID of the
   intended recipient (or needed to fulfill a request) was resolved but
   communications could not be established within a reasonable amount of
   time (e.g., an XML stream cannot be established at the resolved IP
   address and port, or an XML stream can be established but stream
   negotiation fails because of problems with TLS, SASL, Server
   Dialback, etc.); the associated error type SHOULD be "wait" (unless
   the error is of a more permanent nature, e.g., the remote server is
   found but it cannot be authenticated or it violates security
   policies).

> - 8.3.3.21: do you explain anywhere what is the difference between
> "prior registration" and "prior subscription"?

That's really an issue for various XMPP applications. One such
application is IM and presence (3920bis), where we have the concept of
subscriptions. Another application in which we have subscriptions is
publish-subscribe <http://xmpp.org/extensions/xep-0060.html>. An example
of registration can be found in the multi-user chat extension
<http://xmpp.org/extensions/xep-0045.html> or in the older "gateway"
that we used to maintain for connecting to legacy IM services. I don't
see much reason to describe all those differences in 3920bis, but we can
add a sentence or two about it if that would be helpful.

> - 9.1.1, step 7: this is utterly trivial, but please mention that the
> new "stream" element is sent over TLS.

Changed to:

   Step 7: If TLS negotiation is successful, client initiates a new
   stream to server over the TLS-protected TCP connection:

(also changed in 9.2.1)

> - 9.1.5: as I noted in Sec. 4.4, the TLS connection needs to be closed
> as well.

Changed in my working copy to:

   The client now sends a TLS close_notify alert, receives a responding
   close_notify alert from the server, and then terminates the
   underlying TCP connection.

(also in 9.2.5 with "Server1" and "Server2")

### END OF PART 2 ###



--------------ms020301030306050504050409
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAy
OTE4MzIyMFowIwYJKoZIhvcNAQkEMRYEFPMDdYGkp8bAc4uDkFJfyKjb1svXMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCKLoAdev++/e3RTFAi3luDajSMw1T0jXNT+S6b7+ZWTMX95IoSSfAOhADb
AHQ+c8tyzJcX7VxVgpmJGkSvZIqmD+4UkpNCmyC3V3NLujxQ3Q+z5loL487LXqp2A08xFwoC
+MHNN4Q//WwZBtXaRMiy/unDnuO13I2+GHKSArdDCeoyiM7LoyVK1qKC6UqRXhtfn/y0o5Rj
jKhK/9H+gi0YDrPp/q2APeb9VcfegEgLOJejXO2XYTr5ag1P38vKHb0I6wVBPqwv6P9i4+wb
Hvy6ZmV3CjuIvAFllIh6ytkJA2RJKIO+jyHPizkGFGP/2U8uUE+kqCiTxdOsEDHwaJVZAAAA
AAAA
--------------ms020301030306050504050409--

From stpeter@stpeter.im  Fri Oct 29 22:04:02 2010
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 a cryptographically signed message in MIME format.

--------------ms030901010109050600060007
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 preventio=
n?

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 i=
t
> has any normative status. Otherwise, it is almost trivial: of course yo=
u
> 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...=20

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 migh=
t
> 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 b=
y
> 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)?=20

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 o=
n
> 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?=20

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 th=
e
> 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

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




--------------ms030901010109050600060007
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTAz
MDA1MDU0NVowIwYJKoZIhvcNAQkEMRYEFD24OTmFQKG+8Sfy65eP5PcrkWVgMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCkh25fVhi1Lk15UEUY3Uij4B7L5EIoNKHT2NMFDhDAGcxScP6cYyqZiYzj
nC9kOZ4L4iKeOG786s5BovQWKRomVVhmwp/Yz9eVm/ij6sFH/wRIqNBZV4vOs2aGYGcH85F8
BQECi9YXmJJ4ARGKq5EXuteXeEv2/YeA8mEPvdqXxpAJ1Cl1LYI/NfqbyDa1M/urVtVT2uIT
d0RG7LVJTlDcuyv++zQbdFDgj/lfTQXAuSgcuK22/91Dwvpcr0gN7aHo/+d2q8AuB6PsFH/n
6Kk3gnXUJw5IjZbYc+L34WPEXNdCHn3cQs6GXsHLpU6dywrfHycAsT6THivjiI2UFxJaAAAA
AAAA
--------------ms030901010109050600060007--

From kathleen.moriarty@emc.com  Sat Oct 30 08:52:58 2010
Return-Path: <kathleen.moriarty@emc.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 690C03A6A1B; Sat, 30 Oct 2010 08:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.533
X-Spam-Level: 
X-Spam-Status: No, score=-5.533 tagged_above=-999 required=5 tests=[AWL=1.066,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 TkSj32aVzRue; Sat, 30 Oct 2010 08:52:48 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id 7E1503A68E3; Sat, 30 Oct 2010 08:52:48 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9UFsigJ006507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Oct 2010 11:54:44 -0400
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.221.251]) by hop04-l1d11-si04.isus.emc.com (RSA Interceptor); Sat, 30 Oct 2010 11:54:41 -0400
Received: from corpussmtp4.corp.emc.com (corpussmtp4.corp.emc.com [10.254.169.197]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id o9UFrwB3021894; Sat, 30 Oct 2010 11:53:59 -0400
Received: from mxhub06.corp.emc.com ([128.221.46.114]) by corpussmtp4.corp.emc.com with Microsoft SMTPSVC(6.0.3790.4675);  Sat, 30 Oct 2010 11:53:59 -0400
Received: from mx06a.corp.emc.com ([169.254.1.184]) by mxhub06.corp.emc.com ([128.221.46.114]) with mapi; Sat, 30 Oct 2010 11:53:58 -0400
From: <kathleen.moriarty@emc.com>
To: <iesg@ietf.org>, <secdir@ietf.org>, <boschie@tik.ee.ethz.ch>, <trammell@tik.ee.ethz.ch>
Date: Sat, 30 Oct 2010 11:53:47 -0400
Thread-Topic: SECDIR review of draft-ietf-ipfix-anon-05
Thread-Index: Act4SqEcJza7+doNQuO431YWCTqi3Q==
Message-ID: <AE31510960917D478171C79369B660FA0DABC627EA@MX06A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: GL+g LCDD U5Vq VZEb WGYv aewL b/Hy h7nK jEph mYoW nUdG prJU p+Ji s8s2 uzrM xzZo; 4; YgBvAHMAYwBoAGkAZQBAAHQAaQBrAC4AZQBlAC4AZQB0AGgAegAuAGMAaAA7AGkAZQBzAGcAQABpAGUAdABmAC4AbwByAGcAOwBzAGUAYwBkAGkAcgBAAGkAZQB0AGYALgBvAHIAZwA7AHQAcgBhAG0AbQBlAGwAbABAAHQAaQBrAC4AZQBlAC4AZQB0AGgAegAuAGMAaAA=; Sosha1_v1; 7; {1C4B36C8-AA8C-4717-8546-BB63A011BCD6}; awBhAHQAaABsAGUAZQBuAC4AbQBvAHIAaQBhAHIAdAB5AEAAZQBtAGMALgBjAG8AbQA=; Sat, 30 Oct 2010 15:53:47 GMT; UwBFAEMARABJAFIAIAByAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGkAZQB0AGYALQBpAHAAZgBpAHgALQBhAG4AbwBuAC0AMAA1AA==
x-cr-puzzleid: {1C4B36C8-AA8C-4717-8546-BB63A011BCD6}
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 30 Oct 2010 15:53:59.0032 (UTC) FILETIME=[AA4DA780:01CB784A]
X-EMM-MHVC: 1
X-Mailman-Approved-At: Mon, 01 Nov 2010 08:18:58 -0700
Subject: [secdir] SECDIR review of draft-ietf-ipfix-anon-05
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 15:52:58 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

General:
This document presents a mechanism for representing anonymized data within =
IPFIX [RFC5101] and guidelines for using it.  The document in general is we=
ll-written and no security issues were detected.  Adequate background infor=
mation is included in section 1 which aids in the overall readability of th=
e document.  Since the purpose of the document is to anonymize flow informa=
tion, it is itself a security function for the IPFIX protocol.

The document covers the range of fields that are recommended for anonymizat=
ion.  The draft contains adequate explanations as to how the fields might b=
e used to detect either the entities responsible for the flows or informati=
on about the hosts sending or receiving the flows.  The fields recommended =
for anonymization include the IP address, MAC address (can be used to const=
ruct IPv6 addresses or may be possible to trace a device to an entity), por=
t numbers (host OS identification techniques), timestamps and counters (can=
 reveal host behavior information).  Methods to anonymize each field are pr=
ovided in the draft, including the advantages of using some techniques for =
anonymization and remaining gaps if alternate techniques are selected.

The security section of the document further clarifies the purpose of this =
draft versus that of the existing IPFIX standards for confidentiality (not =
covered in this draft).  Encryption for confidentiality is covered in other=
 drafts such as using TLS for transport, this draft is specific to anonymiz=
ation.  The security section is adequate for this draft.

Note: While I majored in Math undergrad and actually enjoyed ring and field=
 theory, I could be missing something in the evaluation as it seems like th=
at was a long time ago!  I do not see any problems with the options present=
ed for anonymization as it appears to be quite thorough.


Detailed Comments:
Introduction:  Grammar nit:  2nd paragraph, anonymisable is not a word.  Ma=
ybe replace this with Anonymize as it still reads fine and I think has the =
same intent.



Nice job!

-Kathleen



From florob@babelmonkeys.de  Mon Nov  1 11:20:12 2010
Return-Path: <florob@babelmonkeys.de>
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 9E32428C0E5; Mon,  1 Nov 2010 11:20:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level: 
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6]
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 WkYpnJDRo5Cs; Mon,  1 Nov 2010 11:20:11 -0700 (PDT)
Received: from babelmonkeys.de (v64231.topnetworks.de [82.197.159.233]) by core3.amsl.com (Postfix) with ESMTP id 621D328C0E0; Mon,  1 Nov 2010 11:20:11 -0700 (PDT)
Received: from xdsl-213-196-247-51.netcologne.de ([213.196.247.51] helo=[192.168.0.38]) by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <florob@babelmonkeys.de>) id 1PCyzJ-0004My-N6; Mon, 01 Nov 2010 19:20:09 +0100
Message-ID: <4CCF04D3.6020504@babelmonkeys.de>
Date: Mon, 01 Nov 2010 19:20:03 +0100
From: Florian Zeitz <florob@babelmonkeys.de>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
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
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 01 Nov 2010 14:21:43 -0700
Cc: secdir@ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, draft-ietf-xmpp-3920bis.all@tools.ietf.org
Subject: Re: [secdir] [xmpp] 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 18:20:12 -0000

On 01.11.2010 10:25, Yaron Sheffer wrote:
> Hi Peter,
> 
> Responding to the last part. Thanks for a constructive discussion.
> 
>     Yaron
> 
Hi,

>>> - 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.
> 
FWIW, I'm not entirely content with that for two reasons:
a) Even if TLS+SASL PLAIN is not MTI people still will and do implement
it. I think it would therefore make sense to still specify that PLAIN
shall only be used as a "last resort".

b) (which is my bigger concern) As strange as that may sound, we need
PLAIN in order to upgrade to a new mechanism. I though this was also
explicit in 3920bis, but I can't find it right now.
Consider a case where a server only stores the MD5 hash of the password.
This is sufficient to do PLAIN and DIGEST MD5 auth. But for SCRAM a
different representation is needed.
The common way for the server to upgrade is to once offer only PLAIN as
a mechanism. If that is not possible (clients can choose not to support
PLAIN) some deployments might be stuck with DIGEST MD5...
We could mandate that PLAIN is only MTI for clients (servers would
implement it when they need to), but that would allow for the same
down-grade attacks that are already possible now (i.e. hopefully none ;) ).

--
Florian Zeitz

From stpeter@stpeter.im  Mon Nov  1 12:19:21 2010
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 1845128C111; Mon,  1 Nov 2010 12:19:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.999
X-Spam-Level: 
X-Spam-Status: No, score=-99.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 TAdhu6NjIiqb; Mon,  1 Nov 2010 12:19:19 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0AFAF28C119; Mon,  1 Nov 2010 12:19:15 -0700 (PDT)
Received: from squire.local (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A63AB40D1E; Mon,  1 Nov 2010 13:27:47 -0600 (MDT)
Message-ID: <4CCF12B2.3050902@stpeter.im>
Date: Mon, 01 Nov 2010 13:19:14 -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> <4CCB1334.3030203@stpeter.im> <4CCD8D2B.50900@gmail.com>
In-Reply-To: <4CCD8D2B.50900@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="------------ms050608020209070706030105"
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 19:19:21 -0000

This is a cryptographically signed message in MIME format.

--------------ms050608020209070706030105
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 10/31/10 9:37 AM, Yaron Sheffer wrote:
>=20
> On 10/29/2010 08:32 PM, Peter Saint-Andre wrote:
>> This is Part 2 of my reply, from the start of Section 5 through the en=
d
>> of Section 9. I should be able to address the remainder (Section 10
>> through Section 15) in Part 3.
>>
>> On 10/28/10 4:28 AM, Yaron Sheffer wrote:
>>
>>> - 5.3.5: the text mentions that client certificates are "sufficiently=

>>> rare", which is a pity because they do make sense for server-to-serve=
r
>>> interaction. So I suggest to promote renegotiation from OPTIONAL to
>>> RECOMMENDED.
>>
>> A bit of background: by client certificates we mean end-user
>> certificates (XMPP client, not TLS client). PKIX certificates are more=

>> common for XMPP servers, but unfortunately they are still far from
>> ubiquitous. The XMPP Standards Foundation even ran an intermediate CA
>> for a few years (under the StartCom root) to help seed the network,
>> which helped us work out bugs in many codebases but still didn't resul=
t
>> in wide adoption. Many service admins still think that PKI is "too har=
d"
>> or "too expensive" (despite the fact that our ICA gave out free
>> certificates, and StartCom continues to do so).
>>
>> The XMPP WG had a discussion about TLS renegotiation, starting here:
>>
>> http://www.ietf.org/mail-archive/web/xmpp/current/msg01146.html
>>
>> At one point we banned TLS renegotiation entirely, then we weighed the=

>> benefits and the costs (including code complexity) and concluded that =
it
>> was appropriate to make support strictly optional in XMPP, given how
>> rarely it would be needed. Simon Josefsson suggested during the WG
>> discussion that we document our reasons, which we've done in Section
>> 5.3.5. If you do not find those reasons compelling, the WG needs to
>> either explain itself more clearly or realize that it is wrong. :)
>>
> I accept your reasoning. And servers in most cases can take the risk of=

> information disclosure and still use mutual cert authentication.

One clarification.... In the case of a client-to-server ("c2s")
connection, it's the client that might leak its credentials to an
unauthenticated server at the TLS negotiation stage, so IMHO it's not
quite right to say that the server takes the risk of information
disclosure. In the server-to-server ("s2s") case, the initiating server
might leak its credentials. I don't think we're worried about the s2s
case, because the initiating server is the one that's asking to
"federate" the two domains in the first place. For the c2s case, so far
end-user certificates are rare enough that I think the sense of the WG
was to not make renegotiation a SHOULD. There are some deployment
scenarios in which end-user certificates are more common (think certain
military or financial organizations), but in general those deployments
might lock down the allowable clients and will probably deal with the
issue at the level of local service policy or a deployment profile
(i.e., both the client and the server must support TLS renegotiation),
so in that sense the risk of information disclosure is indeed accepted
by the application service provider or the organization in which such a
closed deployment occurs. However, those are specialized deployments and
we didn't see a need for TLS renegotiation in the general case.

>>> - 5.3.6: extensions may be out of scope. But I think we need to inclu=
de
>>> a few words re: the TLS version, at least to prohibit SSL 3.0.
>>
>> In fact, discussions within the XMPP WG are what led to this:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-tls-ssl2-must-not/
>>
>> However, it seems there is not yet consensus to prohibit SSL 3.0 in th=
e
>> TLS WG. Are you suggesting that the XMPP WG go where the TLS WG has no=
t
>> gone?
>=20
> I was assuming that XMPP has less legacy baggage than HTTP (i.e.
> browsers) and therefore prohibiting SSLv3 would be reasonable. If it
> isn't, forget it.

XMPP as an application protocol does have less baggage, but it uses all
the same TLS libraries and those tend to be driven by HTTP, so I don't
know if we can really push the envelope here, unfortunately.

>>> - 5.4.3.3: where do we say that both sides must validate the "to" and=

>>> "from" identities in view of the identities presented at the TLS laye=
r
>>> (if any)?
>>
>> Section 13.7.2 ("Certificate Validation"). There is a forward referenc=
e
>> in bullet 4 of Section 5.4.3.3:
>>
>>     4.  The initiating entity MUST validate the certificate to determi=
ne
>>         if the TLS negotiation will succeed; see Section 13.7.2 regard=
ing
>>         certificate validation procedures.
>>
>> Perhaps it would be easier to read if we switched bullets 4 and 5 in
>> that section?
>=20
> Yes, it makes sense to switch #4 and #5.=20

Done in my working copy.

> BTW, you meant 5.4.3.1.

Yep, sorry.

>> Also, the bullet about validation probably also needs to say that if t=
he
>> initiating entity presents a certificate then the receiving entity nee=
ds
>> to also perform validation. Do you agree?
>=20
> Yes, this is the basic case, of course it should be mentioned.

In my working copy the text now reads as follows (order changed, text
tweaked, bullet added)...

   4.  The receiving entity SHOULD choose which certificate to present
       based on the 'to' attribute of the initial stream header.

   5.  To determine if the TLS negotiation will succeed, the initiating
       entity MUST attempt to validate the receiving entity's
       certificate in accordance with the certificate validation
       procedures specified under Section 13.7.2.

   6.  If the initiating entity presents a certificate, the receiving
       entity too MUST attempt to validate the initiating entity's
       certificate in accordance with the certificate validation
       procedures specified under Section 13.7.2.

>>> - 7.7.2.2: the preferred option #1, while reasonable in itself, does =
not
>>> allow the client to determine its own policy (whether it wants multip=
le
>>> sessions from multiple devices or not).
>>
>> If the client wants multiple sessions from multiple devices, it can
>> generate a unique resourcepart for each device or ask the server to do=

>> so on its behalf.
>>
> But if the client prefers the old behavior (newest resource wins), it
> cannot have it. Anyway, I'm sure you have debated this point to death.

It's true that some legacy clients used the old behavior to kick the
existing resource, but we have better ways to do that now and the costs
outweighed the benefits (user complaints about not being able to stay
logged in, etc.). So yes it's been debated. :)

>>> - 8.3.2: MUST NOT... be presented to the human user - this is impossi=
ble
>>> to enforce, and most likely will not be followed. Moreover, there's a=

>>> reason why we include a language tag. I suggest to tone it down a bit=
=2E
>>
>> I suppose SHOULD NOT is fine. The error message shown to the user is
>> supposed to be based on the defined condition, not some random text
>> placed in the<text/>  element (even if language-tagged).
>=20
> Yes, SHOULD NOT would be BETTER...

Done.

>>> - 8.3.3.11: what are "improper credentials"? It sounds like we are no=
t
>>> differentiating the conditions of authentication failure vs.
>>> authorization failure.
>>
>> As an example, if a client attempts to join a password-protected
>> chatroom without providing a password, the chatroom service will retur=
n
>> a<not-authorized/>  stanza error. It will return the same error if the=

>> client attempts to join a password-protected chatroom but provides the=

>> wrong password. Is there a need to differentiate between these two cas=
es?
>>
> What triggered my comment was the name of this element, "not
> authorized".=20

We inherited that from HTTP 401 "Unauthorized".

> Both of your examples are (broadly speaking), "not
> authenticated". What about the same service, where I am duly
> authenticated as Yaron, but still am not allowed to use the service,
> e.g. because only users belonging to the all-saints group are allowed t=
o
> it. This would be a true authorization failure.

Sure. Sticking with the example of multi-user chat rooms, a room admin
has privileges to perform certain actions (say, kick people out of the
room); if a non-privileged user attempts to perform such an action, the
service will return a <forbidden/> error. Perhaps we don't have a very
sophisticated authorization model in XMPP, but we've not yet found the
need for error conditions that are strictly limited to authorization.

>>> - 8.3.3.21: do you explain anywhere what is the difference between
>>> "prior registration" and "prior subscription"?
>>
>> That's really an issue for various XMPP applications. One such
>> application is IM and presence (3920bis), where we have the concept of=

>> subscriptions. Another application in which we have subscriptions is
>> publish-subscribe<http://xmpp.org/extensions/xep-0060.html>. An exampl=
e
>> of registration can be found in the multi-user chat extension
>> <http://xmpp.org/extensions/xep-0045.html>  or in the older "gateway"
>> that we used to maintain for connecting to legacy IM services. I don't=

>> see much reason to describe all those differences in 3920bis, but we c=
an
>> add a sentence or two about it if that would be helpful.
>>
> I would appreciate a pointer to benefit the uninitiated.

Adjusted text:

###

8.3.3.16.  registration-required

   The requesting entity is not authorized to access the requested
   service because prior registration is necessary (examples of prior
   registration include members-only rooms in XMPP multi-user chat
   [XEP-0045] and gateways to non-XMPP instant messaging services, which
   traditionally required registration in order to use the gateway
   [XEP-0100]); the associated error type SHOULD be "auth".

###

8.3.3.21.  subscription-required

   The requesting entity is not authorized to access the requested
   service because a prior subscription is necessary (examples of prior
   subscription include authorization to receive presence information as
   defined in [XMPP-IM] and opt-in data feeds for XMPP publish-subscribe
   as defined in [XEP-0060]); the associated error type SHOULD be
   "auth".

###

Better?

Peter

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




--------------ms050608020209070706030105
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MTE5MTkxNFowIwYJKoZIhvcNAQkEMRYEFF9ZqqVo29yHfiDsYPtEwje01QwNMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBobNBU1VFqpyXzyxaF1qasGmECibGI4t6aCMOTp8g3MZZSOVk2QF6y74Ik
P18z8KuNcRZs2Nsmsh1AmWaQNi5hS5ebL4gu6hFnHpzH6k8raW3qXmKwc1THfVw9ZUtN1Axf
0NuNxUbXdinCademkQuHQG0xB/OQjoiUZ52j/TOHntdNSMsSAMvt7sd8z7w9DCJ16Zg8ZZjh
NqYOy2K9w5qkCcBy4joqHy8Ij1ttmsvJUINtYmrJDPz21SZ/VO5+Di0IA4olThVpIk2KOnBK
5b8WPCRPc8lReVC7f8y2kozof5z3GzCV4Uv8mVJ245L1Fr3M+oJk4uCKT2IsRGTD/ZYrAAAA
AAAA
--------------ms050608020209070706030105--

From stpeter@stpeter.im  Mon Nov  1 13:19:59 2010
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

This is a cryptographically signed message in MIME format.

--------------ms050702010806010901070107
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/1/10 3:25 AM, Yaron Sheffer wrote:
> Hi Peter,
>=20
> 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 e=
nd
>> 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 few=
er
>>> 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 a=
n
>> 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?
>=20
> 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 serv=
er,
>>> 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 (an=
d
>>> 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.
>=20
> 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 a=
nd
>>     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 wit=
h
>> regard to SASL. The use of SASL EXTERNAL with PKIX certificates enable=
s
>> 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.=
=2E.

>>> - 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 th=
at
>>     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 PKC=
S
>>     #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 o=
n
>> 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 c=
an
>>> 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 us=
e
>> 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 M=
UST
>>         NOT contain a basicConstraints extension with the cA boolean s=
et
>>         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 clie=
nt)
>>> 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 wer=
e
>> 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 securit=
y
>>> theater, because 99.5% of your target population cannot understand th=
is
>>> 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 o=
f
>> security software...
>=20
> 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 simpl=
y
>>> fail validation at this point, subject to their policy. I.e., some mi=
ght
>>> 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 mat=
ch
>>        one of the configured hostnames of the server; the server MUST =
NOT
>>        use the represented JID (if any) as the validated identity of t=
he
>>        client but instead MUST validate the identity of the client usi=
ng
>>        other means.  If the identity cannot be so validated, depending=
 on
>>        local service policy the server MAY abort the validation proces=
s
>>        and terminate the TLS negotiation.
>>
> Yes.

Done.

>>> - 13.7.2.3: "periodically query OCSP" - is there any guidance about t=
he
>>> 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 nextUpdat=
e
>> 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 t=
he
>>>  From line (when setting up the original stream and/or when setting t=
he
>>> 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' addres=
s
>> it communicates in the initial stream header, and the receiving entity=

>> sets its reference identifier to the 'from' address communicated by th=
e
>> initiating entity in the initial stream header (i.e., the 'from' addre=
ss
>> 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., thi=
s
>>        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=
=2E
>>
>>     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-implemen=
t
>> 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 SAS=
L
>>> 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 th=
e
>>> 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 i=
t
>>> 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
>=20
>>> 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, bu=
t
>>> 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 SA=
SL.
> - 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 TL=
S
> 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

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




--------------ms050702010806010901070107
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MTIwMTk1MVowIwYJKoZIhvcNAQkEMRYEFEM7pmkqbdoF5UQjhDRWd8a7rbG4MF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCF/nvf7AeGrOxu/UXYACT6Tg0IUfRNCO9O5CXomh+u4+ftC/5IeThDn7Uy
spzNc0AdWZXHlbPaGFugMmBGQb3HqmnW3Lisk3Jxu317WcA7NVWVwthwJseczAyLDgG13Lc4
kYeBihuIXXfYYXHb37e7wCqjK0RgQit8Krnx5MEW1nfHvSmc6VovPs79FRKHtzJcmfiQVcPJ
0mL0fotcdNoFFum+dlh7D2VRe9FNdF9oVeB6+cWVDFb2fIuB2D8Y9FJ9vd/WSdSB+LW7rtnu
Qij3EvP8NzMfh2rcdhpQay7oGWqYEHA+D3zTK/B40iQcmvJBGcFsjHMfb239i+oa7oaxAAAA
AAAA
--------------ms050702010806010901070107--

From stpeter@stpeter.im  Mon Nov  1 13:27:05 2010
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 508B13A69A7; Mon,  1 Nov 2010 13:27:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.233
X-Spam-Level: 
X-Spam-Status: No, score=-101.233 tagged_above=-999 required=5 tests=[AWL=0.767, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 gT9dkr6SpaVV; Mon,  1 Nov 2010 13:27:04 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4422E3A681E; Mon,  1 Nov 2010 13:27:04 -0700 (PDT)
Received: from squire.local (unknown [64.101.72.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 77B8740D1E; Mon,  1 Nov 2010 14:35:37 -0600 (MDT)
Message-ID: <4CCF2298.9030302@stpeter.im>
Date: Mon, 01 Nov 2010 14:27:04 -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: Florian Zeitz <florob@babelmonkeys.de>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de>
In-Reply-To: <4CCF04D3.6020504@babelmonkeys.de>
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="------------ms080703010400030906010709"
X-Mailman-Approved-At: Mon, 01 Nov 2010 14:21:43 -0700
Cc: secdir@ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, draft-ietf-xmpp-3920bis.all@tools.ietf.org
Subject: Re: [secdir] [xmpp] 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:27:05 -0000

This is a cryptographically signed message in MIME format.

--------------ms080703010400030906010709
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/1/10 12:20 PM, Florian Zeitz wrote:
> On 01.11.2010 10:25, Yaron Sheffer wrote:
>>
>>>> - 15: if we insist on PLAIN, I would expect a security-mti-auth-orde=
r
>>>> feature, where the proposals are ordered right (i.e. with PLAIN at t=
he
>>>> end).
>>>
>>> I think it's better to remove TLS plus SASL PLAIN from the list of
>>> mandatory-to-implement technologies.
>>>
>> OK.
>>
> FWIW, I'm not entirely content with that for two reasons:
> a) Even if TLS+SASL PLAIN is not MTI people still will and do implement=

> it. I think it would therefore make sense to still specify that PLAIN
> shall only be used as a "last resort".

I think that's what we were trying to say in the text, but we didn't do
a good job of it.

> b) (which is my bigger concern) As strange as that may sound, we need
> PLAIN in order to upgrade to a new mechanism. I though this was also
> explicit in 3920bis, but I can't find it right now.
> Consider a case where a server only stores the MD5 hash of the password=
=2E
> This is sufficient to do PLAIN and DIGEST MD5 auth. But for SCRAM a
> different representation is needed.
> The common way for the server to upgrade is to once offer only PLAIN as=

> a mechanism. If that is not possible (clients can choose not to support=

> PLAIN) some deployments might be stuck with DIGEST MD5...
> We could mandate that PLAIN is only MTI for clients (servers would
> implement it when they need to), but that would allow for the same
> down-grade attacks that are already possible now (i.e. hopefully none ;=
) ).

I had forgotten about that use case, so thanks for the reminder.

Sometime in the next 24-48 hours I'll propose rewritten text about MTI
technologies, including TLS + SASL PLAIN. However it requires careful
crafting and unfortunately I don't have time to do that right now.

Peter

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




--------------ms080703010400030906010709
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MTIwMjcwNFowIwYJKoZIhvcNAQkEMRYEFLqpBxvmhhmr0tLPYa32pmxbSldrMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQAiQ1z620XkMSrVD1nk8a76cj9YvFlmB76tbqO2j9+KIJbNFQaVRDlayUbG
ay7ac++XKxC7fSIGCFfjP3ap3FVtXdjEIGum/wuRtupVg7f4sHNLhY49uV5DrnzsS6ZSjb62
SSB0sLGZdi/7HQvo5n3jdRrRvTy70YlfnMh3v8CScwvhawKWtcNppoBt+/1lMTlJnt1DreDv
DctnJfyF4p91s6CI3CjO+z9HnYoL4V545mNc/eSaH1elcwwIK1KcTMNJH0ksx2w+tZYEQMv8
Qni0ELiuZ7Omv76RtcvlYWSqH2tHV5tN1DQOFTl9iO3+D4JMwfix4Z39zekg4rgCjq0iAAAA
AAAA
--------------ms080703010400030906010709--

From dave@cridland.net  Mon Nov  1 13:57:48 2010
Return-Path: <dave@cridland.net>
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 5173F3A6A87; Mon,  1 Nov 2010 13:57:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
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 h3xSuhOuJ7hs; Mon,  1 Nov 2010 13:57:43 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 00C163A6A7C; Mon,  1 Nov 2010 13:57:26 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id AE5AB11680F3; Mon,  1 Nov 2010 20:57:27 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3EOk5vaL05W; Mon,  1 Nov 2010 20:57:23 +0000 (GMT)
Received: from puncture (unknown [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 55DD511680CA; Mon,  1 Nov 2010 20:57:23 +0000 (GMT)
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de>
In-Reply-To: <4CCF04D3.6020504@babelmonkeys.de>
MIME-Version: 1.0
Message-Id: <2761.1288645043.347835@puncture>
Date: Mon, 01 Nov 2010 20:57:23 +0000
From: Dave Cridland <dave@cridland.net>
To: Florian Zeitz <florob@babelmonkeys.de>, Yaron Sheffer <yaronf.ietf@gmail.com>, Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>,  Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed"
X-Mailman-Approved-At: Mon, 01 Nov 2010 14:21:43 -0700
Subject: Re: [secdir] [xmpp] 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:57:48 -0000

On Mon Nov  1 18:20:03 2010, Florian Zeitz wrote:
> >> I think it's better to remove TLS plus SASL PLAIN from the list  
> of
> >> mandatory-to-implement technologies.
> >>
> > OK.
> >
> FWIW, I'm not entirely content with that for two reasons:

I'll scrap yours, and add a third.


> a) Even if TLS+SASL PLAIN is not MTI people still will and do  
> implement
> it. I think it would therefore make sense to still specify that  
> PLAIN
> shall only be used as a "last resort".
> 
> 
I think SASL PLAIN should be specifying this. There's nothing special  
in XMPP which makes PLAIN a poor choice.


> b) (which is my bigger concern) As strange as that may sound, we  
> need
> PLAIN in order to upgrade to a new mechanism. I though this was also
> explicit in 3920bis, but I can't find it right now.
> Consider a case where a server only stores the MD5 hash of the  
> password.
> This is sufficient to do PLAIN and DIGEST MD5 auth. But for SCRAM a
> different representation is needed.
> The common way for the server to upgrade is to once offer only  
> PLAIN as
> a mechanism. If that is not possible (clients can choose not to  
> support
> PLAIN) some deployments might be stuck with DIGEST MD5...
> We could mandate that PLAIN is only MTI for clients (servers would
> implement it when they need to), but that would allow for the same
> down-grade attacks that are already possible now (i.e. hopefully  
> none ;) ).

You're thinking of transition-needed, which was IIRC removed from the  
bis drafts.

It's pretty scary itself, as it provides an easy path to a downgrade  
attack.

But here's another compelling (in my view) reason to keep PLAIN,  
quoted from the opening lines of RFC 4616:

   Clear-text, multiple-use passwords are simple, interoperate with
   almost all existing operating system authentication databases

In particular, where we use an Active Directory, or other third-party  
LDAP directory, we more or less have to drop down to only offering  
PLAIN. (With AD we can also offer GSSAPI sometimes, but this isn't an  
ideal choice for an MTI, and with any LDAP directory we could provide  
SCRAM secrets to some extent).

Requiring clients and servers to be capable of using PLAIN, whilst  
advising (and providing) better alternatives to cover other cases,  
seems to be the best choice for interoperability.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From new-work-bounces@ietf.org  Mon Nov  1 14:05:46 2010
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C39DE3A6A7A; Mon,  1 Nov 2010 14:05:46 -0700 (PDT)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id D4B3C3A67B2; Mon,  1 Nov 2010 14:05:45 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org 
Mime-Version: 1.0
Message-Id: <20101101210545.D4B3C3A67B2@core3.amsl.com>
Date: Mon,  1 Nov 2010 14:05:45 -0700 (PDT)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Mon, 01 Nov 2010 14:21:43 -0700
Subject: [secdir] [new-work] WG Review: FTP Extensions, 2nd edition (ftpext2)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
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 21:05:46 -0000

A new IETF working group has been proposed in the Applications Area.  The
IESG has not made any determination as yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday,
November 9, 2010                           

FTP Extensions, 2nd edition (ftpext2)
------------------------------------------
Current Status: Proposed Working Group 
Last updated: 2010-10-28

Chair(s): 
 TBD

Applications Area Directors:
  Alexey Melnikov <alexey.melnikov@isode.com>
  Peter Saint-Andre <stpeter@stpeter.im>

Applications Area Advisor:
  Alexey Melnikov <alexey.melnikov@isode.com>

Mailing Lists:
 General Discussion: ftpext@ietf.org
 To subscribe: https://www.ietf.org/mailman/listinfo/ftpext
 Archive: http://www.ietf.org/mail-archive/web/ftpext/

Description of Working Group:

The Standard File Transfer Protocol specification in RFC 959
has been updated several times with command extensions of one
sort or another, including those based on the extension
mechanism of RFC 2389 (a complete list appears in RFC 5797 and
the corresponding IANA registry at
http://www.iana.org/assignments/ftp-commands-extensions).

The following are active FTP related drafts:

  draft-bryan-ftp-hash
  draft-hethmon-mcmurray-ftp-hosts
  FTP extensions to support IPv4/IPv6 translation scenario
  draft-klensin-ftp-typeu-00 - FTP Extension for Internationalized Text

The Working Group will:
* Review and finalize drafts listed above.
* Review and confirm or reject errata of current FTP RFCs.
* Investigate the differences between FTP in theory
 (current RFCs) and practice, and recommend future work to align them.
 Any future work would require rechartering of the WG.

The Working Group's specification deliverables are:
* A document that specifies the HOST command (Proposed Standard).
* A document that specifies the HASH command (Proposed Standard).
* A document that specifies FTP extensions to support IPv4/IPv6
translation scenario.
* A document that specifies FTP extensions for Internationalized Text.

The Working Group must not introduce a new version of FTP, e.g.
an incompatible FTP 2.0.

Goals and Milestones:
Nov 2010  Submit 'File Transfer Protocol HOST Command for Virtual
         Hosts' as working group item (draft-hethmon-mcmurray-ftp-hosts 
         will be used as a starting point)
Nov 2010  Submit 'File Transfer Protocol HASH Command for
         Cryptographic Hashes' as working group item (draft-bryan-ftp-
         hash will be used as a starting point)
Nov 2010  Submit 'FTP extensions to support IPv4/IPv6 translation'
         as working group item (draft-liu-ftp64-extension will be used 
         as a starting point)
Dec 2010  Working group Last Call of HOST document
Jan 2011  Submit 'File Transfer Protocol HOST Command for Virtual
         Hosts' to the IESG for consideration as a Proposed Standard
Jan 2011  Working group Last Call of HASH document
Feb 2011  Submit 'File Transfer Protocol HASH Command for
         Cryptographic Hashes' to the IESG for consideration as a 
         Proposed Standard
Mar 2011  Working group Last Call of 'FTP extensions to support
         IPv4/IPv6 translation' document
Apr 2011  Submit 'FTP Extension for Internationalized Text'
         as working group item
May 2011  Submit 'FTP extensions to support IPv4/IPv6 translation'
         to the IESG for consideration as Proposed Standard
Jul 2011  Working group Last Call of 'FTP Extension for 
         Internationalized Text'
Aug 2011  Submit 'FTP Extension for Internationalized Text'
         to the IESG for consideration as Proposed Standard
Sep 2011  Close or recharter
_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From new-work-bounces@ietf.org  Mon Nov  1 14:13:05 2010
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B095A3A6A83; Mon,  1 Nov 2010 14:13:05 -0700 (PDT)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 42EAE3A6A84; Mon,  1 Nov 2010 14:13:03 -0700 (PDT)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org 
Mime-Version: 1.0
Message-Id: <20101101211304.42EAE3A6A84@core3.amsl.com>
Date: Mon,  1 Nov 2010 14:13:04 -0700 (PDT)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Mon, 01 Nov 2010 14:21:43 -0700
Subject: [secdir] [new-work] WG Review: Uniform Resource Names, Revised (urnbis)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
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 21:13:05 -0000

A new IETF working group has been proposed in the Applications Area.  The
IESG has not made any determination as yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday,
November 9, 2010                           

Uniform Resource Names, Revised (urnbis) 
--------------------------------
Last Modified:  2010-10-28
Current Status: Proposed Working Group

  Chair(s):
    o   TBD

  Applications Area Director(s):
    o   Alexey Melnikov  <alexey.melnikov at isode.com>
    o   Peter Saint-Andre  <stpeter at stpeter.im>

  Applications Area Advisor:
    o   Alexey Melnikov  <alexey.melnikov at isode.com>

  Mailing Lists:
    o  General Discussion: urn@ietf.org
       To Subscribe:
         https://www.ietf.org/mailman/listinfo/urn
       Archive:
         http://www.ietf.org/mail-archive/web/urn/current/maillist.html

Description of Working Group
++++++++++++++++++++++++++++

  * * *  Problem Statement  * * *

  Uniform Resource Names (URNs) are location-independent, persistent
  identifiers for information resources.

  The RFCs defining URNs were published in 1997-2001.  They rely on old
  (or even provisional) basic documents on the concepts of URI and URL.
  At that time there was almost no URN implementation experience.

  Since then, the URN system has gained significant popularity, and
  roughly 40 formal URN Namespaces have been defined and registered
  with IANA.  Hundreds of millions of resources have been assigned URNs;
  this enables searching of and persistent linking to these documents,
  artifacts, and other objects.
  However, the URN system lacks a foundation that is consistent in
  terminology and formal description with present (Full) Internet
  Standards.

  The core URN RFCs -- RFC 2141 (URN Syntax),
  RFC 3406 (Namespace Definition Mechanisms) --
  are based on outdated framework documents and understanding of digital
  archiving. All references in RFC 2141 point to "work in progress" or
  documents that have been superseded at least once.

  The lack of a standard definition of the 'urn' URI scheme fosters
  recurring discussions on what URNs are and IETF commitment to them.
  There is a need to clarify that URNs are specific URIs (namely those
  using the 'urn' URI scheme) and hence all general URI rules apply to
  URNs.

  There also is a need to update some namespace registrations for at
  least two reasons: the standards specifying the relevant underlying
  namespaces (such as International Standard Book Number (ISBN)) have
  been amended/expanded since the original specification of the related
  URN namespace and the WG's update of the basic URN-related RFCs might
  introduce or identify inconsistencies.

  * * *  Objectives for the Working Group  * * *

  This working group is chartered to update the key RFCs describing the
  URN system, including RFC 2141 (URN Syntax), RFC 3406 (Namespace
  Definition Mechanisms), and review and
  update selected URN namespace specifications including those for
  for ISBN, National Bibliography Numbers (NBN) and International
  Serial Standard Number (ISSN).

  For all document revisions, backward compatibility with previous
  URN-related RFCs will be retained.

  The WG will produce an updated set of URN-related RFCs. All documents
  will be on the Standards-Track or BCP. These updates will provide
  a normative foundation for URNs and assure uniformity of the URN
assignment
  and resolution concepts and procedures at the abstract level.

  Details and tasks (the WG will approach these tasks in roughly this
  order):

  a)  Core URN specifications

  For RFC 2141, this revision will include in particular:
  - an update of the formal syntax specification in the light of the
    URI Standard (STD 66, RFC 3986) using the ABNF from STD 68
    (RFC 5234);
  - a formal IANA registration for the 'urn' URI scheme using the
    current template from BCP 35 (RFC 4395);
  - a revised set of URN examples and
  - an update of the sections describing how URNs are resolved
    in the Internet, based on the current practices.

  RFC 3406 (BCP 33) will be aligned with the current IANA procedures
  and terminology as defined in BCP 26 (RFC 5226).

  b) URN Namespace specifications

  The WG will focus on updating the RFCs related to the key
  bibliographic identifier systems:
  - RFC 3187 (URN Namespace for International Standard Book Numbers),
  - RFC 3188 (URN Namespace for National Bibliography Numbers), and
  - RFC 3044 (URN Namespace for International Serial Standard Number).

  All these identifier systems have been updated since these RFCs were
  written in a way that makes revision of the namespace registration
  necessary.


  c) Further work

  The WG will support the current registrants of URN namespaces.  It
  will review the legacy URN namespace definition documents and if
  needed, provide advice to their registrants on how to bring these
  registrations in line with the upcoming URN-related RFCs.
  However any work on updating such specifications beyond giving an
  advice would require rechartering of the WG.


WG Output:
+++++++++++++++++

  Revision of RFC 2141 based on draft-ah-rfc2141bis-urn
  Revision of RFC 3406

  Revision of RFC 3187 based on draft-hakala-rfc3187bis-isbn-urn
  Revision of RFC 3188 based on draft-hakala-rfc3188bis-nbn-urn
  Revision of RFC 3044
  
Goals and Milestones (rough and preliminary, to be amended):

  Feb 2011   WGLC on rfc2141bis, rfc3406bis, rfc3187bis-isbn-urn
             and rfc3188bis-nbn-urn
  Apr 2011   Deliver rfc2141bis, rfc3406bis, rfc3187bis-isbn-urn
             and rfc3188bis-nbn-urn to IESG for consideration as
             Proposed Standards
  May 2011   WGLC on rfc3044bis
  Jul 2011   Deliver rfc3044bis to IESG for consideration
             as Proposed Standards
  Apr 2012   Implementation report for promoting 2141bis to
             Draft Standard
_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From dave@cridland.net  Mon Nov  1 14:16:12 2010
Return-Path: <dave@cridland.net>
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 42FB73A67AC; Mon,  1 Nov 2010 14:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
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 8-PYyiBgXAkv; Mon,  1 Nov 2010 14:16:11 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [217.155.137.61]) by core3.amsl.com (Postfix) with ESMTP id 028163A676A; Mon,  1 Nov 2010 14:16:11 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 655C011680F6; Mon,  1 Nov 2010 21:16:12 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6b0X8uqw2t68; Mon,  1 Nov 2010 21:16:08 +0000 (GMT)
Received: from puncture (unknown [217.155.137.60]) by peirce.dave.cridland.net (Postfix) with ESMTPA id BD24511680CA; Mon,  1 Nov 2010 21:16:08 +0000 (GMT)
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645042.396621@puncture>
In-Reply-To: <2761.1288645042.396621@puncture>
MIME-Version: 1.0
Message-Id: <2761.1288646168.774025@puncture>
Date: Mon, 01 Nov 2010 21:16:08 +0000
From: Dave Cridland <dave@cridland.net>
To: Dave Cridland <dave@cridland.net>, Florian Zeitz <florob@babelmonkeys.de>, Yaron Sheffer <yaronf.ietf@gmail.com>, Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>,  Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8Bit
X-Mailman-Approved-At: Mon, 01 Nov 2010 14:21:43 -0700
Subject: Re: [secdir] [xmpp] 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 21:16:12 -0000

On Mon Nov  1 20:57:22 2010, Dave Cridland wrote:
> You're thinking of transition-needed, which was IIRC removed from  
> the  bis drafts.
> 
> It's pretty scary itself, as it provides an easy path to a  
> downgrade  attack.

FWIW, Philip Hancke pointed out that transition-needed *is* in the  
current drafts at §6.5.12, with suitable security note.

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From hilarie@purplestreak.com  Mon Nov  1 21:51:33 2010
Return-Path: <hilarie@purplestreak.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 6021A3A67CC; Mon,  1 Nov 2010 21:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 jlQlxaVUMbYY; Mon,  1 Nov 2010 21:51:31 -0700 (PDT)
Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by core3.amsl.com (Postfix) with ESMTP id A35783A67B7; Mon,  1 Nov 2010 21:51:31 -0700 (PDT)
Received: from mx02.mta.xmission.com ([166.70.13.212]) by out02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1PD8qK-0003h6-AA; Mon, 01 Nov 2010 22:51:32 -0600
Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx02.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <hilarie@purplestreak.com>) id 1PD8qI-0007a2-SE; Mon, 01 Nov 2010 22:51:31 -0600
Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id oA24oiaA004490; Mon, 1 Nov 2010 22:50:44 -0600
Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id oA24oigZ004489; Mon, 1 Nov 2010 22:50:44 -0600
Date: Mon, 1 Nov 2010 22:50:44 -0600
Message-Id: <201011020450.oA24oigZ004489@fermat.rhmr.com>
X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f
From: "Hilarie Orman" <ho@alum.mit.edu>
To: iesg@ietf.org, secdir@ietf.org
X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx02.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none
X-XM-DomainKey: sender_domain=alum.mit.edu; ; ; sender=ho@alum.mit.edu; ; ; status=error
X-SA-Exim-Connect-IP: 166.70.57.249
X-SA-Exim-Mail-From: hilarie@purplestreak.com
X-Spam-DCC: XMission; sa07 1397; Body=1 Fuz1=1 Fuz2=1 
X-Spam-Combo: ;iesg@ietf.org, secdir@ietf.org
X-Spam-Relay-Country: 
X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600)
X-SA-Exim-Scanned: Yes (on mx02.mta.xmission.com)
Cc: salvatore.loreto@ericsson.com, krisztian.kiss@nokia.com
Subject: [secdir] SecDir review of draft-ietf-sipcore-event-rate-control-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Hilarie Orman <ho@alum.mit.edu>
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: Tue, 02 Nov 2010 04:51:34 -0000

Security review of Session Initiation Protocol (SIP) Event
Notification Extension for Notification Rate Control
draft-ietf-sipcore-event-rate-control-05

Do not be alarmed.  I have reviewed this document as part of the
security directorate's ongoing effort to review all IETF documents
being processed by the IESG.  These comments were written primarily
for the benefit of the security area directors.  Document editors and
WG chairs should treat these comments just like any other last call
comments.

This document specifies mechanisms for adjusting the rate of Session
Initiation Protocol (SIP) event notifications.  These mechanisms can
be applied in subscriptions to all SIP event packages.  Subscribers
can specify minimum and maximum rates.  The rate can change smoothly
and adaptively while maintaining an average rate requested by the
subscriber.

The security considerations for this document are inherited
from a prior document about SIP security and seem adequate
for the purposes of this document.


Hilarie Orman

From yaronf.ietf@gmail.com  Tue Nov  2 03:47:42 2010
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 771C33A69A9; Tue,  2 Nov 2010 03:47:42 -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=2.133, 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 h30cjpl9xg4g; Tue,  2 Nov 2010 03:47:40 -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 EFCB83A68DC; Tue,  2 Nov 2010 03:47:39 -0700 (PDT)
Received: by wwe15 with SMTP id 15so6788760wwe.13 for <multiple recipients>; Tue, 02 Nov 2010 03:47:43 -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=9kv7wkFbrYHpNf8LVKtMi3yf0nsIf3zEWaCts/+wS08=; b=ZoYXn33rfKr7djN/znkerF7j9UsYIWdF5cpz0wDdxl5eAiQY8uAzfyYJCqUkgvChs6 KexeQYxMmBBevVFociYtRpUxZhVwH8GZ6eyPpSTGEcRqDTos2aClONVqVU6Hmjhn0Y0d XUOzHzgzw+3YbtiNOAkcSI7Se5/xbT7owdKIY=
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=wpkzNNzeTcvsEy0wDSd6qHY6Xyt528Wmpf05sxLT0u1V3M6m3JCwafFVCtaZ1mvRj4 UbOmY/iW+tvtH4IFzJiF6/udUsTcOKT3R6onebCXTqsQxg6lXwtTg7h/JsWhhkU/v0V0 0oxQXV8k3ljlYd9a4wQI8FBSkxET26omlj4KI=
Received: by 10.227.144.13 with SMTP id x13mr16694879wbu.213.1288694862877; Tue, 02 Nov 2010 03:47:42 -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 b30sm6179355wbb.4.2010.11.02.03.47.37 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 03:47:39 -0700 (PDT)
Message-ID: <4CCFEC48.7000808@gmail.com>
Date: Tue, 02 Nov 2010 12:47:36 +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> <4CCB1334.3030203@stpeter.im> <4CCD8D2B.50900@gmail.com> <4CCF12B2.3050902@stpeter.im>
In-Reply-To: <4CCF12B2.3050902@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: Tue, 02 Nov 2010 10:47:42 -0000

Hi Peter,

I'm OK with all your changes below.

Thanks,
     Yaron

On 11/01/2010 09:19 PM, Peter Saint-Andre wrote:
> On 10/31/10 9:37 AM, Yaron Sheffer wrote:
> >
> > On 10/29/2010 08:32 PM, Peter Saint-Andre wrote:
> >> This is Part 2 of my reply, from the start of Section 5 through the end
> >> of Section 9. I should be able to address the remainder (Section 10
> >> through Section 15) in Part 3.
> >>
> >> On 10/28/10 4:28 AM, Yaron Sheffer wrote:
> >>
> >>> - 5.3.5: the text mentions that client certificates are "sufficiently
> >>> rare", which is a pity because they do make sense for server-to-server
> >>> interaction. So I suggest to promote renegotiation from OPTIONAL to
> >>> RECOMMENDED.
> >>
> >> A bit of background: by client certificates we mean end-user
> >> certificates (XMPP client, not TLS client). PKIX certificates are more
> >> common for XMPP servers, but unfortunately they are still far from
> >> ubiquitous. The XMPP Standards Foundation even ran an intermediate CA
> >> for a few years (under the StartCom root) to help seed the network,
> >> which helped us work out bugs in many codebases but still didn't result
> >> in wide adoption. Many service admins still think that PKI is "too 
> hard"
> >> or "too expensive" (despite the fact that our ICA gave out free
> >> certificates, and StartCom continues to do so).
> >>
> >> The XMPP WG had a discussion about TLS renegotiation, starting here:
> >>
> >> http://www.ietf.org/mail-archive/web/xmpp/current/msg01146.html
> >>
> >> At one point we banned TLS renegotiation entirely, then we weighed the
> >> benefits and the costs (including code complexity) and concluded 
> that it
> >> was appropriate to make support strictly optional in XMPP, given how
> >> rarely it would be needed. Simon Josefsson suggested during the WG
> >> discussion that we document our reasons, which we've done in Section
> >> 5.3.5. If you do not find those reasons compelling, the WG needs to
> >> either explain itself more clearly or realize that it is wrong. :)
> >>
> > I accept your reasoning. And servers in most cases can take the risk of
> > information disclosure and still use mutual cert authentication.
>
> One clarification.... In the case of a client-to-server ("c2s")
> connection, it's the client that might leak its credentials to an
> unauthenticated server at the TLS negotiation stage, so IMHO it's not
> quite right to say that the server takes the risk of information
> disclosure. In the server-to-server ("s2s") case, the initiating server
> might leak its credentials. I don't think we're worried about the s2s
> case, because the initiating server is the one that's asking to
> "federate" the two domains in the first place. For the c2s case, so far
> end-user certificates are rare enough that I think the sense of the WG
> was to not make renegotiation a SHOULD. There are some deployment
> scenarios in which end-user certificates are more common (think certain
> military or financial organizations), but in general those deployments
> might lock down the allowable clients and will probably deal with the
> issue at the level of local service policy or a deployment profile
> (i.e., both the client and the server must support TLS renegotiation),
> so in that sense the risk of information disclosure is indeed accepted
> by the application service provider or the organization in which such a
> closed deployment occurs. However, those are specialized deployments and
> we didn't see a need for TLS renegotiation in the general case.
>
> >>> - 5.3.6: extensions may be out of scope. But I think we need to 
> include
> >>> a few words re: the TLS version, at least to prohibit SSL 3.0.
> >>
> >> In fact, discussions within the XMPP WG are what led to this:
> >>
> >> https://datatracker.ietf.org/doc/draft-ietf-tls-ssl2-must-not/
> >>
> >> However, it seems there is not yet consensus to prohibit SSL 3.0 in the
> >> TLS WG. Are you suggesting that the XMPP WG go where the TLS WG has not
> >> gone?
> >
> > I was assuming that XMPP has less legacy baggage than HTTP (i.e.
> > browsers) and therefore prohibiting SSLv3 would be reasonable. If it
> > isn't, forget it.
>
> XMPP as an application protocol does have less baggage, but it uses all
> the same TLS libraries and those tend to be driven by HTTP, so I don't
> know if we can really push the envelope here, unfortunately.
>
> >>> - 5.4.3.3: where do we say that both sides must validate the "to" and
> >>> "from" identities in view of the identities presented at the TLS layer
> >>> (if any)?
> >>
> >> Section 13.7.2 ("Certificate Validation"). There is a forward reference
> >> in bullet 4 of Section 5.4.3.3:
> >>
> >>      4.  The initiating entity MUST validate the certificate to 
> determine
> >>          if the TLS negotiation will succeed; see Section 13.7.2 
> regarding
> >>          certificate validation procedures.
> >>
> >> Perhaps it would be easier to read if we switched bullets 4 and 5 in
> >> that section?
> >
> > Yes, it makes sense to switch #4 and #5.
>
> Done in my working copy.
>
> > BTW, you meant 5.4.3.1.
>
> Yep, sorry.
>
> >> Also, the bullet about validation probably also needs to say that 
> if the
> >> initiating entity presents a certificate then the receiving entity 
> needs
> >> to also perform validation. Do you agree?
> >
> > Yes, this is the basic case, of course it should be mentioned.
>
> In my working copy the text now reads as follows (order changed, text
> tweaked, bullet added)...
>
>     4.  The receiving entity SHOULD choose which certificate to present
>         based on the 'to' attribute of the initial stream header.
>
>     5.  To determine if the TLS negotiation will succeed, the initiating
>         entity MUST attempt to validate the receiving entity's
>         certificate in accordance with the certificate validation
>         procedures specified under Section 13.7.2.
>
>     6.  If the initiating entity presents a certificate, the receiving
>         entity too MUST attempt to validate the initiating entity's
>         certificate in accordance with the certificate validation
>         procedures specified under Section 13.7.2.
>
> >>> - 7.7.2.2: the preferred option #1, while reasonable in itself, 
> does not
> >>> allow the client to determine its own policy (whether it wants 
> multiple
> >>> sessions from multiple devices or not).
> >>
> >> If the client wants multiple sessions from multiple devices, it can
> >> generate a unique resourcepart for each device or ask the server to do
> >> so on its behalf.
> >>
> > But if the client prefers the old behavior (newest resource wins), it
> > cannot have it. Anyway, I'm sure you have debated this point to death.
>
> It's true that some legacy clients used the old behavior to kick the
> existing resource, but we have better ways to do that now and the costs
> outweighed the benefits (user complaints about not being able to stay
> logged in, etc.). So yes it's been debated. :)
>
> >>> - 8.3.2: MUST NOT... be presented to the human user - this is 
> impossible
> >>> to enforce, and most likely will not be followed. Moreover, there's a
> >>> reason why we include a language tag. I suggest to tone it down a bit.
> >>
> >> I suppose SHOULD NOT is fine. The error message shown to the user is
> >> supposed to be based on the defined condition, not some random text
> >> placed in the<text/>   element (even if language-tagged).
> >
> > Yes, SHOULD NOT would be BETTER...
>
> Done.
>
> >>> - 8.3.3.11: what are "improper credentials"? It sounds like we are not
> >>> differentiating the conditions of authentication failure vs.
> >>> authorization failure.
> >>
> >> As an example, if a client attempts to join a password-protected
> >> chatroom without providing a password, the chatroom service will return
> >> a<not-authorized/>   stanza error. It will return the same error if the
> >> client attempts to join a password-protected chatroom but provides the
> >> wrong password. Is there a need to differentiate between these two 
> cases?
> >>
> > What triggered my comment was the name of this element, "not
> > authorized".
>
> We inherited that from HTTP 401 "Unauthorized".
>
> > Both of your examples are (broadly speaking), "not
> > authenticated". What about the same service, where I am duly
> > authenticated as Yaron, but still am not allowed to use the service,
> > e.g. because only users belonging to the all-saints group are allowed to
> > it. This would be a true authorization failure.
>
> Sure. Sticking with the example of multi-user chat rooms, a room admin
> has privileges to perform certain actions (say, kick people out of the
> room); if a non-privileged user attempts to perform such an action, the
> service will return a<forbidden/>  error. Perhaps we don't have a very
> sophisticated authorization model in XMPP, but we've not yet found the
> need for error conditions that are strictly limited to authorization.
>
> >>> - 8.3.3.21: do you explain anywhere what is the difference between
> >>> "prior registration" and "prior subscription"?
> >>
> >> That's really an issue for various XMPP applications. One such
> >> application is IM and presence (3920bis), where we have the concept of
> >> subscriptions. Another application in which we have subscriptions is
> >> publish-subscribe<http://xmpp.org/extensions/xep-0060.html>. An example
> >> of registration can be found in the multi-user chat extension
> >> <http://xmpp.org/extensions/xep-0045.html>   or in the older "gateway"
> >> that we used to maintain for connecting to legacy IM services. I don't
> >> see much reason to describe all those differences in 3920bis, but 
> we can
> >> add a sentence or two about it if that would be helpful.
> >>
> > I would appreciate a pointer to benefit the uninitiated.
>
> Adjusted text:
>
> ###
>
> 8.3.3.16.  registration-required
>
>     The requesting entity is not authorized to access the requested
>     service because prior registration is necessary (examples of prior
>     registration include members-only rooms in XMPP multi-user chat
>     [XEP-0045] and gateways to non-XMPP instant messaging services, which
>     traditionally required registration in order to use the gateway
>     [XEP-0100]); the associated error type SHOULD be "auth".
>
> ###
>
> 8.3.3.21.  subscription-required
>
>     The requesting entity is not authorized to access the requested
>     service because a prior subscription is necessary (examples of prior
>     subscription include authorization to receive presence information as
>     defined in [XMPP-IM] and opt-in data feeds for XMPP publish-subscribe
>     as defined in [XEP-0060]); the associated error type SHOULD be
>     "auth".
>
> ###
>
> Better?
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>

From yaronf.ietf@gmail.com  Tue Nov  2 04:10:50 2010
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 A0AB73A68B1; Tue,  2 Nov 2010 04:10:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.532
X-Spam-Level: 
X-Spam-Status: No, score=-101.532 tagged_above=-999 required=5 tests=[AWL=1.067, 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 VrAFSerJIcxR; Tue,  2 Nov 2010 04:10:43 -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 06BDA3A687A; Tue,  2 Nov 2010 04:10:41 -0700 (PDT)
Received: by wwe15 with SMTP id 15so6810902wwe.13 for <multiple recipients>; Tue, 02 Nov 2010 04:10:45 -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=3wjdbdMO8EglqtvMsIRyikEDWcg+DdPY/6Y59+IQfm8=; b=YVZZD6Ed7svyBwTq35WAuPPppLK5aBDdB4UEQuu1kiig6tHwAwtdq9cqQeSRo1upr0 +dYOhnm4ItfuV4oH2MODF1Ao1e5LD4eqNZ3qyxcql3I4HD08+5HtVw8tizSYb3g2RVqt Ixm2mwLF5HCl1pbMAXiklV4PHD+fJCkqAHLBo=
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=VWLcuzT3udQRBGoyR/UCQSAMzZ0/E3XAc0ZHJpAeHnDYpwQBexAOZcxRDPK2Vsj4Gc adUyCB8AxydJDu563o8R9cqXRn2YcGC0KTPgkojyd8GqPLcNhBBmmY43NTHhId1Xr52s qUcgK8gHsckFG7umlUri8HJ4jFXCE0TekSwHU=
Received: by 10.227.155.15 with SMTP id q15mr2519906wbw.141.1288696245134; Tue, 02 Nov 2010 04:10:45 -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 a17sm6197568wbe.6.2010.11.02.04.10.42 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 04:10:43 -0700 (PDT)
Message-ID: <4CCFF1B0.4080007@gmail.com>
Date: Tue, 02 Nov 2010 13:10:40 +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> <4CCE87A5.80701@gmail.com> <4CCF20E7.30401@stpeter.im>
In-Reply-To: <4CCF20E7.30401@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: Tue, 02 Nov 2010 11:10:50 -0000

Hi Peter,

please see my comments in-line. I have removed already-closed issues.

Thanks,
     Yaron

On 11/01/2010 10:19 PM, Peter Saint-Andre wrote:
> On 11/1/10 3:25 AM, Yaron Sheffer wrote:
> > Hi Peter,
> >
> > Responding to the last part. Thanks for a constructive discussion.
>
>
> >>> - 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.
>
> ###
>
This is all fine, other than the last sentence. There's little security 
value (or performance value, for that matter) in "MUST check, but only 
MAY choose to fail". With possible minor exceptions, these rules are all 
security-critical.

>
> >>> - 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?
>
Yes, definitely.

> >>> - 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).
>
I also think it's a good idea.


From yaronf.ietf@gmail.com  Tue Nov  2 04:20:17 2010
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 0CD493A68B1; Tue,  2 Nov 2010 04:20:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.888
X-Spam-Level: 
X-Spam-Status: No, score=-101.888 tagged_above=-999 required=5 tests=[AWL=0.711, 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 XW51hWVFWr4B; Tue,  2 Nov 2010 04:20:15 -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 8B9D328C113; Tue,  2 Nov 2010 04:20:12 -0700 (PDT)
Received: by wwe15 with SMTP id 15so6819033wwe.13 for <multiple recipients>; Tue, 02 Nov 2010 04:20:11 -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=o6JgBjUhLpehs5Q/EAm2j4GI/FQD69Iw+JPLxLbAlWw=; b=dLMelhbtELV6Sc4ct7ep2te5i9jvLFvTt1VvXhLy7A1bfgr0IRuN/aIe9yA9jzMLZ1 zl7PF5PY1qj1HHS8Ai9sXJj7AWuC93KkXyG0AmXZsfpNCFwd0E5Nxp8IGbuxxJfxhedi ebvbIKbVyTZDezta6sG5PLOriVV+r6JhRK3J4=
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=cInOD4CKTFMAPTpZaW0v8OCjmW0yFkDrugGySmYrJImYlN/gcXPOQPTFj2hCceUQ3G 75Na1+rAJpTuYGkA7w6itF7DY9uMmOA60HPlus0rZ9ErxpxVQ45Yh/xuQulfBhVBzMpv a5z6/ZRFYVlPs7YhTrvv5cEvEjX7ffF07rDYk=
Received: by 10.227.132.209 with SMTP id c17mr3780789wbt.24.1288696811638; Tue, 02 Nov 2010 04:20:11 -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 a17sm6205467wbe.6.2010.11.02.04.20.08 (version=SSLv3 cipher=RC4-MD5); Tue, 02 Nov 2010 04:20:10 -0700 (PDT)
Message-ID: <4CCFF3E6.7040800@gmail.com>
Date: Tue, 02 Nov 2010 13:20:06 +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>	<4CCE87A5.80701@gmail.com>	<4CCF04D3.6020504@babelmonkeys.de>	<2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im>
In-Reply-To: <4CCF9776.5060207@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" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Dave Cridland <dave@cridland.net>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 11:20:17 -0000

I'm OK with this text, including (sigh) PLAIN.

On 11/02/2010 06:45 AM, Peter Saint-Andre wrote:
> On 11/1/10 8:59 PM, Peter Saint-Andre wrote:
>
> > As mentioned, I'll work to capture these considerations in proposed 
> text.
>
> Here is proposed text. Please review and provide feedback.
>
> ###
>
> 13.8.  Mandatory-to-Implement Technologies
>
>     The following TLS ciphersuites and SASL mechanisms are mandatory-to-
>     implement (naturally, implementations MAY support other ciphersuites
>     and mechanisms as well).  For security considerations related to TLS
>     ciphersuites, see Section 13.9.4 and [TLS].  For security
>     considerations related to SASL mechanisms, Section 13.9.4, [SASL],
>     and specifications for particular SASL mechanisms such as [SCRAM],
>     [DIGEST-MD5], and [PLAIN].
>
> 13.8.1.  For Authentication Only
>
>     For authentication only, servers and clients MUST support the SASL
>     Salted Challenge Response mechanism [SCRAM], in particular the SCRAM-
>     SHA-1 variant (REQUIRED) and SCRAM-SHA-1-PLUS variant (RECOMMENDED if
>     channel binding is possible).
>
>        Security Note: Even though it is possible to complete
>        authentication only without confidentiality, it is RECOMMENDED for
>        servers and clients to protect the stream with TLS before
>        attempting authentication with SASL, both to help protect the
>        information exchanged during SASL negotiation and to help prevent
>        certain downgrade attacks; see also Section 13.9.4 and
>        Section 13.9.5.
>
>        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.  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.8.2.  For Confidentiality Only
>
>     For confidentiality only, servers SHOULD support TLS with the
>     TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.
>
>        Security Note: Because a connection with confidentiality only has
>        weaker security properties than a connection with both
>        confidentiality and authentication, it is RECOMMENDED for servers
>        and clients to prefer connections with both qualities (e.g., by
>        protecting the stream with TLS before attempting authentication
>        with SASL).  In practice, confidentiality only is employed merely
>        for server-to-server connections when the peer server does not
>        present a certificate and the servers use Server Dialback
>        [XEP-0220] for weak identity verification, but TLS is still
>        desirable to protect the connection against casual eavesdropping.
>
> 13.8.3.  For Confidentiality and Authentication With Passwords
>
>     For both confidentiality and authentication with passwords, servers
>     and clients MUST support TLS with the TLS_RSA_WITH_AES_128_CBC_SHA
>     ciphersuite plus SCRAM-SHA-1 and (when channel binding is possible)
>     SCRAM-SHA-1-PLUS.
>
>     As a fallback when SCRAM is not available, servers MAY offer and
>     clients MAY use TLS with the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite
>     plus SASL PLAIN.
>
>        Security Note: The SCRAM-SHA-1 and SCRAM-SHA-1-PLUS mechanisms are
>        strongly preferred over the SASL PLAIN mechanism because of their
>        superior security properties.  TLS plus SASL PLAIN is primarily
>        intended to be a fallback for implementations that do not yet
>        support SCRAM.  However, in certain deployment scenarios it can be
>        difficult for a server to offer SCRAM-based mechanisms (e.g.,
>        because the XMPP service depends for authentication purposes on a
>        database or directory that is not under the control of the XMPP
>        administrators).  Furthermore, it can be appropriate for an XMPP
>        service to offer the SASL PLAIN mechanism when it upgrades
>        security mechanisms and needs the plaintext password in order to
>        seed user credentials (see Section 6.5.12).  A client needs to
>        treat all such uses of the SASL PLAIN mechanism with caution, MUST
>        prefer other mechanisms (e.g., SCRAM-SHA-1, SCRAM-SHA-1-PLUS, and
>        EXTERNAL) to the PLAIN mechanism, and MUST NOT use the PLAIN
>        mechanism without confidentiality and integrity protection via
>        TLS.
>
> 13.8.4.  For Confidentiality and Authentication Without Passwords
>
>     For both confidentiality and authentication without passwords,
>     servers MUST and clients SHOULD support TLS with the
>     TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus the SASL EXTERNAL
>     mechanism (see Appendix A of [SASL]) supporting PKIX certificates.
>
> ###
>
> Peter
>

From Kurt.Zeilenga@Isode.COM  Tue Nov  2 07:13:16 2010
Return-Path: <Kurt.Zeilenga@Isode.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 57A9D3A687F; Tue,  2 Nov 2010 07:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.799
X-Spam-Level: 
X-Spam-Status: No, score=-100.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, 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 AGjrTAMje9Gq; Tue,  2 Nov 2010 07:13:15 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 1BF843A69C5; Tue,  2 Nov 2010 07:13:15 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <TNAcfAAEeWu6@rufus.isode.com>; Tue, 2 Nov 2010 14:13:18 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <4CD00025.8030804@stpeter.im>
Date: Tue, 2 Nov 2010 07:13:14 -0700
Message-Id: <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 14:13:16 -0000

On Nov 2, 2010, at 5:12 AM, Peter Saint-Andre wrote:

> On 11/2/10 5:20 AM, Yaron Sheffer wrote:
>> I'm OK with this text, including (sigh) PLAIN.
>=20
> If it's any consolation, I'm sighing along with you. :)
>=20
> Two points:
>=20
> 1. Eventually, we should be able to drop PLAIN in a future revision of
> the MTI technologies spec that we'll pull out of 3920bis in 1+ years.

Good luck with that.  The arguments used now for its inclusion is likely =
to be repeated and, again, win.

Personally, I am against MUST'ing or SHOULD'ing TLS+PLAIN.  While it =
does offer good interoperability, it does good enough security for =
today's, and more importantly, tomorrow's Internet.

I think we actually should be mandating a SCRAM-*-PLUS mechanism, =
because channeling bindings are really needed due to 'user click =
through' of TLS warnings, downgrade attack warnings, etc..   I do =
suspect that it will take time for this mechanism to be come ubiquitous, =
but I fear that without a MUST, it will never become ubiquitous.   But I =
do suspect well have multiple independently developed implementations of =
SCRAM-*-PLUS in XMPP within a few months of publication of this revision =
of XMPP.

I suspect I'm in the rough on both points.  Oh well.

> 2. The technology that the XMPP community uses for account =
registration
> (XEP-0077) could benefit from an update, or even a replacement, and =
when
> that work is completed I'd like to include a method by which a client
> could register a key or cert with the server, thus smoothing the path
> toward password-less authentication. IMHO that will be the best =
approach
> in the longer term, instead of continually tweaking the password-based
> methods. But that's a topic for another time...

I also think transition-needed needs to be deprecated in favor of =
transition within the bound channel (e.g., today via XEP 77, tomorrow =
?).

>=20
> Peter
>=20
> --=20
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20
>=20
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp


From Kurt.Zeilenga@Isode.COM  Tue Nov  2 08:41:41 2010
Return-Path: <Kurt.Zeilenga@Isode.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 5E73B3A69D2; Tue,  2 Nov 2010 08:41:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.799
X-Spam-Level: 
X-Spam-Status: No, score=-100.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, 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 juKqZNgkPsL9; Tue,  2 Nov 2010 08:41:40 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 850503A69DA; Tue,  2 Nov 2010 08:41:17 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <TNAxBAAEeYRv@rufus.isode.com>; Tue, 2 Nov 2010 15:40:54 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM>
Date: Tue, 2 Nov 2010 08:40:50 -0700
Message-Id: <17C848A4-E525-4F01-A9D7-47C80A8BDBD0@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM>
To: Kurt Zeilenga <Kurt.Zeilenga@Isode.com>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Security Area Directorate <secdir@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, XMPP Working Group <xmpp@ietf.org>, The IESG <iesg@ietf.org>, Peter Saint-Andre <stpeter@stpeter.im>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 15:41:41 -0000

On Nov 2, 2010, at 7:13 AM, Kurt Zeilenga wrote:

> Personally, I am against MUST'ing or SHOULD'ing TLS+PLAIN.  While it =
does offer good interoperability, it does good enough security for =
today's, and more importantly, tomorrow's Internet.

s/does good enough/does NOT offer good enough/

-- Kurt=

From tobias.gondrom@gondrom.org  Tue Nov  2 09:20:23 2010
Return-Path: <tobias.gondrom@gondrom.org>
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 8E31B28C12C for <secdir@core3.amsl.com>; Tue,  2 Nov 2010 09:20:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.378
X-Spam-Level: 
X-Spam-Status: No, score=-95.378 tagged_above=-999 required=5 tests=[AWL=-0.016, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, 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 NB251vgsL8s4 for <secdir@core3.amsl.com>; Tue,  2 Nov 2010 09:20:22 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 121E528C105 for <secdir@ietf.org>; Tue,  2 Nov 2010 09:20:21 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1;  q=dns; c=nofws; s=default; d=gondrom.org; b=lihE5ykeEbqAkxiW9WHdSsoXfYLV7cf8t7t3uCdkGjbkKNx/sQaTOofFJtthrQZBfzcCpECd2UEuuCSl20TCL4FTnTuRSHHzzwrrVK2pUnpDOM6Za2zTcDytq0XZ9wJq; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 22251 invoked from network); 2 Nov 2010 17:19:51 +0100
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 2 Nov 2010 17:19:51 +0100
Message-ID: <4CD03A2C.3060908@gondrom.org>
Date: Tue, 02 Nov 2010 16:19:56 +0000
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: Sriganesh Kini <sriganesh.kini@ericsson.com>
References: <4CA081F7.60304@gondrom.org> <5A5E55DF96F73844AF7DFB0F48721F0F56F5FDE903@EUSAACMS0703.eamcs.ericsson.se> <4CA8DDAC.3050801@gondrom.org> <5A5E55DF96F73844AF7DFB0F48721F0F56F5FDEF1A@EUSAACMS0703.eamcs.ericsson.se>
In-Reply-To: <5A5E55DF96F73844AF7DFB0F48721F0F56F5FDEF1A@EUSAACMS0703.eamcs.ericsson.se>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "swallow@cisco.com" <swallow@cisco.com>, Wenhu Lu <wenhu.lu@ericsson.com>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org" <draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org>, "martin.vigoureux@alcatel-lucent.com" <martin.vigoureux@alcatel-lucent.com>, "iesg@ietf.org" <iesg@ietf.org>, "adrian.farrel@huawei.com" <adrian.farrel@huawei.com>, "loa@pi.nu" <loa@pi.nu>
Subject: Re: [secdir] Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-05
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: Tue, 02 Nov 2010 16:20:23 -0000

 Hello Sri,

thank you. I saw the updated draft 05 resolved all my editorial comments
(removed them from this email).
Still one thing remains nagging me:
I appreciate your answers in your email about the topic below, but we
seem to disagree whether that justifies an explanation in the security
considerations or not: I believe it should, but noticed that you didn't
add anything about this in the security considerations in version-05.

Note to the AD: please consider this note only as a COMMENT (not a
DISCUSS) as I still believe it would be good to reflect Sri's
explanations below in the Security considerations, but will not want to
insist on that point.
Btw. the argument that certain problems are not unique to this draft
does not mean you needn't point them out in the security considerations.
;-)

Kind regards and thanks, Tobias




On 10/04/2010 07:07 PM, Sriganesh Kini wrote:
>>
>>>> The document states that there would be no security considerations 
>>>> beyond RFC5443.
>>>> I am not certain of that. Although the idea behind bcast is good, it 
>>>> adds a new mechanism beyond 5443.
>>>> To make sure the security considerations are accurate, I'd like to 
>>>> raise two questions for the authors/WG:
>>>> 1. Which security implications does the WG see for removing a coming 
>>>> up link from the LSDB?
>>> [Sri] Since the link is only delayed from being added to the LSDB we don't believe there are any new/additional 
>>> security implications.
>>>
>> [tg] still the delay is in theory not time limited, but based 
>> on the condition of LDP of the link. In combination with #2 
>> (below) that the cut-edge of the network may actually be 
>> calculated falsely, can this be exploited or lead to unreachability?
>> Note: although your remark is right regarding similarities 
>> with 5443, the criteria in 5443 is much weaker as it only 
>> increases its metric, but does not remove it from LSDB/hold 
>> back its entry. Again, I am not an expert on that layer, but 
>> I am still uncertain that no security considerations derive 
>> from that. Did you consider this scenario when you wrote the 
>> draft? Is it unrealistic that it could be exploited with bad 
>> intentions?
>> If not, which would be the underlying implied pre-conditions 
>> to be met to avoid such or under which pre-conditions could 
>> such a problem occur?
>> (potential input for the security considerations section)
> [Sri] The weaker criteria of RFC 5443 does not ensure that the problem does not exist there. In fact the problem exists in a plain IP network with link-state IGP. If the directly connected path has a higher metric than an alternate path with TTL (say > 255) hops then the standard SPF will conclude that the shortest path is the alternate path although through this path the neighboring node is unreachable. Note that in this case the link is advertised with its normal metric yet there is unreachability in the network.
>>>> 2. Can there be a gap between the algorithm to determine "cut-edge" 
>>>> and TTL (e.g. may not qualify for "cut-edge" and thus be removed from 
>>>> LSDB, but have a large number of links and effectively not be 
>>>> reachable)?
>>> [Sri] This problem is not unique to this draft. Even in RFC 
>>> 5443 when the link has high metric, an alternate path with 
>>> num hops > 255 (but a lower path metric than the directly 
>>> connected link's max metric) can result in unreachability.
>>>


From Kurt.Zeilenga@Isode.COM  Tue Nov  2 12:03:36 2010
Return-Path: <Kurt.Zeilenga@Isode.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 E05D03A6A07; Tue,  2 Nov 2010 12:03:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.699
X-Spam-Level: 
X-Spam-Status: No, score=-101.699 tagged_above=-999 required=5 tests=[AWL=0.900, 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 pg4uDaYCc9q4; Tue,  2 Nov 2010 12:03:36 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id CEF823A69D8; Tue,  2 Nov 2010 12:03:35 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <TNBghgAEeSve@rufus.isode.com>; Tue, 2 Nov 2010 19:03:39 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <4CD03E36.3020304@stpeter.im>
Date: Tue, 2 Nov 2010 12:03:31 -0700
Message-Id: <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 19:03:37 -0000

On Nov 2, 2010, at 9:37 AM, Peter Saint-Andre wrote:

>>=20
>> I suspect I'm in the rough on both points.  Oh well.
>>=20
>>> 2. The technology that the XMPP community uses for account
>>> registration (XEP-0077) could benefit from an update, or even a
>>> replacement, and when that work is completed I'd like to include a
>>> method by which a client could register a key or cert with the
>>> server, thus smoothing the path toward password-less
>>> authentication. IMHO that will be the best approach in the longer
>>> term, instead of continually tweaking the password-based methods.
>>> But that's a topic for another time...
>>=20
>> I also think transition-needed needs to be deprecated in favor of
>> transition within the bound channel (e.g., today via XEP 77, tomorrow
>> ?).
>=20
> I'm not sure exactly what "transition within the bound channel" is, =
but
> it sounds worthy of discussion when we work on 3920ter.

The problem with transition-needed is that the error is sent outside the =
bound channel.

By "within the bound channel", I mean a transitioning method, including =
any necessary signaling, would be performed inside the bound channel, =
that is, within the new <stream:stream/> protected by the SASL exchange.

> At this point I
> don't think the XMPP community has a great deal of experience with, or
> even understanding of, channel binding, so it's difficult for us to =
make
> strong recommendations that depend on channel binding.

It would be same issue of doing transition outside of a SASL negotiated =
security layer.  It's prone to attack.  And the fix is the same.

-- Kurt=

From Kurt.Zeilenga@Isode.COM  Tue Nov  2 14:11:48 2010
Return-Path: <Kurt.Zeilenga@Isode.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 401773A68CF; Tue,  2 Nov 2010 14:11:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level: 
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=0.600, 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 aUqTKNXjaod8; Tue,  2 Nov 2010 14:11:39 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id DA8D23A68E2; Tue,  2 Nov 2010 14:11:36 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <TNB-igAEeZtJ@rufus.isode.com>; Tue, 2 Nov 2010 21:11:40 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <4CD071D5.3080808@stpeter.im>
Date: Tue, 2 Nov 2010 14:11:36 -0700
Message-Id: <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <4CD071D5.3080808@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 21:11:48 -0000

On Nov 2, 2010, at 1:17 PM, Peter Saint-Andre wrote:

> On 11/2/10 1:03 PM, Kurt Zeilenga wrote:
>>=20
>> On Nov 2, 2010, at 9:37 AM, Peter Saint-Andre wrote:
>>=20
>>>>=20
>>>> I suspect I'm in the rough on both points.  Oh well.
>>>>=20
>>>>> 2. The technology that the XMPP community uses for account=20
>>>>> registration (XEP-0077) could benefit from an update, or even
>>>>> a replacement, and when that work is completed I'd like to
>>>>> include a method by which a client could register a key or cert
>>>>> with the server, thus smoothing the path toward password-less=20
>>>>> authentication. IMHO that will be the best approach in the
>>>>> longer term, instead of continually tweaking the password-based
>>>>> methods. But that's a topic for another time...
>>>>=20
>>>> I also think transition-needed needs to be deprecated in favor
>>>> of transition within the bound channel (e.g., today via XEP 77,
>>>> tomorrow ?).
>>>=20
>>> I'm not sure exactly what "transition within the bound channel" is,
>>> but it sounds worthy of discussion when we work on 3920ter.
>>=20
>> The problem with transition-needed is that the error is sent outside
>> the bound channel.
>>=20
>> By "within the bound channel", I mean a transitioning method,
>> including any necessary signaling, would be performed inside the
>> bound channel, that is, within the new <stream:stream/> protected by
>> the SASL exchange.
>>=20
>>> At this point I don't think the XMPP community has a great deal of
>>> experience with, or even understanding of, channel binding, so it's
>>> difficult for us to make strong recommendations that depend on
>>> channel binding.
>>=20
>> It would be same issue of doing transition outside of a SASL
>> negotiated security layer.  It's prone to attack.  And the fix is the
>> same.
>=20
> What is the attack?

> If the client required negotiation of TLS before
> moving on to SASL, the server has already authenticated to the client =
at
> the stage.

In the SASL negotiated security label case, assume no TLS is used.

In the channeling binding case, assume the user/client is relying on the =
SASL mechanism's mutual authentication capabilities to identify the =
server and is merely using TLS to provide stream security.   This is, I =
think, one of the most significant use case of channel binding, at least =
from the client's perspective. (=46rom the server's perspective, I think =
the most significant aspect of channel binding is that server no longer =
needs to rely on the client and its user to verify the server's =
certificate and perform subject name checks, both of which are likely =
not to done well.)

> As I far as I understand, you are arguing that SASL negotiation could =
result
> in establishment of a further security layer
> that is bound to the TLS layer via channel binding, and that it is =
safe
> for the client to send plaintext credentials to the server only after
> channel binding has taken place. Correct?

I am assuming one either has a SASL negotiated security layer OR a =
securely bound lower-level channel (eg, TLS), not both.

In both cases, with the existing <transition-needed/> error, the SASL =
exchanged has failed, nothing is protected by the SASL exchange.  Which =
means there is no (new) SASL security layer and no channel binding.  So, =
if the user/client is relying on the SASL mechanism's mutual =
authentication, it needs to be extremely caution about what it does in =
response to that error.

By signaling the client that transition is needed in the new stream and =
performing the transition in that stream, we ensure that protections =
provided by any security layer or bound channel is in place.

While the attacker could just as well have attempted to get the client =
to do PLAIN by ensuring PLAIN is the only mechanism listed, a client =
might well caution that use of PLAIN is generally dangerous, most =
clients won't give a complain about the downgrade (because most clients =
don't remember last used mechanism).  By using <transition-needed/> =
error, the attacker likely can get the client to display specific noting =
the server has requested transition (hopefully with a warning about the =
possibility this could be spoofed, and PLAIN is dangerous.  Though I =
don't have a reference, I recall some claiming that users are more =
likely to click through the latter dialogs than the former.=20

That is, <transition-needed/> spoofing may well be a more successful =
downgrade attack than SASL mechanism spoofing.

> If so, then we'd need to
> define a post-SASL protocol (that might include work on periodic
> re-authentication requests sent from server to client). But IMHO that
> work is out of scope for 3920bis. The question is: is it better to

> remove the <transition-needed/> SASL condition pending work on the
> future protocol extension?

I think the question can simple as simple as "Should =
<transition-needed/> be removed?".  I am fine with the question being =
viewed as "too late" to ask.

>=20
> Peter
>=20
> --=20
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20
>=20
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp


From Kurt.Zeilenga@Isode.COM  Tue Nov  2 17:14:20 2010
Return-Path: <Kurt.Zeilenga@Isode.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 84A2F3A6A51; Tue,  2 Nov 2010 17:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.149
X-Spam-Level: 
X-Spam-Status: No, score=-102.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 M91h49kW1CSP; Tue,  2 Nov 2010 17:14:19 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id F094C3A6A50; Tue,  2 Nov 2010 17:14:18 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <TNCpXQAEeWm5@rufus.isode.com>; Wed, 3 Nov 2010 00:14:23 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <4CD08E62.3060202@stpeter.im>
Date: Tue, 2 Nov 2010 17:14:19 -0700
Message-Id: <03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <4CD071D5.3080808@stpeter.im> <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM> <4CD08E62.3060202@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: Re: [secdir] [xmpp] 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: Wed, 03 Nov 2010 00:14:20 -0000

On Nov 2, 2010, at 3:19 PM, Peter Saint-Andre wrote:

> On 11/2/10 3:11 PM, Kurt Zeilenga wrote:
>=20
>> I think the question can simple as simple as "Should
>> <transition-needed/> be removed?".  I am fine with the question being
>> viewed as "too late" to ask.
>=20
> I don't think that folks in the WG would cry if the feature were
> removed, given that:
>=20
> 1. It would be used rarely.
>=20
> 2. No one has implemented it (AFAIK).
>=20
> 3. The text provides many warnings about it.
>=20
> 4. It supposedly opens up the possibility of downgrade attacks.
>=20
> However, I still fail to see how <transition-needed/> is more evil =
than
> using SASL, at least if TLS is negotiated first (an attacker could =
just
> advertise the PLAIN mechanism over the TLS-protected stream, and if an
> attacker has so much control over the server that it can launch =
attacks
> after TLS has been negotiated then the client is in deep trouble =
anyway!).

I think you are considering the issue under a different assumptions than =
I.  I am assuming the user has clicked through any and all warnings they =
were faced with.  I am assuming the client did not well implement =
handling all cases.

For instance, if the user clicked said "connect anyways" to a =
certificate verification/subject check warning, a decent client would =
still warn if it previously used SCRAM-SHA1-PLUS and now is only getting =
SCRAM-SHA1 or just PLAIN, and warning about downgrade possibilities with =
transition-needed.  But far too often clients, not surprisingly, will =
assume that "connect anyways" means that TLS is good for purposes (e.g., =
server has been authenticated by the user by means outside the clients =
control) instead of "good enough for use with mechanisms that provide =
mutual authentication".  Of course, what the user meant was "just =
connect, damn it".

Our application protocol security designs are far too reliant on users =
making non-trival decisions, and far too complex for client developers =
to well implement.  (Such issues are certainly not limited to XMPP.)   =
We ought to design our protocols to avoid having to ask the user to make =
non-trival decisions, and simplify things the client developers as much =
possible (such as by ensuring key protocol bits are adequately protected =
from various attacks, instead of "TLS will save us").  And to make =
matters worse, we tend to repeat 'bad designs' (The transition-needed =
error in protocols has been a problem since introduced, as it never been =
protected by the SASL exchange.)

> Furthermore, I think that any client sophisticated enough to support
> <transition-needed/> is going to be sophisticated enough to support
> SCRAM-based mechanisms,

I disagree here.  A client developer is likely to implement =
transition-needed without at all thinking about the implications of =
whether "connect anyways" means "good enough for mechanism which =
provides server authentication and channel bindings" or simply "good =
enough for anything the server might ask us to do".  And, of course, the =
user just meant "I don't care about this" (but that doesn't mean the =
server operator does care).

Note that I don't mean to blame the user or the client developer here, I =
mean to blame the protocol designers for pushing these problems upon =
them.

> which means it can perform a further check to
> make sure that the server really is offering upgraded security
> mechanisms (likely, upgrading from DIGEST-MD5 to SCRAM-SHA-1) before
> sending the password in plaintext over the TLS-encrypted stream.

And if it notices an issue, what, prompt the user again?

> Another
> check: don't use <transition-needed/> more than once with any given =
XMPP
> service (once is enough!).

Once is enough?  I don't think so.

> And never send the plaintext password over an
> unprotected stream.

Ah, some will take "unprotected" to mean its okay to send the password =
over a stream so long as it has data integrity and data confidentiality =
protection.

That isn't enough.  One ought not send a plaintext password without =
server authentication (preferably that's bound to the protected stream =
end-point).  If the user may have intended to rely on SCRAM for server =
authentication, then just having TLS without any server authentication =
is not good enough.

> So IMHO we have a number of protections in place

The only protections we have assumption that TLS is used with client's =
authentication of the server.  That's a hell of an assumption with =
todays use of TLS on the Internet.   Certainly <transition-protected/> =
is not protected in XMPP use without TLS but with SASL security layers.

Of course, we also rely on this assumption to prevent downgrade via =
mechanism advertisements.  We really ought to do something about that as =
well.

> and
> that we can safely use the <transition-needed/> feature if we feel =
that
> we really need it.  The question is: do we really need it? We do want =
to
> encourage folks to migrate from DIGEST-MD5 (lots of interoperability
> issues) to SCRAM, and as part of that upgrade process XMPP services
> might need to collect the plaintext password just once.

Or again if they select SCRAM specific secrets and then realize they =
still need to support DIGEST-MD5.
Or they decide to move to some other password based mechanism and its =
mechanism specific secret.

It's not 'just once'.

> I'd rather have
> it done over the XMPP channel than, say, via an HTTPS web page (more
> phishing possibilities), but opinions might differ.

I rather have it done in a well-protected XMPP channel.   I don't =
consider the use transition-needed and TLS*+PLAIN as generally well =
protected.

(* TLS as often implemented and used on the Internet, e.g., without =
authentication).

> Feedback from our
> security reviewer and the Security ADs would be especially helpful.
>=20
> All that having been said, if we're going to remove the feature then I
> think we need to make sure that the WG has consensus to do so.

Of course.

-- Kurt=

From jhutz@cmu.edu  Tue Nov  2 20:58:14 2010
Return-Path: <jhutz@cmu.edu>
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 AAD7C3A6868; Tue,  2 Nov 2010 20:58:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.799
X-Spam-Level: 
X-Spam-Status: No, score=-104.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4, 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 AF8bu0X2LRa9; Tue,  2 Nov 2010 20:58:13 -0700 (PDT)
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 858223A6867; Tue,  2 Nov 2010 20:58:13 -0700 (PDT)
Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id oA33wGeu018983 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Nov 2010 23:58:16 -0400 (EDT)
Date: Tue, 02 Nov 2010 23:58:16 -0400
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>, Peter Saint-Andre <stpeter@stpeter.im>
Message-ID: <94ADA1731FD50A77669ECEC7@lysithea.fac.cs.cmu.edu>
In-Reply-To: <12812_1288707203_oA2EDMV4029593_706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im>	<4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de>	<2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im>	<4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com>	<4CD00025.8030804@stpeter.im> <12812_1288707203_oA2EDMV4029593_706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.196
Cc: draft-ietf-xmpp-3920bis.all@tools.ietf.org, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: Re: [secdir] [xmpp] 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: Wed, 03 Nov 2010 03:58:14 -0000

--On Tuesday, November 02, 2010 07:13:14 AM -0700 Kurt Zeilenga 
<Kurt.Zeilenga@Isode.COM> wrote:

>
> On Nov 2, 2010, at 5:12 AM, Peter Saint-Andre wrote:
>
>> On 11/2/10 5:20 AM, Yaron Sheffer wrote:
>>> I'm OK with this text, including (sigh) PLAIN.
>>
>> If it's any consolation, I'm sighing along with you. :)
>>
>> Two points:
>>
>> 1. Eventually, we should be able to drop PLAIN in a future revision of
>> the MTI technologies spec that we'll pull out of 3920bis in 1+ years.
>
> Good luck with that.  The arguments used now for its inclusion is likely
> to be repeated and, again, win.
>
> Personally, I am against MUST'ing or SHOULD'ing TLS+PLAIN.  While it does
> offer good interoperability, it does good enough security for today's,
> and more importantly, tomorrow's Internet.
>
> I think we actually should be mandating a SCRAM-*-PLUS mechanism, because
> channeling bindings are really needed due to 'user click through' of TLS
> warnings, downgrade attack warnings, etc..   I do suspect that it will
> take time for this mechanism to be come ubiquitous, but I fear that
> without a MUST, it will never become ubiquitous.   But I do suspect well
> have multiple independently developed implementations of SCRAM-*-PLUS in
> XMPP within a few months of publication of this revision of XMPP.
>
> I suspect I'm in the rough on both points.  Oh well.
>
>> 2. The technology that the XMPP community uses for account registration
>> (XEP-0077) could benefit from an update, or even a replacement, and when
>> that work is completed I'd like to include a method by which a client
>> could register a key or cert with the server, thus smoothing the path
>> toward password-less authentication. IMHO that will be the best approach
>> in the longer term, instead of continually tweaking the password-based
>> methods. But that's a topic for another time...
>
> I also think transition-needed needs to be deprecated in favor of
> transition within the bound channel (e.g., today via XEP 77, tomorrow ?).

FWIW, I agree on all of these points.

-- Jeff

From Kurt.Zeilenga@Isode.COM  Wed Nov  3 08:02:21 2010
Return-Path: <Kurt.Zeilenga@Isode.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 A10373A6AC5; Wed,  3 Nov 2010 08:02:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.342
X-Spam-Level: 
X-Spam-Status: No, score=-102.342 tagged_above=-999 required=5 tests=[AWL=0.257, 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 Bx5c3JBFHp2o; Wed,  3 Nov 2010 08:02:20 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 676D828C0DF; Wed,  3 Nov 2010 08:02:20 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <TNF5gAAEeXTI@rufus.isode.com>; Wed, 3 Nov 2010 15:02:26 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
In-Reply-To: <4CD151F7.6060809@stpeter.im>
Date: Wed, 3 Nov 2010 08:02:22 -0700
Message-Id: <F7E7C266-C802-4487-8A0F-DE930EBB2098@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <4CD071D5.3080808@stpeter.im> <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM> <4CD08E62.3060202@stpeter.im> <03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM> <4CD151F7.6060809@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>
Subject: Re: [secdir] [xmpp] 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: Wed, 03 Nov 2010 15:02:21 -0000

On Nov 3, 2010, at 5:13 AM, Peter Saint-Andre wrote:
> You make a compelling argument. I wish you had made that argument =
months
> ago, but it is compelling.  Indeed, it leads in the direction of two
> consensus calls within the XMPP WG:
>=20
> (a) to remove the <transition-needed/> SASL error condition
>=20
> (b) to remove TLS plus SASL PLAIN as MTI for confidentiality and
> authentication
>=20
> Ideally, both of those changes would be accompanied by additional
> security-related text, and in case (b) an interoperability note.

First, I note that (b) is a no-op in practice.  Implementations are =
going to support SASL PLAIN regardless.  Hell, we could even MUST NOT it =
and folks would still implement it.  It's simply too damn necessary for =
integration with 'legacy' password stores.  (I still rather we not MTI =
PLAIN.)

Second, (a) only removes one of two significant downgrade attack =
vectors, the other vector being the mechanisms advertisement and its =
handling.  (I still rather we remove it.)

While we can well craft our security warnings and considerations and =
guidance on how to use unauthenticated v. authenticated TLS and hope =
that client developers get it right.  Basically that text would say "use =
authenticated TLS" to protect against downgrade attack.  That sounds =
great but I doubt its going to have much effect (though I think it still =
should be said).  Clients are still going to offer user's security check =
bypasses and users are going to continue to take those bypasses.

Also as I noted previously, these problems are not unique to XMPP.  =
Instead of slowing down the publication of XMPP, it might be better to =
spin a more general effort to explore ways to address security issues =
due to general assumption that TLS will be used with server =
authentication when it is often used without server authentication, and =
more generally, explore ways to address the "user click through" problem =
(that is, how to secure protocols such that bypasses are less needed).

Lastly, please note that I don't consider this issue 'critical' at this =
point.  It's not going to be critical until such attacks are far more =
common place.  The best way to currently mitigate such attacks is to =
restrict the set of usable mechanisms to those immune to the attack.  =
(For enterprises which provide 'client builds' to their users, they can =
do this for their users as part of those builds.  But, in general, this =
requires user configuration and hence prone to failure.)

-- Kurt


From Kurt.Zeilenga@isode.com  Wed Nov  3 14:03:42 2010
Return-Path: <Kurt.Zeilenga@isode.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 666E23A688D; Wed,  3 Nov 2010 14:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.374
X-Spam-Level: 
X-Spam-Status: No, score=-102.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 HAlsPV3b8SUt; Wed,  3 Nov 2010 14:03:41 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 3F6EF3A66B4; Wed,  3 Nov 2010 14:03:41 -0700 (PDT)
Received: from [192.168.42.5] (75-141-240-242.dhcp.reno.nv.charter.com [75.141.240.242])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id <TNHOMQAEebuE@rufus.isode.com>; Wed, 3 Nov 2010 21:03:47 +0000
From: Kurt Zeilenga <Kurt.Zeilenga@isode.com>
In-Reply-To: <AANLkTinmSdGN2D1ZzwCQy9iYTTfSfXoF+T+nBOxcLkPv@mail.gmail.com>
Date: Wed, 3 Nov 2010 14:03:42 -0700
Message-Id: <28590B36-877A-47AF-9B7A-D5A3FA3B2079@isode.com>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <4CD071D5.3080808@stpeter.im> <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM> <4CD08E62.3060202@stpeter.im> <03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM> <4CD151F7.6060809@stpeter.im> <F7E7C266-C802-4487-8A0F-DE930EBB2098@Isode.COM> <4CD19C81.9050509@stpeter.im> <AANLkTinmSdGN2D1ZzwCQy9iYTTfSfXoF+T+nBOxcLkPv@mail.gmail.com>
To: Matthew Wild <mwild1@gmail.com>
X-Mailer: Apple Mail (2.1081)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: Security Area Directorate <secdir@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, XMPP Working Group <xmpp@ietf.org>, The IESG <iesg@ietf.org>, Peter Saint-Andre <stpeter@stpeter.im>
Subject: Re: [secdir] [xmpp] 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: Wed, 03 Nov 2010 21:03:42 -0000

On Nov 3, 2010, at 11:10 AM, Matthew Wild wrote:

> On 3 November 2010 17:31, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:
>>=20
>=20
>>      as described under Section 13.7.2.1 (however, the lack of =
channel
>>      binding in the PLAIN mechanism implies that even authenticated =
TLS
>>      cannot fully protect the SASL negotiation and subsequent
>>      communications when PLAIN is used).
>>=20
>=20
> I'm no expert on this, but is this text technically true? I thought
> channel binding would only be beneficial where there is not full TLS
> authentication.

Channel binding is beneficial regardless of whether there the client =
performed TLS server cert/subject checks.  Note that the server has no =
clue what checks, if any, the client (or its user) performed.  With =
channel bindings, it becomes irrelevant to the server whether the client =
performed these checks or not.  That is, (amongst other things) channel =
bindings provide a means for the server itself to protect against MITM =
attacks.

I do agree, however, that he wording of the however comment is confusing =
and seems should either be removed or replaced.

My main concern is that Unauthenticated TLS is subject to downgrade to =
PLAIN by two vectors, spoofing mechanisms and spoofing transition =
required.

Removing <transition-needed/> (in favor of a yet to be specified =
extension) addresses one vector.

There seems no good way to address the other vector at this time.  I do =
suggest however that the 13.9.4 text:
   To help prevent this attack, the parties
   SHOULD protect the channel using TLS before attempting SASL
   negotiation.
be replaced with:
   To mitigate this attack, the partied SHOULD protect the channel using =
TLS before attempting SASL negotiation and either
   perform full certificate validation as described in Section 13.7.2.1 =
or utilize a mechanism which provides channel bindings,
   such as SCRAM-SHA-1-PLUS.=20

-- Kurt=

From gonzalo.camarillo@ericsson.com  Thu Nov  4 00:38:14 2010
Return-Path: <gonzalo.camarillo@ericsson.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 197BD3A69D0 for <secdir@core3.amsl.com>; Thu,  4 Nov 2010 00:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 a2Knzq3lXCd1 for <secdir@core3.amsl.com>; Thu,  4 Nov 2010 00:38:05 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 220493A69D6 for <secdir@ietf.org>; Thu,  4 Nov 2010 00:34:41 -0700 (PDT)
X-AuditID: c1b4fb3d-b7b28ae00000135b-02-4cd261f76838
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D5.6B.04955.7F162DC4; Thu,  4 Nov 2010 08:34:15 +0100 (CET)
Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 4 Nov 2010 08:34:15 +0100
Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Thu, 4 Nov 2010 08:34:14 +0100
Message-ID: <4CD261F6.8070108@ericsson.com>
Date: Thu, 04 Nov 2010 09:34:14 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
References: <p06240800c8e55027a17b@[128.89.89.159]> <4CC81942.3060502@ericsson.com>
In-Reply-To: <4CC81942.3060502@ericsson.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Nov 2010 07:34:14.0554 (UTC) FILETIME=[AE3A27A0:01CB7BF2]
X-Brightmail-Tracker: AAAAAA==
Cc: "secdir@ietf.org" <secdir@ietf.org>, "gao.yang2@zte.com.cn" <gao.yang2@zte.com.cn>, "pkyzivat@cisco.com" <pkyzivat@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>, "tim.polk@nist.gov" <tim.polk@nist.gov>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
Subject: Re: [secdir] review of draft-ietf-sipcore-reinvite-06.txt
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: Thu, 04 Nov 2010 07:38:14 -0000

Hi Stephen,

did you have a chance to check whether my suggestions in the email below
address your concerns?

Thanks,

Gonzalo

On 27/10/2010 3:21 PM, Gonzalo Camarillo wrote:
> Hi Stephen,
> 
> thanks for your review. My answers inline:
> 
> On 21/10/2010 5:17 AM, Stephen Kent wrote:
>> I reviewed this document as part of the security directorate's 
>> ongoing effort to review all IETF documents being processed by the 
>> IESG.  These comments were written primarily for the benefit of the 
>> security area directors.  Document editors and WG chairs should treat 
>> these comments just like any other last call comments.
>>
>> This document (draft-ietf-sipcore-reinvite-06.txt) provides 
>> clarification on how to process a re-invite in SIP. The notion of a 
>> re-invite is defined in RFC 3261 (SIP). This document was created to 
>> clarify the description provided in 3261, based on feedback from 
>> implementers. It includes a number of examples designed to clarify. 
>> It is fair to say that this document not only offers clarifications, 
>> but also makes some changes to SIP handling of re-INVITEs. For 
>> example, the document notes that "Section 4.3 specifies new rules for 
>> the handling of target-refresh requests."
>>
>> The document makes reference to "properly" authenticated requests in 
>> a couple of places (4.4 & 4.6), but provides no indication of what 
>> constitutes proper authentication. I think it would be appropriate to 
>> include references to whatever SIP security mechanisms are currently 
>> recommended for message/session authentication (as opposed to what 
>> 3261 said 8 years ago).
> 
> I suggest adding the following text in both places: "(see Section 26.2
> of RFC 3261)".
> 
> http://tools.ietf.org/html/rfc3261#section-26.2
> 
> The way user agents authenticate incoming requests has not changed much
> since RFC 3261 was published.
> 
>> The document has a trivial Security Considerations section:
>>
>>     This document does not introduce any new security issue.  It just
>>     clarifies how certain transactions should be handled in SIP.
>>     Security issues related to re-INVITEs and UPDATE requests are
>>     discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311].
>>
>> I checked 3261 and I agree that this document provides a decent 
>> review of security for SIP in general, but it makes no specific 
>> mention of UPDATE or (re)INVITE messages and attendant security 
>> concerns. RFC 3311 has an almost trivial Security Considerations 
>> section, but at least it does specifically refer to UPDATE and 
>> (re-)Invite messages, briefly, and the need for authentication. I 
>> think it would be appropriate to add a discussion of how these 
>> clarifications operate in various SIP security contexts, e.g., use of 
>> TLS for point-to-point SIP security or use of S/MIME for end-to-end 
>> SIP security. A statement that the security offered for SIP when the 
>> initial call setup was processed cannot be undermined by a later 
>> re-INVITE or UPDATE would be reassuring (if accompanied by a 
>> rationale for that statement :).
>>
> 
> I suggest adding the following text to the Security Considerations
> Section. Feel free to edit the text if you wish:
> 
> "In particular, in order not to reduce the security level for a given
> session, re-INVITEs and UPDATE requests SHOULD be secured in a similar
> or stronger manner as the initial INVITE request that created the
> session. For example, if the initial INVITE request was end-to-end
> integrity protected or encrypted, subsequent re-INVITEs and UPDATE
> requests should also be so."
> 
> A discussion on which security mechanisms should be applied in different
> contexts in outside the scope of this document, IMHO. SIP has been and
> is being deployed in so different environments that we would need a
> whole document (or more likely a set of them) to discuss all relevant
> issues.
> 
> Thanks,
> 
> Gonzalo
> 
> 

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Hirsalantie 11            Mobile:  +358 40 702 35 35
Ericsson                  Fax   :  +358  9 299 35 35
02420 Jorvas              Email :  Gonzalo.Camarillo@ericsson.com
Finland                   http://www.piuha.fi/~gonzalo

From yaronf.ietf@gmail.com  Thu Nov  4 09:02:25 2010
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 025F13A6927; Thu,  4 Nov 2010 09:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 Jk1kJz3EexQA; Thu,  4 Nov 2010 09:02:24 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id AA37E3A6848; Thu,  4 Nov 2010 09:02:23 -0700 (PDT)
Received: by gwb15 with SMTP id 15so1619625gwb.31 for <multiple recipients>; Thu, 04 Nov 2010 09:02:33 -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=zTkd5/6R8ztF9mUl78ebkTyDcekzX/TctEqMneKn/LE=; b=xXVxEUDwfvvrNzhMFMwn6BEb2stQCXTECoqHCzOTuLYdC1BEHOEB28NEbskCkX4Yp6 /CyCCu6AohNizqaOCDyQEqnPhoxWUHSOI/WHTUDcuhV8K1v+9X6VKsCtnRLBhhWzYCkY 5ZbVAS+weenOwyWYmlUO2o7V3fozxb+EDnFOM=
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=WgBl28rpXF0cKq9OZ9vHNHY7seVIgJsuDyJQXHuFyK+I+Zw8AsHYDsFQ6fWase3PRK XfCdPQG/MALIUDGOFSraJYjUujju2L/6+33OOmHeX02GAWLZE0QqqvXgwV/qDaKm3ggM /k2aW0A6CXFm4nfNOMy8mlaS90X07iQBjrl1k=
Received: by 10.204.53.193 with SMTP id n1mr851022bkg.3.1288886552957; Thu, 04 Nov 2010 09:02:32 -0700 (PDT)
Received: from [192.168.0.102] ([95.35.139.62]) by mx.google.com with ESMTPS id t10sm90368bkj.4.2010.11.04.09.02.27 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Nov 2010 09:02:30 -0700 (PDT)
Message-ID: <4CD2D90F.6040304@gmail.com>
Date: Thu, 04 Nov 2010 18:02:23 +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>	<4CCE87A5.80701@gmail.com> <4CCF20E7.30401@stpeter.im> <4CD1D708.7010308@stpeter.im>
In-Reply-To: <4CD1D708.7010308@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] [xmpp] 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: Thu, 04 Nov 2010 16:02:25 -0000

Hi Peter,

yes, these seem reasonable. Is there a "converse" to the rewriting of 
the client's From header before forwarding to other servers, i.e. is 
there a server-side check on stanza From headers received from other 
servers?

Thanks,
	Yaron

On 11/03/2010 11:41 PM, Peter Saint-Andre wrote:
> Hi Yaron, following up our discusion, here is proposed text for the
> conformance features you suggested...
>
> On 11/1/10 2:19 PM, Peter Saint-Andre wrote:
>> On 11/1/10 3:25 AM, Yaron Sheffer wrote:
>>
>>> On 10/30/2010 07:05 AM, Peter Saint-Andre wrote:
>>>>
>>>> On 10/28/10 4:28 AM, Yaron Sheffer wrote:
>>>>
>>>>> - 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.
>
> I think we can combine client and server validation into two features
> (instead of four), one for TLS and one for SASL.
>
> The TLS feature would be:
>
>     Feature:  tls-correlate
>     Description:  When validating a certificate presented by a stream
>        peer during TLS negotiation, correlate the validated identity with
>        the 'from' address (if any) of the stream header it received from
>        the peer.
>     Section:  Section 13.7.2
>     Roles:  Client SHOULD, Server SHOULD.
>
> As a target for that pointer, I think we need to add the following
> paragraph to the end of Section 13.7.2 ("Certificate Validation"):
>
>     Once the identity of the stream peer has been validated, the
>     validating entity SHOULD also correlate the validated identity with
>     the 'from' address (if any; see Section 4.6.1) of the stream header
>     it received from the peer.  If the two identities do not match, the
>     validating entity SHOULD terminate the connection attempt.
>
> The SASL feature would be:
>
>     Feature:  sasl-correlate
>     Description:  When authenticating a stream peer using SASL, correlate
>        the authentication identifier resulting from SASL negotiation with
>        the 'from' address (if any) of the stream header it received from
>        the peer.
>     Section:  Section 6.4.6
>     Roles:  Client N/A, Server SHOULD.
>
> As a target for that pointer, I think we need to add the following
> paragraph to the beginning of Section 6.4.6 ("SASL Success"):
>
>     Before considering the SASL handshake to be a success, the receiving
>     entity SHOULD correlate the authentication identity resulting from
>     the SASL negotiation with the 'from' address (if any; see
>     Section 4.6.1) of the stream header it received from the initiating
>     entity.  If the two identities do not match, the receiving entity
>     SHOULD terminate the connection attempt.
>
> Finally, we need one more feature, for server stamping of client 'from'
> addresses:
>
>     Feature:  stanza-attribute-from-stamp
>     Description:  Stamp or rewrite the 'from' address of all stanzas
>        received from connected clients.
>     Section:  Section 8.1.2.1
>     Roles:  Client N/A, Server MUST.
>
> Let me know if those seem reasonable.
>
> Peter
>

From scott@hyperthought.com  Thu Nov  4 09:31:24 2010
Return-Path: <scott@hyperthought.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 DBF203A69DC for <secdir@core3.amsl.com>; Thu,  4 Nov 2010 09:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.061
X-Spam-Level: 
X-Spam-Status: No, score=-4.061 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 r-6OK04xXgwY for <secdir@core3.amsl.com>; Thu,  4 Nov 2010 09:31:22 -0700 (PDT)
Received: from smtp132.iad.emailsrvr.com (smtp132.iad.emailsrvr.com [207.97.245.132]) by core3.amsl.com (Postfix) with ESMTP id 9FF633A6927 for <secdir@ietf.org>; Thu,  4 Nov 2010 09:31:22 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp43.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id B20F22D0803; Thu,  4 Nov 2010 12:31:32 -0400 (EDT)
X-Virus-Scanned: OK
Received: from dynamic4.wm-web.iad.mlsrvr.com (dynamic4.wm-web.iad1a.rsapps.net [192.168.2.153]) by smtp43.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 779382D07DD; Thu,  4 Nov 2010 12:31:32 -0400 (EDT)
Received: from hyperthought.com (localhost [127.0.0.1]) by dynamic4.wm-web.iad.mlsrvr.com (Postfix) with ESMTP id 567211D4A25F;  Thu,  4 Nov 2010 12:31:32 -0400 (EDT)
Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com)  with HTTP; Thu, 4 Nov 2010 09:31:32 -0700 (PDT)
Date: Thu, 4 Nov 2010 09:31:32 -0700 (PDT)
From: "Scott G. Kelly" <scott@hyperthought.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-avt-rtp-h264-rcdo.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain;charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Importance: Normal
X-Priority: 3 (Normal)
X-Type: plain
Message-ID: <1288888292.35265529@192.168.2.228>
X-Mailer: webmail8
Subject: [secdir] secdir review of draft-ietf-avt-rtp-h264-rcdo-07
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: Thu, 04 Nov 2010 16:31:24 -0000

I have reviewed this document as part of the security directorate's ongoing=
 effort to review all IETF documents being processed by the IESG.  These co=
mments were written primarily for the benefit of the security area director=
s.  Document editors and WG chairs should treat these comments just like an=
y other last call comments.=0A=0AThis draft describes a new RTP payload for=
mat, extending existing RTP capabilities. Based on my limited understanding=
 of RTP, this introduces no new security considerations.=0A=0AThe security =
considerations section starts off by saying this, but then goes on to talk =
about various security properties that could be added by various means. I f=
ound the text to be a little confusing, especially when it makes recommenda=
tions without detailing any particular threats.=0A=0AI would suggest simpli=
fying the security considerations. Here is the current text:=0A=0A  "RTP pa=
ckets using the payload format defined in this specification=0A   are subje=
ct to the security considerations discussed in the RTP=0A   specification [=
6], and in any applicable RTP profile.  The main=0A   security consideratio=
ns for the RTP packet carrying the RTP payload=0A   format defined within t=
his document are confidentiality, integrity=0A   and source authenticity.  =
Confidentiality is achieved by encryption=0A   of the RTP payload.  Integri=
ty of the RTP packets through suitable=0A   cryptographic integrity protect=
ion mechanism.  Cryptographic system=0A   may also allow the authentication=
 of the source of the payload.  A=0A   suitable security mechanism for this=
 RTP payload format should=0A   provide confidentiality, integrity protecti=
on and at least source=0A   authentication capable of determining if an RTP=
 packet is from a=0A   member of the RTP session or not.=0A=0A   Note that =
the appropriate mechanism to provide security to RTP and=0A   payloads foll=
owing this document may vary.  It is dependent on the=0A   application, the=
 transport, and the signalling protocol employed.=0A   Therefore a single m=
echanism is not sufficient.  Usage of data origin=0A   authentication and d=
ata integrity protection of at least the RTP=0A   packet is RECOMMENDED, fo=
r example by use of the Secure Real-time=0A   Transport Protocol (SRTP) [12=
].  Other mechanisms that may be used=0A   are IPsec [13] and Transport Lay=
er Security (TLS) [14] (RTP over=0A   TCP), but other alternatives may exis=
t.=0A=0A   Refer also to section 9 of RFC YYYY [3], as no reasons for separ=
ate=0A   considerations are introduced in this document."=0A=0A=0AI would s=
uggest the following simplified text:=0A=0A  "RTP packets using the payload=
 format defined in this specification=0A   are subject to the security cons=
iderations discussed in the RTP=0A   specification [6], and in any applicab=
le RTP profile.  No additional=0A   security considerations are introduced =
by this specification."=0A=0A(or something like this).=0A=0A--Scott=0A


From stpeter@stpeter.im  Mon Nov  1 19:59:09 2010
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 CAA0F3A6868; Mon,  1 Nov 2010 19:59:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level: 
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 0Ztdf8neE2gI; Mon,  1 Nov 2010 19:59:08 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 46FB43A682A; Mon,  1 Nov 2010 19:59:08 -0700 (PDT)
Received: from squire.local (dsl-175-35.dynamic-dsl.frii.net [216.17.175.35]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3799340D1E; Mon,  1 Nov 2010 21:07:43 -0600 (MDT)
Message-ID: <4CCF7E7A.5050303@stpeter.im>
Date: Mon, 01 Nov 2010 20:59:06 -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: Dave Cridland <dave@cridland.net>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im>	<4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture>
In-Reply-To: <2761.1288645043.347835@puncture>
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="------------ms000309080307060705020302"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Florian Zeitz <florob@babelmonkeys.de>, Security Area Directorate <secdir@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, XMPP Working Group <xmpp@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 02:59:10 -0000

This is a cryptographically signed message in MIME format.

--------------ms000309080307060705020302
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/1/10 2:57 PM, Dave Cridland wrote:
> On Mon Nov  1 18:20:03 2010, Florian Zeitz wrote:
>> >> I think it's better to remove TLS plus SASL PLAIN from the list of
>> >> mandatory-to-implement technologies.
>> >>
>> > OK.
>> >
>> FWIW, I'm not entirely content with that for two reasons:
>=20
> I'll scrap yours, and add a third.
>=20
>=20
>> a) Even if TLS+SASL PLAIN is not MTI people still will and do implemen=
t
>> it. I think it would therefore make sense to still specify that PLAIN
>> shall only be used as a "last resort".
>>
>>
> I think SASL PLAIN should be specifying this. There's nothing special i=
n
> XMPP which makes PLAIN a poor choice.

I disagree -- it's our job to specify how we use the tools we've been giv=
en.

>> b) (which is my bigger concern) As strange as that may sound, we need
>> PLAIN in order to upgrade to a new mechanism. I though this was also
>> explicit in 3920bis, but I can't find it right now.
>> Consider a case where a server only stores the MD5 hash of the passwor=
d.
>> This is sufficient to do PLAIN and DIGEST MD5 auth. But for SCRAM a
>> different representation is needed.
>> The common way for the server to upgrade is to once offer only PLAIN a=
s
>> a mechanism. If that is not possible (clients can choose not to suppor=
t
>> PLAIN) some deployments might be stuck with DIGEST MD5...
>> We could mandate that PLAIN is only MTI for clients (servers would
>> implement it when they need to), but that would allow for the same
>> down-grade attacks that are already possible now (i.e. hopefully none
>> ;) ).
>=20
> You're thinking of transition-needed, which was IIRC removed from the
> bis drafts.
>=20
> It's pretty scary itself, as it provides an easy path to a downgrade
> attack.

If the stream is already TLS-protected, the attacker would need to have
control over the server (in which case the server wouldn't offer TLS in
the first place, of course). It seems to me that the client can take
appropriate protective measures to avoid this attack (just always force
TLS).

> But here's another compelling (in my view) reason to keep PLAIN, quoted=

> from the opening lines of RFC 4616:
>=20
>   Clear-text, multiple-use passwords are simple, interoperate with
>   almost all existing operating system authentication databases
>=20
> In particular, where we use an Active Directory, or other third-party
> LDAP directory, we more or less have to drop down to only offering
> PLAIN. (With AD we can also offer GSSAPI sometimes, but this isn't an
> ideal choice for an MTI, and with any LDAP directory we could provide
> SCRAM secrets to some extent).
>=20
> Requiring clients and servers to be capable of using PLAIN, whilst
> advising (and providing) better alternatives to cover other cases, seem=
s
> to be the best choice for interoperability.

IMHO that's been the experience of the XMPP community so far.

As mentioned, I'll work to capture these considerations in proposed text.=


Peter

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




--------------ms000309080307060705020302
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MjAyNTkwNlowIwYJKoZIhvcNAQkEMRYEFBryQedOrKsza44z502DZ+0B9MTEMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBvoBbhN2ss3/lCmbiL/sAeABXdr9QmvMebz7HEHRy+sWr9mfXNSql3THHo
/2ET9rIVq5DfHHMU2mQOyMuZ90GF3NQaTbEV3bKvcgzxtLsweUhEaILV/FQWwVTnfHF4ZTGa
BsbmaTJI5DpgsoHunzwHNeaVdV1sy6nUInJnX+SIpjaeFEXaB7cYraXd6FWMnQF9OSzrNeCf
JrOFjjP4+Qzhp/RsAeEq2tQLsg6mcua6EITGrA1qzuKlaWofXCjlta6LmuNhJRcAzjgGpEsD
cq0/iIT4fQ85HpMDHFmcYbmijT4WpSbZYYm9Xw4VpyGaxzTyb8Mm/J4M74FEmOa1fT3UAAAA
AAAA
--------------ms000309080307060705020302--

From stpeter@stpeter.im  Mon Nov  1 21:45:50 2010
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 1233C3A66B4; Mon,  1 Nov 2010 21:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.299
X-Spam-Level: 
X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 HIGtOywWodG6; Mon,  1 Nov 2010 21:45:44 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 9ED083A67CC; Mon,  1 Nov 2010 21:45:43 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 77A3740D1E; Mon,  1 Nov 2010 22:54:18 -0600 (MDT)
Message-ID: <4CCF9776.5060207@stpeter.im>
Date: Mon, 01 Nov 2010 22:45:42 -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: Dave Cridland <dave@cridland.net>
References: <4CC9503D.2000809@gmail.com>	<4CCBA7A9.7030506@stpeter.im>	<4CCE87A5.80701@gmail.com>	<4CCF04D3.6020504@babelmonkeys.de>	<2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im>
In-Reply-To: <4CCF7E7A.5050303@stpeter.im>
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="------------ms000403000101040301060400"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 04:45:50 -0000

This is a cryptographically signed message in MIME format.

--------------ms000403000101040301060400
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/1/10 8:59 PM, Peter Saint-Andre wrote:

> As mentioned, I'll work to capture these considerations in proposed tex=
t.

Here is proposed text. Please review and provide feedback.

###

13.8.  Mandatory-to-Implement Technologies

   The following TLS ciphersuites and SASL mechanisms are mandatory-to-
   implement (naturally, implementations MAY support other ciphersuites
   and mechanisms as well).  For security considerations related to TLS
   ciphersuites, see Section 13.9.4 and [TLS].  For security
   considerations related to SASL mechanisms, Section 13.9.4, [SASL],
   and specifications for particular SASL mechanisms such as [SCRAM],
   [DIGEST-MD5], and [PLAIN].

13.8.1.  For Authentication Only

   For authentication only, servers and clients MUST support the SASL
   Salted Challenge Response mechanism [SCRAM], in particular the SCRAM-
   SHA-1 variant (REQUIRED) and SCRAM-SHA-1-PLUS variant (RECOMMENDED if
   channel binding is possible).

      Security Note: Even though it is possible to complete
      authentication only without confidentiality, it is RECOMMENDED for
      servers and clients to protect the stream with TLS before
      attempting authentication with SASL, both to help protect the
      information exchanged during SASL negotiation and to help prevent
      certain downgrade attacks; see also Section 13.9.4 and
      Section 13.9.5.

      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.  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.8.2.  For Confidentiality Only

   For confidentiality only, servers SHOULD support TLS with the
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.

      Security Note: Because a connection with confidentiality only has
      weaker security properties than a connection with both
      confidentiality and authentication, it is RECOMMENDED for servers
      and clients to prefer connections with both qualities (e.g., by
      protecting the stream with TLS before attempting authentication
      with SASL).  In practice, confidentiality only is employed merely
      for server-to-server connections when the peer server does not
      present a certificate and the servers use Server Dialback
      [XEP-0220] for weak identity verification, but TLS is still
      desirable to protect the connection against casual eavesdropping.

13.8.3.  For Confidentiality and Authentication With Passwords

   For both confidentiality and authentication with passwords, servers
   and clients MUST support TLS with the TLS_RSA_WITH_AES_128_CBC_SHA
   ciphersuite plus SCRAM-SHA-1 and (when channel binding is possible)
   SCRAM-SHA-1-PLUS.

   As a fallback when SCRAM is not available, servers MAY offer and
   clients MAY use TLS with the TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite
   plus SASL PLAIN.

      Security Note: The SCRAM-SHA-1 and SCRAM-SHA-1-PLUS mechanisms are
      strongly preferred over the SASL PLAIN mechanism because of their
      superior security properties.  TLS plus SASL PLAIN is primarily
      intended to be a fallback for implementations that do not yet
      support SCRAM.  However, in certain deployment scenarios it can be
      difficult for a server to offer SCRAM-based mechanisms (e.g.,
      because the XMPP service depends for authentication purposes on a
      database or directory that is not under the control of the XMPP
      administrators).  Furthermore, it can be appropriate for an XMPP
      service to offer the SASL PLAIN mechanism when it upgrades
      security mechanisms and needs the plaintext password in order to
      seed user credentials (see Section 6.5.12).  A client needs to
      treat all such uses of the SASL PLAIN mechanism with caution, MUST
      prefer other mechanisms (e.g., SCRAM-SHA-1, SCRAM-SHA-1-PLUS, and
      EXTERNAL) to the PLAIN mechanism, and MUST NOT use the PLAIN
      mechanism without confidentiality and integrity protection via
      TLS.

13.8.4.  For Confidentiality and Authentication Without Passwords

   For both confidentiality and authentication without passwords,
   servers MUST and clients SHOULD support TLS with the
   TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus the SASL EXTERNAL
   mechanism (see Appendix A of [SASL]) supporting PKIX certificates.

###

Peter

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




--------------ms000403000101040301060400
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MjA0NDU0MlowIwYJKoZIhvcNAQkEMRYEFAVgA2OLglfOQQwX79j94rrA2AnBMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQA1THRPHs7BXWlk1H3SRoe95SX1Syf/2A9ceVBolOQdSkquQ7oKHrd5cXMO
VZqbRd9qj4aT8kYJnZu6zPDEqtSsRDjqTqcd1bqxx8BGMP9gIDOL5LWIH+/gS91ie1wtDwl0
d2HNddW06qXl38jS9M1ZnstDezR37ZSZsJ7A2BzBqzV0iIqS2rRSF5/Vk9Hxx5TDRETELZqI
tmifmdScbyv7W4tBEhnbNx8afLdUZN5LCDrDUJmWHWX8Y0gmmgymRFnc5UOYwJATqyrj3rka
TqJo7Mi7rUXo7XqjwYaYwlBvqd86OlvFB1c6fZTkeV4OgYtmJhtdeSgftPI0GhUBNfcRAAAA
AAAA
--------------ms000403000101040301060400--

From stpeter@stpeter.im  Tue Nov  2 05:06:48 2010
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 2EC0C3A68D2; Tue,  2 Nov 2010 05:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 dFo0ZqShYzTi; Tue,  2 Nov 2010 05:06:46 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 551AE3A676A; Tue,  2 Nov 2010 05:06:46 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8177340D1E; Tue,  2 Nov 2010 06:15:24 -0600 (MDT)
Message-ID: <4CCFFED7.70208@stpeter.im>
Date: Tue, 02 Nov 2010 06:06:47 -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> <4CCF20E7.30401@stpeter.im> <4CCFF1B0.4080007@gmail.com>
In-Reply-To: <4CCFF1B0.4080007@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="------------ms010104080901090304050100"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -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: Tue, 02 Nov 2010 12:06:48 -0000

This is a cryptographically signed message in MIME format.

--------------ms010104080901090304050100
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/2/10 5:10 AM, Yaron Sheffer wrote:
>=20
> On 11/01/2010 10:19 PM, Peter Saint-Andre wrote:
>> On 11/1/10 3:25 AM, Yaron Sheffer wrote:
>>
>> >>> - 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 add=
ing
>> >> 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 t=
hat
>> >> 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 see=
ms
>> > 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 Secti=
on
>> 13.7.2 as follows, breaking it into bullets for easier readability:
>>
>> ###
>>
>>     For both server certificates and client certificates, the validati=
ng
>>     entity MUST do the following:
>>
>>     1.  Attempt to verify the integrity of the certificate.
>>
>>     2.  Attempt to verify that the certificate has been properly signe=
d
>>         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.
>>
>> ###
>>
> This is all fine, other than the last sentence. There's little security=

> value (or performance value, for that matter) in "MUST check, but only
> MAY choose to fail". With possible minor exceptions, these rules are al=
l
> security-critical.

Very true. At the least, SHOULD is much more appropriate, and even then
there are, as you say, only some possible minor exceptions (which I
think are RECOMMENDED in the profile, e.g., including the address of an
OCSP responder).

>> >>> - 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 matt=
ers
>> >> is that the client authenticates using the credentials of a registe=
red
>> >> 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-CERT=
S])
>> >> the initiating entity sets its reference identifier to the 'to'
>> address
>> >> it communicates in the initial stream header, and the receiving ent=
ity
>> >> 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). Pe=
r
>> >> 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 identifi=
er
>> >>      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 initia=
l
>> >>         stream header; i.e., this is the identity that the initiati=
ng
>> >>         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 th=
e
>> >>         identity it expects the server to provide in a PKIX
>> certificate.
>> >>
>> >>      o  The server sets its reference identifier to the 'from' addr=
ess
>> >>         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?
>>
> Yes, definitely.
>=20
>> >>> - 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 th=
e
>> core spec so that they could be updated more frequently. Maybe we'll d=
o
>> that in the next revision cycle (which will result in a much smaller
>> diff).
>>
> I also think it's a good idea.

It seems a bit late in this revision cycle to do that, but as mentioned
I think we'll be working on 3920ter after a year or more of experience
with the spec you've reviewed (and after we've had a chance to fix up
the address format based on the results of the PRECIS WG), so I think
that would be a good time to help ensure the longevity of the specs by
moving the MTI security technologies into a "living document". I don't
know if any other application protocols have done that, but I'll ask the
Security ADs for advice about how we might proceed when the time comes.

Peter

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




--------------ms010104080901090304050100
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MjEyMDY0N1owIwYJKoZIhvcNAQkEMRYEFGnqL6ZCY77i523pslVmKtgW5S2DMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCDhmubIKzhS9fpnTfouM0Frl8HUxv15wLTWpbeZEd0piPpbx8SE3qlnGZQ
/bOuv83fH3qIu4g+hVORFWfCDHl//szcCwxTOH9ADN31mOdW+d9FeWRNIKpNbAIi4J5F4V0K
10DTtIUv89V5HXtssTO5LyvDPtFp4UeWczKeouovBKkAvchWgWU0vZ3RJ6jTnkhTt/LlNGky
iDZDsCCizIpilnXbbblSM58JmUFfH6CfKoMbR2EEC1Sekfi2vONJBuLRH+IhxbtaNRKp58Fq
EIE3w9sJMas4t64hdCbYrm1Qd3dOSqsIsWGmD3lpzioG/tW3lJsiFQFm22ZFnkGNYYxEAAAA
AAAA
--------------ms010104080901090304050100--

From stpeter@stpeter.im  Tue Nov  2 05:12:20 2010
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 80D4D28B797; Tue,  2 Nov 2010 05:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 54wjKADYhNDF; Tue,  2 Nov 2010 05:12:19 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 0D5093A69AC; Tue,  2 Nov 2010 05:12:19 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD41A40D1E; Tue,  2 Nov 2010 06:20:57 -0600 (MDT)
Message-ID: <4CD00025.8030804@stpeter.im>
Date: Tue, 02 Nov 2010 06:12:21 -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>	<4CCF04D3.6020504@babelmonkeys.de>	<2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com>
In-Reply-To: <4CCFF3E6.7040800@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="------------ms060105040903000904080408"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Dave Cridland <dave@cridland.net>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 12:12:20 -0000

This is a cryptographically signed message in MIME format.

--------------ms060105040903000904080408
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/2/10 5:20 AM, Yaron Sheffer wrote:
> I'm OK with this text, including (sigh) PLAIN.

If it's any consolation, I'm sighing along with you. :)

Two points:

1. Eventually, we should be able to drop PLAIN in a future revision of
the MTI technologies spec that we'll pull out of 3920bis in 1+ years.

2. The technology that the XMPP community uses for account registration
(XEP-0077) could benefit from an update, or even a replacement, and when
that work is completed I'd like to include a method by which a client
could register a key or cert with the server, thus smoothing the path
toward password-less authentication. IMHO that will be the best approach
in the longer term, instead of continually tweaking the password-based
methods. But that's a topic for another time...

Peter

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




--------------ms060105040903000904080408
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MjEyMTIyMVowIwYJKoZIhvcNAQkEMRYEFGZxle9Fbt4BG7bAN3E2sTcS5wBAMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCTxSvCmi0J/yMryFBWQpMUYyG+/+FgqXTAUP/UAkQv/LWfSS+BWUsKPbzW
4KM0qxyN3QweESRRF5kxVyZDA8A5Cic+W9gHwvwcdRTdauuYN42AjM4jwR6ML6PEFjs9k7xJ
3EtbOaLbdABl0BrzIDD2gfRyQVe3VpTVN3W3SH+OtkLct2zgyoJl1HvnSbgzweAmPkHytLQD
zxF+Kr97DK1vwF0faiLdTX3Xl2ShAenRixVi/XvlJupnI07WHegrXk+Ta6hJvNoRwm5yOgpz
5wgPUh9QN4fXqJNTwCfLgjABlg1QAqeg3uJLn+JMM+BHKI+b50d2xge4LnMBX4yqaiKTAAAA
AAAA
--------------ms060105040903000904080408--

From stewe@stewe.org  Tue Nov  2 07:12:49 2010
Return-Path: <stewe@stewe.org>
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 56F103A687F; Tue,  2 Nov 2010 07:12:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Y2kyAIa7gOPr; Tue,  2 Nov 2010 07:12:48 -0700 (PDT)
Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 4F70F3A68D6; Tue,  2 Nov 2010 07:12:45 -0700 (PDT)
Received: from [172.16.7.203] (unverified [160.79.219.114])  by stewe.org (SurgeMail 3.9e) with ESMTP id 11732-1743317  for multiple; Tue, 02 Nov 2010 15:11:40 +0100
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Tue, 02 Nov 2010 10:07:13 -0400
From: Stephan Wenger <stewe@stewe.org>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, <julienl@qualcomm.com>, <draft-ietf-avt-rtp-svc@tools.ietf.org>, <secdir@ietf.org>, <iesg@ietf.org>
Message-ID: <C8F58A4B.23F35%stewe@stewe.org>
Thread-Topic: SECDIR Review of draft-ietf-avt-rtp-svc-23
In-Reply-To: <4CC6B2E6.9090408@ericsson.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Originating-IP: 160.79.219.114
X-Authenticated-User: stewe@stewe.org 
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Ye-Kui Wang <yekuiwang@huawei.com>, Alex Eleftheriadis <alex@vidyo.com>, Thomas Schierl <schierl@hhi.fhg.de>, avt-chairs@tools.ietf.org, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
Subject: Re: [secdir] SECDIR Review of draft-ietf-avt-rtp-svc-23
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: Tue, 02 Nov 2010 14:12:49 -0000

Hi all,

Julien, thanks for your thoughtful review.  After (rather loose)
coordination with my co-authors, here is our input.  In summary, the
editorial changes requested are fine with us and will be worked in
(chairs/Ads, please advise whether doing this during AUTH48 is ok).  As
for the non-editorial points, please see inline.


On 10.26.2010 03:52 , "Gonzalo Camarillo" <Gonzalo.Camarillo@ericsson.com>
wrote:

>[...]
>This document describes an RTP payload format for Scalable Video Coding
>that is applicable to applications such as video streaming.
>
>Disclaimer: I am not familiar with RTP applications, and even less with
>video coding. However, it appears that the security considerations MAY
>need more work:
>
>> 8. Security Considerations
>>
>>   Section 9 of [I-D.ietf-avt-rtp-rfc3984bis] applies.  Additionally,
>>   the following applies.
>
>Suggest rewording: "The security considerations of the RTP Payload
>Format for H.264 Video specification [I-D.ietf-avt-rtp-rfc3984bis]
>applies."
>
>Also, the reference is not listed in the {Normative, Informative}
>Reference Section.

OK.  

>
>>   Decoders MUST exercise caution with respect to the handling of
>>   reserved NAL unit types and reserved SEI messages, particularly if
>>   they contain active elements, and MUST restrict their domain of
>>   applicability to the presentation containing the stream.  The safest
>>   way is to simply discard these NAL units and SEI messages.
>
>Maybe this is due to my ignorance about coding but I find this
>underspecified, notably given the presence of the MUST key word. How
>about spelling exactly what a decoder MUST do, as opposed to say
>"exercise caution". E.g., "Decoders MUST discard NAL units and SEI
>messages.", and then explain why, or point to
>[I-D.ietf-avt-rtp-rfc3984bis] if there's a good explanation there.

This point is non-trivial, and I will answer it in separate email.  To
summarize, we adapted the (back since when highly contested) language from
RFC 3984 with modifications in video coding terminology only, and would
prefer not to reopen this issue.

>
>>   When integrity protection is applied, care MUST be taken that the
>>   stream being transported may be scalable; hence a receiver may be
>>   able to access only part of the entire stream.
>
>Hmm. If integrity protection is applied to the RTP packet, and not to
>the video content being encoded in a scalable manner, there shouldn't be
>a problem, right? So maybe you need to qualify the object to which
>integrity protection is applied in the statement above. Is it the RTP
>packet, or the stream?

We were thinking about "stream", and, yes, a clarification needs to be
added.

>
>>      Informative note: Other security aspects, including
>>      confidentiality, authentication, and denial-of-service threat,
>>      for SVC are similar as H.264/AVC, as discussed in Section 9 of
>>      [I-D.ietf-avt-rtp-rfc3984bis].
>
>This seems redundant with the first paragraph of the Security
>Considerations that already stated that Section 9 of
>[I-D.ietf-avt-rtp-rfc3984bis] applies.

Will be removed.

>
>HTH,
>
>--julien
>



From stewe@stewe.org  Tue Nov  2 07:12:50 2010
Return-Path: <stewe@stewe.org>
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 00A833A687F; Tue,  2 Nov 2010 07:12:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396]
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 3S3DVh4RBT3c; Tue,  2 Nov 2010 07:12:49 -0700 (PDT)
Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 4F7723A69A8; Tue,  2 Nov 2010 07:12:45 -0700 (PDT)
Received: from [172.16.7.203] (unverified [160.79.219.114])  by stewe.org (SurgeMail 3.9e) with ESMTP id 11731-1743317  for multiple; Tue, 02 Nov 2010 15:11:38 +0100
User-Agent: Microsoft-MacOutlook/14.0.0.100825
Date: Tue, 02 Nov 2010 10:07:11 -0400
From: Stephan Wenger <stewe@stewe.org>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, <julienl@qualcomm.com>, <draft-ietf-avt-rtp-svc@tools.ietf.org>, <secdir@ietf.org>, <iesg@ietf.org>
Message-ID: <C8F5934F.23FAB%stewe@stewe.org>
Thread-Topic: SECDIR Review of draft-ietf-avt-rtp-svc-23 -- here: active content
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3371537497_25055"
X-Originating-IP: 160.79.219.114
X-Authenticated-User: stewe@stewe.org 
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Ye-Kui Wang <yekuiwang@huawei.com>, Alex Eleftheriadis <alex@vidyo.com>, Thomas Schierl <schierl@hhi.fhg.de>, avt-chairs@tools.ietf.org, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
Subject: Re: [secdir] SECDIR Review of draft-ietf-avt-rtp-svc-23 -- here: active content
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: Tue, 02 Nov 2010 14:12:50 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3371537497_25055
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Hi all,
This is the companion email related to the one point of Julien's secdir
review where we are a bit reluctant to make a non-editorial change.

>>    Decoders MUST exercise caution with respect to the handling of
>>    reserved NAL unit types and reserved SEI messages, particularly if
>>    they contain active elements, and MUST restrict their domain of
>>    applicability to the presentation containing the stream.  The safest
>>    way is to simply discard these NAL units and SEI messages.
> 
> Maybe this is due to my ignorance about coding but I find this
> underspecified, notably given the presence of the MUST key word. How
> about spelling exactly what a decoder MUST do, as opposed to say
> "exercise caution". E.g., "Decoders MUST discard NAL units and SEI
> messages.", and then explain why, or point to
> [I-D.ietf-avt-rtp-rfc3984bis] if there's a good explanation there.

The language of this paragraph has been taken from RFC3984, section 9,
fourth paragraph, and has been adapted to changes in H.264 video standard
terminology.

Back in 2004, this paragraph (as the rest of RFC 3984's security
consideration section) has been subject to lengthily deliberations in AVT.
What we arrived at was considered both sufficiently flexible for
implementers and sufficiently cautious to keep security risks at bay.  A
compromise, that was deemed sensible by everyone involved.  We would like to
keep the spirit of this compromise.

The technical issue is as follows: as most video compression standards, SVC
allows to include data into its bitstream that is not intuitively video
related.  For example, there is a copyright message SEI--which almost
certainly has no negative security implications.  However, there is also an
URI SEI message.  If a stupidly designed system would use the URI in the
bitstream without being cautious--ie copying the URI into a web browser just
to see what happens--then all kinds of evil things could happen.  Further,
there are open codepoints both in the SEI message format and in the NAL unit
tables that can and, historically, have be used for vendor specific
extensions.  Vender specific extensions may include stuff such as Java code.
This is what is meant with "active".  The purpose of the paragraph is to
advise implementers not to blindly use any URI they find in the SEI
messages, or the vendor specific extensions, to the non-video decoding part
of the system. 

On the other hand, both the SEI messages and the extension mechanisms are
there for a reason.  Simply requiring discarding information conveyed in
these fields (that may, and in most cases will, have been put there by an
encoder for a reason beyond malicious intent) may well degenerate the
performance of a system to a point where it becomes useless.  Simply
requiring discarding these bits is not a good choice for the RFC, because
such a requirement would not be sensible to many implementations and,
therefore, would be ignored.

We could add explanatory language to the above extent to the draft, and if
you were insisting, we would do so.  However, please bear in mind that the
situation described above is, we believe, well enough understood in the
codec implementer community, and that the draft will be implemented by a
codec guy, and not a protocol guy, because of the close interaction between
codec technology and the payload format.  Further, codec guys are used to
work with the type of dense documents like this draft, that include very
little explanation or justification.  Therefore, we suggest that adding more
information will simply bloat the draft, without adding any critical
information, and suggest to leave that part of the draft as is.

Please let us know you wish us to proceed.

Thanks,
Stephan




--B_3371537497_25055
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size:=
 14px; font-family: Calibri, sans-serif; "><div>Hi all,</div><div>This is th=
e companion email related to the one point of Julien's secdir review where w=
e are a bit reluctant to make a non-editorial change.</div><div><br></div><d=
iv><span class=3D"Apple-style-span" style=3D"font-size: 12px; font-family: Conso=
las, monospace; "><blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D=
"border-left-color: rgb(181, 196, 223); border-left-width: 5px; border-left-=
style: solid; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; pad=
ding-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; marg=
in-left: 5px; "><blockquote id=3D"MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style=3D"b=
order-left-color: rgb(181, 196, 223); border-left-width: 5px; border-left-st=
yle: solid; padding-top: 0px; padding-right: 0px; padding-bottom: 0px; paddi=
ng-left: 5px; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin=
-left: 5px; "><div>&nbsp;&nbsp; Decoders MUST exercise caution with respect =
to the handling of</div><div>&nbsp;&nbsp; reserved NAL unit types and reserv=
ed SEI messages, particularly if</div><div>&nbsp;&nbsp; they contain active =
elements, and MUST restrict their domain of</div><div>&nbsp;&nbsp; applicabi=
lity to the presentation containing the stream.&nbsp;&nbsp;The safest</div><=
div>&nbsp;&nbsp; way is to simply discard these NAL units and SEI messages.<=
/div></blockquote><div><br></div><div>Maybe this is due to my ignorance abou=
t coding but I find this</div><div>underspecified, notably given the presenc=
e of the MUST key word. How</div><div>about spelling exactly what a decoder =
MUST do, as opposed to say</div><div>"exercise caution". E.g., "Decoders MUS=
T discard NAL units and SEI</div><div>messages.", and then explain why, or p=
oint to</div><div>[I-D.ietf-avt-rtp-rfc3984bis] if there's a good explanatio=
n there.</div></blockquote><div><font class=3D"Apple-style-span" face=3D"Calibri=
, sans-serif" size=3D"4"><span class=3D"Apple-style-span" style=3D"font-size: 14px=
;"><font class=3D"Apple-style-span" face=3D"Consolas,monospace" size=3D"3"><span c=
lass=3D"Apple-style-span" style=3D"font-size: 12px;"><br></span></font></span></=
font></div><div><span class=3D"Apple-style-span" style=3D"font-size: 14px; font-=
family: Calibri, sans-serif; "><div><div>The language of this paragraph has =
been taken from RFC3984,&nbsp;section 9, fourth paragraph, and has been adap=
ted to changes&nbsp;in H.264 video standard terminology.</div><div><br></div=
><div>Back in 2004, this paragraph (as the rest of&nbsp;RFC 3984's security =
consideration&nbsp;section) has been subject to lengthily deliberations in A=
VT. &nbsp;What we arrived at was considered both sufficiently flexible&nbsp;=
for implementers and sufficiently cautious to keep security&nbsp;risks at ba=
y. &nbsp;A compromise, that was deemed sensible by everyone involved. &nbsp;=
We would like to keep the spirit of this compromise.</div><div><br></div><di=
v>The technical issue is as follows: as most video compression&nbsp;standard=
s, SVC allows to include data into its bitstream that&nbsp;is not intuitivel=
y video related. &nbsp;For example, there is a&nbsp;copyright message SEI--w=
hich almost certainly has no negative&nbsp;security implications. &nbsp;Howe=
ver, there is also an URI SEI&nbsp;message. &nbsp;If a stupidly designed sys=
tem would use the URI in&nbsp;the bitstream without being cautious--ie copyi=
ng the URI into&nbsp;a web browser just to see what happens--then all kinds =
of&nbsp;evil things could happen. &nbsp;Further, there are open codepoints&n=
bsp;both in the SEI message format and in the NAL unit tables&nbsp;that can =
and, historically, have be used for vendor specific&nbsp;extensions. &nbsp;V=
ender specific extensions may include stuff&nbsp;such as Java code. &nbsp;Th=
is is what is meant with "active". &nbsp;The purpose of the paragraph is to =
advise implementers not to&nbsp;blindly use any URI they find in the SEI mes=
sages, or the&nbsp;vendor specific extensions, to the non-video decoding par=
t of&nbsp;the system.&nbsp;</div><div><br></div><div>On the other hand, both=
 the SEI messages and the extension&nbsp;mechanisms are there for a reason. =
&nbsp;Simply requiring&nbsp;discarding information conveyed in these fields =
(that may, and in most cases will,&nbsp;have been put there by an encoder fo=
r a reason beyond&nbsp;malicious intent) may well degenerate the performance=
 of a&nbsp;system to a point where it becomes useless. &nbsp;Simply requirin=
g&nbsp;discarding these bits is not a good choice for the RFC,&nbsp;because =
such a requirement would not be sensible to many&nbsp;implementations and, t=
herefore, would be ignored.&nbsp;</div><div><br></div><div>We could add expl=
anatory language to the above extent to the draft, and&nbsp;if you were insi=
sting, we would do so. &nbsp;However, please bear&nbsp;in mind that the situ=
ation described above is, we believe,&nbsp;well enough understood in the cod=
ec implementer community,&nbsp;and that the draft will be implemented by a c=
odec guy, and&nbsp;not a protocol guy, because of the close interaction betw=
een&nbsp;codec technology and the payload format. &nbsp;Further, codec guys&=
nbsp;are used to work with the type of dense documents like this&nbsp;draft,=
 that include very little explanation or justification. &nbsp;Therefore, we =
suggest that adding more information will&nbsp;simply bloat the draft, witho=
ut adding any critical information, and suggest to leave that part of the dr=
aft as is.</div><div><br></div>Please let us know you wish us to proceed.</d=
iv><div><br></div><div>Thanks,</div><div>Stephan</div><div><br></div></span>=
</div></span></div></body></html>

--B_3371537497_25055--



From stpeter@stpeter.im  Tue Nov  2 09:37:11 2010
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 E3A1C3A69DE; Tue,  2 Nov 2010 09:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.888
X-Spam-Level: 
X-Spam-Status: No, score=-100.888 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, J_CHICKENPOX_43=0.6, J_CHICKENPOX_63=0.6, 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 yYgj7eEQ-39h; Tue,  2 Nov 2010 09:37:08 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 4F97D3A679C; Tue,  2 Nov 2010 09:37:08 -0700 (PDT)
Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7613540D1E; Tue,  2 Nov 2010 10:45:48 -0600 (MDT)
Message-ID: <4CD03E36.3020304@stpeter.im>
Date: Tue, 02 Nov 2010 10:37:10 -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: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM>
In-Reply-To: <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.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="------------ms000106070902070709080102"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 16:37:11 -0000

This is a cryptographically signed message in MIME format.

--------------ms000106070902070709080102
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/2/10 8:13 AM, Kurt Zeilenga wrote:
>=20
> On Nov 2, 2010, at 5:12 AM, Peter Saint-Andre wrote:
>=20
>> On 11/2/10 5:20 AM, Yaron Sheffer wrote:
>>> I'm OK with this text, including (sigh) PLAIN.
>>=20
>> If it's any consolation, I'm sighing along with you. :)
>>=20
>> Two points:
>>=20
>> 1. Eventually, we should be able to drop PLAIN in a future revision
>> of the MTI technologies spec that we'll pull out of 3920bis in 1+
>> years.
>=20
> Good luck with that.  The arguments used now for its inclusion is
> likely to be repeated and, again, win.
>=20
> Personally, I am against MUST'ing or SHOULD'ing TLS+PLAIN.  While it
> does offer good interoperability, it does [NOT offer] good enough secur=
ity for
> today's, and more importantly, tomorrow's Internet.

IMHO the point of moving the MTI list out of the core spec is that we
can revise it more frequently. I think we'll be in a stronger position
to discard PLAIN once we have more SCRAM implementations in our world.

> I think we actually should be mandating a SCRAM-*-PLUS mechanism,
> because channeling bindings are really needed due to 'user click
> through' of TLS warnings, downgrade attack warnings, etc..   I do
> suspect that it will take time for this mechanism to be come
> ubiquitous, but I fear that without a MUST, it will never become
> ubiquitous.   But I do suspect well have multiple independently
> developed implementations of SCRAM-*-PLUS in XMPP within a few months
> of publication of this revision of XMPP.

I think the section on "Mandatory-to-Implement Technologies" is not
quite right, because it needs to say that SCRAM-SHA1-PLUS shall be
*implemented in code*:

###

13.8.1.  For Authentication Only

   For authentication only, servers and clients MUST support the SASL
   Salted Challenge Response mechanism [SCRAM], in particular the SCRAM-
   SHA-1 variant and SCRAM-SHA-1-PLUS variant.

###

Whereas the section on "Use of SASL" specifies when those MTI variants
are actually *used in deployment* by software that implements it:

###

13.9.4.  Use of SASL

   [...]

   The SASL framework itself does not provide a method for binding SASL
   authentication to a security layer providing confidentiality and
   integrity protection that was negotiated at a lower layer (e.g.,
   TLS).  Such a binding is known as a "channel binding" (see
   [CHANNEL]).  Some SASL mechanisms provide channel bindings, which in
   the case of XMPP would typically be a binding to TLS (see
   [CHANNEL-TLS]).  If a SASL mechanism provides a channel binding
   (e.g., this is true of [SCRAM]), then XMPP entities using that
   mechanism SHOULD prefer the channel binding variant (e.g., preferring
   "SCRAM-SHA-1-PLUS" over "SCRAM-SHA-1").  If a SASL mechanism does not
   provide a channel binding, then the mechanism cannot provide a way to
   verify that the source and destination end points to which the lower
   layer's security is bound are equivalent to the end points that SASL
   is authenticating; furthermore, if the end points are not identical,
   then the lower layer's security cannot be trusted to protect data
   transmitted between the SASL-authenticated entities.  In such a
   situation, a SASL security layer SHOULD be negotiated that
   effectively ignores the presence of the lower-layer security.

###

> I suspect I'm in the rough on both points.  Oh well.
>=20
>> 2. The technology that the XMPP community uses for account
>> registration (XEP-0077) could benefit from an update, or even a
>> replacement, and when that work is completed I'd like to include a
>> method by which a client could register a key or cert with the
>> server, thus smoothing the path toward password-less
>> authentication. IMHO that will be the best approach in the longer
>> term, instead of continually tweaking the password-based methods.
>> But that's a topic for another time...
>=20
> I also think transition-needed needs to be deprecated in favor of
> transition within the bound channel (e.g., today via XEP 77, tomorrow
> ?).

I'm not sure exactly what "transition within the bound channel" is, but
it sounds worthy of discussion when we work on 3920ter. At this point I
don't think the XMPP community has a great deal of experience with, or
even understanding of, channel binding, so it's difficult for us to make
strong recommendations that depend on channel binding.

Peter

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




--------------ms000106070902070709080102
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MjE2MzcxMFowIwYJKoZIhvcNAQkEMRYEFKtZVTLNwWwvZWjBTLrYirvb39teMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQAzZFN2QG/TO5VnhCxuVQ1h3itYGNhupr8pu2Z2Q4x9RntuD/EhN4xvkSVh
GSp2W+H/A3iz5XFWHKtXfYFGZC33B6HE0mRqHnBlRPiCwe00r09HWR5xb4XSwNczHxJJrQf8
J0dRgKZoxagChV6jY05Sbv7WCTXBcGC+pYfjb4UYkvFZ3z44I29XYbkMMjtajazPj83/GD1k
KtSsst5Bg6ZfDFbQWAmT9E3ZqsyMvbE5wi5fMixzDdkB7ruv+gnSZcMYpC82J6jcD0w5fk53
EiUCGlTLjNPkxuiM7Q9OX8XfJAFzxuK5Fxnlsqkp8hBIR0tiU+8ZSH1HU05bitYlKCtjAAAA
AAAA
--------------ms000106070902070709080102--

From stpeter@stpeter.im  Tue Nov  2 13:17:24 2010
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 1ABF13A69E1; Tue,  2 Nov 2010 13:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.932
X-Spam-Level: 
X-Spam-Status: No, score=-101.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 Y99I3FxLJuff; Tue,  2 Nov 2010 13:17:23 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EDCBC3A68E6; Tue,  2 Nov 2010 13:17:22 -0700 (PDT)
Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2CA4F40D1E; Tue,  2 Nov 2010 14:26:04 -0600 (MDT)
Message-ID: <4CD071D5.3080808@stpeter.im>
Date: Tue, 02 Nov 2010 14:17:25 -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: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM>
In-Reply-To: <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.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="------------ms050800080302030503040007"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 20:17:24 -0000

This is a cryptographically signed message in MIME format.

--------------ms050800080302030503040007
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/2/10 1:03 PM, Kurt Zeilenga wrote:
>=20
> On Nov 2, 2010, at 9:37 AM, Peter Saint-Andre wrote:
>=20
>>>=20
>>> I suspect I'm in the rough on both points.  Oh well.
>>>=20
>>>> 2. The technology that the XMPP community uses for account=20
>>>> registration (XEP-0077) could benefit from an update, or even
>>>> a replacement, and when that work is completed I'd like to
>>>> include a method by which a client could register a key or cert
>>>> with the server, thus smoothing the path toward password-less=20
>>>> authentication. IMHO that will be the best approach in the
>>>> longer term, instead of continually tweaking the password-based
>>>> methods. But that's a topic for another time...
>>>=20
>>> I also think transition-needed needs to be deprecated in favor
>>> of transition within the bound channel (e.g., today via XEP 77,
>>> tomorrow ?).
>>=20
>> I'm not sure exactly what "transition within the bound channel" is,
>> but it sounds worthy of discussion when we work on 3920ter.
>=20
> The problem with transition-needed is that the error is sent outside
> the bound channel.
>=20
> By "within the bound channel", I mean a transitioning method,
> including any necessary signaling, would be performed inside the
> bound channel, that is, within the new <stream:stream/> protected by
> the SASL exchange.
>=20
>> At this point I don't think the XMPP community has a great deal of
>> experience with, or even understanding of, channel binding, so it's
>> difficult for us to make strong recommendations that depend on
>> channel binding.
>=20
> It would be same issue of doing transition outside of a SASL
> negotiated security layer.  It's prone to attack.  And the fix is the
> same.

What is the attack? If the client required negotiation of TLS before
moving on to SASL, the server has already authenticated to the client at
the stage. As I far as I understand, you are arguing that SASL
negotiation could result in establishment of a further security layer
that is bound to the TLS layer via channel binding, and that it is safe
for the client to send plaintext credentials to the server only after
channel binding has taken place. Correct? If so, then we'd need to
define a post-SASL protocol (that might include work on periodic
re-authentication requests sent from server to client). But IMHO that
work is out of scope for 3920bis. The question is: is it better to
remove the <transition-needed/> SASL condition pending work on the
future protocol extension?

Peter

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




--------------ms050800080302030503040007
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MjIwMTcyNVowIwYJKoZIhvcNAQkEMRYEFHlOuiZ8rxpQq97qQAE2LbbiyWEGMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCmgC+evgxLxY/RUNiS8JtA2540LK+efVgjeQbkOurjS349HHtk8BKleR6q
yI8hybS7fccAF5LjKl7lp8v3OQ4ngEDZJ64cDEGqzv/3pwa3K+LZhfzJfLwrA4C/yVV2jt13
rS1vs5ai9Y2zLb6kFYJPbBAK540jnwLe/yEQjYNt62KTlg3NXwTNXie2I2g6h2o7BtdROSRy
43ZAz4VxIPFsTnoVoPlqIqt6ceNY1And0fRY8rEUE7SIJTxKko81uc4Y0VRxRse7RVZXMgb3
S89zyFYdaCUg20t+EuFVaC0TlSp+XWweQ7DZUZma3ItV8OJ3F4D1onFY3nua4V7rYvxRAAAA
AAAA
--------------ms050800080302030503040007--

From stpeter@stpeter.im  Tue Nov  2 15:19:14 2010
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 411FA3A69F0; Tue,  2 Nov 2010 15:19:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.123
X-Spam-Level: 
X-Spam-Status: No, score=-102.123 tagged_above=-999 required=5 tests=[AWL=0.476, 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 I0znJhrQ+gFq; Tue,  2 Nov 2010 15:19:12 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 91A003A68C2; Tue,  2 Nov 2010 15:19:12 -0700 (PDT)
Received: from dhcp-64-101-72-188.cisco.com (dhcp-64-101-72-188.cisco.com [64.101.72.188]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 89B5940D1E; Tue,  2 Nov 2010 16:27:54 -0600 (MDT)
Message-ID: <4CD08E62.3060202@stpeter.im>
Date: Tue, 02 Nov 2010 16:19:14 -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: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <4CD071D5.3080808@stpeter.im> <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM>
In-Reply-To: <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.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="------------ms070604050705080907000006"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Security Area Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 22:19:14 -0000

This is a cryptographically signed message in MIME format.

--------------ms070604050705080907000006
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/2/10 3:11 PM, Kurt Zeilenga wrote:

> I think the question can simple as simple as "Should
> <transition-needed/> be removed?".  I am fine with the question being
> viewed as "too late" to ask.

I don't think that folks in the WG would cry if the feature were
removed, given that:

1. It would be used rarely.

2. No one has implemented it (AFAIK).

3. The text provides many warnings about it.

4. It supposedly opens up the possibility of downgrade attacks.

However, I still fail to see how <transition-needed/> is more evil than
using SASL, at least if TLS is negotiated first (an attacker could just
advertise the PLAIN mechanism over the TLS-protected stream, and if an
attacker has so much control over the server that it can launch attacks
after TLS has been negotiated then the client is in deep trouble anyway!)=
=2E

Furthermore, I think that any client sophisticated enough to support
<transition-needed/> is going to be sophisticated enough to support
SCRAM-based mechanisms, which means it can perform a further check to
make sure that the server really is offering upgraded security
mechanisms (likely, upgrading from DIGEST-MD5 to SCRAM-SHA-1) before
sending the password in plaintext over the TLS-encrypted stream. Another
check: don't use <transition-needed/> more than once with any given XMPP
service (once is enough!). And never send the plaintext password over an
unprotected stream. So IMHO we have a number of protections in place and
that we can safely use the <transition-needed/> feature if we feel that
we really need it. The question is: do we really need it? We do want to
encourage folks to migrate from DIGEST-MD5 (lots of interoperability
issues) to SCRAM, and as part of that upgrade process XMPP services
might need to collect the plaintext password just once. I'd rather have
it done over the XMPP channel than, say, via an HTTPS web page (more
phishing possibilities), but opinions might differ. Feedback from our
security reviewer and the Security ADs would be especially helpful.

All that having been said, if we're going to remove the feature then I
think we need to make sure that the WG has consensus to do so. I leave
that up to the chairs.

Peter

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




--------------ms070604050705080907000006
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MjIyMTkxNFowIwYJKoZIhvcNAQkEMRYEFHKKaQSX//BFV++9b0w06TvstdaGMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQAquZzccpKpBXoqBcKJcGnvb/Rz2nqxBCwoNMCby3fmw02ZmD3w0CwSzcth
acnvJwxxMHG1lZtSfJbje7wQL3TKkOPG1lWaCxpuA6GXjP5TRnwyJ6Glr0mvlxJNtKWO8IB1
qQd9vidQnhR7Zk3ycI6OI1QDZ+tWH4N7eDF+m3uAEX7sMqYCIcFzaAWi8JEbjMJj7uSoSXc+
Y8eNTzY4khpYQiitIwuZ9yQINcJSJUhyxY2hfPkjgBAfQhrI9ZrJfWLxlWSDD2LUibIgkOmE
WdU35o+2OKVF39b70toIpNb+byREK1uwHJJO8EftPEcIpuIH59xFwnPuq6Z86vcvalR2AAAA
AAAA
--------------ms070604050705080907000006--

From ben@nostrum.com  Tue Nov  2 15:29:36 2010
Return-Path: <ben@nostrum.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 E10FC3A68C2; Tue,  2 Nov 2010 15:29:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, 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 rx2bc0q3ee9e; Tue,  2 Nov 2010 15:29:35 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id F17EB3A6774; Tue,  2 Nov 2010 15:29:34 -0700 (PDT)
Received: from [10.0.1.12] (cpe-76-183-178-106.tx.res.rr.com [76.183.178.106]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oA2MTbRB010857 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Nov 2010 17:29:38 -0500 (CDT) (envelope-from ben@nostrum.com)
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <4CD071D5.3080808@stpeter.im> <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM> <4CD08E62.3060202@stpeter.im>
Message-Id: <03A2F4DE-56FF-4420-A1DF-24EE5C6EE82A@nostrum.com>
From: Ben Campbell <ben@nostrum.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
In-Reply-To: <4CD08E62.3060202@stpeter.im>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
X-Mailer: iPad Mail (7B500)
Mime-Version: 1.0 (iPad Mail 7B500)
Date: Tue, 2 Nov 2010 17:29:36 -0500
Received-SPF: pass (nostrum.com: 76.183.178.106 is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Security Area Directorate <secdir@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>, XMPP Working Group <xmpp@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [secdir] [xmpp] 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: Tue, 02 Nov 2010 22:29:37 -0000

(as XMPP chair)

On Nov 2, 2010, at 5:19 PM, Peter Saint-Andre <stpeter@stpeter.im> =
wrote:

> On 11/2/10 3:11 PM, Kurt Zeilenga wrote:
>=20
>> I think the question can simple as simple as "Should
>> <transition-needed/> be removed?".  I am fine with the question being
>> viewed as "too late" to ask.
>=20
> I don't think that folks in the WG would cry if the feature were
> removed, given that:
>=20
> 1. It would be used rarely.
>=20
> 2. No one has implemented it (AFAIK).
>=20
> 3. The text provides many warnings about it.
>=20
> 4. It supposedly opens up the possibility of downgrade attacks.
>=20
> However, I still fail to see how <transition-needed/> is more evil =
than
> using SASL, at least if TLS is negotiated first (an attacker could =
just
> advertise the PLAIN mechanism over the TLS-protected stream, and if an
> attacker has so much control over the server that it can launch =
attacks
> after TLS has been negotiated then the client is in deep trouble =
anyway!).
>=20
> Furthermore, I think that any client sophisticated enough to support
> <transition-needed/> is going to be sophisticated enough to support
> SCRAM-based mechanisms, which means it can perform a further check to
> make sure that the server really is offering upgraded security
> mechanisms (likely, upgrading from DIGEST-MD5 to SCRAM-SHA-1) before
> sending the password in plaintext over the TLS-encrypted stream. =
Another
> check: don't use <transition-needed/> more than once with any given =
XMPP
> service (once is enough!). And never send the plaintext password over =
an
> unprotected stream. So IMHO we have a number of protections in place =
and
> that we can safely use the <transition-needed/> feature if we feel =
that
> we really need it. The question is: do we really need it? We do want =
to
> encourage folks to migrate from DIGEST-MD5 (lots of interoperability
> issues) to SCRAM, and as part of that upgrade process XMPP services
> might need to collect the plaintext password just once. I'd rather =
have
> it done over the XMPP channel than, say, via an HTTPS web page (more
> phishing possibilities), but opinions might differ. Feedback from our
> security reviewer and the Security ADs would be especially helpful.
>=20
> All that having been said, if we're going to remove the feature then I
> think we need to make sure that the WG has consensus to do so. I leave
> that up to the chairs.

I concur that we need WG consensus to remove this. We can assume we had =
consensus for the feature to be there in the first place, since it was =
in the doc as pubreq'd.

Certainly the are room for changes due to post WG review without taking =
everything back to the WG. This seems to me to border on too big a =
change for that. It's no big deal to query the work group on it, if we =
see the need.

>=20
> Peter
>=20
> --=20
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20
>=20

From stpeter@stpeter.im  Wed Nov  3 05:13:41 2010
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 E3FA43A6A9D; Wed,  3 Nov 2010 05:13:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 jdltAmnKmbBY; Wed,  3 Nov 2010 05:13:40 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 585293A6825; Wed,  3 Nov 2010 05:13:40 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2E3C940D1E; Wed,  3 Nov 2010 06:22:26 -0600 (MDT)
Message-ID: <4CD151F7.6060809@stpeter.im>
Date: Wed, 03 Nov 2010 06:13:43 -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: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <4CD071D5.3080808@stpeter.im> <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM> <4CD08E62.3060202@stpeter.im> <03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM>
In-Reply-To: <03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.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="------------ms020301000600030603070603"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: Re: [secdir] [xmpp] 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: Wed, 03 Nov 2010 12:13:42 -0000

This is a cryptographically signed message in MIME format.

--------------ms020301000600030603070603
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/2/10 6:14 PM, Kurt Zeilenga wrote:
>=20
> On Nov 2, 2010, at 3:19 PM, Peter Saint-Andre wrote:
>=20
>> On 11/2/10 3:11 PM, Kurt Zeilenga wrote:
>>=20
>>> I think the question can simple as simple as "Should=20
>>> <transition-needed/> be removed?".  I am fine with the question
>>> being viewed as "too late" to ask.
>>=20
>> I don't think that folks in the WG would cry if the feature were=20
>> removed, given that:
>>=20
>> 1. It would be used rarely.
>>=20
>> 2. No one has implemented it (AFAIK).
>>=20
>> 3. The text provides many warnings about it.
>>=20
>> 4. It supposedly opens up the possibility of downgrade attacks.
>>=20
>> However, I still fail to see how <transition-needed/> is more evil
>> than using SASL, at least if TLS is negotiated first (an attacker
>> could just advertise the PLAIN mechanism over the TLS-protected
>> stream, and if an attacker has so much control over the server that
>> it can launch attacks after TLS has been negotiated then the client
>> is in deep trouble anyway!).
>=20
> I think you are considering the issue under a different assumptions
> than I.  I am assuming the user has clicked through any and all
> warnings they were faced with.  I am assuming the client did not well
> implement handling all cases.
>=20
> For instance, if the user clicked said "connect anyways" to a
> certificate verification/subject check warning, a decent client would
> still warn if it previously used SCRAM-SHA1-PLUS and now is only
> getting SCRAM-SHA1 or just PLAIN, and warning about downgrade
> possibilities with transition-needed.  But far too often clients, not
> surprisingly, will assume that "connect anyways" means that TLS is
> good for purposes (e.g., server has been authenticated by the user by
> means outside the clients control) instead of "good enough for use
> with mechanisms that provide mutual authentication".  Of course, what
> the user meant was "just connect, damn it".
>=20
> Our application protocol security designs are far too reliant on
> users making non-trival decisions, and far too complex for client
> developers to well implement.  (Such issues are certainly not limited
> to XMPP.)   We ought to design our protocols to avoid having to ask
> the user to make non-trival decisions, and simplify things the client
> developers as much possible (such as by ensuring key protocol bits
> are adequately protected from various attacks, instead of "TLS will
> save us").  And to make matters worse, we tend to repeat 'bad
> designs' (The transition-needed error in protocols has been a problem
> since introduced, as it never been protected by the SASL exchange.)
>=20
>> Furthermore, I think that any client sophisticated enough to
>> support <transition-needed/> is going to be sophisticated enough to
>> support SCRAM-based mechanisms,
>=20
> I disagree here.  A client developer is likely to implement
> transition-needed without at all thinking about the implications of
> whether "connect anyways" means "good enough for mechanism which
> provides server authentication and channel bindings" or simply "good
> enough for anything the server might ask us to do".  And, of course,
> the user just meant "I don't care about this" (but that doesn't mean
> the server operator does care).
>=20
> Note that I don't mean to blame the user or the client developer
> here, I mean to blame the protocol designers for pushing these
> problems upon them.
>=20
>> which means it can perform a further check to make sure that the
>> server really is offering upgraded security mechanisms (likely,
>> upgrading from DIGEST-MD5 to SCRAM-SHA-1) before sending the
>> password in plaintext over the TLS-encrypted stream.
>=20
> And if it notices an issue, what, prompt the user again?
>=20
>> Another check: don't use <transition-needed/> more than once with
>> any given XMPP service (once is enough!).
>=20
> Once is enough?  I don't think so.
>=20
>> And never send the plaintext password over an unprotected stream.
>=20
> Ah, some will take "unprotected" to mean its okay to send the
> password over a stream so long as it has data integrity and data
> confidentiality protection.
>=20
> That isn't enough.  One ought not send a plaintext password without
> server authentication (preferably that's bound to the protected
> stream end-point).  If the user may have intended to rely on SCRAM
> for server authentication, then just having TLS without any server
> authentication is not good enough.
>=20
>> So IMHO we have a number of protections in place
>=20
> The only protections we have assumption that TLS is used with
> client's authentication of the server.  That's a hell of an
> assumption with todays use of TLS on the Internet.   Certainly
> <transition-protected/> is not protected in XMPP use without TLS but
> with SASL security layers.
>=20
> Of course, we also rely on this assumption to prevent downgrade via
> mechanism advertisements.  We really ought to do something about that
> as well.
>=20
>> and that we can safely use the <transition-needed/> feature if we
>> feel that we really need it.  The question is: do we really need
>> it? We do want to encourage folks to migrate from DIGEST-MD5 (lots
>> of interoperability issues) to SCRAM, and as part of that upgrade
>> process XMPP services might need to collect the plaintext password
>> just once.
>=20
> Or again if they select SCRAM specific secrets and then realize they
> still need to support DIGEST-MD5. Or they decide to move to some
> other password based mechanism and its mechanism specific secret.
>=20
> It's not 'just once'.
>=20
>> I'd rather have it done over the XMPP channel than, say, via an
>> HTTPS web page (more phishing possibilities), but opinions might
>> differ.
>=20
> I rather have it done in a well-protected XMPP channel.   I don't
> consider the use transition-needed and TLS*+PLAIN as generally well
> protected.
>=20
> (* TLS as often implemented and used on the Internet, e.g., without
> authentication).
>=20
>> Feedback from our security reviewer and the Security ADs would be
>> especially helpful.
>>=20
>> All that having been said, if we're going to remove the feature
>> then I think we need to make sure that the WG has consensus to do
>> so.
>=20
> Of course.

You make a compelling argument. I wish you had made that argument months
ago, but it is compelling. Indeed, it leads in the direction of two
consensus calls within the XMPP WG:

(a) to remove the <transition-needed/> SASL error condition

(b) to remove TLS plus SASL PLAIN as MTI for confidentiality and
authentication

Ideally, both of those changes would be accompanied by additional
security-related text, and in case (b) an interoperability note.

Peter

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




--------------ms020301000600030603070603
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MzEyMTM0M1owIwYJKoZIhvcNAQkEMRYEFDZRWFynsfaETlBoC2LXZeTDAKczMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCZlh/Sd67tepSGqGsXlOZMQIg0q51SQXght837QVM6xK8CEMIbT96/Yopf
/wJ9oRZJth/7NdqYiX21SBGZp8YLmWYKp8kcvGu07wxvt29g4Aa4ofrBD4FXLchfx3/Nr3wK
0fTim0FRTgkq6U5brMORkQy14eTdpLHx3CNjKn1UEzZmHFZ2r721XdZNdkc13z+Yu+jQ0ysQ
YvgLBdLAskbQ4kCsDOdZklbK/K/TSMqAO4lQcpsW72qmYhTcjew8MddtLOhLrqbH+KXekjYh
YJu6S2se7YmaLxgn9wc0/+Vi8Uk4/0/I5vQeV+9TpHrQiLaAkdMkf4gyQi3HaFLj2TfZAAAA
AAAA
--------------ms020301000600030603070603--

From stpeter@stpeter.im  Wed Nov  3 10:31:43 2010
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 5B8123A6885; Wed,  3 Nov 2010 10:31:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.539
X-Spam-Level: 
X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 jtBCLcMR9mYt; Wed,  3 Nov 2010 10:31:42 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D93933A659B; Wed,  3 Nov 2010 10:31:41 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 97FB040D1E; Wed,  3 Nov 2010 11:40:29 -0600 (MDT)
Message-ID: <4CD19C81.9050509@stpeter.im>
Date: Wed, 03 Nov 2010 11:31: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: Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im>	<4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de>	<2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im>	<4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com>	<4CD00025.8030804@stpeter.im>	<706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM>	<4CD03E36.3020304@stpeter.im>	<60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM>	<4CD071D5.3080808@stpeter.im>	<44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM>	<4CD08E62.3060202@stpeter.im>	<03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM>	<4CD151F7.6060809@stpeter.im> <F7E7C266-C802-4487-8A0F-DE930EBB2098@Isode.COM>
In-Reply-To: <F7E7C266-C802-4487-8A0F-DE930EBB2098@Isode.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="------------ms050001020805000700060202"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, The IESG <iesg@ietf.org>, XMPP Working Group <xmpp@ietf.org>, Security Area Directorate <secdir@ietf.org>
Subject: Re: [secdir] [xmpp] 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: Wed, 03 Nov 2010 17:31:43 -0000

This is a cryptographically signed message in MIME format.

--------------ms050001020805000700060202
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/3/10 9:02 AM, Kurt Zeilenga wrote:
>=20
> On Nov 3, 2010, at 5:13 AM, Peter Saint-Andre wrote:
>> You make a compelling argument. I wish you had made that argument
>> months ago, but it is compelling.  Indeed, it leads in the
>> direction of two consensus calls within the XMPP WG:
>>=20
>> (a) to remove the <transition-needed/> SASL error condition
>>=20
>> (b) to remove TLS plus SASL PLAIN as MTI for confidentiality and=20
>> authentication
>>=20
>> Ideally, both of those changes would be accompanied by additional=20
>> security-related text, and in case (b) an interoperability note.
>=20
> First, I note that (b) is a no-op in practice.  Implementations are
> going to support SASL PLAIN regardless.  Hell, we could even MUST NOT
> it and folks would still implement it.  It's simply too damn
> necessary for integration with 'legacy' password stores.  (I still
> rather we not MTI PLAIN.)

This is true.

> Second, (a) only removes one of two significant downgrade attack
> vectors, the other vector being the mechanisms advertisement and its
> handling.  (I still rather we remove it.)

We're not about to get rid of mechanisms advertisement, given that it's
what enables us to do SASL authentication in the first place. :)

However, <transition-needed/> is new in 3920bis and it's better to
remove it now than to encourage software to implement it, only to remove
it in a few years.

> While we can well craft our security warnings and considerations and
> guidance on how to use unauthenticated v. authenticated TLS and hope
> that client developers get it right.  Basically that text would say
> "use authenticated TLS" to protect against downgrade attack. =20

And we already say that.

> That
> sounds great but I doubt its going to have much effect (though I
> think it still should be said).  Clients are still going to offer
> user's security check bypasses and users are going to continue to
> take those bypasses.

Also true.

> Also as I noted previously, these problems are not unique to XMPP.
> Instead of slowing down the publication of XMPP, it might be better
> to spin a more general effort to explore ways to address security
> issues due to general assumption that TLS will be used with server
> authentication when it is often used without server authentication,
> and more generally, explore ways to address the "user click through"
> problem (that is, how to secure protocols such that bypasses are less
> needed).

That does sound like a worthy effort. It might intersect with the WEBSEC =
WG.

> Lastly, please note that I don't consider this issue 'critical' at
> this point.  It's not going to be critical until such attacks are far
> more common place.  The best way to currently mitigate such attacks
> is to restrict the set of usable mechanisms to those immune to the
> attack.  (For enterprises which provide 'client builds' to their
> users, they can do this for their users as part of those builds.
> But, in general, this requires user configuration and hence prone to
> failure.)

OK, so here is one path forward:

(a) Remove <transition-needed/> because it opens a hole that wasn't open
with RFC 3920 and doesn't need to be opened now.

(b) Remove TLS plus SASL PLAIN as mandatory-to-implement for the same
reason (note that it was not mandatory-to-implement in RFC 3920).

As previously mentioned, I think we also need to update the relevant
part of the security considerations -- here is proposed text:

###

13.8.3.  For Confidentiality and Authentication With Passwords

   For both confidentiality and authentication with passwords, servers
   and clients MUST implement TLS with the TLS_RSA_WITH_AES_128_CBC_SHA
   ciphersuite plus SASL SCRAM, in particular the SCRAM-SHA-1 and SCRAM-
   SHA-1-PLUS variants.

      Interoperability and Security Note: In practice, when SCRAM is not
      available, typically servers and clients use TLS plus SASL PLAIN.
      The SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants of the SCRAM
      mechanism are strongly preferred over the PLAIN mechanism because
      of their vastly superior security properties (including the
      ability to enforce channel binding as described under
      Section 13.9.4).  Although in certain deployment scenarios it can
      be difficult for a server to offer SCRAM-based mechanisms (e.g.,
      because the XMPP service depends for authentication purposes on a
      database or directory that is not under the control of the XMPP
      administrators), in general implementations SHOULD treat TLS plus
      SASL PLAIN as a technology of last resort when interacting with
      implementations that do not yet support SCRAM; in particular, a
      client MUST prefer more secure mechanisms (e.g., SCRAM-SHA-1,
      SCRAM-SHA-1-PLUS, and EXTERNAL) to the PLAIN mechanism and MUST
      NOT use the PLAIN mechanism without at a minimum confidentiality
      and integrity protection via TLS with full certificate validation
      as described under Section 13.7.2.1 (however, the lack of channel
      binding in the PLAIN mechanism implies that even authenticated TLS
      cannot fully protect the SASL negotiation and subsequent
      communications when PLAIN is used).

###

I have no great love for <transition-needed/> or SASL PLAIN, and given
that they were not mentioned or encouraged in RFC 3920 I see no strong
reason to add them in 3920bis. Yes, PLAIN will be used in the short run
and it is helpful to document that fact for interoperability purposes,
but hopefully we can move away from PLAIN with all due speed by
encouraging the use of SCRAM and of EXTERNAL with client certificates.

If the chairs are willing, I would like to request a consensus call on
(a) and (b), based on feedback received during the security review.

Peter

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




--------------ms050001020805000700060202
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MzE3MzE0NVowIwYJKoZIhvcNAQkEMRYEFAI5J/m2wHv3wK+51CfReNSiIHRMMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBNTl6aZdtrAa04zjEBC9Fv6t8WQ5KOqPP3Sa6W5Xpp/SC5fi2aCPQ9j1DL
bk7GcSWR2pQCRMPQfCbxgYAIgU2ry6Kl6Ufb+jY6C7BNKOCgs4/HtC2eOikxQUo+nD1lZeeb
tozVSkYciTlcpdMjPdoL3XXF+3BeisAamXFA7UyGQAiJA97/WOi/ec936zpajW8JxBRS16uz
gZQO9aO1PXbcBShR7868m1jLt5072LQsoB5ic0Xc7/N1hJ4hSvvwz3qaCvvf8M+mC5pNAReI
x8ZvJGNrFRzTMW6CnbkEry2O6BqhbZzuIWkv1zvUA5tN9LfAL6499kfXKnzgZkZ7EzT2AAAA
AAAA
--------------ms050001020805000700060202--

From ben@nostrum.com  Wed Nov  3 10:39:54 2010
Return-Path: <ben@nostrum.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 EE4FF28C10F; Wed,  3 Nov 2010 10:39:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, 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 y7YYj-qWtJ4Y; Wed,  3 Nov 2010 10:39:53 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5A54C3A6AD8; Wed,  3 Nov 2010 10:39:50 -0700 (PDT)
Received: from dn3-174.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oA3Hdq61013138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 3 Nov 2010 12:39:52 -0500 (CDT) (envelope-from ben@nostrum.com)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=us-ascii
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <4CD19C81.9050509@stpeter.im>
Date: Wed, 3 Nov 2010 12:39:52 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <74CE7A43-0E0B-4847-98D0-501EDEAA78F4@nostrum.com>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im>	<4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de>	<2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im>	<4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com>	<4CD00025.8030804@stpeter.im>	<706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM>	<4CD03E36.3020304@stpeter.im>	<60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM>	<4CD071D5.3080808@stpeter.im>	<44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM>	<4CD08E62.3060202@stpeter.im>	<03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM>	<4CD151F7.6060809@stpeter.im> <F7E7C266-C802-4487-8A0F-DE930EBB2098@Isode.COM> <4CD19C81.9050509@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1081)
Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Security Area Directorate <secdir@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, Kurt Zeilenga <Kurt.Zeilenga@Isode.COM>, XMPP Working Group <xmpp@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [secdir] [xmpp] 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: Wed, 03 Nov 2010 17:39:54 -0000

(as chair)

On Nov 3, 2010, at 12:31 PM, Peter Saint-Andre wrote:

> If the chairs are willing, [...]

No objection to the consensus call from me, at least

> I would like to request a consensus call on
> (a) and (b), based on feedback received during the security review.

I think you just did :-)

From mwild1@gmail.com  Wed Nov  3 11:10:42 2010
Return-Path: <mwild1@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 BD52228C121; Wed,  3 Nov 2010 11:10:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 bHWwqktewGeK; Wed,  3 Nov 2010 11:10:40 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id D72CE28C117; Wed,  3 Nov 2010 11:10:38 -0700 (PDT)
Received: by gxk7 with SMTP id 7so728579gxk.31 for <multiple recipients>; Wed, 03 Nov 2010 11:10:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=sY2Nejy210Koa51egLao/sHWXiDCvKPCSuktyLwQCLs=; b=fPtidEEIkcj8Uhs6b+OEnfYsPaNL0t7nSpzd5yf1+LyDUQU6Pk5AXZ+3yGXRpDEnLD yTy8foONDFaFwdHgDpqh0pSQC+iDxJIMMPrHcTs7SUI3rux2AAOT+xcTy+01E4OYrrbt bG9mnMQT7WB4w6qTcGeDiWAFnM22TnZNwgb40=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=apvA/Fx1u+1ncvP3uM9p0t3IcwhDx3chyk3btv4fi/oBY7QcZrw2+CfgWoux9FmcwJ KLYm4fHzlew/p2vJDHU9huJo7D5J0hNKNc+HVDFBTXxyDGKz0tF/HHEfgxvkMD5P/XFR ZlK63xeAfS0vo8oGQybD0B3yrmS8QmupG02uE=
Received: by 10.42.21.17 with SMTP id i17mr13861637icb.263.1288807845597; Wed, 03 Nov 2010 11:10:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.166.84 with HTTP; Wed, 3 Nov 2010 11:10:25 -0700 (PDT)
In-Reply-To: <4CD19C81.9050509@stpeter.im>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de> <2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im> <4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com> <4CD00025.8030804@stpeter.im> <706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM> <4CD03E36.3020304@stpeter.im> <60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM> <4CD071D5.3080808@stpeter.im> <44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM> <4CD08E62.3060202@stpeter.im> <03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM> <4CD151F7.6060809@stpeter.im> <F7E7C266-C802-4487-8A0F-DE930EBB2098@Isode.COM> <4CD19C81.9050509@stpeter.im>
From: Matthew Wild <mwild1@gmail.com>
Date: Wed, 3 Nov 2010 18:10:25 +0000
Message-ID: <AANLkTinmSdGN2D1ZzwCQy9iYTTfSfXoF+T+nBOxcLkPv@mail.gmail.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Security Area Directorate <secdir@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, Kurt Zeilenga <Kurt.Zeilenga@isode.com>, XMPP Working Group <xmpp@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [secdir] [xmpp] 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: Wed, 03 Nov 2010 18:10:43 -0000

On 3 November 2010 17:31, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>

> =C2=A0 =C2=A0 =C2=A0as described under Section 13.7.2.1 (however, the lac=
k of channel
> =C2=A0 =C2=A0 =C2=A0binding in the PLAIN mechanism implies that even auth=
enticated TLS
> =C2=A0 =C2=A0 =C2=A0cannot fully protect the SASL negotiation and subsequ=
ent
> =C2=A0 =C2=A0 =C2=A0communications when PLAIN is used).
>

I'm no expert on this, but is this text technically true? I thought
channel binding would only be beneficial where there is not full TLS
authentication.

I'm not going to weigh in on the to-MTI/to-not-MTI issue... it's not
going to affect anything either way. There are deployment scenarios
where PLAIN is necessary, and as far as I'm aware it is quite safe
with full TLS verification/authentication. I think Kurt is mainly
arguing that in practice TLS is rarely fully verified. However this is
a deployment issue, and has no bearing on the protocol - though were
we to MTI for interop reasons we should of course strongly stress the
importance of TLS being fully verified when using PLAIN.

Regards,
Matthew

From stpeter@stpeter.im  Wed Nov  3 14:41:24 2010
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 937773A68E8; Wed,  3 Nov 2010 14:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level: 
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 YhzHNR+SuTuT; Wed,  3 Nov 2010 14:41:23 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2EF483A66B4; Wed,  3 Nov 2010 14:41:23 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D917E40D1E; Wed,  3 Nov 2010 15:50:12 -0600 (MDT)
Message-ID: <4CD1D708.7010308@stpeter.im>
Date: Wed, 03 Nov 2010 15:41:28 -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> <4CCF20E7.30401@stpeter.im>
In-Reply-To: <4CCF20E7.30401@stpeter.im>
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="------------ms020704090006000309010701"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] [xmpp] 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: Wed, 03 Nov 2010 21:41:24 -0000

This is a cryptographically signed message in MIME format.

--------------ms020704090006000309010701
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Yaron, following up our discusion, here is proposed text for the
conformance features you suggested...

On 11/1/10 2:19 PM, Peter Saint-Andre wrote:
> On 11/1/10 3:25 AM, Yaron Sheffer wrote:
>=20
>> On 10/30/2010 07:05 AM, Peter Saint-Andre wrote:
>>>
>>> On 10/28/10 4:28 AM, Yaron Sheffer wrote:
>>>
>>>> - 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, b=
ut
>>>> 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 S=
ASL.
>> - 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 T=
LS
>> certs and/or SASL.

I think we can combine client and server validation into two features
(instead of four), one for TLS and one for SASL.

The TLS feature would be:

   Feature:  tls-correlate
   Description:  When validating a certificate presented by a stream
      peer during TLS negotiation, correlate the validated identity with
      the 'from' address (if any) of the stream header it received from
      the peer.
   Section:  Section 13.7.2
   Roles:  Client SHOULD, Server SHOULD.

As a target for that pointer, I think we need to add the following
paragraph to the end of Section 13.7.2 ("Certificate Validation"):

   Once the identity of the stream peer has been validated, the
   validating entity SHOULD also correlate the validated identity with
   the 'from' address (if any; see Section 4.6.1) of the stream header
   it received from the peer.  If the two identities do not match, the
   validating entity SHOULD terminate the connection attempt.

The SASL feature would be:

   Feature:  sasl-correlate
   Description:  When authenticating a stream peer using SASL, correlate
      the authentication identifier resulting from SASL negotiation with
      the 'from' address (if any) of the stream header it received from
      the peer.
   Section:  Section 6.4.6
   Roles:  Client N/A, Server SHOULD.

As a target for that pointer, I think we need to add the following
paragraph to the beginning of Section 6.4.6 ("SASL Success"):

   Before considering the SASL handshake to be a success, the receiving
   entity SHOULD correlate the authentication identity resulting from
   the SASL negotiation with the 'from' address (if any; see
   Section 4.6.1) of the stream header it received from the initiating
   entity.  If the two identities do not match, the receiving entity
   SHOULD terminate the connection attempt.

Finally, we need one more feature, for server stamping of client 'from'
addresses:

   Feature:  stanza-attribute-from-stamp
   Description:  Stamp or rewrite the 'from' address of all stanzas
      received from connected clients.
   Section:  Section 8.1.2.1
   Roles:  Client N/A, Server MUST.

Let me know if those seem reasonable.

Peter

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




--------------ms020704090006000309010701
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MzIxNDEyOFowIwYJKoZIhvcNAQkEMRYEFA4d2mDAX1+6Q7/OKtDmgFXBMM6WMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBtrA4HEywAyXkLqwBhoUV16ci5pKgDi60efze2ztf0Ju9oDShN+fQSZ9Lx
XE6NMfrC6iwrnm38NfByGAaHBClNtpClaCMfB3c17x7HVXFAQZfbVxav7IK/h6/pKuD9X8cq
5QdaECtglqk+y4eAojnEgHRLMy+rwlGQ+Te8S0caiqeI6d/fcOtnk4e268UuWS51EykFopij
F8D8vKsdOf38UIxJimdghIVXc9Aqif8yUYvUbU8nvBfSLO4s9MPMyWJdsCJ0UiZNv7CF58H5
hIkKRky96LajH1o58/BU3hU3lzYh3SpqXGLM2BR/4cN8IUO8L+UmFbHqYA0zjkvYp2YOAAAA
AAAA
--------------ms020704090006000309010701--

From stpeter@stpeter.im  Wed Nov  3 14:53:27 2010
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 1292B3A690A; Wed,  3 Nov 2010 14:53:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level: 
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 FQ7chxOLHGVd; Wed,  3 Nov 2010 14:53:26 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id D92123A68E8; Wed,  3 Nov 2010 14:53:25 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0DD7D40D1E; Wed,  3 Nov 2010 16:02:14 -0600 (MDT)
Message-ID: <4CD1D9DA.9020400@stpeter.im>
Date: Wed, 03 Nov 2010 15:53:30 -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: Kurt Zeilenga <Kurt.Zeilenga@isode.com>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im>	<4CCE87A5.80701@gmail.com> <4CCF04D3.6020504@babelmonkeys.de>	<2761.1288645043.347835@puncture> <4CCF7E7A.5050303@stpeter.im>	<4CCF9776.5060207@stpeter.im> <4CCFF3E6.7040800@gmail.com>	<4CD00025.8030804@stpeter.im>	<706C109C-A2D2-4E17-B5AA-6B881F7E0334@Isode.COM>	<4CD03E36.3020304@stpeter.im>	<60F15D22-C2F2-47F7-8BC1-4442B764EDFA@Isode.COM>	<4CD071D5.3080808@stpeter.im>	<44FB1E43-1F0F-4652-B6FF-D437B6C53DE7@Isode.COM>	<4CD08E62.3060202@stpeter.im>	<03C37501-30DB-4C80-8358-DD853EF59F1A@Isode.COM>	<4CD151F7.6060809@stpeter.im>	<F7E7C266-C802-4487-8A0F-DE930EBB2098@Isode.COM>	<4CD19C81.9050509@stpeter.im>	<AANLkTinmSdGN2D1ZzwCQy9iYTTfSfXoF+T+nBOxcLkPv@mail.gmail.com> <28590B36-877A-47AF-9B7A-D5A3FA3B2079@isode.com>
In-Reply-To: <28590B36-877A-47AF-9B7A-D5A3FA3B2079@isode.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="------------ms010106010101030308050604"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
Cc: Security Area Directorate <secdir@ietf.org>, "draft-ietf-xmpp-3920bis.all@tools.ietf.org" <draft-ietf-xmpp-3920bis.all@tools.ietf.org>, XMPP Working Group <xmpp@ietf.org>, The IESG <iesg@ietf.org>, Matthew Wild <mwild1@gmail.com>
Subject: Re: [secdir] [xmpp] 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: Wed, 03 Nov 2010 21:53:27 -0000

This is a cryptographically signed message in MIME format.

--------------ms010106010101030308050604
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 11/3/10 3:03 PM, Kurt Zeilenga wrote:
>=20
> On Nov 3, 2010, at 11:10 AM, Matthew Wild wrote:
>=20
>> On 3 November 2010 17:31, Peter Saint-Andre <stpeter@stpeter.im>
>> wrote:
>>>=20
>>=20
>>> as described under Section 13.7.2.1 (however, the lack of
>>> channel binding in the PLAIN mechanism implies that even
>>> authenticated TLS cannot fully protect the SASL negotiation and
>>> subsequent communications when PLAIN is used).
>>>=20
>>=20
>> I'm no expert on this, but is this text technically true? I
>> thought channel binding would only be beneficial where there is not
>> full TLS authentication.
>=20
> Channel binding is beneficial regardless of whether there the client
> performed TLS server cert/subject checks.  Note that the server has
> no clue what checks, if any, the client (or its user) performed.
> With channel bindings, it becomes irrelevant to the server whether
> the client performed these checks or not.  That is, (amongst other
> things) channel bindings provide a means for the server itself to
> protect against MITM attacks.
>=20
> I do agree, however, that he wording of the however comment is
> confusing and seems should either be removed or replaced.

Removed in my working copy.

> My main concern is that Unauthenticated TLS is subject to downgrade
> to PLAIN by two vectors, spoofing mechanisms and spoofing transition
> required.
>=20
> Removing <transition-needed/> (in favor of a yet to be specified
> extension) addresses one vector.
>=20
> There seems no good way to address the other vector at this time.  I
> do suggest however that the 13.9.4 text: To help prevent this attack,
> the parties SHOULD protect the channel using TLS before attempting
> SASL negotiation. be replaced with: To mitigate this attack, the
> partied SHOULD protect the channel using TLS before attempting SASL
> negotiation and either perform full certificate validation as
> described in Section 13.7.2.1 or utilize a mechanism which provides
> channel bindings, such as SCRAM-SHA-1-PLUS.

Text incorporated, with minor tweaks.

Peter

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




--------------ms010106010101030308050604
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
MzIxNTMzMFowIwYJKoZIhvcNAQkEMRYEFOmeEfl90TvowxlahTp18CDf/A7bMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQAMeypNIjlQlATDlvNJxEpX5z/xYgVGxRRriu812d8ExbvLDqQuWWIZf1sz
GRdHofCog/SF5uyI7CPcxy63r9N5Eqgu5wszy6/6pcLyI/2r7s72oI48RR5dGwP7HNBJdRuf
tr8AsHLMWtb0Ey0VFEZDqsGdkRm7YZpSl0wJSlU1RckLIt83Hm96gqXspU4cc3zLnbVu98yj
3Jt1oZ86FAKcNpLWFeQcSqTheAjNdWcSNFTW34mlG08i68rljyoX07kU17A9GAdngneaZsqr
00mxgYv9kvLWMD8DD2YCbdAkBzn4Hldc7wZnoE4eAa5EjRRs/FTF2Dggyqa9PGDRy0scAAAA
AAAA
--------------ms010106010101030308050604--

From fippo@mail.symlynx.com  Thu Nov  4 13:56:27 2010
Return-Path: <fippo@mail.symlynx.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 7A73528C102; Thu,  4 Nov 2010 13:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 gagyyI2bsGVN; Thu,  4 Nov 2010 13:56:26 -0700 (PDT)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by core3.amsl.com (Postfix) with ESMTP id 3DEEC28C0E6; Thu,  4 Nov 2010 13:42:14 -0700 (PDT)
Received: from [192.168.2.103] (p4FF0C2F2.dip.t-dialin.net [79.240.194.242]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id oA4Kh8TL001051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Nov 2010 21:43:51 +0100
Message-ID: <4CD31A7C.1060502@mail.symlynx.com>
Date: Thu, 04 Nov 2010 21:41:32 +0100
From: Philipp Hancke <fippo@mail.symlynx.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>
References: <4CC9503D.2000809@gmail.com>	<4CCBA7A9.7030506@stpeter.im>	<4CCE87A5.80701@gmail.com>	<4CCF20E7.30401@stpeter.im> <4CD1D708.7010308@stpeter.im> <4CD2D90F.6040304@gmail.com>
In-Reply-To: <4CD2D90F.6040304@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sat, 06 Nov 2010 17:57:25 -0700
Cc: XMPP <xmpp@ietf.org>, draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org, Peter Saint-Andre <stpeter@stpeter.im>, secdir@ietf.org
Subject: Re: [secdir] [xmpp] 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: Thu, 04 Nov 2010 20:56:27 -0000

Yaron Sheffer wrote:
> Hi Peter,
>
> yes, these seem reasonable. Is there a "converse" to the rewriting of
> the client's From header before forwarding to other servers, i.e. is
> there a server-side check on stanza From headers received from other
> servers?

Yes, see 8.1.2.2. Server-to-Server Streams (or search for the associated 
invalid-from stream error).

From tom.kristensen@tandberg.com  Fri Nov  5 05:46:19 2010
Return-Path: <tom.kristensen@tandberg.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 AD5533A68F0; Fri,  5 Nov 2010 05:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 RTv63qSWMYZD; Fri,  5 Nov 2010 05:46:18 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 38FEB3A68CE; Fri,  5 Nov 2010 05:46:17 -0700 (PDT)
Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtsEAN+Z00yQ/khNgWdsb2JhbACDKZ5HFQEBFiIioFWKLpEAgSKDMnMEjV0G
X-IronPort-AV: E=Sophos;i="4.58,301,1286150400"; d="scan'208";a="68440413"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 05 Nov 2010 12:46:30 +0000
Received: from OSLEXCP11.eu.tandberg.int ([173.38.136.5]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id oA5CkUkc025176; Fri, 5 Nov 2010 12:46:30 GMT
Received: from ultra.eu.tandberg.int ([10.47.1.15]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Nov 2010 13:46:30 +0100
Received: from [10.47.13.151] ([10.47.13.151]) by ultra.eu.tandberg.int (8.13.1/8.13.1) with ESMTP id oA5CkT43010486;  Fri, 5 Nov 2010 13:46:29 +0100
Message-ID: <4CD3FCA4.70401@tandberg.com>
Date: Fri, 05 Nov 2010 13:46:28 +0100
From: Tom Kristensen <tom.kristensen@tandberg.com>
Organization: Cisco
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100907 Fedora/3.0.7-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.7
MIME-Version: 1.0
To: "Scott G. Kelly" <scott@hyperthought.com>
References: <1288888292.35265529@192.168.2.228>
In-Reply-To: <1288888292.35265529@192.168.2.228>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Nov 2010 12:46:30.0179 (UTC) FILETIME=[77F16730:01CB7CE7]
X-Mailman-Approved-At: Sat, 06 Nov 2010 17:57:25 -0700
Cc: "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-avt-rtp-h264-rcdo.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-avt-rtp-h264-rcdo-07
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: Fri, 05 Nov 2010 12:46:19 -0000

On 11/04/2010 05:31 PM, Scott G. Kelly wrote:
> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.
>
> This draft describes a new RTP payload format, extending existing RTP capabilities. Based on my limited understanding of RTP, this introduces no new security considerations.
>
> The security considerations section starts off by saying this, but then goes on to talk about various security properties that could be added by various means. I found the text to be a little confusing, especially when it makes recommendations without detailing any particular threats.

I can understand this conclusion. A simplification makes sense as the 
recommendations given here is described better within a security context 
in the RTP RFC and associated specifications. However, I'd like to keep 
the reference to the H.264 security considerations, with its codec 
specific details. My proposed text for the security considerations at 
bottom.

> I would suggest simplifying the security considerations. Here is the current text:
>
>    "RTP packets using the payload format defined in this specification
>     are subject to the security considerations discussed in the RTP
>     specification [6], and in any applicable RTP profile.  The main
>     security considerations for the RTP packet carrying the RTP payload
>     format defined within this document are confidentiality, integrity
>     and source authenticity.  Confidentiality is achieved by encryption
>     of the RTP payload.  Integrity of the RTP packets through suitable
>     cryptographic integrity protection mechanism.  Cryptographic system
>     may also allow the authentication of the source of the payload.  A
>     suitable security mechanism for this RTP payload format should
>     provide confidentiality, integrity protection and at least source
>     authentication capable of determining if an RTP packet is from a
>     member of the RTP session or not.
>
>     Note that the appropriate mechanism to provide security to RTP and
>     payloads following this document may vary.  It is dependent on the
>     application, the transport, and the signalling protocol employed.
>     Therefore a single mechanism is not sufficient.  Usage of data origin
>     authentication and data integrity protection of at least the RTP
>     packet is RECOMMENDED, for example by use of the Secure Real-time
>     Transport Protocol (SRTP) [12].  Other mechanisms that may be used
>     are IPsec [13] and Transport Layer Security (TLS) [14] (RTP over
>     TCP), but other alternatives may exist.
>
>     Refer also to section 9 of RFC YYYY [3], as no reasons for separate
>     considerations are introduced in this document."
>
>
> I would suggest the following simplified text:
>
>    "RTP packets using the payload format defined in this specification
>     are subject to the security considerations discussed in the RTP
>     specification [6], and in any applicable RTP profile.  No additional
>     security considerations are introduced by this specification."
>
> (or something like this).

I would like to keep the reference to the security considerations 
section of RFC YYYY/RFC3984bis in, as specific H.264 threats and 
recommendations are included there. Cf.:
http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-12#section-9

So, something like this should be fine:

   "RTP packets using the payload format defined in this specification
    are subject to the security considerations discussed in the RTP
    specification [6], and in any applicable RTP profile. Refer also
    to section 9 of RFC YYYY [3]. No additional security
    considerations are introduced by this specification."

As a side note. One might consider altering the "template security 
considerations" section in the "How to Write an RTP Payload Format" 
draft according to the preferred security directorate/IESG policy for 
the RTP payload format specifications later on. Cf.:
http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-06#appendix-A.13

-- Tom

From Peter.SaintAndre@webex.com  Fri Nov  5 06:54:39 2010
Return-Path: <Peter.SaintAndre@webex.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 667F53A6948; Fri,  5 Nov 2010 06:54:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 5nRXvjPBOehF; Fri,  5 Nov 2010 06:54:38 -0700 (PDT)
Received: from gw1.webex.com (gw1.webex.com [64.68.122.208]) by core3.amsl.com (Postfix) with SMTP id A384D3A693F; Fri,  5 Nov 2010 06:54:38 -0700 (PDT)
Received: from SRV-EXSC03.webex.local ([192.168.252.197]) by gw1.webex.com with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 5 Nov 2010 06:54:51 -0700
X-Mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 5 Nov 2010 06:54:50 -0700
Message-ID: <B276A36CB76AE04FADC48FDD7ED6A1CA0368BE@SRV-EXSC03.webex.local>
In-Reply-To: <4CD31A7C.1060502@mail.symlynx.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17
Thread-Index: Act8YNP9Bdg8dPG1RMGfhaCCLK0A4QAkDBXY
From: "Peter Saint Andre" <Peter.SaintAndre@webex.com>
To: <fippo@mail.symlynx.com>, <yaronf.ietf@gmail.com>
X-OriginalArrivalTime: 05 Nov 2010 13:54:51.0130 (UTC) FILETIME=[044CDDA0:01CB7CF1]
X-Mailman-Approved-At: Sat, 06 Nov 2010 17:57:25 -0700
Cc: xmpp@ietf.org, draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org, stpeter@stpeter.im, secdir@ietf.org
Subject: Re: [secdir] [xmpp] 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: Fri, 05 Nov 2010 13:54:39 -0000

Yes, it would be good to add a conformance feature for that one, too.

----- Original Message -----
From: Philipp Hancke <fippo@mail.symlynx.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Cc: Peter Saint-Andre <stpeter@stpeter.im>; =
draft-ietf-xmpp-3920bis.all@tools.ietf.org =
<draft-ietf-xmpp-3920bis.all@tools.ietf.org>; iesg@ietf.org =
<iesg@ietf.org>; XMPP <xmpp@ietf.org>; secdir@ietf.org <secdir@ietf.org>
Sent: Thu Nov 04 13:41:32 2010
Subject: Re: [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17

Yaron Sheffer wrote:
> Hi Peter,
>
> yes, these seem reasonable. Is there a "converse" to the rewriting of
> the client's From header before forwarding to other servers, i.e. is
> there a server-side check on stanza From headers received from other
> servers?

Yes, see 8.1.2.2. Server-to-Server Streams (or search for the associated =

invalid-from stream error).

From patrick.luthi@tandberg.com  Fri Nov  5 11:29:48 2010
Return-Path: <patrick.luthi@tandberg.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 AB8CC3A691C; Fri,  5 Nov 2010 11:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 ZEgeMcf-Nt56; Fri,  5 Nov 2010 11:29:47 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3E11E3A6919; Fri,  5 Nov 2010 11:29:47 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAOHp00ytJV2a/2dsb2JhbACGRpsncaBjmz6FSASNZg
X-IronPort-AV: E=Sophos;i="4.58,304,1286150400"; d="scan'208";a="179040381"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 05 Nov 2010 18:29:59 +0000
Received: from OSLEXCP11.eu.tandberg.int ([173.38.136.5]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oA5ITwJk030849;  Fri, 5 Nov 2010 18:29:58 GMT
Received: from oslexcp2.eu.tandberg.int ([10.47.136.30]) by OSLEXCP11.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Nov 2010 19:29:58 +0100
Received: from Suisse129.tandberg.com ([128.107.141.242]) by oslexcp2.eu.tandberg.int with Microsoft SMTPSVC(6.0.3790.3959);  Fri, 5 Nov 2010 19:29:56 +0100
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 05 Nov 2010 19:23:43 +0100
To: Tom Kristensen <tom.kristensen@tandberg.com>, "Scott G. Kelly" <scott@hyperthought.com>
From: Patrick Luthi <patrick.luthi@tandberg.com>
In-Reply-To: <4CD3FCA4.70401@tandberg.com>
References: <1288888292.35265529@192.168.2.228> <4CD3FCA4.70401@tandberg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-ID: <OSLEXCP2XvpFVjCRGry00000012@oslexcp2.eu.tandberg.int>
X-OriginalArrivalTime: 05 Nov 2010 18:29:56.0953 (UTC) FILETIME=[72899490:01CB7D17]
X-Mailman-Approved-At: Sat, 06 Nov 2010 17:57:25 -0700
Cc: "iesg@ietf.org" <iesg@ietf.org>, draft-ietf-avt-rtp-h264-rcdo.all@tools.ietf.org, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-avt-rtp-h264-rcdo-07
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: Fri, 05 Nov 2010 18:29:48 -0000

Tom,

Your proposed text sounds good to me!

Regards,

Patrick

At 13:46 05/11/2010, Tom Kristensen wrote:
>On 11/04/2010 05:31 PM, Scott G. Kelly wrote:
>>I have reviewed this document as part of the security directorate's 
>>ongoing effort to review all IETF documents being processed by the 
>>IESG.  These comments were written primarily for the benefit of the 
>>security area directors.  Document editors and WG chairs should 
>>treat these comments just like any other last call comments.
>>
>>This draft describes a new RTP payload format, extending existing 
>>RTP capabilities. Based on my limited understanding of RTP, this 
>>introduces no new security considerations.
>>
>>The security considerations section starts off by saying this, but 
>>then goes on to talk about various security properties that could 
>>be added by various means. I found the text to be a little 
>>confusing, especially when it makes recommendations without 
>>detailing any particular threats.
>
>I can understand this conclusion. A simplification makes sense as 
>the recommendations given here is described better within a security 
>context in the RTP RFC and associated specifications. However, I'd 
>like to keep the reference to the H.264 security considerations, 
>with its codec specific details. My proposed text for the security 
>considerations at bottom.
>
>>I would suggest simplifying the security considerations. Here is 
>>the current text:
>>
>>    "RTP packets using the payload format defined in this specification
>>     are subject to the security considerations discussed in the RTP
>>     specification [6], and in any applicable RTP profile.  The main
>>     security considerations for the RTP packet carrying the RTP payload
>>     format defined within this document are confidentiality, integrity
>>     and source authenticity.  Confidentiality is achieved by encryption
>>     of the RTP payload.  Integrity of the RTP packets through suitable
>>     cryptographic integrity protection mechanism.  Cryptographic system
>>     may also allow the authentication of the source of the payload.  A
>>     suitable security mechanism for this RTP payload format should
>>     provide confidentiality, integrity protection and at least source
>>     authentication capable of determining if an RTP packet is from a
>>     member of the RTP session or not.
>>
>>     Note that the appropriate mechanism to provide security to RTP and
>>     payloads following this document may vary.  It is dependent on the
>>     application, the transport, and the signalling protocol employed.
>>     Therefore a single mechanism is not sufficient.  Usage of data origin
>>     authentication and data integrity protection of at least the RTP
>>     packet is RECOMMENDED, for example by use of the Secure Real-time
>>     Transport Protocol (SRTP) [12].  Other mechanisms that may be used
>>     are IPsec [13] and Transport Layer Security (TLS) [14] (RTP over
>>     TCP), but other alternatives may exist.
>>
>>     Refer also to section 9 of RFC YYYY [3], as no reasons for separate
>>     considerations are introduced in this document."
>>
>>
>>I would suggest the following simplified text:
>>
>>    "RTP packets using the payload format defined in this specification
>>     are subject to the security considerations discussed in the RTP
>>     specification [6], and in any applicable RTP profile.  No additional
>>     security considerations are introduced by this specification."
>>
>>(or something like this).
>
>I would like to keep the reference to the security considerations 
>section of RFC YYYY/RFC3984bis in, as specific H.264 threats and 
>recommendations are included there. Cf.:
>http://tools.ietf.org/html/draft-ietf-avt-rtp-rfc3984bis-12#section-9
>
>So, something like this should be fine:
>
>   "RTP packets using the payload format defined in this specification
>    are subject to the security considerations discussed in the RTP
>    specification [6], and in any applicable RTP profile. Refer also
>    to section 9 of RFC YYYY [3]. No additional security
>    considerations are introduced by this specification."
>
>As a side note. One might consider altering the "template security 
>considerations" section in the "How to Write an RTP Payload Format" 
>draft according to the preferred security directorate/IESG policy 
>for the RTP payload format specifications later on. Cf.:
>http://tools.ietf.org/html/draft-ietf-avt-rtp-howto-06#appendix-A.13
>
>-- Tom



From william.polk@nist.gov  Sat Nov  6 19:09:34 2010
Return-Path: <william.polk@nist.gov>
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 42D3C3A67A3 for <secdir@core3.amsl.com>; Sat,  6 Nov 2010 19:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 wzsJM7McsBOx for <secdir@core3.amsl.com>; Sat,  6 Nov 2010 19:09:33 -0700 (PDT)
Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 623AB3A6768 for <secdir@ietf.org>; Sat,  6 Nov 2010 19:09:33 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id oA729f5I024179 for <secdir@ietf.org>; Sat, 6 Nov 2010 22:09:41 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Sat, 6 Nov 2010 22:09:41 -0400
From: "Polk, William T." <william.polk@nist.gov>
To: "secdir@ietf.org" <secdir@ietf.org>
Date: Sat, 6 Nov 2010 22:09:22 -0400
Thread-Topic: Secdir lunch in Ruby, Tuesday 11:30 - 1:00
Thread-Index: AQHLfiDLsKW/5rOzfE6k5Ns/DzbShQ==
Message-ID: <D7A0423E5E193F40BE6E94126930C49307D6CF5537@MBCLUSTER.xchange.nist.gov>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: william.polk@nist.gov
Subject: [secdir] Secdir lunch in Ruby, Tuesday 11:30 - 1:00
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: Sun, 07 Nov 2010 02:09:34 -0000

Folks,

We will be having the security directorate lunch in the Ruby room (3rd floor) in our usual Tuesday time slot.

Hope to see you all there!

Thanks,

Tim Polk

From hannes.tschofenig@gmx.net  Sat Nov  6 19:29:06 2010
Return-Path: <hannes.tschofenig@gmx.net>
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 E3F9E28C0D9 for <secdir@core3.amsl.com>; Sat,  6 Nov 2010 19:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 DZH6ijdGxFLM for <secdir@core3.amsl.com>; Sat,  6 Nov 2010 19:29:06 -0700 (PDT)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.22]) by core3.amsl.com (Postfix) with SMTP id 543243A697C for <secdir@ietf.org>; Sat,  6 Nov 2010 19:29:06 -0700 (PDT)
Received: (qmail invoked by alias); 07 Nov 2010 02:22:41 -0000
Received: from dhcp-7730.meeting.ietf.org (EHLO dhcp-7730.meeting.ietf.org) [130.129.119.48] by mail.gmx.net (mp054) with SMTP; 07 Nov 2010 03:22:41 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19n/CxaxKRnPOLWqdig6r/No3Jvg6FTHRPuMNzUOR hWWFzgaMPScol0
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Date: Sat, 6 Nov 2010 21:22:33 -0500
Message-Id: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net>
To: ietf@ietf.org
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
X-Y-GMX-Trusted: 0
Cc: abfab@ietf.org, rai@ietf.org, secdir@ietf.org, websec@ietf.org, xmpp@ietf.org, kitten@ietf.org, "iab@iab.org Board" <iab@iab.org>, iesg@ietf.org, oauth@ietf.org
Subject: [secdir] ** OAuth Tutorial & OAuth Security Session **
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: Sun, 07 Nov 2010 02:29:07 -0000

Hi all,=20

please consider attending the following two meetings!=20

** OAuth Security Session **

	=95 Date: Monday, 13:00-15:00
	=95 Location: IAB breakout room (Jade 2)
	=95 Contact: Hannes Tschofenig hannes.tschofenig@gmx.net
The security consideration section of OAuth 2.0 (draft -10) is still =
empty. Hence, we would like to put some time aside to discuss what =
security threats, requirements, and countermeasures need to be =
described. We will use the Monday, November 8, 1300-1500 slot to have a  =
discussion session.

As a starting point I suggest to look at the following documents:

	=95 =
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
	=95 http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
	=95 =
http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt

Note: If you are unfamiliar with OAuth then the OAuth tutorial session =
might be more suitable for you!



** OAuth Tutorial **

	=95 Date: Wednesday, 19:30 (after the plenary)
	=95 Location: IAB breakout room (Jade 2)
	=95 Contact: Hannes Tschofenig hannes.tschofenig@gmx.net
OAuth allows a user to grant a third-party Web site or application =
access to their resources, without necessarily revealing their =
credentials, or even their identity. The OAuth working group, see =
http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to =
finalize their main specification, namely OAuth v2: =
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/

Based on the positive response at the last IETF meeting (in Maastricht) =
we decided to hold another OAuth tutorial, namely on *Wednesday, =
starting at 19:30 (after the IETF Operations and Administration Plenary) =
till about 21:00. (Note: I had to switch the day because of the social =
event!)

It is helpful to read through the documents available int he working =
group but not required.

Up-to-date information can be found here: =
http://www.ietf.org/registration/MeetingWiki/wiki/79bofs

Ciao
Hannes


From kent@bbn.com  Sat Nov  6 20:26:57 2010
Return-Path: <kent@bbn.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 AECD03A69BD for <secdir@core3.amsl.com>; Sat,  6 Nov 2010 20:26:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 D7JSHFyMtGtJ for <secdir@core3.amsl.com>; Sat,  6 Nov 2010 20:26:55 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id E2DF43A67B6 for <secdir@ietf.org>; Sat,  6 Nov 2010 20:26:54 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:51054 helo=[222.128.202.177]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1PEvuO-000PXX-Jz; Sat, 06 Nov 2010 23:27:09 -0400
Mime-Version: 1.0
Message-Id: <p06240801c8fbcc3b59d7@[222.128.202.177]>
In-Reply-To: <4CC81942.3060502@ericsson.com>
References: <p06240800c8e55027a17b@[128.89.89.159]> <4CC81942.3060502@ericsson.com>
Date: Sat, 6 Nov 2010 23:25:48 -0400
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary="============_-923022067==_ma============"
Cc: "secdir@ietf.org" <secdir@ietf.org>, "gao.yang2@zte.com.cn" <gao.yang2@zte.com.cn>, "pkyzivat@cisco.com" <pkyzivat@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>, "tim.polk@nist.gov" <tim.polk@nist.gov>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
Subject: Re: [secdir] review of draft-ietf-sipcore-reinvite-06.txt
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: Sun, 07 Nov 2010 03:26:57 -0000

--============_-923022067==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Gonzalo,

Sorry for my tardy reply.

I like your changes, with a minor edit at the end:

"In particular, in order not to reduce the security level for a given
session, re-INVITEs and UPDATE requests SHOULD be secured using a 
mechanism equivalent to or stronger than the initial INVITE request 
that created the
session. For example, if the initial INVITE request was end-to-end
integrity protected or encrypted, subsequent re-INVITEs and UPDATE
requests should also be so."


Steve
--============_-923022067==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: review of
draft-ietf-sipcore-reinvite-06.txt</title></head><body>
<div>Gonzalo,</div>
<div><br></div>
<div>Sorry for my tardy reply.</div>
<div><br></div>
<div>I like your changes, with a minor edit at the end:</div>
<div><br></div>
<div>&quot;In particular, in order not to reduce the security level
for a given</div>
<div>session, re-INVITEs and UPDATE requests SHOULD be<font
color="#FF0000"> secured using a mechanism equivalent to or stronger
than</font> the initial INVITE request that created the</div>
<div>session. For example, if the initial INVITE request was
end-to-end<br>
integrity protected or encrypted, subsequent re-INVITEs and
UPDATE</div>
<div>requests should also be so.&quot;</div>
<div><br></div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-923022067==_ma============--

From torsten@lodderstedt.net  Sun Nov  7 15:04:07 2010
Return-Path: <torsten@lodderstedt.net>
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 A981F28C11F; Sun,  7 Nov 2010 15:04:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level: 
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 jwtw++ocQDAp; Sun,  7 Nov 2010 15:04:06 -0800 (PST)
Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.24]) by core3.amsl.com (Postfix) with ESMTP id 89E1A3A6919; Sun,  7 Nov 2010 15:04:06 -0800 (PST)
Received: from [79.253.37.94] (helo=[192.168.71.43]) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1PFEHg-0007pK-9T; Mon, 08 Nov 2010 00:04:24 +0100
Message-ID: <4CD73075.8050408@lodderstedt.net>
Date: Mon, 08 Nov 2010 00:04:21 +0100
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net>
In-Reply-To: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Df-Sender: torsten@lodderstedt-online.de
X-Mailman-Approved-At: Sun, 07 Nov 2010 15:51:03 -0800
Cc: abfab@ietf.org, rai@ietf.org, ietf@ietf.org, secdir@ietf.org, websec@ietf.org, xmpp@ietf.org, kitten@ietf.org, "iab@iab.org Board" <iab@iab.org>, iesg@ietf.org, Mark Mcgloin <mark.mcgloin@ie.ibm.com>, oauth@ietf.org
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
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: Sun, 07 Nov 2010 23:04:07 -0000

Hi all,

Mark McGloin and me have been working on OAuth 2.0 security 
considerations for a couple of weeks now. Since we both cannot attend 
the IETF-79 meetings, we would like to provide the WG with information 
regarding the current status of our work. I therefore uploaded a 
_preliminary_ version of our working document to the WG's wiki at 
http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. 
The focus of this version was on consolidating previous work as well as 
results of mailing list discussions and start working towards a rigorous 
threat model.

Please give us feedback.

regards,
Torsten.

Am 07.11.2010 03:22, schrieb Hannes Tschofenig:
> Hi all,
>
> please consider attending the following two meetings!
>
> ** OAuth Security Session **
>
> 	• Date: Monday, 13:00-15:00
> 	• Location: IAB breakout room (Jade 2)
> 	• Contact: Hannes Tschofenig hannes.tschofenig@gmx.net
> The security consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we would like to put some time aside to discuss what security threats, requirements, and countermeasures need to be described. We will use the Monday, November 8, 1300-1500 slot to have a  discussion session.
>
> As a starting point I suggest to look at the following documents:
>
> 	• http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
> 	• http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
> 	• http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.txt
>
> Note: If you are unfamiliar with OAuth then the OAuth tutorial session might be more suitable for you!
>
>
>
> ** OAuth Tutorial **
>
> 	• Date: Wednesday, 19:30 (after the plenary)
> 	• Location: IAB breakout room (Jade 2)
> 	• Contact: Hannes Tschofenig hannes.tschofenig@gmx.net
> OAuth allows a user to grant a third-party Web site or application access to their resources, without necessarily revealing their credentials, or even their identity. The OAuth working group, see http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to finalize their main specification, namely OAuth v2: http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/
>
> Based on the positive response at the last IETF meeting (in Maastricht) we decided to hold another OAuth tutorial, namely on *Wednesday, starting at 19:30 (after the IETF Operations and Administration Plenary) till about 21:00. (Note: I had to switch the day because of the social event!)
>
> It is helpful to read through the documents available int he working group but not required.
>
> Up-to-date information can be found here: http://www.ietf.org/registration/MeetingWiki/wiki/79bofs
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth


From gonzalo.camarillo@ericsson.com  Sun Nov  7 22:01:00 2010
Return-Path: <gonzalo.camarillo@ericsson.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 991C53A69C0 for <secdir@core3.amsl.com>; Sun,  7 Nov 2010 22:01:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.511
X-Spam-Level: 
X-Spam-Status: No, score=-106.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 nkUMUIdq2YRt for <secdir@core3.amsl.com>; Sun,  7 Nov 2010 22:00:59 -0800 (PST)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7781C3A69B3 for <secdir@ietf.org>; Sun,  7 Nov 2010 22:00:59 -0800 (PST)
X-AuditID: c1b4fb39-b7b54ae000003464-e1-4cd7922f305b
Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 80.65.13412.F2297DC4; Mon,  8 Nov 2010 07:01:19 +0100 (CET)
Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 8 Nov 2010 07:01:18 +0100
Received: from [131.160.126.193] ([131.160.126.193]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959);  Mon, 8 Nov 2010 07:01:18 +0100
Message-ID: <4CD79229.8040400@ericsson.com>
Date: Mon, 08 Nov 2010 14:01:13 +0800
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
References: <p06240800c8e55027a17b@[128.89.89.159]> <4CC81942.3060502@ericsson.com> <p06240801c8fbcc3b59d7@[222.128.202.177]>
In-Reply-To: <p06240801c8fbcc3b59d7@[222.128.202.177]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 08 Nov 2010 06:01:18.0597 (UTC) FILETIME=[5C59A350:01CB7F0A]
X-Brightmail-Tracker: AAAAAA==
Cc: "secdir@ietf.org" <secdir@ietf.org>, "gao.yang2@zte.com.cn" <gao.yang2@zte.com.cn>, "pkyzivat@cisco.com" <pkyzivat@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>, "tim.polk@nist.gov" <tim.polk@nist.gov>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
Subject: Re: [secdir] review of draft-ietf-sipcore-reinvite-06.txt
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, 08 Nov 2010 06:01:00 -0000

Hi Stephen,

I agree with your proposed edit. I will revise the draft accordingly.

Thanks,

Gonzalo

On 07/11/2010 11:25 AM, Stephen Kent wrote:
> Gonzalo,
> 
> Sorry for my tardy reply.
> 
> I like your changes, with a minor edit at the end:
> 
> "In particular, in order not to reduce the security level for a given
> session, re-INVITEs and UPDATE requests SHOULD be secured using a
> mechanism equivalent to or stronger than the initial INVITE request that
> created the
> session. For example, if the initial INVITE request was end-to-end
> integrity protected or encrypted, subsequent re-INVITEs and UPDATE
> requests should also be so."
> 
> 
> Steve


From tena@huawei.com  Mon Nov  8 03:55:31 2010
Return-Path: <tena@huawei.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 CD2113A69BB for <secdir@core3.amsl.com>; Mon,  8 Nov 2010 03:55:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.384
X-Spam-Level: 
X-Spam-Status: No, score=-100.384 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, 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 J3nX5TzXksX5 for <secdir@core3.amsl.com>; Mon,  8 Nov 2010 03:55:30 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2FCF43A69AC for <secdir@ietf.org>; Mon,  8 Nov 2010 03:55:30 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBK00544EGSXC@szxga03-in.huawei.com> for secdir@ietf.org; Mon, 08 Nov 2010 19:55:40 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LBK00K5WEGSIR@szxga03-in.huawei.com> for secdir@ietf.org; Mon, 08 Nov 2010 19:55:40 +0800 (CST)
Received: from dhcp-72cb.meeting.ietf.org (dhcp-72cb.meeting.ietf.org [130.129.114.203]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LBK00IYQEGNNF@szxml01-in.huawei.com> for secdir@ietf.org; Mon, 08 Nov 2010 19:55:40 +0800 (CST)
Date: Mon, 08 Nov 2010 19:55:34 +0800
From: Tina TSOU <tena@huawei.com>
To: secdir@ietf.org
Message-id: <6DB045CE-E31B-4BA4-999F-313316A05389@huawei.com>
MIME-version: 1.0
X-Mailer: Apple Mail (2.936)
Content-type: multipart/alternative; boundary="Boundary_(ID_gX5v6XWIJyd+OTeNmpECxA)"
Subject: [secdir] SecDir review of draft-ietf-sieve-vacation-seconds-02
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, 08 Nov 2010 11:55:31 -0000

--Boundary_(ID_gX5v6XWIJyd+OTeNmpECxA)
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-transfer-encoding: 7BIT

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document describes a further extension to the Sieve Vacation
    extension, allowing multiple auto-replies to the same sender in a
    single day by adding a ":seconds" parameter.

In section 4, it says

    Security considerations for the Sieve Vacation extension [RFC5230]
    apply equally here.  In addition, implementations SHOULD consider  
the
    number of auto-replies that might be generated by allowing small
    values of ":seconds" (including 0), and MAY impose additional limits
    on that number.  See the Security Considerations section of RFC 3834
    [RFC3834] for a fuller discussion.

I don't see any other pending issues regarding the security aspect.


B. R.
Tina
http://tinatsou.weebly.com





--Boundary_(ID_gX5v6XWIJyd+OTeNmpECxA)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: quoted-printable

<html><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; =
-webkit-line-break: after-white-space; "><div><font =
class=3D"Apple-style-span" face=3D"Arial">I have reviewed this document =
as part of the security directorate's<br>ongoing effort to review all =
IETF documents being processed by the IESG.<br>These comments were =
written primarily for the benefit of the security<br>area directors. =
&nbsp;Document editors and WG chairs should treat these<br>comments just =
like any other last call comments.<br><br></font><span =
class=3D"Apple-style-span" style=3D"line-height: 16px; =
-webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: =
2px; "><pre style=3D"line-height: 1.2em; margin-top: 0px; margin-right: =
0px; margin-bottom: 0px; margin-left: 0px; "><font =
class=3D"Apple-style-span" face=3D"Arial" size=3D"3"><span =
class=3D"Apple-style-span" style=3D"font-size: 12px;">This document =
describes a further extension to the Sieve Vacation
   extension, allowing multiple auto-replies to the same sender in a
   single day by adding a ":seconds" parameter.</span></font></pre><pre =
style=3D"line-height: 1.2em; margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font class=3D"Apple-style-span" =
face=3D"Arial" size=3D"3"><span class=3D"Apple-style-span" =
style=3D"font-size: 12px;"><br></span></font></pre><pre =
style=3D"line-height: 1.2em; margin-top: 0px; margin-right: 0px; =
margin-bottom: 0px; margin-left: 0px; "><font class=3D"Apple-style-span" =
face=3D"Arial" size=3D"3"><span class=3D"Apple-style-span" =
style=3D"font-size: 12px;">In section 4, it =
says</span></font></pre></span></div><div><font class=3D"Apple-style-span"=
 face=3D"Arial"><br></font></div><div><span class=3D"Apple-style-span" =
style=3D"line-height: 16px; -webkit-border-horizontal-spacing: 2px; =
-webkit-border-vertical-spacing: 2px; "><pre style=3D"line-height: =
1.2em; margin-top: 0px; margin-right: 0px; margin-bottom: 0px; =
margin-left: 0px; "><font class=3D"Apple-style-span" face=3D"Arial" =
size=3D"3"><span class=3D"Apple-style-span" style=3D"font-size: 12px;">  =
 Security considerations for the Sieve Vacation extension [RFC5230]
   apply equally here.  In addition, implementations SHOULD consider the
   number of auto-replies that might be generated by allowing small
   values of ":seconds" (including 0), and MAY impose additional limits
   on that number.  See the Security Considerations section of RFC 3834
   [RFC3834] for a fuller =
discussion.</span></font></pre></span></div><div><font =
class=3D"Apple-style-span" face=3D"Arial"><br></font></div><font =
class=3D"Apple-style-span" face=3D"Arial">I don't see any other pending =
issues regarding the security aspect.<br></font><div><font =
class=3D"Apple-style-span" face=3D"Arial"><br =
class=3D"webkit-block-placeholder"></font></div><div><font =
class=3D"Apple-style-span" face=3D"Arial"><br =
class=3D"webkit-block-placeholder"></font></div><div =
apple-content-edited=3D"true"> <span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><span class=3D"Apple-style-span" =
style=3D"border-collapse: separate; color: rgb(0, 0, 0); font-style: =
normal; font-variant: normal; font-weight: normal; letter-spacing: =
normal; line-height: normal; orphans: 2; text-indent: 0px; =
text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; "><div style=3D"word-wrap: =
break-word; -webkit-nbsp-mode: space; -webkit-line-break: =
after-white-space; "><div><div><font class=3D"Apple-style-span" =
face=3D"Arial">B. R.</font></div><div><font class=3D"Apple-style-span" =
face=3D"Arial">Tina</font></div><div><font class=3D"Apple-style-span" =
face=3D"Arial"><a =
href=3D"http://tinatsou.weebly.com">http://tinatsou.weebly.com</a></font><=
/div><div></div></div><div><font class=3D"Apple-style-span" =
face=3D"Arial"><br></font></div></div></span><font =
class=3D"Apple-style-span" face=3D"Arial"><br =
class=3D"Apple-interchange-newline"></font></div></span><font =
class=3D"Apple-style-span" face=3D"Arial"><br =
class=3D"Apple-interchange-newline"></font> </div><br></body></html>=

--Boundary_(ID_gX5v6XWIJyd+OTeNmpECxA)--

From weiler@watson.org  Mon Nov  8 14:22:36 2010
Return-Path: <weiler@watson.org>
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 277583A68AE for <secdir@core3.amsl.com>; Mon,  8 Nov 2010 14:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level: 
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599]
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 3kXSb3LcKbD2 for <secdir@core3.amsl.com>; Mon,  8 Nov 2010 14:22:35 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 3863F3A6874 for <secdir@ietf.org>; Mon,  8 Nov 2010 14:22:35 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id oA8MMuSN066693 for <secdir@ietf.org>; Mon, 8 Nov 2010 17:22:57 -0500 (EST) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id oA8MMuqN066690 for <secdir@ietf.org>; Mon, 8 Nov 2010 17:22:56 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Mon, 8 Nov 2010 17:22:56 -0500 (EST)
From: Samuel Weiler <weiler@watson.org>
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.1011080443540.54601@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 08 Nov 2010 17:22:57 -0500 (EST)
Subject: [secdir]  Secdir lunch in Ruby, Tuesday 11:30 - 1:00 (fwd)
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
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, 08 Nov 2010 22:22:36 -0000

As a reminder of the location:

---------- Forwarded message ----------
Date: Sat, 6 Nov 2010 22:09:22 -0400
From: "Polk, William T." <william.polk@nist.gov>
To: "secdir@ietf.org" <secdir@ietf.org>
Subject: [secdir] Secdir lunch in Ruby, Tuesday 11:30 - 1:00

Folks,

We will be having the security directorate lunch in the Ruby room (3rd floor) in our usual Tuesday time slot.

Hope to see you all there!

Thanks,

Tim Polk
_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir


From stpeter@stpeter.im  Mon Nov  8 11:44:45 2010
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 825303A686D; Mon,  8 Nov 2010 11:44:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ftdBSX2b3xlO; Mon,  8 Nov 2010 11:44:44 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 935163A6800; Mon,  8 Nov 2010 11:44:44 -0800 (PST)
Received: from dhcp-44a7.meeting.ietf.org (dhcp-44a7.meeting.ietf.org [130.129.68.167]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6285A40D1E; Mon,  8 Nov 2010 12:54:14 -0700 (MST)
Message-ID: <4CD8533D.1090006@stpeter.im>
Date: Tue, 09 Nov 2010 03:45:01 +0800
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: Peter Saint Andre <Peter.SaintAndre@webex.com>
References: <B276A36CB76AE04FADC48FDD7ED6A1CA0368BE@SRV-EXSC03.webex.local>
In-Reply-To: <B276A36CB76AE04FADC48FDD7ED6A1CA0368BE@SRV-EXSC03.webex.local>
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="------------ms020305020303020006020102"
X-Mailman-Approved-At: Mon, 08 Nov 2010 16:06:25 -0800
Cc: secdir@ietf.org, draft-ietf-xmpp-3920bis.all@tools.ietf.org, fippo@mail.symlynx.com, xmpp@ietf.org, iesg@ietf.org
Subject: Re: [secdir] [xmpp] 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, 08 Nov 2010 19:44:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms020305020303020006020102
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Never mind, we already have that:

   Feature:  stanza-attribute-from-validate
   Description:  Validate the 'from' address of all stanzas received
      from a peer servers.
   Section:  Section 8.1.2.2
   Roles:  Client N/A, Server MUST.

Issue closed. :)

On 11/5/10 9:54 PM, Peter Saint Andre wrote:
> Yes, it would be good to add a conformance feature for that one,
> too.
>=20
> ----- Original Message ----- From: Philipp Hancke
> <fippo@mail.symlynx.com> To: Yaron Sheffer <yaronf.ietf@gmail.com>=20
> Cc: Peter Saint-Andre <stpeter@stpeter.im>;
> draft-ietf-xmpp-3920bis.all@tools.ietf.org
> <draft-ietf-xmpp-3920bis.all@tools.ietf.org>; iesg@ietf.org
> <iesg@ietf.org>; XMPP <xmpp@ietf.org>; secdir@ietf.org
> <secdir@ietf.org> Sent: Thu Nov 04 13:41:32 2010 Subject: Re: [xmpp]
> SecDir review of draft-ietf-xmpp-3920bis-17
>=20
> Yaron Sheffer wrote:
>> Hi Peter,
>>=20
>> yes, these seem reasonable. Is there a "converse" to the rewriting
>> of the client's From header before forwarding to other servers,
>> i.e. is there a server-side check on stanza From headers received
>> from other servers?
>=20
> Yes, see 8.1.2.2. Server-to-Server Streams (or search for the
> associated invalid-from stream error).


--------------ms020305020303020006020102
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEw
ODE5NDUwMVowIwYJKoZIhvcNAQkEMRYEFP0Bi/Z0I0GPAPopY8+cucmlKnxkMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCf6UqgMjlmvO5pa/pSMYfTKdL5DtvriNzIWSX0dy0BuSPO8S62KXEyyv/t
6VTwBG3SG+pQTDdgAwP/FMacckPBei/f4YRFUkeacE3WUqSHTCf/AxaXaQlnKcdnzLodRIp6
i/Qc9QSSBeA/riUNZYQw8/sJ+JmMlk+cIhhRoZgo6PGuH+pr8/4r0RzO43lzTSbUmczE1+DS
emcCKUI9PLyBTddK3g5DypAKFclv2oY0he1IHgqxm51FZ5ebA/r3qf6oAaUY0rRkyIOqcOfg
IyM0F9J3o7WoJ2omYkz6O4QgJygZ5TJTSNL+7YNO55IqEx2ju+RaycyfJTBvgekINs7fAAAA
AAAA
--------------ms020305020303020006020102--

From Hannes.Tschofenig@gmx.net  Mon Nov  8 20:48:23 2010
Return-Path: <Hannes.Tschofenig@gmx.net>
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 D8C113A681E for <secdir@core3.amsl.com>; Mon,  8 Nov 2010 20:48:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.474
X-Spam-Level: 
X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 WYGfG7eUTkYI for <secdir@core3.amsl.com>; Mon,  8 Nov 2010 20:48:23 -0800 (PST)
Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id A24863A67BD for <secdir@ietf.org>; Mon,  8 Nov 2010 20:48:22 -0800 (PST)
Received: (qmail invoked by alias); 09 Nov 2010 04:48:44 -0000
Received: from dhcp-7730.meeting.ietf.org (EHLO dhcp-7730.meeting.ietf.org) [130.129.119.48] by mail.gmx.net (mp055) with SMTP; 09 Nov 2010 05:48:44 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX18DdaFYe2sDFYYKcKms5qsQqHTdbjMCyK9B8c70HO vX7NAUjTAkAAk1
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1081)
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Date: Tue, 9 Nov 2010 12:48:40 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <30791BD9-3574-4FBF-9E5A-038800B73A5E@gmx.net>
References: <5F644EED-8B5F-4FDB-B04A-505917386F9D@gmx.net>
To: secdir@ietf.org
X-Mailer: Apple Mail (2.1081)
X-Y-GMX-Trusted: 0
Cc: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Subject: [secdir] Fwd: 2nd OAuth Security Session, Thursday (18:10)
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: Tue, 09 Nov 2010 04:48:24 -0000

FYI: Interested participants please show up.

Begin forwarded message:

> From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> Date: November 9, 2010 12:47:03 PM GMT+08:00
> To: oauth@ietf.org
> Cc: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
> Subject: 2nd OAuth Security Session, Thursday (18:10)
>=20
> Hi all,=20
>=20
> at yesterday's security session we discussed ways on what to provide =
in the security consideration for the OAuth specifications. =20
> The plan was to have another session on Thursday, November 11th, =
starting at 18:10 at the IAB breakout room (Jade 2).
>=20
> We plan to go out for dinner together.=20
>=20
> Ciao
> Hannes
>=20


From tonynad@microsoft.com  Mon Nov  8 17:54:36 2010
Return-Path: <tonynad@microsoft.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 A861C3A68FA; Mon,  8 Nov 2010 17:54:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 2a7xn1iLpb31; Mon,  8 Nov 2010 17:54:35 -0800 (PST)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by core3.amsl.com (Postfix) with ESMTP id A8A9A3A6898; Mon,  8 Nov 2010 17:54:35 -0800 (PST)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 8 Nov 2010 17:54:58 -0800
Received: from TK5EX14MBXC113.redmond.corp.microsoft.com ([169.254.6.199]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0255.003; Mon, 8 Nov 2010 17:54:58 -0800
From: Anthony Nadalin <tonynad@microsoft.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>, Hannes Tschofenig <hannes.tschofenig@gmx.net>
Thread-Topic: [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
Thread-Index: AQHLfisaqAne5bBEGEGUAfaUzHbBGZNnKf+AgAE438A=
Date: Tue, 9 Nov 2010 01:54:57 +0000
Message-ID: <180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com>
References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> <4CD73075.8050408@lodderstedt.net>
In-Reply-To: <4CD73075.8050408@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.123.12]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 08 Nov 2010 23:38:06 -0800
Cc: "abfab@ietf.org" <abfab@ietf.org>, "rai@ietf.org" <rai@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "websec@ietf.org" <websec@ietf.org>, "xmpp@ietf.org" <xmpp@ietf.org>, "kitten@ietf.org" <kitten@ietf.org>, "iab@iab.org Board" <iab@iab.org>, "iesg@ietf.org" <iesg@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
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: Tue, 09 Nov 2010 01:54:36 -0000

I was looking for less of an analysis and more of considerations (of the cu=
rrent flows and actors), I'm not sure how to adapt what you have done to ac=
tually fit in the current specification, was your thought that you would pr=
oduce a separate security analysis document?

-----Original Message-----
From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of T=
orsten Lodderstedt
Sent: Sunday, November 07, 2010 3:04 PM
To: Hannes Tschofenig
Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org; websec@ie=
tf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; iesg@ietf.org; o=
auth@ietf.org
Subject: Re: [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **

Hi all,

Mark McGloin and me have been working on OAuth 2.0 security considerations =
for a couple of weeks now. Since we both cannot attend the IETF-79 meetings=
, we would like to provide the WG with information regarding the current st=
atus of our work. I therefore uploaded a _preliminary_ version of our worki=
ng document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/at=
tachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf.=20
The focus of this version was on consolidating previous work as well as res=
ults of mailing list discussions and start working towards a rigorous threa=
t model.

Please give us feedback.

regards,
Torsten.

Am 07.11.2010 03:22, schrieb Hannes Tschofenig:
> Hi all,
>
> please consider attending the following two meetings!
>
> ** OAuth Security Session **
>
> 	* Date: Monday, 13:00-15:00
> 	* Location: IAB breakout room (Jade 2)
> 	* Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The security=20
> consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we =
would like to put some time aside to discuss what security threats, require=
ments, and countermeasures need to be described. We will use the Monday, No=
vember 8, 1300-1500 slot to have a  discussion session.
>
> As a starting point I suggest to look at the following documents:
>
> 	* http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
> 	* http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
> 	*=20
> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.
> txt
>
> Note: If you are unfamiliar with OAuth then the OAuth tutorial session mi=
ght be more suitable for you!
>
>
>
> ** OAuth Tutorial **
>
> 	* Date: Wednesday, 19:30 (after the plenary)
> 	* Location: IAB breakout room (Jade 2)
> 	* Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth allows a=20
> user to grant a third-party Web site or application access to their=20
> resources, without necessarily revealing their credentials, or even=20
> their identity. The OAuth working group, see=20
> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to=20
> finalize their main specification, namely OAuth v2:=20
> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/
>
> Based on the positive response at the last IETF meeting (in=20
> Maastricht) we decided to hold another OAuth tutorial, namely on=20
> *Wednesday, starting at 19:30 (after the IETF Operations and=20
> Administration Plenary) till about 21:00. (Note: I had to switch the=20
> day because of the social event!)
>
> It is helpful to read through the documents available int he working grou=
p but not required.
>
> Up-to-date information can be found here:=20
> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs
>
> Ciao
> Hannes
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


From SRS0=si2S7B=SK=lodderstedt.net=torsten@srs.bis.eu.blackberry.com  Tue Nov  9 00:07:39 2010
Return-Path: <SRS0=si2S7B=SK=lodderstedt.net=torsten@srs.bis.eu.blackberry.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 66F0E3A6890; Tue,  9 Nov 2010 00:07:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.846
X-Spam-Level: 
X-Spam-Status: No, score=-4.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
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 wlATxjM3OeG8; Tue,  9 Nov 2010 00:07:38 -0800 (PST)
Received: from smtp06.bis.eu.blackberry.com (smtp06.bis.eu.blackberry.com [216.9.253.29]) by core3.amsl.com (Postfix) with ESMTP id 73A5C3A688E; Tue,  9 Nov 2010 00:07:36 -0800 (PST)
Received: from bda2319.bisx.produk.on.blackberry (bda2319.bisx.produk.on.blackberry [172.24.204.122]) by srs.bis.eu.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id oA987xRm004407; Tue, 9 Nov 2010 08:07:59 GMT
Received: from bda2319.bisx.produk.on.blackberry (localhost.localdomain [127.0.0.1]) by bda2319.bisx.produk.on.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id oA987vRo016870; Tue, 9 Nov 2010 08:07:57 GMT
X-rim-org-msg-ref-id: 1893623701
Message-ID: <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry>
Content-Transfer-Encoding: base64
X-Priority: Normal
References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com>
In-Reply-To: <180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com>
Sensitivity: Normal
Importance: Normal
To: "Anthony Nadalin" <tonynad@microsoft.com>, "Tschofenig, Hannes" <Hannes.Tschofenig@gmx.net>
From: torsten@lodderstedt.net
Date: Tue, 9 Nov 2010 08:07:56 +0000
Content-Type: text/plain; charset="Windows-1252"
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 09 Nov 2010 00:38:47 -0800
Cc: "abfab@ietf.org" <abfab@ietf.org>, "rai@ietf.org" <rai@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "websec@ietf.org" <websec@ietf.org>, "xmpp@ietf.org" <xmpp@ietf.org>, "kitten@ietf.org" <kitten@ietf.org>, "iab@iab.org Board" <iab@iab.org>, "iesg@ietf.org" <iesg@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: torsten@lodderstedt.net
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: Tue, 09 Nov 2010 08:11:47 -0000

V2UgdGhpbmsgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNob3VsZCBiZSBiYXNlZCBvbiBh
IHRocmVhdCBtb2RlbCBvZiBPQXV0aC4gQnV0IGEgY29tcGxldGUgdGhyZWF0IG1vZGVsIHdvdWxk
IGJsb3cgdXAgdGhlIHNwZWMuDQoNCldlIHRoZXJlZm9yZSBhaW0gdG8gcHJvZHVjZSBhIHNlcGFy
YXRlIHNlY3VyaXR5IGRvY3VtZW50IChpbmZvcm1hdGlvbmFsIEktRC9SRkMpIGNvdmVyaW5nIHRo
cmVhdCBtb2RlbCBhcyB3ZWxsIGFzIHNlY3VyaXR5IGRlc2lnbiBhbmQgY29uc2lkZXJhdGlvbnMu
IFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIG9mIHRoZSBjb3JlIHNwZWMgY2Fu
IHRoZW4gYmUgZGlzdGlsbGVkIGZyb20gdGhpcyBkb2N1bWVudC4NCg0KUmVnYXJkcywNClRvcnN0
ZW4uDQpHZXNlbmRldCBtaXQgQmxhY2tCZXJyea4gV2VibWFpbCB2b24gVGVsZWtvbSBEZXV0c2No
bGFuZCAgDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBBbnRob255IE5hZGFs
aW4gPHRvbnluYWRAbWljcm9zb2Z0LmNvbT4NCkRhdGU6IFR1ZSwgOSBOb3YgMjAxMCAwMTo1NDo1
NyANClRvOiBUb3JzdGVuIExvZGRlcnN0ZWR0PHRvcnN0ZW5AbG9kZGVyc3RlZHQubmV0PjsgSGFu
bmVzIFRzY2hvZmVuaWc8aGFubmVzLnRzY2hvZmVuaWdAZ214Lm5ldD4NCkNjOiBhYmZhYkBpZXRm
Lm9yZzxhYmZhYkBpZXRmLm9yZz47IHJhaUBpZXRmLm9yZzxyYWlAaWV0Zi5vcmc+OyBpZXRmQGll
dGYub3JnPGlldGZAaWV0Zi5vcmc+OyBzZWNkaXJAaWV0Zi5vcmc8c2VjZGlyQGlldGYub3JnPjsg
d2Vic2VjQGlldGYub3JnPHdlYnNlY0BpZXRmLm9yZz47IHhtcHBAaWV0Zi5vcmc8eG1wcEBpZXRm
Lm9yZz47IGtpdHRlbkBpZXRmLm9yZzxraXR0ZW5AaWV0Zi5vcmc+OyBpYWJAaWFiLm9yZyBCb2Fy
ZDxpYWJAaWFiLm9yZz47IGllc2dAaWV0Zi5vcmc8aWVzZ0BpZXRmLm9yZz47IG9hdXRoQGlldGYu
b3JnPG9hdXRoQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtPQVVUSC1XR10gKiogT0F1dGggVHV0
b3JpYWwgJiBPQXV0aCBTZWN1cml0eSBTZXNzaW9uICoqDQoNCkkgd2FzIGxvb2tpbmcgZm9yIGxl
c3Mgb2YgYW4gYW5hbHlzaXMgYW5kIG1vcmUgb2YgY29uc2lkZXJhdGlvbnMgKG9mIHRoZSBjdXJy
ZW50IGZsb3dzIGFuZCBhY3RvcnMpLCBJJ20gbm90IHN1cmUgaG93IHRvIGFkYXB0IHdoYXQgeW91
IGhhdmUgZG9uZSB0byBhY3R1YWxseSBmaXQgaW4gdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbiwg
d2FzIHlvdXIgdGhvdWdodCB0aGF0IHlvdSB3b3VsZCBwcm9kdWNlIGEgc2VwYXJhdGUgc2VjdXJp
dHkgYW5hbHlzaXMgZG9jdW1lbnQ/DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t
OiBvYXV0aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86b2F1dGgtYm91bmNlc0BpZXRmLm9yZ10g
T24gQmVoYWxmIE9mIFRvcnN0ZW4gTG9kZGVyc3RlZHQNClNlbnQ6IFN1bmRheSwgTm92ZW1iZXIg
MDcsIDIwMTAgMzowNCBQTQ0KVG86IEhhbm5lcyBUc2Nob2ZlbmlnDQpDYzogYWJmYWJAaWV0Zi5v
cmc7IHJhaUBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgc2VjZGlyQGlldGYub3JnOyB3ZWJzZWNA
aWV0Zi5vcmc7IHhtcHBAaWV0Zi5vcmc7IGtpdHRlbkBpZXRmLm9yZzsgaWFiQGlhYi5vcmcgQm9h
cmQ7IGllc2dAaWV0Zi5vcmc7IG9hdXRoQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW09BVVRILVdH
XSAqKiBPQXV0aCBUdXRvcmlhbCAmIE9BdXRoIFNlY3VyaXR5IFNlc3Npb24gKioNCg0KSGkgYWxs
LA0KDQpNYXJrIE1jR2xvaW4gYW5kIG1lIGhhdmUgYmVlbiB3b3JraW5nIG9uIE9BdXRoIDIuMCBz
ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgYSBjb3VwbGUgb2Ygd2Vla3Mgbm93LiBTaW5jZSB3
ZSBib3RoIGNhbm5vdCBhdHRlbmQgdGhlIElFVEYtNzkgbWVldGluZ3MsIHdlIHdvdWxkIGxpa2Ug
dG8gcHJvdmlkZSB0aGUgV0cgd2l0aCBpbmZvcm1hdGlvbiByZWdhcmRpbmcgdGhlIGN1cnJlbnQg
c3RhdHVzIG9mIG91ciB3b3JrLiBJIHRoZXJlZm9yZSB1cGxvYWRlZCBhX3ByZWxpbWluYXJ5XyB2
ZXJzaW9uIG9mIG91ciB3b3JraW5nIGRvY3VtZW50IHRvIHRoZSBXRydzIHdpa2kgYXQgaHR0cDov
L3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvb2F1dGgvdHJhYy9hdHRhY2htZW50L3dpa2kvU2VjdXJp
dHlDb25zaWRlcmF0aW9ucy9vYXV0aDIwX3NlY2NvbnNfMjAxMDExMDcucGRmLiANClRoZSBmb2N1
cyBvZiB0aGlzIHZlcnNpb24gd2FzIG9uIGNvbnNvbGlkYXRpbmcgcHJldmlvdXMgd29yayBhcyB3
ZWxsIGFzIHJlc3VsdHMgb2YgbWFpbGluZyBsaXN0IGRpc2N1c3Npb25zIGFuZCBzdGFydCB3b3Jr
aW5nIHRvd2FyZHMgYSByaWdvcm91cyB0aHJlYXQgbW9kZWwuDQoNClBsZWFzZSBnaXZlIHVzIGZl
ZWRiYWNrLg0KDQpyZWdhcmRzLA0KVG9yc3Rlbi4NCg0KQW0gMDcuMTEuMjAxMCAwMzoyMiwgc2No
cmllYiBIYW5uZXMgVHNjaG9mZW5pZzoNCj4gSGkgYWxsLA0KPg0KPiBwbGVhc2UgY29uc2lkZXIg
YXR0ZW5kaW5nIHRoZSBmb2xsb3dpbmcgdHdvIG1lZXRpbmdzIQ0KPg0KPiAqKiBPQXV0aCBTZWN1
cml0eSBTZXNzaW9uICoqDQo+DQo+IAkqIERhdGU6IE1vbmRheSwgMTM6MDAtMTU6MDANCj4gCSog
TG9jYXRpb246IElBQiBicmVha291dCByb29tIChKYWRlIDIpDQo+IAkqIENvbnRhY3Q6IEhhbm5l
cyBUc2Nob2ZlbmlnIGhhbm5lcy50c2Nob2ZlbmlnQGdteC5uZXQgVGhlIHNlY3VyaXR5IA0KPiBj
b25zaWRlcmF0aW9uIHNlY3Rpb24gb2YgT0F1dGggMi4wIChkcmFmdCAtMTApIGlzIHN0aWxsIGVt
cHR5LiBIZW5jZSwgd2Ugd291bGQgbGlrZSB0byBwdXQgc29tZSB0aW1lIGFzaWRlIHRvIGRpc2N1
c3Mgd2hhdCBzZWN1cml0eSB0aHJlYXRzLCByZXF1aXJlbWVudHMsIGFuZCBjb3VudGVybWVhc3Vy
ZXMgbmVlZCB0byBiZSBkZXNjcmliZWQuIFdlIHdpbGwgdXNlIHRoZSBNb25kYXksIE5vdmVtYmVy
IDgsIDEzMDAtMTUwMCBzbG90IHRvIGhhdmUgYSAgZGlzY3Vzc2lvbiBzZXNzaW9uLg0KPg0KPiBB
cyBhIHN0YXJ0aW5nIHBvaW50IEkgc3VnZ2VzdCB0byBsb29rIGF0IHRoZSBmb2xsb3dpbmcgZG9j
dW1lbnRzOg0KPg0KPiAJKiBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9vYXV0aC90cmFj
L3dpa2kvU2VjdXJpdHlDb25zaWRlcmF0aW9ucw0KPiAJKiBodHRwOi8vdHJhYy50b29scy5pZXRm
Lm9yZy93Zy9vYXV0aC90cmFjL3dpa2kvU2lnbmF0dXJlc1doeQ0KPiAJKiANCj4gaHR0cDovL3Rv
b2xzLmlldGYub3JnL2lkL2RyYWZ0LXRzY2hvZmVuaWctb2F1dGgtc2lnbmF0dXJlLXRob3VnaHRz
LTAwLg0KPiB0eHQNCj4NCj4gTm90ZTogSWYgeW91IGFyZSB1bmZhbWlsaWFyIHdpdGggT0F1dGgg
dGhlbiB0aGUgT0F1dGggdHV0b3JpYWwgc2Vzc2lvbiBtaWdodCBiZSBtb3JlIHN1aXRhYmxlIGZv
ciB5b3UhDQo+DQo+DQo+DQo+ICoqIE9BdXRoIFR1dG9yaWFsICoqDQo+DQo+IAkqIERhdGU6IFdl
ZG5lc2RheSwgMTk6MzAgKGFmdGVyIHRoZSBwbGVuYXJ5KQ0KPiAJKiBMb2NhdGlvbjogSUFCIGJy
ZWFrb3V0IHJvb20gKEphZGUgMikNCj4gCSogQ29udGFjdDogSGFubmVzIFRzY2hvZmVuaWcgaGFu
bmVzLnRzY2hvZmVuaWdAZ214Lm5ldCBPQXV0aCBhbGxvd3MgYSANCj4gdXNlciB0byBncmFudCBh
IHRoaXJkLXBhcnR5IFdlYiBzaXRlIG9yIGFwcGxpY2F0aW9uIGFjY2VzcyB0byB0aGVpciANCj4g
cmVzb3VyY2VzLCB3aXRob3V0IG5lY2Vzc2FyaWx5IHJldmVhbGluZyB0aGVpciBjcmVkZW50aWFs
cywgb3IgZXZlbiANCj4gdGhlaXIgaWRlbnRpdHkuIFRoZSBPQXV0aCB3b3JraW5nIGdyb3VwLCBz
ZWUgDQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy93Zy9vYXV0aC9jaGFydGVyLywgaXMg
Y3VycmVudGx5IHRyeWluZyB0byANCj4gZmluYWxpemUgdGhlaXIgbWFpbiBzcGVjaWZpY2F0aW9u
LCBuYW1lbHkgT0F1dGggdjI6IA0KPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWlldGYtb2F1dGgtdjIvDQo+DQo+IEJhc2VkIG9uIHRoZSBwb3NpdGl2ZSByZXNwb25zZSBh
dCB0aGUgbGFzdCBJRVRGIG1lZXRpbmcgKGluIA0KPiBNYWFzdHJpY2h0KSB3ZSBkZWNpZGVkIHRv
IGhvbGQgYW5vdGhlciBPQXV0aCB0dXRvcmlhbCwgbmFtZWx5IG9uIA0KPiAqV2VkbmVzZGF5LCBz
dGFydGluZyBhdCAxOTozMCAoYWZ0ZXIgdGhlIElFVEYgT3BlcmF0aW9ucyBhbmQgDQo+IEFkbWlu
aXN0cmF0aW9uIFBsZW5hcnkpIHRpbGwgYWJvdXQgMjE6MDAuIChOb3RlOiBJIGhhZCB0byBzd2l0
Y2ggdGhlIA0KPiBkYXkgYmVjYXVzZSBvZiB0aGUgc29jaWFsIGV2ZW50ISkNCj4NCj4gSXQgaXMg
aGVscGZ1bCB0byByZWFkIHRocm91Z2ggdGhlIGRvY3VtZW50cyBhdmFpbGFibGUgaW50IGhlIHdv
cmtpbmcgZ3JvdXAgYnV0IG5vdCByZXF1aXJlZC4NCj4NCj4gVXAtdG8tZGF0ZSBpbmZvcm1hdGlv
biBjYW4gYmUgZm91bmQgaGVyZTogDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmVnaXN0cmF0aW9u
L01lZXRpbmdXaWtpL3dpa2kvNzlib2ZzDQo+DQo+IENpYW8NCj4gSGFubmVzDQo+DQo+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gT0F1dGggbWFpbGlu
ZyBsaXN0DQo+IE9BdXRoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vb2F1dGgNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCk9BdXRoIG1haWxpbmcgbGlzdA0KT0F1dGhAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vb2F1dGgNCg0K


From rbarnes@bbn.com  Tue Nov  9 00:53:26 2010
Return-Path: <rbarnes@bbn.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 35BCA28C170; Tue,  9 Nov 2010 00:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.617
X-Spam-Level: 
X-Spam-Status: No, score=-102.617 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 u1-hw6kBQHuj; Tue,  9 Nov 2010 00:53:25 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id DDB223A69D8; Tue,  9 Nov 2010 00:53:24 -0800 (PST)
Received: from [128.89.253.252] (port=54397 helo=richards-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1PFjxa-000OfY-Ep; Tue, 09 Nov 2010 03:53:47 -0500
Message-ID: <4CD90C14.2060803@bbn.com>
Date: Tue, 09 Nov 2010 16:53:40 +0800
From: "Richard L. Barnes" <rbarnes@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: torsten@lodderstedt.net
References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry>
In-Reply-To: <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Anthony Nadalin <tonynad@microsoft.com>, "abfab@ietf.org" <abfab@ietf.org>, "rai@ietf.org" <rai@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "websec@ietf.org" <websec@ietf.org>, "xmpp@ietf.org" <xmpp@ietf.org>, "kitten@ietf.org" <kitten@ietf.org>, "iab@iab.org Board" <iab@iab.org>, "iesg@ietf.org" <iesg@ietf.org>, "Tschofenig, Hannes" <Hannes.Tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
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: Tue, 09 Nov 2010 08:53:26 -0000

I would say that the security considerations should be based on a model 
of OAuth.  Start with a model of the protocol and the guarantees you 
want, then explain how to use security mechanisms to achieve those 
guarantees.

I promised Hannes today to do a review of the current document (which I 
admit I haven't read) and start on some security considerations from 
that perspective.  So expect that in the next few weeks.

--Richard




On 11/9/10 4:07 PM, torsten@lodderstedt.net wrote:
> We think the security considerations should be based on a threat model of OAuth. But a complete threat model would blow up the spec.
>
> We therefore aim to produce a separate security document (informational I-D/RFC) covering threat model as well as security design and considerations. The security considerations section of the core spec can then be distilled from this document.
>
> Regards,
> Torsten.
> Gesendet mit BlackBerry® Webmail von Telekom Deutschland
>
> -----Original Message-----
> From: Anthony Nadalin<tonynad@microsoft.com>
> Date: Tue, 9 Nov 2010 01:54:57
> To: Torsten Lodderstedt<torsten@lodderstedt.net>; Hannes Tschofenig<hannes.tschofenig@gmx.net>
> Cc: abfab@ietf.org<abfab@ietf.org>; rai@ietf.org<rai@ietf.org>; ietf@ietf.org<ietf@ietf.org>; secdir@ietf.org<secdir@ietf.org>; websec@ietf.org<websec@ietf.org>; xmpp@ietf.org<xmpp@ietf.org>; kitten@ietf.org<kitten@ietf.org>; iab@iab.org Board<iab@iab.org>; iesg@ietf.org<iesg@ietf.org>; oauth@ietf.org<oauth@ietf.org>
> Subject: RE: [OAUTH-WG] ** OAuth Tutorial&  OAuth Security Session **
>
> I was looking for less of an analysis and more of considerations (of the current flows and actors), I'm not sure how to adapt what you have done to actually fit in the current specification, was your thought that you would produce a separate security analysis document?
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Torsten Lodderstedt
> Sent: Sunday, November 07, 2010 3:04 PM
> To: Hannes Tschofenig
> Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org; websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; iesg@ietf.org; oauth@ietf.org
> Subject: Re: [OAUTH-WG] ** OAuth Tutorial&  OAuth Security Session **
>
> Hi all,
>
> Mark McGloin and me have been working on OAuth 2.0 security considerations for a couple of weeks now. Since we both cannot attend the IETF-79 meetings, we would like to provide the WG with information regarding the current status of our work. I therefore uploaded a_preliminary_ version of our working document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf.
> The focus of this version was on consolidating previous work as well as results of mailing list discussions and start working towards a rigorous threat model.
>
> Please give us feedback.
>
> regards,
> Torsten.
>
> Am 07.11.2010 03:22, schrieb Hannes Tschofenig:
>> Hi all,
>>
>> please consider attending the following two meetings!
>>
>> ** OAuth Security Session **
>>
>> 	* Date: Monday, 13:00-15:00
>> 	* Location: IAB breakout room (Jade 2)
>> 	* Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The security
>> consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we would like to put some time aside to discuss what security threats, requirements, and countermeasures need to be described. We will use the Monday, November 8, 1300-1500 slot to have a  discussion session.
>>
>> As a starting point I suggest to look at the following documents:
>>
>> 	* http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
>> 	* http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
>> 	*
>> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.
>> txt
>>
>> Note: If you are unfamiliar with OAuth then the OAuth tutorial session might be more suitable for you!
>>
>>
>>
>> ** OAuth Tutorial **
>>
>> 	* Date: Wednesday, 19:30 (after the plenary)
>> 	* Location: IAB breakout room (Jade 2)
>> 	* Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth allows a
>> user to grant a third-party Web site or application access to their
>> resources, without necessarily revealing their credentials, or even
>> their identity. The OAuth working group, see
>> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to
>> finalize their main specification, namely OAuth v2:
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/
>>
>> Based on the positive response at the last IETF meeting (in
>> Maastricht) we decided to hold another OAuth tutorial, namely on
>> *Wednesday, starting at 19:30 (after the IETF Operations and
>> Administration Plenary) till about 21:00. (Note: I had to switch the
>> day because of the social event!)
>>
>> It is helpful to read through the documents available int he working group but not required.
>>
>> Up-to-date information can be found here:
>> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir

From mark.mcgloin@ie.ibm.com  Tue Nov  9 06:54:30 2010
Return-Path: <mark.mcgloin@ie.ibm.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 CCC2C3A6A04; Tue,  9 Nov 2010 06:54:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 kxy8MrZ8zQvp; Tue,  9 Nov 2010 06:54:29 -0800 (PST)
Received: from mtagate3.de.ibm.com (mtagate3.de.ibm.com [195.212.17.163]) by core3.amsl.com (Postfix) with ESMTP id 949B13A69BE; Tue,  9 Nov 2010 06:54:28 -0800 (PST)
Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.de.ibm.com (8.13.1/8.13.1) with ESMTP id oA9Esflx004036; Tue, 9 Nov 2010 14:54:41 GMT
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1307.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id oA9EsfKQ3305506; Tue, 9 Nov 2010 14:54:41 GMT
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id oA9EsfPh002056; Tue, 9 Nov 2010 07:54:41 -0700
Received: from d06ml093.portsmouth.uk.ibm.com (d06ml093.portsmouth.uk.ibm.com [9.149.104.171]) by d06av04.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id oA9Esf4U002048; Tue, 9 Nov 2010 07:54:41 -0700
In-Reply-To: <4CD90C14.2060803@bbn.com>
References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> <4CD90C14.2060803@bbn.com>
X-KeepSent: 7957FE3B:45025425-802577D6:004F9E8F; type=4; name=$KeepSent
To: "Richard L. Barnes" <rbarnes@bbn.com>
X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009
Message-ID: <OF7957FE3B.45025425-ON802577D6.004F9E8F-802577D6.0051E8D0@ie.ibm.com>
From: Mark Mcgloin <mark.mcgloin@ie.ibm.com>
Date: Tue, 9 Nov 2010 14:54:06 +0000
X-MIMETrack: Serialize by Router on D06ML093/06/M/IBM(Release 8.0.2FP6|July 15, 2010) at 09/11/2010 14:54:07
MIME-Version: 1.0
Content-type: text/plain; charset=ISO-8859-1
Content-transfer-encoding: quoted-printable
X-Mailman-Approved-At: Tue, 09 Nov 2010 22:04:43 -0800
Cc: "abfab@ietf.org" <abfab@ietf.org>, torsten@lodderstedt.net, "rai@ietf.org" <rai@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "websec@ietf.org" <websec@ietf.org>, "xmpp@ietf.org" <xmpp@ietf.org>, "kitten@ietf.org" <kitten@ietf.org>, "iab@iab.org Board" <iab@iab.org>, "iesg@ietf.org" <iesg@ietf.org>, "Tschofenig, Hannes" <Hannes.Tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>, oauth-bounces@ietf.org
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
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: Tue, 09 Nov 2010 14:54:31 -0000

When Torsten and I started pulling together the security considerations=

over the last 4-6 weeks, we toyed with the idea of either populating th=
e
security considerations section of the protocol with a list/tree of
considerations, or creating a more comprehensive document to ensure we
covered all aspects, list security features and which would also act as=
 a
security aid to developers implementing the oauth protocol. We decided =
on
the latter and agreed it could later be distilled down to something tha=
t
will fit into the security considerations section of the protocol.

Bear in mind the document needs tidying but we wanted to push something=
 in
before the security meeting in China

Regards
Mark McGloin

oauth-bounces@ietf.org wrote on 09/11/2010 08:53:40:

> "Richard L. Barnes" <rbarnes@bbn.com>
> Sent by: oauth-bounces@ietf.org
>
> 09/11/2010 08:53
>
> To
>
> torsten@lodderstedt.net
>
> cc
>
> "abfab@ietf.org" <abfab@ietf.org>, "rai@ietf.org" <rai@ietf.org>,
> "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org"
> <secdir@ietf.org>, "websec@ietf.org" <websec@ietf.org>,
> "xmpp@ietf.org" <xmpp@ietf.org>, "kitten@ietf.org"
> <kitten@ietf.org>, "iab@iab.org Board" <iab@iab.org>,
> "iesg@ietf.org" <iesg@ietf.org>, "Tschofenig, Hannes"
> <Hannes.Tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
>
> Subject
>
> Re: [OAUTH-WG] [secdir] ** OAuth Tutorial & OAuth Security Session **=

>
> I would say that the security considerations should be based on a mod=
el
> of OAuth.  Start with a model of the protocol and the guarantees you
> want, then explain how to use security mechanisms to achieve those
> guarantees.
>
> I promised Hannes today to do a review of the current document (which=
 I
> admit I haven't read) and start on some security considerations from
> that perspective.  So expect that in the next few weeks.
>
> --Richard
>
>
>
>
> On 11/9/10 4:07 PM, torsten@lodderstedt.net wrote:
> > We think the security considerations should be based on a threat
> model of OAuth. But a complete threat model would blow up the spec.
> >
> > We therefore aim to produce a separate security document
> (informational I-D/RFC) covering threat model as well as security
> design and considerations. The security considerations section of
> the core spec can then be distilled from this document.
> >
> > Regards,
> > Torsten.
> > Gesendet mit BlackBerry=AE Webmail von Telekom Deutschland
> >
> > -----Original Message-----
> > From: Anthony Nadalin<tonynad@microsoft.com>
> > Date: Tue, 9 Nov 2010 01:54:57
> > To: Torsten Lodderstedt<torsten@lodderstedt.net>; Hannes
> Tschofenig<hannes.tschofenig@gmx.net>
> > Cc: abfab@ietf.org<abfab@ietf.org>; rai@ietf.org<rai@ietf.org>;
> ietf@ietf.org<ietf@ietf.org>; secdir@ietf.org<secdir@ietf.org>;
> websec@ietf.org<websec@ietf.org>; xmpp@ietf.org<xmpp@ietf.org>;
> kitten@ietf.org<kitten@ietf.org>; iab@iab.org Board<iab@iab.org>;
> iesg@ietf.org<iesg@ietf.org>; oauth@ietf.org<oauth@ietf.org>
> > Subject: RE: [OAUTH-WG] ** OAuth Tutorial&  OAuth Security Session =
**
> >
> > I was looking for less of an analysis and more of considerations
> (of the current flows and actors), I'm not sure how to adapt what
> you have done to actually fit in the current specification, was your
> thought that you would produce a separate security analysis document?=

> >
> > -----Original Message-----
> > From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On
> Behalf Of Torsten Lodderstedt
> > Sent: Sunday, November 07, 2010 3:04 PM
> > To: Hannes Tschofenig
> > Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org;
> websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board;
> iesg@ietf.org; oauth@ietf.org
> > Subject: Re: [OAUTH-WG] ** OAuth Tutorial&  OAuth Security Session =
**
> >
> > Hi all,
> >
> > Mark McGloin and me have been working on OAuth 2.0 security
> considerations for a couple of weeks now. Since we both cannot
> attend the IETF-79 meetings, we would like to provide the WG with
> information regarding the current status of our work. I therefore
> uploaded a_preliminary_ version of our working document to the WG's w=
iki
at
> http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/
> SecurityConsiderations/oauth20_seccons_20101107.pdf.
> > The focus of this version was on consolidating previous work as
> well as results of mailing list discussions and start working
> towards a rigorous threat model.
> >
> > Please give us feedback.
> >
> > regards,
> > Torsten.
> >
> > Am 07.11.2010 03:22, schrieb Hannes Tschofenig:
> >> Hi all,
> >>
> >> please consider attending the following two meetings!
> >>
> >> ** OAuth Security Session **
> >>
> >>    * Date: Monday, 13:00-15:00
> >>    * Location: IAB breakout room (Jade 2)
> >>    * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The secu=
rity
> >> consideration section of OAuth 2.0 (draft -10) is still empty.
> Hence, we would like to put some time aside to discuss what security
> threats, requirements, and countermeasures need to be described. We
> will use the Monday, November 8, 1300-1500 slot to have a  discussion=

session.
> >>
> >> As a starting point I suggest to look at the following documents:
> >>
> >>    *
http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
> >>    * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
> >>    *
> >> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts=
-00.
> >> txt
> >>
> >> Note: If you are unfamiliar with OAuth then the OAuth tutorial
> session might be more suitable for you!
> >>
> >>
> >>
> >> ** OAuth Tutorial **
> >>
> >>    * Date: Wednesday, 19:30 (after the plenary)
> >>    * Location: IAB breakout room (Jade 2)
> >>    * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth al=
lows
a
> >> user to grant a third-party Web site or application access to thei=
r
> >> resources, without necessarily revealing their credentials, or eve=
n
> >> their identity. The OAuth working group, see
> >> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying=
 to
> >> finalize their main specification, namely OAuth v2:
> >> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/
> >>
> >> Based on the positive response at the last IETF meeting (in
> >> Maastricht) we decided to hold another OAuth tutorial, namely on
> >> *Wednesday, starting at 19:30 (after the IETF Operations and
> >> Administration Plenary) till about 21:00. (Note: I had to switch t=
he
> >> day because of the social event!)
> >>
> >> It is helpful to read through the documents available int he
> working group but not required.
> >>
> >> Up-to-date information can be found here:
> >> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs
> >>
> >> Ciao
> >> Hannes
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> OAuth@ietf.org
> >> https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > OAuth mailing list
> > OAuth@ietf.org
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> > _______________________________________________
> > secdir mailing list
> > secdir@ietf.org
> > https://www.ietf.org/mailman/listinfo/secdir
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth=



From tonynad@microsoft.com  Tue Nov  9 22:03:34 2010
Return-Path: <tonynad@microsoft.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 3F13E3A68C8; Tue,  9 Nov 2010 22:03:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 Ed2jPVsD-p8p; Tue,  9 Nov 2010 22:03:34 -0800 (PST)
Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id 0EDF53A68C6; Tue,  9 Nov 2010 22:03:34 -0800 (PST)
Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 9 Nov 2010 22:03:48 -0800
Received: from TK5EX14MBXC117.redmond.corp.microsoft.com ([169.254.8.138]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0255.003; Tue, 9 Nov 2010 22:03:48 -0800
From: Anthony Nadalin <tonynad@microsoft.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>, "torsten@lodderstedt.net" <torsten@lodderstedt.net>
Thread-Topic: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
Thread-Index: AQHLf+vNz+Zyzs3OwkSCnvjMrh08w5NqOX4w
Date: Wed, 10 Nov 2010 06:03:47 +0000
Message-ID: <180155C5EA10854997314CA5E063D18FEE90B8@TK5EX14MBXC117.redmond.corp.microsoft.com>
References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> <4CD90C14.2060803@bbn.com>
In-Reply-To: <4CD90C14.2060803@bbn.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.123.12]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Tue, 09 Nov 2010 22:04:46 -0800
Cc: "abfab@ietf.org" <abfab@ietf.org>, "rai@ietf.org" <rai@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "websec@ietf.org" <websec@ietf.org>, "xmpp@ietf.org" <xmpp@ietf.org>, "kitten@ietf.org" <kitten@ietf.org>, "iab@iab.org Board" <iab@iab.org>, "iesg@ietf.org" <iesg@ietf.org>, "Tschofenig, Hannes" <Hannes.Tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
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: Wed, 10 Nov 2010 06:03:34 -0000

Issue here is that guarantees (and what you want as a guarantee may not be =
what somebody else wants) can vary depending on scenario and deployment.

-----Original Message-----
From: Richard L. Barnes [mailto:rbarnes@bbn.com]=20
Sent: Tuesday, November 09, 2010 12:54 AM
To: torsten@lodderstedt.net
Cc: Anthony Nadalin; Tschofenig, Hannes; abfab@ietf.org; rai@ietf.org; ietf=
@ietf.org; secdir@ietf.org; websec@ietf.org; xmpp@ietf.org; kitten@ietf.org=
; iab@iab.org Board; iesg@ietf.org; oauth@ietf.org
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session=
 **

I would say that the security considerations should be based on a model of =
OAuth.  Start with a model of the protocol and the guarantees you want, the=
n explain how to use security mechanisms to achieve those guarantees.

I promised Hannes today to do a review of the current document (which I adm=
it I haven't read) and start on some security considerations from that pers=
pective.  So expect that in the next few weeks.

--Richard




On 11/9/10 4:07 PM, torsten@lodderstedt.net wrote:
> We think the security considerations should be based on a threat model of=
 OAuth. But a complete threat model would blow up the spec.
>
> We therefore aim to produce a separate security document (informational I=
-D/RFC) covering threat model as well as security design and considerations=
. The security considerations section of the core spec can then be distille=
d from this document.
>
> Regards,
> Torsten.
> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland
>
> -----Original Message-----
> From: Anthony Nadalin<tonynad@microsoft.com>
> Date: Tue, 9 Nov 2010 01:54:57
> To: Torsten Lodderstedt<torsten@lodderstedt.net>; Hannes=20
> Tschofenig<hannes.tschofenig@gmx.net>
> Cc: abfab@ietf.org<abfab@ietf.org>; rai@ietf.org<rai@ietf.org>;=20
> ietf@ietf.org<ietf@ietf.org>; secdir@ietf.org<secdir@ietf.org>;=20
> websec@ietf.org<websec@ietf.org>; xmpp@ietf.org<xmpp@ietf.org>;=20
> kitten@ietf.org<kitten@ietf.org>; iab@iab.org Board<iab@iab.org>;=20
> iesg@ietf.org<iesg@ietf.org>; oauth@ietf.org<oauth@ietf.org>
> Subject: RE: [OAUTH-WG] ** OAuth Tutorial&  OAuth Security Session **
>
> I was looking for less of an analysis and more of considerations (of the =
current flows and actors), I'm not sure how to adapt what you have done to =
actually fit in the current specification, was your thought that you would =
produce a separate security analysis document?
>
> -----Original Message-----
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf=20
> Of Torsten Lodderstedt
> Sent: Sunday, November 07, 2010 3:04 PM
> To: Hannes Tschofenig
> Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org;=20
> websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board;=20
> iesg@ietf.org; oauth@ietf.org
> Subject: Re: [OAUTH-WG] ** OAuth Tutorial&  OAuth Security Session **
>
> Hi all,
>
> Mark McGloin and me have been working on OAuth 2.0 security consideration=
s for a couple of weeks now. Since we both cannot attend the IETF-79 meetin=
gs, we would like to provide the WG with information regarding the current =
status of our work. I therefore uploaded a_preliminary_ version of our work=
ing document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/a=
ttachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf.
> The focus of this version was on consolidating previous work as well as r=
esults of mailing list discussions and start working towards a rigorous thr=
eat model.
>
> Please give us feedback.
>
> regards,
> Torsten.
>
> Am 07.11.2010 03:22, schrieb Hannes Tschofenig:
>> Hi all,
>>
>> please consider attending the following two meetings!
>>
>> ** OAuth Security Session **
>>
>> 	* Date: Monday, 13:00-15:00
>> 	* Location: IAB breakout room (Jade 2)
>> 	* Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The security=20
>> consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we=
 would like to put some time aside to discuss what security threats, requir=
ements, and countermeasures need to be described. We will use the Monday, N=
ovember 8, 1300-1500 slot to have a  discussion session.
>>
>> As a starting point I suggest to look at the following documents:
>>
>> 	* http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
>> 	* http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
>> 	*
>> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.
>> txt
>>
>> Note: If you are unfamiliar with OAuth then the OAuth tutorial session m=
ight be more suitable for you!
>>
>>
>>
>> ** OAuth Tutorial **
>>
>> 	* Date: Wednesday, 19:30 (after the plenary)
>> 	* Location: IAB breakout room (Jade 2)
>> 	* Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth allows=20
>> a user to grant a third-party Web site or application access to their=20
>> resources, without necessarily revealing their credentials, or even=20
>> their identity. The OAuth working group, see=20
>> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to=20
>> finalize their main specification, namely OAuth v2:
>> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/
>>
>> Based on the positive response at the last IETF meeting (in
>> Maastricht) we decided to hold another OAuth tutorial, namely on=20
>> *Wednesday, starting at 19:30 (after the IETF Operations and=20
>> Administration Plenary) till about 21:00. (Note: I had to switch the=20
>> day because of the social event!)
>>
>> It is helpful to read through the documents available int he working gro=
up but not required.
>>
>> Up-to-date information can be found here:
>> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs
>>
>> Ciao
>> Hannes
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir


From rbarnes@bbn.com  Tue Nov  9 22:19:37 2010
Return-Path: <rbarnes@bbn.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 2CE0C3A68D6; Tue,  9 Nov 2010 22:19:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.609
X-Spam-Level: 
X-Spam-Status: No, score=-102.609 tagged_above=-999 required=5 tests=[AWL=-0.010, 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 IZYj+e0Guafa; Tue,  9 Nov 2010 22:19:30 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 3EB973A6895; Tue,  9 Nov 2010 22:19:30 -0800 (PST)
Received: from [128.89.254.59] (port=53402 helo=richards-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1PG42E-000Emt-1U; Wed, 10 Nov 2010 01:19:54 -0500
Message-ID: <4CDA3983.7050101@bbn.com>
Date: Wed, 10 Nov 2010 14:19:47 +0800
From: "Richard L. Barnes" <rbarnes@bbn.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Anthony Nadalin <tonynad@microsoft.com>
References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry> <4CD90C14.2060803@bbn.com> <180155C5EA10854997314CA5E063D18FEE90B8@TK5EX14MBXC117.redmond.corp.microsoft.com>
In-Reply-To: <180155C5EA10854997314CA5E063D18FEE90B8@TK5EX14MBXC117.redmond.corp.microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "abfab@ietf.org" <abfab@ietf.org>, "Tschofenig, Hannes" <Hannes.Tschofenig@gmx.net>, "rai@ietf.org" <rai@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "websec@ietf.org" <websec@ietf.org>, "xmpp@ietf.org" <xmpp@ietf.org>, "kitten@ietf.org" <kitten@ietf.org>, "iab@iab.org Board" <iab@iab.org>, "iesg@ietf.org" <iesg@ietf.org>, "torsten@lodderstedt.net" <torsten@lodderstedt.net>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
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: Wed, 10 Nov 2010 06:19:37 -0000

Of course not every scenario calls for all of the security knobs to be 
turned to 11.  Think of things instead in terms of syllogisms: "IF you 
want X guarantee, THEN you MUST do A, B, C."

Then you can also read the same things backwards in a given deployment 
scenario: "Given that I can't do B, I can't get assurances X, Y, but I 
can get Z (if I do D, F as well)".

I promise to produce something more concrete soon :)  In the meantime, 
this text illustrates what I mean pretty well:
<http://tools.ietf.org/html/draft-barnes-oauth-model-01#section-5>

--Richard


On 11/10/10 2:03 PM, Anthony Nadalin wrote:
> Issue here is that guarantees (and what you want as a guarantee may not be what somebody else wants) can vary depending on scenario and deployment.
>
> -----Original Message-----
> From: Richard L. Barnes [mailto:rbarnes@bbn.com]
> Sent: Tuesday, November 09, 2010 12:54 AM
> To: torsten@lodderstedt.net
> Cc: Anthony Nadalin; Tschofenig, Hannes; abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org; websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; iesg@ietf.org; oauth@ietf.org
> Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial&  OAuth Security Session **
>
> I would say that the security considerations should be based on a model of OAuth.  Start with a model of the protocol and the guarantees you want, then explain how to use security mechanisms to achieve those guarantees.
>
> I promised Hannes today to do a review of the current document (which I admit I haven't read) and start on some security considerations from that perspective.  So expect that in the next few weeks.
>
> --Richard
>
>
>
>
> On 11/9/10 4:07 PM, torsten@lodderstedt.net wrote:
>> We think the security considerations should be based on a threat model of OAuth. But a complete threat model would blow up the spec.
>>
>> We therefore aim to produce a separate security document (informational I-D/RFC) covering threat model as well as security design and considerations. The security considerations section of the core spec can then be distilled from this document.
>>
>> Regards,
>> Torsten.
>> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland
>>
>> -----Original Message-----
>> From: Anthony Nadalin<tonynad@microsoft.com>
>> Date: Tue, 9 Nov 2010 01:54:57
>> To: Torsten Lodderstedt<torsten@lodderstedt.net>; Hannes
>> Tschofenig<hannes.tschofenig@gmx.net>
>> Cc: abfab@ietf.org<abfab@ietf.org>; rai@ietf.org<rai@ietf.org>;
>> ietf@ietf.org<ietf@ietf.org>; secdir@ietf.org<secdir@ietf.org>;
>> websec@ietf.org<websec@ietf.org>; xmpp@ietf.org<xmpp@ietf.org>;
>> kitten@ietf.org<kitten@ietf.org>; iab@iab.org Board<iab@iab.org>;
>> iesg@ietf.org<iesg@ietf.org>; oauth@ietf.org<oauth@ietf.org>
>> Subject: RE: [OAUTH-WG] ** OAuth Tutorial&   OAuth Security Session **
>>
>> I was looking for less of an analysis and more of considerations (of the current flows and actors), I'm not sure how to adapt what you have done to actually fit in the current specification, was your thought that you would produce a separate security analysis document?
>>
>> -----Original Message-----
>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>> Of Torsten Lodderstedt
>> Sent: Sunday, November 07, 2010 3:04 PM
>> To: Hannes Tschofenig
>> Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org;
>> websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board;
>> iesg@ietf.org; oauth@ietf.org
>> Subject: Re: [OAUTH-WG] ** OAuth Tutorial&   OAuth Security Session **
>>
>> Hi all,
>>
>> Mark McGloin and me have been working on OAuth 2.0 security considerations for a couple of weeks now. Since we both cannot attend the IETF-79 meetings, we would like to provide the WG with information regarding the current status of our work. I therefore uploaded a_preliminary_ version of our working document to the WG's wiki at http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf.
>> The focus of this version was on consolidating previous work as well as results of mailing list discussions and start working towards a rigorous threat model.
>>
>> Please give us feedback.
>>
>> regards,
>> Torsten.
>>
>> Am 07.11.2010 03:22, schrieb Hannes Tschofenig:
>>> Hi all,
>>>
>>> please consider attending the following two meetings!
>>>
>>> ** OAuth Security Session **
>>>
>>> 	* Date: Monday, 13:00-15:00
>>> 	* Location: IAB breakout room (Jade 2)
>>> 	* Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The security
>>> consideration section of OAuth 2.0 (draft -10) is still empty. Hence, we would like to put some time aside to discuss what security threats, requirements, and countermeasures need to be described. We will use the Monday, November 8, 1300-1500 slot to have a  discussion session.
>>>
>>> As a starting point I suggest to look at the following documents:
>>>
>>> 	* http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
>>> 	* http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
>>> 	*
>>> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.
>>> txt
>>>
>>> Note: If you are unfamiliar with OAuth then the OAuth tutorial session might be more suitable for you!
>>>
>>>
>>>
>>> ** OAuth Tutorial **
>>>
>>> 	* Date: Wednesday, 19:30 (after the plenary)
>>> 	* Location: IAB breakout room (Jade 2)
>>> 	* Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth allows
>>> a user to grant a third-party Web site or application access to their
>>> resources, without necessarily revealing their credentials, or even
>>> their identity. The OAuth working group, see
>>> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to
>>> finalize their main specification, namely OAuth v2:
>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/
>>>
>>> Based on the positive response at the last IETF meeting (in
>>> Maastricht) we decided to hold another OAuth tutorial, namely on
>>> *Wednesday, starting at 19:30 (after the IETF Operations and
>>> Administration Plenary) till about 21:00. (Note: I had to switch the
>>> day because of the social event!)
>>>
>>> It is helpful to read through the documents available int he working group but not required.
>>>
>>> Up-to-date information can be found here:
>>> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs
>>>
>>> Ciao
>>> Hannes
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>

From Nicolas.Williams@oracle.com  Tue Nov  9 23:02:37 2010
Return-Path: <Nicolas.Williams@oracle.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 BF19B3A6A17; Tue,  9 Nov 2010 23:02:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.476
X-Spam-Level: 
X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.122,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 RQmB7Qzdzfxn; Tue,  9 Nov 2010 23:02:25 -0800 (PST)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 116863A68B5; Tue,  9 Nov 2010 23:02:00 -0800 (PST)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oAA72ATX008484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 10 Nov 2010 07:02:11 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oA9HhiJO024108; Wed, 10 Nov 2010 07:02:09 GMT
Received: from abhmt001.oracle.com by acsmt354.oracle.com with ESMTP id 765322921289372442; Tue, 09 Nov 2010 23:00:42 -0800
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 09 Nov 2010 23:00:42 -0800
Date: Wed, 10 Nov 2010 01:00:37 -0600
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: torsten@lodderstedt.net
Message-ID: <20101110070037.GT6536@oracle.com>
References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net> <4CD73075.8050408@lodderstedt.net> <180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com> <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry>
User-Agent: Mutt/1.5.20 (2010-03-02)
Cc: Anthony Nadalin <tonynad@microsoft.com>, "abfab@ietf.org" <abfab@ietf.org>, "rai@ietf.org" <rai@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "websec@ietf.org" <websec@ietf.org>, "xmpp@ietf.org" <xmpp@ietf.org>, "kitten@ietf.org" <kitten@ietf.org>, "iab@iab.org Board" <iab@iab.org>, "iesg@ietf.org" <iesg@ietf.org>, "Tschofenig, Hannes" <Hannes.Tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [secdir] [kitten] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: oauth@ietf.org
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: Wed, 10 Nov 2010 07:02:37 -0000

[That is some cc list!  Do you really need a cc list that large for this
thread?  I've set the reply-to to just oauth@ietf.org (note: I'm NOT
subscribed to that list).  Please honor the reply-to header.  It's a
good idea to set reply-to when making announcements, so that replies
don't flood people who are almost certainly not interested.]

On Tue, Nov 09, 2010 at 08:07:56AM +0000, torsten@lodderstedt.net wrote:
> We think the security considerations should be based on a threat model
> of OAuth. But a complete threat model would blow up the spec.

Really?  I would think that a threat model for OAuth could be described
fairly briefly.  What is the typical value of resources protected by
OAuth?  What kinds of attackers (active, passive, ...) does OAuth aim to
defeat, and under what assumptions (end-points are secure, trusted third
parties are trustworthy, certain cryptographic algorithms are not broken
with parameters in certain ranges, smartcards are secure, ...)?  Which
kinds of attacks does OAuth explicitly not protect against (e.g., DoS)?
What resources do you expect attackers to apply to compromising
resources protected by OAuth?

A few pages should do for the threat model.  An abstract of the OAuth
threat model should also be possible to write.

> We therefore aim to produce a separate security document
> (informational I-D/RFC) covering threat model as well as security
> design and considerations. The security considerations section of the
> core spec can then be distilled from this document.

Sure.  Procedurally speaking, that works.

Nico
-- 

From igor.faynberg@alcatel-lucent.com  Tue Nov  9 22:57:56 2010
Return-Path: <igor.faynberg@alcatel-lucent.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 925393A69A3; Tue,  9 Nov 2010 22:57:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 WHx5MIc21mga; Tue,  9 Nov 2010 22:57:54 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 1E1113A69A9; Tue,  9 Nov 2010 22:57:54 -0800 (PST)
Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id oAA6aZcM011476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 10 Nov 2010 00:36:35 -0600 (CST)
Received: from [135.244.80.3] (faynberg.lra.lucent.com [135.244.80.3]) by umail.lucent.com (8.13.8/TPES) with ESMTP id oAA6aUoF026012; Wed, 10 Nov 2010 00:36:31 -0600 (CST)
Message-ID: <4CDA3D73.10609@alcatel-lucent.com>
Date: Wed, 10 Nov 2010 01:36:35 -0500
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "Richard L. Barnes" <rbarnes@bbn.com>
References: <30C8090C-AD0E-4D2A-8F26-6EFC52DCDD9D@gmx.net><4CD73075.8050408@lodderstedt.net><180155C5EA10854997314CA5E063D18FECBAC9@TK5EX14MBXC113.redmond.corp.microsoft.com>	<1893623701-1289290076-cardhu_decombobulator_blackberry.rim.net-776340369-@bda356.bisx.produk.on.blackberry>	<4CD90C14.2060803@bbn.com>	<180155C5EA10854997314CA5E063D18FEE90B8@TK5EX14MBXC117.redmond.corp.microsoft.com> <4CDA3983.7050101@bbn.com>
In-Reply-To: <4CDA3983.7050101@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Mailman-Approved-At: Tue, 09 Nov 2010 23:20:23 -0800
Cc: Anthony Nadalin <tonynad@microsoft.com>, "abfab@ietf.org" <abfab@ietf.org>, "rai@ietf.org" <rai@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "websec@ietf.org" <websec@ietf.org>, "xmpp@ietf.org" <xmpp@ietf.org>, "kitten@ietf.org" <kitten@ietf.org>, "iab@iab.org Board" <iab@iab.org>, "iesg@ietf.org" <iesg@ietf.org>, "Tschofenig, Hannes" <Hannes.Tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial & OAuth Security Session **
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
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: Wed, 10 Nov 2010 06:57:56 -0000

(With apologies for bringing up a tangential matter...)

Talking about the OAuth model, I still see here "Client" instead of 
"Consumer."  I thought there was an agreement on the terminology 
change.  I have no specific preference for either term, but  I think it 
is essential that our terminology be consistent, especially now that 
other SDOs are considering adopting OAuth.

This is not necessarily a question for Richard, but could someone set me 
straight: Is it "Client" or "Consumer"? 

With thanks,

Igor

Richard L. Barnes wrote:
> Of course not every scenario calls for all of the security knobs to be 
> turned to 11.  Think of things instead in terms of syllogisms: "IF you 
> want X guarantee, THEN you MUST do A, B, C."
>
> Then you can also read the same things backwards in a given deployment 
> scenario: "Given that I can't do B, I can't get assurances X, Y, but I 
> can get Z (if I do D, F as well)".
>
> I promise to produce something more concrete soon :)  In the meantime, 
> this text illustrates what I mean pretty well:
> <http://tools.ietf.org/html/draft-barnes-oauth-model-01#section-5>
>
> --Richard
>
>
> On 11/10/10 2:03 PM, Anthony Nadalin wrote:
>> Issue here is that guarantees (and what you want as a guarantee may 
>> not be what somebody else wants) can vary depending on scenario and 
>> deployment.
>>
>> -----Original Message-----
>> From: Richard L. Barnes [mailto:rbarnes@bbn.com]
>> Sent: Tuesday, November 09, 2010 12:54 AM
>> To: torsten@lodderstedt.net
>> Cc: Anthony Nadalin; Tschofenig, Hannes; abfab@ietf.org; 
>> rai@ietf.org; ietf@ietf.org; secdir@ietf.org; websec@ietf.org; 
>> xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board; iesg@ietf.org; 
>> oauth@ietf.org
>> Subject: Re: [secdir] [OAUTH-WG] ** OAuth Tutorial&  OAuth Security 
>> Session **
>>
>> I would say that the security considerations should be based on a 
>> model of OAuth.  Start with a model of the protocol and the 
>> guarantees you want, then explain how to use security mechanisms to 
>> achieve those guarantees.
>>
>> I promised Hannes today to do a review of the current document (which 
>> I admit I haven't read) and start on some security considerations 
>> from that perspective.  So expect that in the next few weeks.
>>
>> --Richard
>>
>>
>>
>>
>> On 11/9/10 4:07 PM, torsten@lodderstedt.net wrote:
>>> We think the security considerations should be based on a threat 
>>> model of OAuth. But a complete threat model would blow up the spec.
>>>
>>> We therefore aim to produce a separate security document 
>>> (informational I-D/RFC) covering threat model as well as security 
>>> design and considerations. The security considerations section of 
>>> the core spec can then be distilled from this document.
>>>
>>> Regards,
>>> Torsten.
>>> Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland
>>>
>>> -----Original Message-----
>>> From: Anthony Nadalin<tonynad@microsoft.com>
>>> Date: Tue, 9 Nov 2010 01:54:57
>>> To: Torsten Lodderstedt<torsten@lodderstedt.net>; Hannes
>>> Tschofenig<hannes.tschofenig@gmx.net>
>>> Cc: abfab@ietf.org<abfab@ietf.org>; rai@ietf.org<rai@ietf.org>;
>>> ietf@ietf.org<ietf@ietf.org>; secdir@ietf.org<secdir@ietf.org>;
>>> websec@ietf.org<websec@ietf.org>; xmpp@ietf.org<xmpp@ietf.org>;
>>> kitten@ietf.org<kitten@ietf.org>; iab@iab.org Board<iab@iab.org>;
>>> iesg@ietf.org<iesg@ietf.org>; oauth@ietf.org<oauth@ietf.org>
>>> Subject: RE: [OAUTH-WG] ** OAuth Tutorial&   OAuth Security Session **
>>>
>>> I was looking for less of an analysis and more of considerations (of 
>>> the current flows and actors), I'm not sure how to adapt what you 
>>> have done to actually fit in the current specification, was your 
>>> thought that you would produce a separate security analysis document?
>>>
>>> -----Original Message-----
>>> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf
>>> Of Torsten Lodderstedt
>>> Sent: Sunday, November 07, 2010 3:04 PM
>>> To: Hannes Tschofenig
>>> Cc: abfab@ietf.org; rai@ietf.org; ietf@ietf.org; secdir@ietf.org;
>>> websec@ietf.org; xmpp@ietf.org; kitten@ietf.org; iab@iab.org Board;
>>> iesg@ietf.org; oauth@ietf.org
>>> Subject: Re: [OAUTH-WG] ** OAuth Tutorial&   OAuth Security Session **
>>>
>>> Hi all,
>>>
>>> Mark McGloin and me have been working on OAuth 2.0 security 
>>> considerations for a couple of weeks now. Since we both cannot 
>>> attend the IETF-79 meetings, we would like to provide the WG with 
>>> information regarding the current status of our work. I therefore 
>>> uploaded a_preliminary_ version of our working document to the WG's 
>>> wiki at 
>>> http://trac.tools.ietf.org/wg/oauth/trac/attachment/wiki/SecurityConsiderations/oauth20_seccons_20101107.pdf. 
>>>
>>> The focus of this version was on consolidating previous work as well 
>>> as results of mailing list discussions and start working towards a 
>>> rigorous threat model.
>>>
>>> Please give us feedback.
>>>
>>> regards,
>>> Torsten.
>>>
>>> Am 07.11.2010 03:22, schrieb Hannes Tschofenig:
>>>> Hi all,
>>>>
>>>> please consider attending the following two meetings!
>>>>
>>>> ** OAuth Security Session **
>>>>
>>>>     * Date: Monday, 13:00-15:00
>>>>     * Location: IAB breakout room (Jade 2)
>>>>     * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net The 
>>>> security
>>>> consideration section of OAuth 2.0 (draft -10) is still empty. 
>>>> Hence, we would like to put some time aside to discuss what 
>>>> security threats, requirements, and countermeasures need to be 
>>>> described. We will use the Monday, November 8, 1300-1500 slot to 
>>>> have a  discussion session.
>>>>
>>>> As a starting point I suggest to look at the following documents:
>>>>
>>>>     * 
>>>> http://trac.tools.ietf.org/wg/oauth/trac/wiki/SecurityConsiderations
>>>>     * http://trac.tools.ietf.org/wg/oauth/trac/wiki/SignaturesWhy
>>>>     *
>>>> http://tools.ietf.org/id/draft-tschofenig-oauth-signature-thoughts-00.
>>>> txt
>>>>
>>>> Note: If you are unfamiliar with OAuth then the OAuth tutorial 
>>>> session might be more suitable for you!
>>>>
>>>>
>>>>
>>>> ** OAuth Tutorial **
>>>>
>>>>     * Date: Wednesday, 19:30 (after the plenary)
>>>>     * Location: IAB breakout room (Jade 2)
>>>>     * Contact: Hannes Tschofenig hannes.tschofenig@gmx.net OAuth 
>>>> allows
>>>> a user to grant a third-party Web site or application access to their
>>>> resources, without necessarily revealing their credentials, or even
>>>> their identity. The OAuth working group, see
>>>> http://datatracker.ietf.org/wg/oauth/charter/, is currently trying to
>>>> finalize their main specification, namely OAuth v2:
>>>> http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/
>>>>
>>>> Based on the positive response at the last IETF meeting (in
>>>> Maastricht) we decided to hold another OAuth tutorial, namely on
>>>> *Wednesday, starting at 19:30 (after the IETF Operations and
>>>> Administration Plenary) till about 21:00. (Note: I had to switch the
>>>> day because of the social event!)
>>>>
>>>> It is helpful to read through the documents available int he 
>>>> working group but not required.
>>>>
>>>> Up-to-date information can be found here:
>>>> http://www.ietf.org/registration/MeetingWiki/wiki/79bofs
>>>>
>>>> Ciao
>>>> Hannes
>>>>
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>> _______________________________________________
>>> secdir mailing list
>>> secdir@ietf.org
>>> https://www.ietf.org/mailman/listinfo/secdir
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

From hartmans@mit.edu  Wed Nov 10 22:30:42 2010
Return-Path: <hartmans@mit.edu>
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 0D1373A6A24 for <secdir@core3.amsl.com>; Wed, 10 Nov 2010 22:30:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.132
X-Spam-Level: 
X-Spam-Status: No, score=-103.132 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 BXJ4gEte7BzK for <secdir@core3.amsl.com>; Wed, 10 Nov 2010 22:30:36 -0800 (PST)
Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 064ED3A69F5 for <secdir@ietf.org>; Wed, 10 Nov 2010 22:30:34 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (dhcp-2392.meeting.ietf.org [130.129.35.146]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4BBCA202B3 for <secdir@ietf.org>; Thu, 11 Nov 2010 01:30:41 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 017554761; Thu, 11 Nov 2010 01:30:57 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: secdir@ietf.org
Date: Thu, 11 Nov 2010 01:30:57 -0500
Message-ID: <tsltyjomkwu.fsf@carter-zimmerman.suchdamage.org>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: [secdir] Heads up: security model at PCP today at 1740: no authentication to open firewall holes
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: Thu, 11 Nov 2010 06:30:42 -0000

Folks, to my great surprise, we seem to have chartered work to
standardize a protocol for opening holes in NATs and firewalls.  They
are meeting oposite KARP, so I can't go, but you should.

They have a presentation to discuss their security model:

http://tools.ietf.org/agenda/79/slides/pcp-6.pdf

The idea is that there is no authenticatino at all for the on-link case
and ingress filtering (IP ACL authentication) for the off-link case.

That's actually probably fine for the NAT case.  however, for the
firewall control case, which is explicitly within their charter, that is
very much problematic.

This is early work, they need help not flames. (I'll admit that because
it's fairly late before the session, I've focused on shock value in the
subject of this message.)  Also, note that this presentation is a
summary of a fairly long mailing list thread.  If you have time to read
that, please do.

From weiler+secdir@watson.org  Fri Nov 12 13:50:25 2010
Return-Path: <weiler+secdir@watson.org>
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 337CE3A692C for <secdir@core3.amsl.com>; Fri, 12 Nov 2010 13:50:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 0i+cQWY63FSF for <secdir@core3.amsl.com>; Fri, 12 Nov 2010 13:50:18 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id CE1243A6A92 for <secdir@ietf.org>; Fri, 12 Nov 2010 13:50:17 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id oACLopU5071250 for <secdir@ietf.org>; Fri, 12 Nov 2010 16:50:51 -0500 (EST) (envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id oACLopbA071247 for <secdir@ietf.org>; Fri, 12 Nov 2010 16:50:51 -0500 (EST) (envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Fri, 12 Nov 2010 16:50:51 -0500 (EST)
From: Samuel Weiler <weiler+secdir@watson.org>
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.1011121648470.67666@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 12 Nov 2010 16:50:51 -0500 (EST)
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
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: Fri, 12 Nov 2010 21:50:25 -0000

The last assignment message was 29 October, before the Beijing 
meeting.

Review instructions and related resources are at:
      http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Kurt Zeilenga is next in the rotation.

For telechat 2010-11-18

Magnus Nystrom         T 2010-11-05 draft-ietf-dnsop-name-server-management-reqs-04
Eric Rescorla          T 2010-11-08 draft-ietf-opsec-ip-security-04
Joe Salowey            T 2010-11-17 draft-ietf-dhc-dhcpv6-ldra-03


For telechat 2010-12-02

Donald Eastlake        TR2010-11-23 draft-cheshire-dnsext-multicastdns-12
David McGrew           T 2010-11-15 draft-igoe-secsh-x509v3-06
Russ Mundy             T 2010-11-10 draft-ietf-emu-eaptunnel-req-08
Vincent Roca           T 2010-11-22 draft-ietf-mpls-tp-oam-framework-09
Stefan Santesson       T 2010-11-09 draft-ietf-sieve-notify-presence-02
Juergen Schoenwaelder  T 2010-11-23 draft-cheshire-dnsext-nbp-09
Sam Weiler             T 2010-11-22 draft-ietf-dhc-leasequery-by-remote-id-07
Nico Williams          T 2010-11-22 draft-ietf-mext-rfc3775bis-10

Last calls and special requests:

Reviewer                 LC end     Draft
Love Hornquist-Astrand   2010-07-23 draft-ietf-pkix-ocspagility-09
Jeffrey Hutzelman        2010-10-13 draft-ietf-mpls-ldp-upstream-08
David McGrew             -          draft-ietf-ecrit-framework-12
Radia Perlman            2010-11-18 draft-ietf-martini-gin-10
Eric Rescorla            2010-06-21 draft-ietf-simple-msrp-acm-09
Yaron Sheffer            2010-10-21 draft-ietf-xmpp-address-06
Carl Wallace             2010-11-16 draft-ietf-dime-rfc3588bis-25
Brian Weis               2010-12-02 draft-linowski-netmod-yang-abstract-04
Tom Yu                   2010-12-09 draft-cdmi-mediatypes-02
Larry Zhu                2010-09-30 draft-lundberg-app-tei-xml-06



From stefan@aaa-sec.com  Fri Nov 12 15:07:38 2010
Return-Path: <stefan@aaa-sec.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 DD45A3A6B68 for <secdir@core3.amsl.com>; Fri, 12 Nov 2010 15:07:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.085
X-Spam-Level: 
X-Spam-Status: No, score=-102.085 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 G8G6OyLjpPSf for <secdir@core3.amsl.com>; Fri, 12 Nov 2010 15:07:38 -0800 (PST)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.115]) by core3.amsl.com (Postfix) with ESMTP id EACBD3A6B59 for <secdir@ietf.org>; Fri, 12 Nov 2010 15:07:37 -0800 (PST)
Received: from s42.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 1AF75567E82 for <secdir@ietf.org>; Sat, 13 Nov 2010 00:08:19 +0100 (CET)
Received: (qmail 81116 invoked from network); 12 Nov 2010 23:08:09 -0000
Received: from 213-64-142-247-no153.business.telia.com (HELO [192.168.1.2]) (stefan@fiddler.nu@[213.64.142.247]) (envelope-sender <stefan@aaa-sec.com>) by s42.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <iesg@ietf.org>; 12 Nov 2010 23:08:09 -0000
User-Agent: Microsoft-MacOutlook/14.1.0.101012
Date: Sat, 13 Nov 2010 00:08:06 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: <iesg@ietf.org>, <secdir@ietf.org>, <draft-ietf-sieve-notify-presence.all@tools.ietf.org>
Message-ID: <C9038765.BF75%stefan@aaa-sec.com>
Thread-Topic: SecDir review of draft-ietf-sieve-notify-presence-02
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3372451690_9337421"
Subject: [secdir] SecDir review of draft-ietf-sieve-notify-presence-02
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: Fri, 12 Nov 2010 23:07:39 -0000

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3372451690_9337421
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

I have reviewed this document as part of the security directorate's  ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This draft seems short well written and to the point.
However, the security considerations section seems to be on the short side
and I'm wandering if all relevant security issues really are covered.

One thing that strikes me as possibly relevant is if this in any way can be
a means (in some variants of it's use) through which a spammer can gain
information about the status of the recipient.

/Stefan Santesson




--B_3372451690_9337421
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<html><head></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size:=
 14px; font-family: Calibri, sans-serif; "><div><div>I have reviewed this do=
cument as part of the security directorate's &nbsp;ongoing effort to review =
all IETF documents being processed by the IESG. &nbsp;These comments were wr=
itten primarily for the benefit of the&nbsp;</div><div>security area directo=
rs. &nbsp;Document editors and WG chairs should treat&nbsp;these comments ju=
st like any other last call comments.</div></div><div><br></div><div>This dr=
aft seems short well written and to the point.</div><div>However, the securi=
ty considerations section seems to be on the short side and I'm wandering if=
 all relevant security issues really are covered.</div><div><br></div><div>O=
ne thing that strikes me as possibly relevant is if this in any way can be a=
 means (in some variants of it's use) through which a spammer can gain infor=
mation about the status of the recipient.</div><div><br></div><div>/Stefan S=
antesson</div><div><br></div></body></html>

--B_3372451690_9337421--



From barryleiba@gmail.com  Sat Nov 13 16:49:20 2010
Return-Path: <barryleiba@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 CE4CE3A6C68; Sat, 13 Nov 2010 16:49:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.022
X-Spam-Level: 
X-Spam-Status: No, score=-102.022 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 5pH1X8KzS+pj; Sat, 13 Nov 2010 16:49:20 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id E6ED43A6B5F; Sat, 13 Nov 2010 16:49:19 -0800 (PST)
Received: by iwn40 with SMTP id 40so5449943iwn.31 for <multiple recipients>; Sat, 13 Nov 2010 16:49:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=TPbwt9jMIwlFMRxHDxFF+AFboDFXI75OWpya0pqsVYs=; b=Qt4eHwnNg1WzFW2ScDhBSB4uOSnQGBlvq9CTz05wibIC1omIY4r5bwukF7E6uz7wr1 MZiH3VMP+IO6aFlDBUTO9KuJR3K3GzTKEXrypKgCzL6/xaQ9M1XJzcKVWjb2tCO/AZWr pS6Qhe/Hm906HMFjkoVHbjLb4OiULloHCsdBY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=CyxgYGcixCmF+OyHsdO6OjsOQfYPLSicZQexoJgh/94WBYevMnZwj784gRtRYVvknR QGNknKdaqsUiR48NqH1TvctnIOMjq+fq43gUqq9P+DOeDW/CjjI3cmrKp5ykXfA2+s7U ehrACmbe2vkCNRcAT69Myx3Stv7C7sibKPDOc=
MIME-Version: 1.0
Received: by 10.231.37.1 with SMTP id v1mr3200884ibd.103.1289695796854; Sat, 13 Nov 2010 16:49:56 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.231.19.137 with HTTP; Sat, 13 Nov 2010 16:49:56 -0800 (PST)
In-Reply-To: <C9038765.BF75%stefan@aaa-sec.com>
References: <C9038765.BF75%stefan@aaa-sec.com>
Date: Sun, 14 Nov 2010 08:49:56 +0800
X-Google-Sender-Auth: NliVNYxFu3Z2w_AH_r2cTH9xY6M
Message-ID: <AANLkTimMOFZKTt-29N1bww5GCbLgor7Aa49mXAAPi-8d@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Stefan Santesson <stefan@aaa-sec.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: iesg@ietf.org, draft-ietf-sieve-notify-presence.all@tools.ietf.org, secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-sieve-notify-presence-02
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: Sun, 14 Nov 2010 00:49:20 -0000

Thanks for the review, Stefan.

> One thing that strikes me as possibly relevant is if this in any way can be
> a means (in some variants of it's use) through which a spammer can gain
> information about the status of the recipient.

We had thought of that, but I thought enough was said.  Probably not,
so I intend to add this paragraph to the security considerations,
already in my working copy:
---
In some situations, scripts may act on some of the recipient's
presence information that the sender of the triggering message
is not allowed to see.  This can be a benefit to the recipient
in many cases, but it can also present an opportunity for a
sender to use messages to probe the recipient's presence (if,
for example, messages sometimes result in auto-replies, and
sometimes do not).  Script authors should take care in
considering this aspect of presence-triggered actions.
---

Does that address your concern adequately?

Barry

From jsalowey@cisco.com  Tue Nov 16 14:40:52 2010
Return-Path: <jsalowey@cisco.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 EE5413A680A; Tue, 16 Nov 2010 14:40:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ghiEfCZIGXUS; Tue, 16 Nov 2010 14:40:51 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0EE8B3A67E3; Tue, 16 Nov 2010 14:40:50 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEuX4kxAZnwN/2dsb2JhbACiZHGlTZsdhUsEhFqFfoMM
X-IronPort-AV: E=Sophos;i="4.59,207,1288569600"; d="scan'208";a="182958635"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Nov 2010 22:41:34 +0000
Received: from [10.33.251.139] ([10.33.251.139]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAGMfXFs018729; Tue, 16 Nov 2010 22:41:33 GMT
From: Joe Salowey <jsalowey@cisco.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 16 Nov 2010 14:41:41 -0800
Message-Id: <7A66959C-0892-4151-A000-45AD67E1B788@cisco.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-dhc-dhcpv6-ldra.all@tools.ietf.org
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Subject: [secdir] Review of draft-ietf-dhc-dhcpv6-ldra-03
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: Tue, 16 Nov 2010 22:40:52 -0000

I have reviewed this document as part of the security directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.

This document defines a type of DHCPv6 relay agent that adds client =
interface information into DHCP messages.   I do not think that this =
document introduces any new security concerns over DHCPv6.  I think it =
would be good if the security considerations section had reference to =
the relevant information in the security considerations of RFC 3315. =20

Cheers,

Joe=

From radiaperlman@gmail.com  Tue Nov 16 21:15:57 2010
Return-Path: <radiaperlman@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 AF7593A680C; Tue, 16 Nov 2010 21:15:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 BrUbrSpIa4em; Tue, 16 Nov 2010 21:15:56 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id AE7323A67E4; Tue, 16 Nov 2010 21:15:56 -0800 (PST)
Received: by iwn40 with SMTP id 40so1757202iwn.31 for <multiple recipients>; Tue, 16 Nov 2010 21:16:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=UZoaLeL8o/tbO1vWGOmA+P2aEtOHgCRw5W4H+gPBpJQ=; b=Kzi5dkSh9AXuILFoxr3q3fmHb+VQt9SQmG2A9J+3oYKF9P9qdJSHTKziEjUWEfPa3H IOJ1Y/UP4Gj1fHY+CThHGD4VS1cCuMVHV/b34oWWqLB6axp60U1Ql6GOOACzvcnKlyks /m2WpnxdCacn+uOXKJFK3tQ5IdeSgbKLRJBns=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=N8nHOiMdhhlP+7bGEPFSJHPWBpMG/fBE7ZZReL0cvUmZp4M+UfG3wxeG3vcQBpIGZ+ QK9JRTtSYGt8ataxpzJLyNvrokNLIc/As/qlYFh+RwQol/CQmPlDbHD8T9XSmLRgaZ4D 4GMTF9VFaDmhYSHqZENraWSs8ZZzspi3ud490=
MIME-Version: 1.0
Received: by 10.231.17.9 with SMTP id q9mr6489048iba.109.1289971001020; Tue, 16 Nov 2010 21:16:41 -0800 (PST)
Received: by 10.42.6.66 with HTTP; Tue, 16 Nov 2010 21:16:41 -0800 (PST)
Date: Tue, 16 Nov 2010 21:16:41 -0800
Message-ID: <AANLkTikZva3c=D0tRKg-g3QsCoB-PpcSDUzsmYfJCqrU@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: secdir@ietf.org, iesg@ietf.org, draft-ietf-martini-gin.all@tools.ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [secdir] Secdir review of draft-ietf-martini-gin-10.txt
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: Wed, 17 Nov 2010 05:15:57 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This draft defines an extension to the SIP protocol to enable a more
efficient encoding in the case where multiple phone numbers (those
under the control of a SIP-PBX) can roam together. Backwards and
forwards compatibility requirements make this change more complex than
one might expect.

There are no important security considerations for this document other
than the amplification of some DoS attacks, and much of the
information in the Security Considerations section is actually about
requirements for protocol correctness. I would assume the rest
duplicates information from the SIP specification, though I haven't
checked. The bottom line is that I believe the document is just fine
as it is.

I found two minor typos:

1) Page 3 para 2 line 3: "users" -> "user's"

2) The indented text at the end of section 3  was copied from RFC4475,
but in the copying some leading spaces on some of the lines were lost.
Since the purpose of this text is to illustrate how embedded spaces in
actual data will be represented in the body of this RFC, losing those
spaces negates the value of the section.

From new-work-bounces@ietf.org  Tue Nov 16 21:08:51 2010
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F33723A6848; Tue, 16 Nov 2010 21:08:50 -0800 (PST)
X-Original-To: new-work@core3.amsl.com
Delivered-To: new-work@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F40053A6848 for <new-work@core3.amsl.com>; Tue, 16 Nov 2010 21:08:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 mwXhX-X6gCzH for <new-work@core3.amsl.com>; Tue, 16 Nov 2010 21:08:49 -0800 (PST)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id E8A893A680C for <new-work@ietf.org>; Tue, 16 Nov 2010 21:08:48 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from <ij@w3.org>) id 1PIaGx-0006y1-VH; Wed, 17 Nov 2010 00:09:32 -0500
Message-Id: <C995F77E-06AD-43D7-AC2A-7DDEA273CBE9@w3.org>
From: Ian Jacobs <ij@w3.org>
To: new-work@ietf.org
Mime-Version: 1.0 (Apple Message framework v936)
Date: Tue, 16 Nov 2010 23:09:31 -0600
X-Mailer: Apple Mail (2.936)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Wed, 17 Nov 2010 05:45:21 -0800
Subject: [secdir] [new-work] Proposed W3C Charter: HTML5 Chinese Interest Group	(until 2010-12-17)
X-BeenThere: secdir@ietf.org
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: Wed, 17 Nov 2010 05:08:51 -0000

Hello,

Today W3C Advisory Committee Representatives received a Proposal to  
revise the HTML Activity [0] (see the W3C Process Document description  
of Activity Proposals [1]). This proposal includes a draft charter for  
the HTML5 Chinese Interest Group:
    http://www.w3.org/html/ig/zh/charter.html (English)
    http://www.w3.org/html/ig/zh/charter.zh.html (Simplified Chinese)
    http://www.w3.org/html/ig/zh/charter.zh-hant.html (Traditional
Chinese)	

As part of ensuring that the community is aware of proposed work at  
W3C, this draft charter is public during the Advisory Committee review  
period.

W3C invites public comments through 2010-12-17 on the proposed  
charter. Please send comments to public-new-work@w3.org, which has a  
public archive:
    http://lists.w3.org/Archives/Public/public-new-work/

Other than comments sent in formal responses by W3C Advisory Committee  
Representatives, W3C cannot guarantee a response to comments. If you  
work for a W3C Member [2], please coordinate your comments with your  
Advisory Committee Representative. For example, you may wish to make  
public comments via this list and have your Advisory Committee  
Representative refer to it from his or her formal review comments.

If you should have any questions or need further information, please  
contact Kanghao (Kenny) Lu, Team Contact <kennyluck@w3.org>

Thank you,

Ian Jacobs, Head of W3C Communications

[0] http://www.w3.org/html/
[1]
http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation
[2] http://www.w3.org/Consortium/Member/List

--
Ian Jacobs (ij@w3.org)    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From adam@nostrum.com  Wed Nov 17 05:37:29 2010
Return-Path: <adam@nostrum.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 0D7733A68FF; Wed, 17 Nov 2010 05:37:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.743
X-Spam-Level: 
X-Spam-Status: No, score=-102.743 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, SPF_PASS=-0.001, 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 1Shi8JLbnMKN; Wed, 17 Nov 2010 05:37:28 -0800 (PST)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id CE26F3A68F3; Wed, 17 Nov 2010 05:37:27 -0800 (PST)
Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oAHDcAUQ038923 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 17 Nov 2010 07:38:11 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <4CE3DAC2.3080505@nostrum.com>
Date: Wed, 17 Nov 2010 07:38:10 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Radia Perlman <radiaperlman@gmail.com>
References: <AANLkTikZva3c=D0tRKg-g3QsCoB-PpcSDUzsmYfJCqrU@mail.gmail.com>
In-Reply-To: <AANLkTikZva3c=D0tRKg-g3QsCoB-PpcSDUzsmYfJCqrU@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
X-Mailman-Approved-At: Wed, 17 Nov 2010 05:45:21 -0800
Cc: draft-ietf-martini-gin.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] Secdir review of draft-ietf-martini-gin-10.txt
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: Wed, 17 Nov 2010 13:37:29 -0000

Radia:

Thanks for the review! One quick comment.

On 11/16/10 23:16, Nov 16, Radia Perlman wrote:
> 1) Page 3 para 2 line 3: "users" ->  "user's"

The sentence begins: "The users registered individual reachability 
information with this authority..."

In this case, we are talking about a class of users (plural, not 
possessive) who registered (past-tense verb, not adjective) information.

The construction is a bit awkward, and I can see how you would read it 
differently than intended. I'll see what I can do to make it less 
confusing; perhaps "The users would register..."

/a

From mcgrew@cisco.com  Thu Nov 18 12:18:29 2010
Return-Path: <mcgrew@cisco.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 36A713A68CF; Thu, 18 Nov 2010 12:18:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3aC2tzS2j9ey; Thu, 18 Nov 2010 12:18:28 -0800 (PST)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 42CBA3A6811; Thu, 18 Nov 2010 12:18:28 -0800 (PST)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAAIZ5UyrR7Ht/2dsb2JhbACiV3GkDJs4hUsEhFqGAA
X-IronPort-AV: E=Sophos;i="4.59,218,1288569600"; d="scan'208";a="219888017"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 18 Nov 2010 20:19:05 +0000
Received: from stealth-10-32-254-214.cisco.com (stealth-10-32-254-214.cisco.com [10.32.254.214]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAIKJ1Lh015137; Thu, 18 Nov 2010 20:19:02 GMT
Message-Id: <085BE277-7C5F-4479-944D-A2DBD4447CEA@cisco.com>
From: David McGrew <mcgrew@cisco.com>
To: secdir@ietf.org, IESG <iesg@ietf.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 18 Nov 2010 12:19:01 -0800
X-Mailer: Apple Mail (2.936)
Cc: douglas@stebila.ca, "Kevin M. Igoe" <kmigoe@nsa.gov>
Subject: [secdir] SECDIR review of draft-igoe-secsh-x509v3-06
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: Thu, 18 Nov 2010 20:18:29 -0000

I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the   
IESG.  These comments were written primarily for the benefit of the  
security area directors. Document editors and WG chairs should treat  
these comments just like any other review comments.

The document describes how to use X509 and OCSP within SSH.  It is  
clearly written, and the security considerations section is  
appropriate (it mostly points to the relevant sections in the SSH,  
X509, and OCSP RFCs).

I have one nit, which is wording that authors might want to change for  
clarity.  Section 4 says "The mapping between certificates and host  
names is left as an implementation and configuration issue for  
implementers and system administrators."   I believe that what is  
meant is that "The method that the server uses to verify that the host  
certificate and key actually belongs to the client host named in the  
message is out of scope of this note", to use language from RFC 4252.

regards,

David


From gonzalo.camarillo@ericsson.com  Fri Nov 19 06:07:28 2010
Return-Path: <gonzalo.camarillo@ericsson.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 9074D3A67E9 for <secdir@core3.amsl.com>; Fri, 19 Nov 2010 06:07:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 cdrfJg0dGTM2 for <secdir@core3.amsl.com>; Fri, 19 Nov 2010 06:07:26 -0800 (PST)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0D7963A6783 for <secdir@ietf.org>; Fri, 19 Nov 2010 06:07:24 -0800 (PST)
X-AuditID: c1b4fb3d-b7c05ae0000028e7-8f-4ce684cd1eca
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CC.81.10471.DC486EC4; Fri, 19 Nov 2010 15:08:14 +0100 (CET)
Received: from [131.160.37.44] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.2.234.1; Fri, 19 Nov 2010 15:08:13 +0100
Message-ID: <4CE684CD.1080902@ericsson.com>
Date: Fri, 19 Nov 2010 16:08:13 +0200
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: Stephen Kent <kent@bbn.com>
References: <p06240800c8e55027a17b@[128.89.89.159]> <4CC81942.3060502@ericsson.com> <p06240801c8fbcc3b59d7@[222.128.202.177]>
In-Reply-To: <p06240801c8fbcc3b59d7@[222.128.202.177]>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: AAAAAA==
Cc: "secdir@ietf.org" <secdir@ietf.org>, "gao.yang2@zte.com.cn" <gao.yang2@zte.com.cn>, "pkyzivat@cisco.com" <pkyzivat@cisco.com>, Christer Holmberg <christer.holmberg@ericsson.com>, "tim.polk@nist.gov" <tim.polk@nist.gov>, "rjsparks@nostrum.com" <rjsparks@nostrum.com>
Subject: Re: [secdir] review of draft-ietf-sipcore-reinvite-06.txt
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: Fri, 19 Nov 2010 14:07:28 -0000

Hi Steve,

I have just submitted a new revision of the draft that addresses all
your comments. Thanks for your review.

http://www.ietf.org/id/draft-ietf-sipcore-reinvite-07.txt

Cheers,

Gonzalo

On 07/11/2010 5:25 AM, Stephen Kent wrote:
> Gonzalo,
> 
> Sorry for my tardy reply.
> 
> I like your changes, with a minor edit at the end:
> 
> "In particular, in order not to reduce the security level for a given
> session, re-INVITEs and UPDATE requests SHOULD be secured using a
> mechanism equivalent to or stronger than the initial INVITE request that
> created the
> session. For example, if the initial INVITE request was end-to-end
> integrity protected or encrypted, subsequent re-INVITEs and UPDATE
> requests should also be so."
> 
> 
> Steve


From margaretw42@gmail.com  Fri Nov 19 10:19:56 2010
Return-Path: <margaretw42@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 3DE7128C0DC for <secdir@core3.amsl.com>; Fri, 19 Nov 2010 10:19:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 AdFfa79MHmWJ for <secdir@core3.amsl.com>; Fri, 19 Nov 2010 10:19:54 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id AE0293A6809 for <secdir@ietf.org>; Fri, 19 Nov 2010 10:19:54 -0800 (PST)
Received: by vws7 with SMTP id 7so194158vws.31 for <secdir@ietf.org>; Fri, 19 Nov 2010 10:20:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date:cc :x-mailer; bh=KLeE3yXrsEEklRCsVvxDVrNXLxjMzJWSbqH+TPnERNs=; b=PZDpgoLrdT3i1hO3j604xnWXww3R7SpIeVswYGlesnA38AG/R9JDpbFfVGrIiTfeFh nVoC67G3qPr3zMeVsfwZvphSus8Axe9GeigGElpIFGOC+catyjX6BWfqwqgUosPPer6V EjJ5J8yAqankWUGhvCPpjaRvhSWqFY/PMJo/E=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; b=rF0fnWe6T+BOSiz0CjZZzno+M0pZHMY9ETO4sFDV+SxORqyFrsK4tqxCOEQWRt/Zb9 zexn+jCXcyLzY4FNwUriIc6ESj5BYZhQBK9dEAXo7jsu+cf5ZZ7HnHfmgr3ApgEuJJBb 3cfYnUpLIF/vcSxoOESJhlQzKg3M64eh7t2qk=
Received: by 10.220.186.2 with SMTP id cq2mr567318vcb.142.1290190842667; Fri, 19 Nov 2010 10:20:42 -0800 (PST)
Received: from [10.36.0.42] (pool-108-20-27-240.bstnma.fios.verizon.net [108.20.27.240]) by mx.google.com with ESMTPS id v20sm712781vbw.19.2010.11.19.10.20.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 10:20:42 -0800 (PST)
Message-Id: <F3073454-E86F-4E6F-AEFC-7B4184A73040@lilacglade.org>
From: Margaret Wasserman <margaretw42@gmail.com>
To: secdir@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Fri, 19 Nov 2010 13:20:40 -0500
X-Mailer: Apple Mail (2.936)
X-Mailman-Approved-At: Fri, 19 Nov 2010 10:30:03 -0800
Cc: Ralph Droms <rdroms.ietf@gmail.com>
Subject: [secdir] Security Review for draft-ohba-pana-relay-02.txt
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: Fri, 19 Nov 2010 18:19:56 -0000

Hi Security Directorate Folks,

I am shepherding draft-ohba-pana-relay-02.txt for publication as a  
Proposed Standard RFC, and I would like to get a Security Directorate  
review for this document as soon as possible.  The document can be  
found here:

https://datatracker.ietf.org/doc/draft-ohba-pana-relay/

IMO, there is (at least) one way in which the introduction of a relay  
changes the security model for PANA.  In the original PANA protocol,  
the PANA Authentication Agent (PAA) determines the source IP Address  
and source UDP Port number of the PANA Client (PaC) by looking in the  
headers of the request, and responds to that IP Address/Port.   
However, in the case where a relay is being used, the client IP  
Address/Port are included in an option in the relay message.  Requests  
are sent from the relay and responses are sent to the relay, using the  
IP Address/Port in the headers, but the client (using information from  
the option) is authenticated.  I understand that this changes the  
security properties of the PANA exchange, but I am not sure if it  
changes them in a way that matters for the PANA protocol.

So, I could use help here from someone who understands EAP (and  
ideally, PANA) well enough to understand how/if a relay can safely be  
used in a PANA environment.

This is not a WG document, as the PANA WG is closed.  Review comments  
should be sent to me, to Ralph Droms (cc:ed), to the authors (paduffy@cisco.com 
, samitac@ipinfusion.com, robert.cragie@gridmerge.com, yoshihiro.ohba@toshiba.co.jp 
, alper.yegin@yegin.org), and to the (still operational, but now  
unofficial) PANA mailing list (pana@ietf.org).

Thanks,
Margaret





From weiler+secdir@watson.org  Mon Nov 22 05:05:19 2010
Return-Path: <weiler+secdir@watson.org>
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 A6E3C3A6A7A for <secdir@core3.amsl.com>; Mon, 22 Nov 2010 05:05:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
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 8GmIoNE3X4iO for <secdir@core3.amsl.com>; Mon, 22 Nov 2010 05:05:18 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 236343A6A4A for <secdir@ietf.org>; Mon, 22 Nov 2010 05:05:17 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id oAMD6D6d024387 for <secdir@ietf.org>; Mon, 22 Nov 2010 08:06:13 -0500 (EST) (envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id oAMD61kT024361 for <secdir@ietf.org>; Mon, 22 Nov 2010 08:06:13 -0500 (EST) (envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Mon, 22 Nov 2010 08:06:01 -0500 (EST)
From: Samuel Weiler <weiler+secdir@watson.org>
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.1011220801420.16697@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Mon, 22 Nov 2010 08:06:13 -0500 (EST)
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
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, 22 Nov 2010 13:05:19 -0000

Review instructions and related resources are at:
      http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Donald Eastlake is next in the rotation.

For telechat 2010-12-02

Reviewer                 LC end     Draft
Donald Eastlake        TR2010-11-23 draft-cheshire-dnsext-multicastdns-12
Jeffrey Hutzelman      T 2010-10-13 draft-ietf-mpls-ldp-upstream-08
Russ Mundy             T 2010-11-10 draft-ietf-emu-eaptunnel-req-08
Eric Rescorla          T 2010-06-21 draft-ietf-simple-msrp-acm-09
Eric Rescorla          T 2010-11-08 draft-ietf-opsec-ip-security-04
Carl Wallace           TR2010-07-09 draft-stone-mgcp-vbd-08
Sam Weiler             T 2010-11-22 draft-ietf-dhc-leasequery-by-remote-id-07
Nico Williams          T 2010-11-22 draft-ietf-mext-rfc3775bis-10

For telechat 2010-12-16

Vincent Roca           T 2010-11-22 draft-ietf-mpls-tp-oam-framework-09

Last calls and special requests:

Derek Atkins             2010-12-02 draft-ietf-sieve-autoreply-02
Rob Austein              2010-12-15 draft-salowey-secsh-uri-
Richard Barnes           2010-12-16 draft-melnikov-mailserver-uri-to-historic-
Dave Cridland            2010-12-03 draft-ietf-sipcore-sec-flows-03
Alan DeKok               -          draft-ohba-pana-relay-02
Love Hornquist-Astrand   2010-07-23 draft-ietf-pkix-ocspagility-09
Barry Leiba             R2010-12-16 draft-saintandre-tls-server-id-check-10
David McGrew             -          draft-ietf-ecrit-framework-12
Carl Wallace             2010-11-16 draft-ietf-dime-rfc3588bis-25
Brian Weis               2010-12-02 draft-linowski-netmod-yang-abstract-04
Tom Yu                   2010-12-09 draft-cdmi-mediatypes-02
Kurt Zeilenga            2010-12-02 draft-ietf-httpstate-cookie-17
Larry Zhu                2010-09-30 draft-lundberg-app-tei-xml-06
Larry Zhu                2010-11-30 draft-ietf-mpls-ip-options-04
Glen Zorn                2010-12-03 draft-ietf-opsec-protect-control-plane-04


From rbarnes@bbn.com  Mon Nov 22 08:19:55 2010
Return-Path: <rbarnes@bbn.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 6242A3A6AB4; Mon, 22 Nov 2010 08:19:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 uRC9BjCfFsFU; Mon, 22 Nov 2010 08:19:53 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id ACADC3A6A9A; Mon, 22 Nov 2010 08:19:52 -0800 (PST)
Received: from [192.1.255.215] (port=51923 helo=col-dhcp-192-1-255-215.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1PKZ8K-000Cei-4d; Mon, 22 Nov 2010 11:20:48 -0500
Message-Id: <C68932A1-8773-4D07-B72A-E4F05DC335E4@bbn.com>
From: "Richard L. Barnes" <rbarnes@bbn.com>
To: secdir@ietf.org, iesg@ietf.org, "ietf@ietf.org IETF" <ietf@ietf.org>, draft-melnikov-mailserver-uri-to-historic@tools.ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 22 Nov 2010 11:20:46 -0500
X-Mailer: Apple Mail (2.936)
Subject: [secdir] secdir review of draft-melnikov-mailserver-uri-to-historic-00
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, 22 Nov 2010 16:19:56 -0000

I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG.  These comments were written primarily for the benefit of the  
security area directors.  Document editors and WG chairs should treat  
these comments just like any other last call comments.

As the name suggests, this document requests that IANA change the  
registration status of the "mailserver:" URI scheme to  
"Historic" (from its current status as "Provisional").  The document  
explains the lack of interoperability around this URI scheme, and  
describes better alternatives that developers should use.

I agree with the document's assessment that it does not create any new  
security concerns.  By reducing the ambiguity related to "mailserver:"  
URIs, this change in status should reduce the risk the improper  
implementations will create security vulnerabilities in software.

--Richard
  

From new-work-bounces@ietf.org  Tue Nov 23 09:19:16 2010
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2163A6988; Tue, 23 Nov 2010 09:19:16 -0800 (PST)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id 2B7743A6985; Tue, 23 Nov 2010 09:19:12 -0800 (PST)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20101123171913.2B7743A6985@core3.amsl.com>
Date: Tue, 23 Nov 2010 09:19:12 -0800 (PST)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Tue, 23 Nov 2010 11:21:18 -0800
Subject: [secdir] [new-work] WG Review: Recharter of Mobility Multicast (multimob)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
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: Tue, 23 Nov 2010 17:19:16 -0000

A modified charter has been submitted for the Mobility Multicast
(multimob) working group in the Internet Area of the IETF.  The IESG has
not made any determination as yet.  The modified charter is provided below
for informational purposes only.  Please send your comments to the IESG
mailing list (iesg@ietf.org) by Tuesday, November 30, 2010.

Mobility Multicast (multimob)
-------------------------------
Current Status: Active Working Group 
Last Modified: 2010-11-09

Chairs:
    Behcet Sarikaya <sarikaya@ieee.org>
    Stig Venaas <stig@venaas.com>
    Behcet Sarikaya <bsarikaya@huawei.com>

Internet Area Directors:
    Ralph Droms <rdroms.ietf@gmail.com>
    Jari Arkko <jari.arkko@piuha.net>

Internet Area Advisor:
    Jari Arkko <jari.arkko@piuha.net>

Mailing Lists:
    General Discussion: multimob@ietf.org
    To Subscribe:       https://www.ietf.org/mailman/listinfo/multimob
    Archive:           
http://www.ietf.org/mail-archive/web/multimob/current/maillist.html

Description of Working Group:

 The Multicast mobility (multimob) working group provides guidance
 for supporting multicast in a mobile environment. The scope of work
 will be limited to Proxy Mobile IPv6, IGMPv3/MLDv2 protocols and
 listener mobility. The group will work on extensions of Proxy Mobile
 IPv6 to improve its capability to handle multicast efficiently. Work
 requiring modifications to IGMPv3/MLDv2 is out of scope in this
 stage of this working group, however, as are modifications to
 multicast routing protocols.

 Specific goals for the group are: 

 - A solution to the tunnel convergence problem by separating
   multicast routing from a mobility anchor. Possible techniques are
   using native infrastructure, using a dedicated mobility anchor
   etc.

 - Mechanisms to optimize multicast traffic during a handover. Such
   mechanisms may include context transfer functionality.

 - Mechanisms needed to support multicast source mobility. Both any
   source multicast and source specific multicast source mobility
   will be covered.

 - Document the configuration of IGMPv3/MLDv2 in mobile environments

 The group shall primarily focus on Proxy Mobile IPv6 (PMIPv6) based
 networks when looking at the first three items. It is possible but
 not required that the solutions are applicable also for Mobile IPv6
 (MIPv6) based networks.

 For background, the PMIPv6 specification as defined in RFC 5213 does
 not describe how to support multicast. Some forms of multicast
 support can, however, be built in the involved nodes by using
 existing capabilities of multicast protocols and the underlying
 mobility protocols. The working group has already documented how
 existing mechanisms can be used to support multicast, without
 requiring any additions or changes to message types and parameters
 specified in RFC 5213, and assuming an unmodified mobile host. The
 current goals of the working group relate to improving the
 efficiency of this base solution.

 IGMPv3/MLDv2 has been specified for wired networks with shared links.
 Mobile nodes have needs that are specific to wireless networks and
 mobility (e.g. entering a dormant mode to conserve battery power,
 minimizing the latency for joining and leaving a group in support of
 movement).

 In performing its work, the working group will work closely with
 both the mobility community (NETEXT WG) and the multicast community
 (MBONED WG). The group will consider both source specific multicast
 and any source multicast multicast models.

 Future work, subject to rechartering, may study/evaluate extensions
 to IGMPv3/MLDv2 to support better operation in mobile environments.


Goals and Milestones:
Nov 2010 - Initial version of a document on how to tune IGMPv3/MLDv2 for 
           mobility
Apr 2011 - Submit a document on how to tune IGMPv3/MLDv2 for mobility, 
           for publication as either Informational or Best Current 
           Practice
Jun 2011 - Initial version of document on PMIPv6 routing optimizations 
           to avoid tunnel convergence problem
Nov 2011 - Initial version of document on PMIPv6 handover optimizations
Nov 2011 - Initial version of document on PMIPv6 multicast source 
           mobility solution
Jun 2012 - Submit PMIPv6 routing optimizations document to IESG for 
           publication as Internet Standard
Nov 2012 - Submit PMIPv6 handover optimizations document to IESG for 
           publication as Internet Standard
Nov 2012 - Submit PMIPv6 multicast source mobility solution to IESG for 
           publication as Internet Standard
Dec 2012 - Decision to include additional optimization work involving 
           extensions to IGMPv3 or MLDv2
Dec 2012 - Recharter based on the above decisions (or close the group if 
           no new work is needed)
_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From new-work-bounces@ietf.org  Tue Nov 23 09:26:37 2010
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25D9928C0CE; Tue, 23 Nov 2010 09:26:37 -0800 (PST)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id AF5F83A698F; Tue, 23 Nov 2010 09:26:34 -0800 (PST)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20101123172634.AF5F83A698F@core3.amsl.com>
Date: Tue, 23 Nov 2010 09:26:34 -0800 (PST)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Tue, 23 Nov 2010 11:21:18 -0800
Subject: [secdir] [new-work] WG Review: Recharter of DNS Extensions (dnsext)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
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: Tue, 23 Nov 2010 17:26:37 -0000

A modified charter has been submitted for the DNS Extensions (dnsext)
working group in the Internet Area of the IETF.  The IESG has not made any
determination as yet.  The modified charter is provided below for
informational purposes only.  Please send your comments to the IESG
mailing list (iesg@ietf.org) by Tuesday, November 30, 2010.

DNS Extensions (dnsext)
---------------------------------------------
Status: Active Working Group
Last updated: 2010-11-09

Chairs:
  Olafur Gudmundsson <ogud@ogud.com>
  Andrew Sullivan <ajs@shinkuro.com>

Internet Area Directors:
  Ralph Droms <rdroms.ietf@gmail.com>
  Jari Arkko <jari.arkko@piuha.net>

Internet Area Advisor:
  Ralph Droms <rdroms.ietf@gmail.com>

Mailing Lists:
  Address:	dnsext@ietf.org
  To Subscribe:	https://www.ietf.org/mailman/listinfo/dnsext
  Archive:	http://www.ietf.org/mail-archive/web/dnsext/

Description of Working Group:

The DNS has a large installed base and repertoire of protocol
specifications. The DNSEXT working group will actively advance DNS
protocol-related RFCs on the standards track while thoroughly
reviewing further proposed extensions. The scope of the DNSEXT WG is
confined to the DNS protocol, particularly changes that affect DNS
protocols "on the wire" or the internal processing of DNS data. DNS
operations are out of scope for the WG.

The WG will consider work in the following areas:

* DNSSEC and TSIG/TKEY algorithm maintenance
* Mechanisms that complement, or are alternatives to, TSIG and SIG(0)
* Hardening DNS protocol and providing guidance to implementers
* Advancing existing DNS-related Proposed Standard RFCs to Draft/Full
  Standard
* Obsoleting DNS-related RFCs
* Maintaining a Wiki containing a guide to DNS protocol RFCs
* Improving DNS zone synchronization mechanisms 
* Examining transport protocols, possibly adding new ones.
* Mechanisms to alias DNS trees or parts thereof

While the DNS offers two mechanisms for aliasing DNS labels -- CNAME
and DNAME -- neither of these provides the support necessary to alias
completely one part of the DNS tree as another part.  There are claims
that the restriction has proven to be too great in practice,
particularly with burgeoning deployment of IDNA and the need to
provide domain name variants.  The issue is made more complex by
DNSSEC

The DNSEXT WG will evaluate ways to provide such aliasing, to add
metadata to zones to allow easier operation of zones when such
aliasing is needed, or both.  The WG will also provide an
informational document outlining the various strategies available,
what they might be used for, and what their limitations are.  It is
possible that the WG will conclude no aliasing or metadata support is
possible, or that none of the proposals so far made are adequate.

Before formal adoption of any work item at least 5 working group
participants must publicly state that the item is within charter and
is a worthwhile item for further study.

The DNSEXT WG will conduct the specified RFC5395 review of RR
templates as they are posted, and EDNS0 Option templates if EDNS0-bis
updates registration requirements.

The WG will review DNS protocol related work which may originate
elsewhere in the IETF, including AD-sponsored submissions or drafts
in other working group.

Goals and Milestones:

Done           AXFR Clarify to IESG
Done           DNS existing transport protocol
                    recommendations/clarifications to IESG
Dec 2010       RFC3597-bis Unknown RR advanced to IESG for PS 
Dec 2010       DNSKEY Registry fixes and allocation procedure
                    advanced to IESG
Dec 2010       EDNS0-bis update advanced to IESG
Dec 2010       TSIG/MD5 Obsoleting to IESG
Dec 2010       IXFR-only to IESG
Jan 2011       DNSSEC Errata document to IESG 
Jul 2011       WG consensus on new or revised RRTYPEs for aliasing
                    work
Jul 2011       Interoperation testing on new or revised RRTYPEs
                    (particularly with existing deployed code)
Nov 2011       Document on new RRTYPE or revised RRTYPE handling for
                    alias to IESG
Nov 2011       Document on in-zone metadata for aliases to IESG
Nov 2011       Document on uses and limitations of different alias
                    techniques to IESG

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From violeta.cakulev@alcatel-lucent.com  Tue Nov 23 11:15:09 2010
Return-Path: <violeta.cakulev@alcatel-lucent.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 DC81F3A69B0; Tue, 23 Nov 2010 11:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 Zg+GQPNWa9T0; Tue, 23 Nov 2010 11:14:58 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 4EA963A69AB; Tue, 23 Nov 2010 11:14:57 -0800 (PST)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id oANJFsMA011069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Nov 2010 13:15:55 -0600 (CST)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id oANJFrww013846 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 23 Nov 2010 13:15:54 -0600
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.119]) by USNAVSXCHHUB02.ndc.alcatel-lucent.com ([135.3.39.111]) with mapi; Tue, 23 Nov 2010 13:15:53 -0600
From: "Cakulev, Violeta (Violeta)" <violeta.cakulev@alcatel-lucent.com>
To: Glen Zorn <gwz@net-zen.net>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "Sundaram, Ganapathy S (Ganesh)" <ganesh.sundaram@alcatel-lucent.com>, "'Tim Polk'" <william.polk@nist.gov>
Date: Tue, 23 Nov 2010 13:15:52 -0600
Thread-Topic: secdir review of draft-cakulev-mikey-ibake-02
Thread-Index: ActaOFVRLTmiVrU2Qw28WkPSr1be4AwKeloQ
Message-ID: <AAE76B481E7A0E4C96610790A852B9A62508045DBF@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <002801cb5a38$5db4f5c0$191ee140$@net>
In-Reply-To: <002801cb5a38$5db4f5c0$191ee140$@net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_AAE76B481E7A0E4C96610790A852B9A62508045DBFUSNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
X-Mailman-Approved-At: Tue, 23 Nov 2010 11:21:18 -0800
Subject: Re: [secdir] secdir review of draft-cakulev-mikey-ibake-02
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: Tue, 23 Nov 2010 19:15:10 -0000

--_000_AAE76B481E7A0E4C96610790A852B9A62508045DBFUSNAVSXCHMBSA_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Glen,
Thanks for the comments.
Please see inline ([VC]).

-Violeta

________________________________
From: Glen Zorn [mailto:gwz@net-zen.net]
Sent: Wednesday, September 22, 2010 5:27 AM
To: iesg@ietf.org; secdir@ietf.org; Cakulev, Violeta (Violeta); Sundaram, G=
anapathy S (Ganesh); 'Tim Polk'
Subject: secdir review of draft-cakulev-mikey-ibake-02


I have reviewed this document as part of the security directorate's ongoing=
 effort to review all IETF documents being processed by the IESG.  These co=
mments were written primarily for the benefit of the Security Area director=
s.  Document editors and WG chairs should treat these comments just like an=
y other last call comments.



Editorial Comments


General

*         Articles are missing in a large number of places (too many to spe=
cify and correct one-by-one here).  For example, "The REQUEST_KEY_INIT mess=
age includes Initiator's public identity" which should, presupposing that "=
Initiator" is not a proper noun, read  "The REQUEST_KEY_INIT message includ=
es the Initiator's public identity".  Other examples are given below; pleas=
e correct.

Abstract

*         s/relies on trusted key management service/relies on a trusted ke=
y management service/
[VC]  Changed as suggested.

Section 1
Paragraph 1

*         s/Multimedia Internet Keying (MIKEY) [RFC3830] specification/The =
Multimedia Internet Keying (MIKEY) [RFC3830] specification/

*         The last sentence doesn't make a lot of sense to me; suggest chan=
ging "Following MIKEY specification, multiple  extensions of MIKEY have bee=
n specified such as [RFC4650] and  [RFC4738]." to "Multiple extensions of M=
IKEY have been defined, such as HMAC-Authenticated Diffie-Hellman [RFC4650]=
 and MIKEY-RSA-R [RFC4738]."
[VC] Changed as suggested.
Paragraph 2

*         s/key management services will have to be online/such key managem=
ent services would have to be online/

*         The statement that "In some applications, this architecture creat=
es a huge burden on operators to install, and manage these boxes." seems to=
 be unnecessarily evangelistic; suggest deleting it.

*         I don't know what "operational discomfort on the part of end-user=
s" means.
[VC] Changed as suggested. "operational discomfort on the part of end-users=
" is deleted.
Paragraph 3

*         Suggest changing the first sentence to read "This document descri=
bes a solution in which the KMS are provided by low availability..."

*         s/identity based/identity-based/

*         s/in the date field, is/in the date field is/

*         Suggest changing "for a whole month (more generally subscription =
cycle) at the beginning of a subscription cycle." to "for a whole subscript=
ion cycle at the beginning of the cycle."
[VC] Changed as suggested.


Section 2

*         It's not clear why "Definitions and Notation" and "Abbreviations"=
 are sub-sections of "Requirements notation".   Suggest that Section 2 be r=
e-titled as "Terminology", with "Requirements Language", "Definitions and N=
otation" and "Abbreviations" as sub-sections.

*         s/IBE framework is defined in/The IBE framework is defined in/

*         I'm continually amazed by the apparent inability of people who pr=
esumably work with objects and pointers thereto to distinguish between a re=
ference and the document to which it refers.  [RFC5091] is a pointer; it do=
es not define anything, let alone the IBE framework.

*         s/Identity Based/Identity-based/g

*         Add definitions of TGK and TEK to the list of abbreviations.
[VC] Changed as suggested.

Section 3.2

*         It's not clear that "call" and "session" are the same thing.  Sug=
gest changing "redirect the call to a different destination" to "redirect t=
he session to a different destination" for the sake of clarity and consiste=
ncy.

*         The acronym "IMS" is used w/o being previously defined; suggest a=
dding an entry for IMS to the "Abbreviations" section.
[VC] Changed as suggested. References to IMS are deleted.

Section 4.1

*         In the second paragraph, "Key Management Services" is plural but =
seems to generally referred to in the singular.  As an example, how should =
one read "KMSs"? "Key Management Serviceses"?  Suggest s/Key Management Ser=
vices/Key Management Service/G

*         Correct grammar: Change "The Initiator and the Responder do not s=
hare any credentials, however the Initiator knows Responder's public identi=
ty.  Below, description of how private keys are obtained using MIKEY messag=
es is provided.  Alternative way" to "The Initiator and Responder do not sh=
are any credentials; however, the Initiator knows the Responder's public id=
entity.  Below, a description of how private keys are obtained using MIKEY =
messages is provided.  An alternative way"
[VC] Changed as suggested.

Section 4.2.1

*         In the first paragraph, s/the user have pre-shared credentials/th=
e user has pre-shared credentials
[VC] Changed as suggested.

Section 4.2.1.1.1

*         s/[RFC3830] Section 4.1.4/Section 4.1.4 of RFC 3830/
[VC] Changed as suggested.

Section 4.2.1.1.2

*         The first sentence makes no sense.

*         In the second paragraph, s/PKE payload/The PKE payload/
[VC] The first sentence is modified.

Section 4.2.1.2

*         The second sentence of the first paragraph says "In case of a REQ=
UEST_KEY_INIT_PKE message, the KMS MUST ensure that the IDcert is equal to =
the identity specified in the certificate."  My guess is that IDcert should=
 actually be IDRi here, since IDcert occurs nowhere else in the draft.
[VC] Changes are reflected in the latest version of the I-D.

Section 4.2.2

*         s/key mode ,/key mode,/
[VC] Changed as suggested.


Technical Comments

General

*         The fourth paragraph of Section 4.1 (and elsewhere) says 'If the =
Initiator is authorized to make the request' but the criteria for this auth=
orization decision don't seem to be specified anywhere in the document.  Si=
nce this decision is vital to the successful operation of the protocol, I t=
hink it would be nice if the authors gave readers a clue as to how to go ab=
out making it.
[VC] Figure 4 is added to clarify trust relation assumed in the I-D. Trust =
relation between a user and the KMS is pre-established and is out of scope =
of this document. Modifications are made throughout the text to address thi=
s comment elsewhere in the I-D.

Section 4.1

*         The first sentence of paragraph 4 contains rather confusing notat=
ion.  It says "The Initiator next chooses a random x and computes xP (i.e. =
adds P to itself x times), where P is a point on elliptic curve E known to =
all users."  The notation "xP" is a conventional one for expressing the mul=
tiplication of P by x, which is not the same as the addition of P to itself=
 x times.  If the latter interpretation is actually, I think that a better =
notation should be chosen.
[VC] Currently, , there is no notation that is common across I-Ds and RFCs =
for elliptic curve point multiplication. Therefore, the intent was to defin=
e it in that one sentence. Nevertheless, to clarify the notation and text, =
point multiplication is denoted as [x]P in the latest version of the I-D, a=
nd this notation is added in Section 2.

Section 4.2.1.1

*         The last sentence says "The KEMAC payload SHOULD be used only whe=
n the user needs to use specific keys.  Otherwise, this payload SHALL not b=
e used."  This appears to be self-contradictory, since "SHOULD" allows the =
usage under certain circumstances while "SHALL NOT" (note typo) absolutely =
forbids it.
[VC] Good point. Fixed in the latest version

Section 4.2.1.2

*         The last paragraph says "If the KMS cannot correctly parse the re=
ceived message, or the user is not authorized to receive the requested Priv=
ate Keys, the KMS SHOULD send an appropriate Error message."  I'm assuming =
that the term "Error message" here is referring to the Error payload define=
d in section 6.12 of RFC 3830, but I don't see any Error no values therein =
that seem appropriate for either of the listed conditions.
[VC] Error message here actually refers to error message defined in Section=
 5.1.2 of RFC 3830. Nevertheless, the text is modified to address the first=
 technical comment.


--_000_AAE76B481E7A0E4C96610790A852B9A62508045DBFUSNAVSXCHMBSA_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:m =3D=20
"http://schemas.microsoft.com/office/2004/12/omml"><HEAD>
<META content=3D"text/html; charset=3Dus-ascii" http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18702">
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: Cambria Math;
}
@font-face {
	font-family: Cambria;
}
@font-face {
	font-family: Calibri;
}
@font-face {
	font-family: Consolas;
}
@page WordSection1 {size: 8.5in 11.0in; margin: 1.0in 1.0in 1.0in 1.0in; }
P.MsoNormal {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
LI.MsoNormal {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
DIV.MsoNormal {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE: 11pt
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; mso-style-priority: 99
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; mso-style-priority: 99
}
P.MsoPlainText {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: Consolas; FONT-SIZE: 10.5pt; mso-style-p=
riority: 99; mso-style-link: "Plain Text Char"
}
LI.MsoPlainText {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: Consolas; FONT-SIZE: 10.5pt; mso-style-p=
riority: 99; mso-style-link: "Plain Text Char"
}
DIV.MsoPlainText {
	MARGIN: 0in 0in 0pt; FONT-FAMILY: Consolas; FONT-SIZE: 10.5pt; mso-style-p=
riority: 99; mso-style-link: "Plain Text Char"
}
P.MsoListParagraph {
	MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE:=
 11pt; mso-style-priority: 34
}
LI.MsoListParagraph {
	MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE:=
 11pt; mso-style-priority: 34
}
DIV.MsoListParagraph {
	MARGIN: 0in 0in 0pt 0.5in; FONT-FAMILY: "Calibri","sans-serif"; FONT-SIZE:=
 11pt; mso-style-priority: 34
}
SPAN.PlainTextChar {
	FONT-FAMILY: Consolas; mso-style-priority: 99; mso-style-link: "Plain Text=
"; mso-style-name: "Plain Text Char"
}
SPAN.EmailStyle20 {
	FONT-FAMILY: "Calibri","sans-serif"; mso-style-type: personal-compose
}
.MsoChpDefault {
	FONT-SIZE: 10pt; mso-style-type: export-only
}
DIV.WordSection1 {
	page: WordSection1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]--></HEAD>
<BODY lang=3DEN-US link=3Dblue vLink=3Dpurple>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D461072816-22112010><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial>Glen,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D461072816-22112010><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial>Thanks for the comments.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D461072816-22112010><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial>Please see inline ([VC]).</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D461072816-22112010><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D461072816-22112010><FONT color=3D=
#0000ff=20
size=3D2 face=3DArial>-Violeta</FONT></SPAN></DIV><BR>
<BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px" dir=3Dltr>
  <DIV dir=3Dltr lang=3Den-us class=3DOutlookMessageHeader align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT size=3D2 face=3DTahoma><B>From:</B> Glen Zorn [mailto:gwz@net-zen.n=
et]=20
  <BR><B>Sent:</B> Wednesday, September 22, 2010 5:27 AM<BR><B>To:</B>=20
  iesg@ietf.org; secdir@ietf.org; Cakulev, Violeta (Violeta); Sundaram,=20
  Ganapathy S (Ganesh); 'Tim Polk'<BR><B>Subject:</B> secdir review of=20
  draft-cakulev-mikey-ibake-02<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DWordSection1>
  <P class=3DMsoPlainText><SPAN style=3D"FONT-FAMILY: 'Calibri','sans-serif=
'">I have=20
  reviewed this document as part of the security directorate's ongoing effo=
rt to=20
  review all IETF documents being processed by the IESG.&nbsp; These commen=
ts=20
  were written primarily for the benefit of the Security Area directors.&nb=
sp;=20
  Document editors and WG chairs should treat these comments just like any =
other=20
  last call comments.<o:p></o:p></SPAN></P>
  <P class=3DMsoPlainText><SPAN=20
  style=3D"FONT-FAMILY: 'Calibri','sans-serif'"><o:p>&nbsp;</o:p></SPAN></P=
>
  <P class=3DMsoPlainText><B><U><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'">Editorial=20
  Comments<o:p></o:p></SPAN></U></B></P>
  <P class=3DMsoPlainText><B><U><o:p><SPAN=20
  style=3D"TEXT-DECORATION: none">&nbsp;</SPAN></o:p></U></B></P>
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'">General<o:p></o:p></SPAN></B></P=
>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l10 level1 lfo2"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'">Articles are missing in a large =
number=20
  of places (too many to specify and correct one-by-one here).&nbsp; For=20
  example<B>, &#8220;</B>The REQUEST_KEY_INIT message includes Initiator&#8=
217;s public=20
  identity&#8221; which should, presupposing that &#8220;Initiator&#8221; i=
s not a proper noun,=20
  read <B>&nbsp;&#8220;</B>The REQUEST_KEY_INIT message includes <U>the</U>=
=20
  Initiator&#8217;s public identity&#8221;.&nbsp; Other examples are given =
below; please=20
  correct.<B><o:p></o:p></B></SPAN></P>
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p>&nbsp;</o:p></SPAN></B></P>
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'">Abstract</SPAN></B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p></o:p></SPAN></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l4 level1 lfo4"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>s/<SPAN style=3D"FONT-SIZE: 10pt">relies o=
n=20
  trusted key management service/relies on a trusted key management=20
  service/<BR><SPAN class=3D461072816-22112010><FONT color=3D#0000ff=20
  face=3DArial>[VC]&nbsp;&nbsp;Changed as suggested.</FONT></SPAN></SPAN></=
P>
  <P class=3DMsoNormal><B><U><o:p><SPAN=20
  style=3D"TEXT-DECORATION: none">&nbsp;</SPAN></o:p></U></B></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  1<o:p></o:p></SPAN></B></P>
  <P style=3D"MARGIN-LEFT: 0.25in" class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'">Paragraph 1<o:p></o:p></SPAN></B=
></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l4 level1 lfo4"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>s/<SPAN style=3D"FONT-SIZE: 10pt">Multimed=
ia=20
  Internet Keying (MIKEY) [RFC3830] specification/The Multimedia Internet K=
eying=20
  (MIKEY) [RFC3830] specification/</SPAN><o:p></o:p></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l4 level1 lfo4"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]><SPAN style=3D"FONT-SIZE: 10pt">The last s=
entence=20
  doesn&#8217;t make a lot of sense to me; suggest changing &#8220;Followin=
g MIKEY=20
  specification, multiple&nbsp; extensions of MIKEY have been specified suc=
h as=20
  [RFC4650] and&nbsp; [RFC4738].&#8221; to &#8220;Multiple extensions of MI=
KEY have been=20
  defined, such as HMAC-Authenticated Diffie-Hellman [RFC4650] and MIKEY-RS=
A-R=20
  [RFC4738].&#8221;<BR><SPAN class=3D461072816-22112010><FONT color=3D#0000=
ff=20
  face=3DArial>[VC] Changed as=20
  suggested.&nbsp;&nbsp;</FONT></SPAN></SPAN><o:p></o:p></P>
  <P style=3D"MARGIN-LEFT: 0.25in" class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'">Paragraph 2<o:p></o:p></SPAN></B=
></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo6"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>s/<SPAN style=3D"FONT-SIZE: 10pt">key mana=
gement=20
  services will have to be online/such key management services would have t=
o be=20
  online/</SPAN><o:p></o:p></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo6"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]><SPAN style=3D"FONT-SIZE: 10pt">The statem=
ent=20
  that &#8220;In some applications, this architecture creates a huge burden=
 on=20
  operators to install, and manage these boxes.&#8221; seems to be unnecess=
arily=20
  evangelistic; suggest deleting it.</SPAN><o:p></o:p></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l0 level1 lfo6"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol; FONT-SIZE: 10pt"><SPAN=20
  style=3D"mso-list: Ignore">&middot;<SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]><SPAN style=3D"FONT-SIZE: 10pt">I don&#821=
7;t know what=20
  &#8220;operational discomfort on the part of end-users&#8221; means.<BR><=
SPAN=20
  class=3D461072816-22112010><FONT color=3D#0000ff face=3DArial>[VC] Change=
d as=20
  suggested. <FONT color=3D#000000 face=3DCalibri>&#8220;operational discom=
fort on the=20
  part of end-users&#8221; </FONT>is deleted.=20
  &nbsp;&nbsp;</FONT></SPAN><o:p></o:p></SPAN></P>
  <P style=3D"MARGIN-LEFT: 0.25in" class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'">Paragraph 3<o:p></o:p></SPAN></B=
></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l7 level1 lfo8"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>Suggest changing the first sentence to rea=
d=20
  &#8220;This document describes a solution in which the KMS are provided b=
y low=20
  availability&#8230;&#8221;<o:p></o:p></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l7 level1 lfo8"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>s/identity based/identity-based/<o:p></o:p=
></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l7 level1 lfo8"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>s/in the date field, is/in the date field=
=20
  is/<o:p></o:p></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l7 level1 lfo8"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>Suggest changing &#8220;for a whole month =
(more=20
  generally subscription cycle) at the beginning of a subscription cycle.&#=
8221; to=20
  &#8220;for a whole subscription cycle at the beginning of the cycle.&#822=
1;<BR><SPAN=20
  class=3D461072816-22112010><FONT color=3D#0000ff size=3D2 face=3DArial>[V=
C] Changed as=20
  suggested.&nbsp;&nbsp;</FONT></SPAN><o:p></o:p></P>
  <P class=3DMsoListParagraph><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  2<o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l11 level1 lfo10"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>It&#8217;s not clear why &#8220;Definition=
s and Notation&#8221;=20
  and &#8220;Abbreviations&#8221; are sub-sections of &#8220;Requirements n=
otation&#8221;.&nbsp;&nbsp;=20
  Suggest that Section 2 be re-titled as &#8220;Terminology&#8221;, with &#=
8220;Requirements=20
  Language&#8221;, &#8220;Definitions and Notation&#8221; and &#8220;Abbrev=
iations&#8221; as=20
  sub-sections.<B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l11 level1 lfo10"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>s/IBE framework is defined in/The IBE fram=
ework=20
  is defined in/<B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l11 level1 lfo10"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>I&#8217;m continually amazed by the appare=
nt=20
  inability of people who presumably work with objects and pointers thereto=
 to=20
  distinguish between a reference and the document to which it refers.&nbsp=
;=20
  [RFC5091] is a <I>pointer</I>; it does not define anything, let alone the=
 IBE=20
  framework.<B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l11 level1 lfo10"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>s/Identity Based/Identity-based/g<B><SPAN=
=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l11 level1 lfo10"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>Add definitions of TGK and TEK to the list=
 of=20
  abbreviations.<BR><SPAN class=3D461072816-22112010><FONT color=3D#0000ff =
size=3D2=20
  face=3DArial>[VC] Changed as suggested.&nbsp;&nbsp;</FONT></SPAN><B><SPAN=
=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p></o:p></SPAN></B></P>
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p>&nbsp;</o:p></SPAN></B></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  3.2<o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l8 level1 lfo12"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>It&#8217;s not clear that &#8220;call&#822=
1; and &#8220;session&#8221; are=20
  the same thing.&nbsp; Suggest changing &#8220;redirect the call to a diff=
erent=20
  destination&#8221; to &#8220;redirect the session to a different destinat=
ion&#8221; for the sake=20
  of clarity and consistency.<o:p></o:p></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l8 level1 lfo12"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>The acronym &#8220;IMS&#8221; is used w/o =
being previously=20
  defined; suggest adding an entry for IMS to the &#8220;Abbreviations&#822=
1;=20
  section.<BR><SPAN class=3D461072816-22112010><FONT color=3D#0000ff size=
=3D2=20
  face=3DArial>[VC] Changed as suggested.&nbsp;References to IMS are delete=
d.=20
  &nbsp;&nbsp;</FONT></SPAN><o:p></o:p></P>
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p>&nbsp;</o:p></SPAN></B></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  4.1<o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l5 level1 lfo14"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>In the second paragraph, &#8220;Key Manage=
ment=20
  Services&#8221; is plural but seems to generally referred to in the singu=
lar.&nbsp;=20
  As an example, how should one read &#8220;KMSs&#8221;? &#8220;Key Managem=
ent Serviceses&#8221;?&nbsp;=20
  Suggest s/Key Management Services/Key Management Service/G<o:p></o:p></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l5 level1 lfo14"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>Correct grammar: Change &#8220;The Initiat=
or and the=20
  Responder do not share any credentials, however the Initiator knows=20
  Responder's public identity.&nbsp; Below, description of how private keys=
 are=20
  obtained using MIKEY messages is provided.&nbsp; Alternative way&#8221; t=
o &#8220;The=20
  Initiator and Responder do not share any credentials; however, the Initia=
tor=20
  knows the Responder's public identity.&nbsp; Below, a description of how=
=20
  private keys are obtained using MIKEY messages is provided.&nbsp; An=20
  alternative way&#8221; <BR><SPAN class=3D461072816-22112010><FONT color=
=3D#0000ff size=3D2=20
  face=3DArial>[VC] Changed as=20
  suggested.&nbsp;&nbsp;&nbsp;</FONT></SPAN><o:p></o:p></P>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  4.2.1<o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l6 level1 lfo17"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>In the first paragraph, s/the user have=20
  pre-shared credentials/the user has pre-shared credentials<BR><SPAN=20
  class=3D461072816-22112010><FONT color=3D#0000ff size=3D2 face=3DArial>[V=
C] Changed as=20
  suggested.&nbsp;&nbsp;&nbsp;</FONT></SPAN><o:p></o:p></P>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  4.2.1.1.1<o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l6 level1 lfo17"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>s/[RFC3830] Section 4.1.4/Section 4.1.4 of=
 RFC=20
  3830/<BR><SPAN class=3D461072816-22112010><FONT color=3D#0000ff size=3D2=
=20
  face=3DArial>[VC] Changed as=20
  suggested.&nbsp;&nbsp;&nbsp;</FONT></SPAN><o:p></o:p></P>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  4.2.1.1.2<o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l6 level1 lfo17"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>The first sentence makes no=20
  sense.<o:p></o:p></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l6 level1 lfo17"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>In the second paragraph, s/PKE payload/The=
 PKE=20
  payload/<BR><SPAN class=3D461072816-22112010><FONT color=3D#0000ff size=
=3D2=20
  face=3DArial>[VC] The first sentence is modified.=20
  &nbsp;&nbsp;</FONT></SPAN><o:p></o:p></P>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  4.2.1.2<o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l12 level1 lfo20"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>The second sentence of the first paragraph=
 says=20
  &#8220;In case of a REQUEST_KEY_INIT_PKE message, the KMS MUST ensure tha=
t the=20
  IDcert is equal to the identity specified in the certificate.&#8221;&nbsp=
; My guess=20
  is that IDcert should actually be IDRi here, since IDcert occurs nowhere =
else=20
  in the draft.<BR><SPAN class=3D461072816-22112010><FONT color=3D#0000ff s=
ize=3D2=20
  face=3DArial>[VC] Changes are reflected in the latest version of the I-D.=
=20
  &nbsp;&nbsp;</FONT></SPAN><o:p></o:p></P>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  4.2.2<o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l3 level1 lfo19"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>s/key mode ,/key mode,/<BR><SPAN=20
  class=3D461072816-22112010><FONT color=3D#0000ff size=3D2 face=3DArial>[V=
C] Changed as=20
  suggested.&nbsp;&nbsp;</FONT></SPAN><o:p></o:p></P>
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p>&nbsp;</o:p></SPAN></B></P>
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p>&nbsp;</o:p></SPAN></B></P>
  <P class=3DMsoNormal><B><U><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'">Technical=20
  Comments<o:p></o:p></SPAN></U></B></P>
  <P class=3DMsoNormal><B><U><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'"><o:p><SPAN=20
  style=3D"TEXT-DECORATION: none">&nbsp;</SPAN></o:p></SPAN></U></B></P>
  <P class=3DMsoNormal><B><SPAN=20
  style=3D"FONT-FAMILY: 'Cambria','serif'">General<o:p></o:p></SPAN></B></P=
>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l1 level1 lfo16"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>The fourth paragraph of Section 4.1 (and=20
  elsewhere) says &#8216;If the Initiator is authorized to make the request=
&#8217; but the=20
  criteria for this authorization decision don&#8217;t seem to be specified=
 anywhere=20
  in the document.&nbsp; Since this decision is vital to the successful=20
  operation of the protocol, I think it would be nice if the authors gave=20
  readers a clue as to how to go about making it.&nbsp; <BR><SPAN=20
  class=3D461072816-22112010><FONT color=3D#0000ff size=3D2 face=3DArial>[V=
C] Figure 4=20
  is added to clarify trust relation assumed in the I-D. Trust relation bet=
ween=20
  a user and the KMS is pre-established and is out of scope of this=20
  document.&nbsp;Modifications are made throughout the text to address this=
=20
  comment elsewhere in the I-D. </FONT></SPAN></P>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  4.1<o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l1 level1 lfo16"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>The first sentence of paragraph 4 contains=
=20
  rather confusing notation.&nbsp; It says &#8220;The Initiator next choose=
s a random=20
  x and computes xP (i.e. adds P to itself x times), where P is a point on=
=20
  elliptic curve E known to all users.&#8221;&nbsp; The notation &#8220;xP&=
#8221; is a=20
  conventional one for expressing the multiplication of P by x, which is no=
t the=20
  same as the addition of P to itself x times.&nbsp; If the latter=20
  interpretation is actually, I think that a better notation should be=20
  chosen.<BR><SPAN class=3D461072816-22112010><FONT color=3D#0000ff size=3D=
2=20
  face=3DArial>[VC] Currently, <SPAN=20
  style=3D"FONT-FAMILY: Calibri; FONT-SIZE: 11pt; mso-fareast-font-family: =
SimSun; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">,=20
  there is no notation that is common across I-Ds and RFCs for elliptic cur=
ve=20
  point multiplication. Therefore, the intent was to define it in that one=
=20
  sentence. Nevertheless, to clarify the notation and text, point multiplic=
ation=20
  is denoted as [x]P in the latest version of the I-D, and this notation is=
=20
  added in Section 2.&nbsp;</SPAN>&nbsp;&nbsp;</FONT></SPAN><o:p></o:p></P>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  4.2.1.1<o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l3 level1 lfo19"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>The last sentence says &#8220;The KEMAC pa=
yload=20
  SHOULD be used only when the user needs to use specific keys.&nbsp; Other=
wise,=20
  this payload SHALL not be used.&#8221;&nbsp; This appears to be self-cont=
radictory,=20
  since &#8220;SHOULD&#8221; allows the usage under certain circumstances w=
hile &#8220;SHALL NOT&#8221;=20
  (note typo) absolutely forbids it.<BR><SPAN class=3D461072816-22112010><F=
ONT=20
  color=3D#0000ff size=3D2 face=3DArial>[VC] <SPAN=20
  style=3D"FONT-FAMILY: Calibri; FONT-SIZE: 11pt; mso-fareast-font-family: =
SimSun; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">Good=20
  point. Fixed in the&nbsp;latest=20
  version</SPAN>&nbsp;&nbsp;</FONT></SPAN><o:p></o:p></P>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P>
  <P class=3DMsoNormal><B><SPAN style=3D"FONT-FAMILY: 'Cambria','serif'">Se=
ction=20
  4.2.1.2<o:p></o:p></SPAN></B></P>
  <P style=3D"TEXT-INDENT: -0.25in; mso-list: l3 level1 lfo19"=20
  class=3DMsoListParagraph><![if !supportLists]><SPAN=20
  style=3D"FONT-FAMILY: Symbol"><SPAN style=3D"mso-list: Ignore">&middot;<S=
PAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  </SPAN></SPAN></SPAN><![endif]>The last paragraph says &#8220;If the KMS =
cannot=20
  correctly parse the received message, or the user is not authorized to re=
ceive=20
  the requested Private Keys, the KMS SHOULD send an appropriate Error=20
  message.&#8221;&nbsp; I&#8217;m assuming that the term &#8220;Error messa=
ge&#8221; here is referring=20
  to the Error payload defined in section 6.12 of RFC 3830, but I don&#8217=
;t see any=20
  Error no values therein that seem appropriate for either of the listed=20
  conditions. <BR><SPAN class=3D461072816-22112010><FONT color=3D#0000ff si=
ze=3D2=20
  face=3DArial>[VC] <SPAN=20
  style=3D"FONT-FAMILY: Calibri; FONT-SIZE: 11pt; mso-fareast-font-family: =
SimSun; mso-bidi-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA"><FONT=20
  color=3D#000000><FONT color=3D#0000ff>Error message here actually refers =
to error=20
  message defined in Section 5.1.2 of RFC 3830. Nevertheless, the text is=20
  modified to address the first technical=20
  comment.</FONT>&nbsp;</FONT></SPAN>&nbsp;&nbsp;</FONT></SPAN><o:p></o:p><=
/P>
  <P class=3DMsoNormal><o:p>&nbsp;</o:p></P></DIV></BLOCKQUOTE></BODY></HTM=
L>

--_000_AAE76B481E7A0E4C96610790A852B9A62508045DBFUSNAVSXCHMBSA_--

From CWallace@cygnacom.com  Wed Nov 24 10:58:18 2010
Return-Path: <CWallace@cygnacom.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 94B4C3A697E; Wed, 24 Nov 2010 10:58:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 1C2BKkJkC6Fc; Wed, 24 Nov 2010 10:58:17 -0800 (PST)
Received: from mail75.messagelabs.com (mail75.messagelabs.com [216.82.250.3]) by core3.amsl.com (Postfix) with SMTP id 28E1A3A6944; Wed, 24 Nov 2010 10:58:17 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: CWallace@cygnacom.com
X-Msg-Ref: server-8.tower-75.messagelabs.com!1290625155!106478554!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [65.242.48.8]
Received: (qmail 18452 invoked from network); 24 Nov 2010 18:59:16 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.8) by server-8.tower-75.messagelabs.com with SMTP; 24 Nov 2010 18:59:16 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB8C09.B021AA0B"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 24 Nov 2010 13:59:13 -0500
Message-ID: <FAD1CF17F2A45B43ADE04E140BA83D48011D49ED@scygexch1.cygnacom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secdir review of draft-ietf-dime-rfc3588bis-25
Thread-Index: AcuMCUtS7iwykT0kT0GDC8IqMHmmbQ==
From: "Carl Wallace" <CWallace@cygnacom.com>
To: <secdir@ietf.org>, <iesg@ietf.org>, <ietf@ietf.org>
Cc: john.loughney@nokia.com, vf0213@gmail.com, jari.arkko@ericsson.com
Subject: [secdir] secdir review of draft-ietf-dime-rfc3588bis-25
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: Wed, 24 Nov 2010 18:58:18 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CB8C09.B021AA0B
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

=20

This is a fairly long document and my review has been conducted in
chunks, answers to some of the questions may be apparent on a subsequent
reading.  My primary concern is with authorization of nodes.  Comments,
questions and a few nits are below:

=20

- Section 2.1 should state TLS usage requires mutual authentication.  At
present, this is not mentioned until section 13.

=20

- In 2.6, there appears to be a stray sentence fragment: "Additional
security information, when needed (e.g., keys, certificates)".  Suggest
adding a sentence two beneath if this is another item in the list.

=20

- In section 2.9, authorization checks are mandated but no mechanisms
are defined.  How is authorization performed?  Is this related to the
authorization checks described in 2.9?=20

=20

- What does this mean: "the domain name in the SRV query and the domain
name in the target in the SRV record MUST both be valid based on the
same site certificate"?

=20

- Should expand CA acronym in 5.2. =20

=20

- In 5.2, including OIDs in a certificate is not a useful authorization
mechanism unless those values are processed across the path from the
trust anchor to the server certificate (or there are some restrictions
on the nature of the path or trust anchor store).  What OIDs are meant
here, extended key usage or certificate policy OIDs? =20

=20

- In 13.2, Are trust anchor stores per realm?  If not how will relays be
able to determine how to use authorization information?

=20

- May want to reference RFC 5280 to ensure full path validation
(including revocation status determination) is performed.

=20

- In 5.1, the first bullet correlates to the state table in section 5.6.
The second bullet does not.  Should it?

=20

- Is the deprecation in 6.10 worth a SHOULD NOT?

=20

- The security considerations should include some words describing the
consequences of inappropriately authenticating or authorizing a diameter
node. =20

=20

- Should relays, agents etc. be required to authenticate to clients with
the same identity used to authenticate to servers? =20


------_=_NextPart_001_01CB8C09.B021AA0B
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta =
http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DEN-US link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoPlainText>I have =
reviewed this document as part of the security directorate's ongoing =
effort to review all IETF documents being processed by the IESG.&nbsp; =
These comments were written primarily for the benefit of the security =
area directors.&nbsp; Document editors and WG chairs should treat these =
comments just like any other last call comments.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>This is a =
fairly long document and my review has been conducted in chunks, answers =
to some of the questions may be apparent on a subsequent reading.&nbsp; =
My primary concern is with authorization of nodes.&nbsp; Comments, =
questions and a few nits are below:<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>- Section =
2.1 should state TLS usage requires mutual authentication.&nbsp; At =
present, this is not mentioned until section 13.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>- In 2.6, =
there appears to be a stray sentence fragment: &quot;Additional security =
information, when needed (e.g., keys, certificates)&quot;.&nbsp; Suggest =
adding a sentence two beneath if this is another item in the =
list.<o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>- In section 2.9, authorization checks are mandated =
but no mechanisms are defined.&nbsp; How is authorization =
performed?&nbsp; Is this related to the authorization checks described =
in 2.9? <o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>- What does this mean: &quot;the domain name in the =
SRV query and the domain name in the target in the SRV record MUST both =
be valid based on the same site certificate&quot;?<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>- Should =
expand CA acronym in 5.2.&nbsp; <o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>- In 5.2, =
including OIDs in a certificate is not a useful authorization mechanism =
unless those values are processed across the path from the trust anchor =
to the server certificate (or there are some restrictions on the nature =
of the path or trust anchor store).&nbsp; What OIDs are meant here, =
extended key usage or certificate policy OIDs?&nbsp; <o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>- In 13.2, =
Are trust anchor stores per realm?&nbsp; If not how will relays be able =
to determine how to use authorization information?<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>- May want =
to reference RFC 5280 to ensure full path validation (including =
revocation status determination) is performed.<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>- In 5.1, =
the first bullet correlates to the state table in section 5.6.&nbsp; The =
second bullet does not.&nbsp; Should it?<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>- Is the =
deprecation in 6.10 worth a SHOULD NOT?<o:p></o:p></p><p =
class=3DMsoNormal><o:p>&nbsp;</o:p></p><p class=3DMsoNormal>- The =
security considerations should include some words describing the =
consequences of inappropriately authenticating or authorizing a diameter =
node.&nbsp; <o:p></o:p></p><p class=3DMsoNormal><o:p>&nbsp;</o:p></p><p =
class=3DMsoNormal>- Should relays, agents etc. be required to =
authenticate to clients with the same identity used to authenticate to =
servers?&nbsp; <o:p></o:p></p></div></body></html>
------_=_NextPart_001_01CB8C09.B021AA0B--

From new-work-bounces@ietf.org  Wed Nov 24 15:30:56 2010
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B38E28C1BD; Wed, 24 Nov 2010 15:30:56 -0800 (PST)
X-Original-To: new-work@core3.amsl.com
Delivered-To: new-work@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8DB28C175 for <new-work@core3.amsl.com>; Wed, 24 Nov 2010 15:30:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 UaXYTpbCj7wC for <new-work@core3.amsl.com>; Wed, 24 Nov 2010 15:30:42 -0800 (PST)
Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 3925628C1EF for <new-work@ietf.org>; Wed, 24 Nov 2010 15:30:28 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from <ij@w3.org>) id 1PLOo2-0002iK-O7; Wed, 24 Nov 2010 18:31:18 -0500
Message-Id: <8EAE40E8-5CD7-4C5D-A755-27FF387BCD74@w3.org>
From: Ian Jacobs <ij@w3.org>
To: new-work@ietf.org
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 24 Nov 2010 17:31:18 -0600
X-Mailer: Apple Mail (2.936)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Mon, 29 Nov 2010 05:42:23 -0800
Subject: [secdir] [new-work] Proposed W3C Charter: Web and TV Interest Group (until	2010-12-31)
X-BeenThere: secdir@ietf.org
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: Wed, 24 Nov 2010 23:30:56 -0000

Hello,

Today W3C Advisory Committee Representatives received a Proposal to  
create a new Web and TV Activity (see the W3C Process Document  
description of Activity Proposals [1]). This proposal includes a draft  
charter for the Web and TV Interest Group:
   http://www.w3.org/2010/09/webTVIGcharter

As part of ensuring that the community is aware of proposed work at  
W3C, this draft charter is public during the Advisory Committee review  
period.

W3C invites public comments through 2010-12-31 on the proposed  
charter. Please send comments to public-new-work@w3.org, which has a  
public archive:
     http://lists.w3.org/Archives/Public/public-new-work/

Other than comments sent in formal responses by W3C Advisory Committee  
Representatives, W3C cannot guarantee a response to comments. If you  
work for a W3C Member [2], please coordinate your comments with your  
Advisory Committee Representative. For example, you may wish to make  
public comments via this list and have your Advisory Committee  
Representative refer to it from his or her formal review comments.

If you should have any questions or need further information, please  
contact Kaz Ashimura <ashimura@w3.org>.

Thank you,

Ian Jacobs, Head of W3C Communications

[1]
http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation
[2] http://www.w3.org/Consortium/Member/List
--
Ian Jacobs (ij@w3.org)    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447

_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From d3e3e3@gmail.com  Tue Nov 30 09:12:44 2010
Return-Path: <d3e3e3@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 D9B353A6BCC; Tue, 30 Nov 2010 09:12:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.483
X-Spam-Level: 
X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, 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 Jhgm6uoUvX4i; Tue, 30 Nov 2010 09:12:44 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C13813A6BD2; Tue, 30 Nov 2010 09:12:43 -0800 (PST)
Received: by wyf23 with SMTP id 23so5024166wyf.31 for <multiple recipients>; Tue, 30 Nov 2010 09:13:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=mZEN5Yu2kToyqZTwC7qXhjhB/06R3lfbIkr3imLLW80=; b=S3FXz8tInzHj0cAvPFfd/xdHMgabOOKkGzbBr1g5xl0MobhQ+rU+6pjSbFcmabggAg xOOoyyCAxp0RIleRzmYDxgAY6yQ/ZGyqXKzUOcde8vg/xShfdVYBJVEl5KxBceEdRjRj bqnX3/CQiEADNXdvlTSa4rFi8m8n8Ylk5LMco=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=GQ9mpkC8d9eKq4Whspm4D3xpfuD/Azw7s6xoHuPJZjNhuQfFGrPjS2D1oN99pO+7qN Qsr9tRKH6TkBUK/Lux+RuSR5dJ5oXBDCH7qZ1igoeF5jPpO/QZuQyZLGXL4vmZFvpcyu GeQhuD6JTCACn5OcHK5dhArz6NcpaqKxKmREQ=
MIME-Version: 1.0
Received: by 10.227.145.134 with SMTP id d6mr7985656wbv.195.1291137234913; Tue, 30 Nov 2010 09:13:54 -0800 (PST)
Received: by 10.227.153.8 with HTTP; Tue, 30 Nov 2010 09:13:54 -0800 (PST)
Date: Tue, 30 Nov 2010 12:13:54 -0500
Message-ID: <AANLkTimWr0NZtOFCrQqfvjpA0WYjRb=b-Dse3=m9ZZvo@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
To: secdir@ietf.org, IETF Discussion <ietf@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [secdir] draft-cheshire-dnsext-multicastdns-12.txt
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: Tue, 30 Nov 2010 17:12:44 -0000

I have reviewed this document as part of the Security Directorate's
ongoing effort to review all IETF documents being processed by the
IESG. Document editors and WG chairs should treat these comments just
like any other last call comments.

This Standards Track draft specifies a multicast link-local variant of
DNS. I previously reviewed the -08 version which was aimed at
Informational.

SECURITY COMMENTS:

The Security Considerations section seems reasonable for a standards
track document describing an existing link local usage. The Security
Considerations documentation suggestions in my previous review appear
to have been adopted.

OTHER COMMENTS:

The Other Comments in my previous review have been delt with to a
greater or lesser extent.

TRIVIA

All my trivia complaints in the previous review have been fixed.

I would suggest that the first word of Section 20, currently "The",
should be replaced by "A major" or "One of the" or the like.

For consistency with RFC 5395, all occurrences of "pseudo-RR" should
be replace with "meta-RR" and it would not hurt to add a reference to
RFC 5395 (or the rfc5395bis draft which is being fast tracked).

Thanks,
Donald

From new-work-bounces@ietf.org  Tue Nov 30 09:43:52 2010
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA9C83A6C20; Tue, 30 Nov 2010 09:43:51 -0800 (PST)
X-Original-To: new-work@ietf.org
Delivered-To: new-work@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id D977628C0D9; Tue, 30 Nov 2010 09:43:48 -0800 (PST)
From: IESG Secretary <iesg-secretary@ietf.org>
To: new-work@ietf.org
Mime-Version: 1.0
Message-Id: <20101130174348.D977628C0D9@core3.amsl.com>
Date: Tue, 30 Nov 2010 09:43:48 -0800 (PST)
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: new-work-bounces@ietf.org
Errors-To: new-work-bounces@ietf.org
X-Mailman-Approved-At: Tue, 30 Nov 2010 11:59:40 -0800
Subject: [secdir] [new-work] WG Review: Recharter of Ad-Hoc Network Autoconfiguration (autoconf)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
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: Tue, 30 Nov 2010 17:43:52 -0000

A modified charter has been submitted for the Ad-Hoc Network
Autoconfiguration (autoconf) working group in the Internet Area of the
IETF.  The IESG has not made any determination as yet.  The modified
charter is provided below for informational purposes only.  Please send
your comments to the IESG mailing list (iesg@ietf.org) by Tuesday,
December 7, 2010.

Ad-Hoc Network Autoconfiguration (autoconf)
-------------------------------------------
Last modified: 2010-11-30
Current Status: Active

Chairs:
  Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
  Thomas Clausen <T.Clausen@computer.org>

Internet Area Directors:
  Ralph Droms <rdroms.ietf@gmail.com>
  Jari Arkko <jari.arkko@piuha.net>

Internet Area Advisor:
  Jari Arkko <jari.arkko@piuha.net>

Mailing Lists:
  General Discussion: autoconf@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf
  Archive:
http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html

Description of Working Group:

RFC 5889 presents one possible IPv6 addressing model for ad hoc
nodes. In this model the ad hoc routers need to configure their
network interface(s) with addresses valid in the ad hoc network, and
may configure additional prefixes for use by attached nodes.

After completing the work on RFC 5889, the main purpose of the
AUTOCONF WG is to standardize how existing IPv6 address configuration
tools can be used for address configuration.

1. DHCPv6 operation over MANET, including:

- A DHCPv6-based mechanism for configuring required interface
addresses for the routers in the ad hoc network. This mechanism
is expected to produce addresses with properties outlined in RFC
5889. This mechanism uses the existing DHCPv6 protocol unchanged,
and assumes a central node that can allocate addresses on a
first-come-first-served basis. Other nodes in the ad hoc network
will relay messages to the central node in order to help a new
node get an address for itself. This mechanism is only suitable
for deployments were a central node can be set up. It should be
noted that many existing deployments employ Internet gateways
that can act as such a central node as well. Future extensions
such as central node election may make this mechanism suitable
for also for stand-alone ad hoc networks.

- A DHCPv6-based mechanism for delegating a prefix(es) to each
router for use by applications running on the routers themselves,
or for configuration of attached hosts/networks. This mechanism
works in a similar manner to the one above, but allocates
prefixes instead of addresses.

Both mechanisms should be independent from operation of any specific
MANET routing protocol, although may exploit information maintained by
such a routing protocol, if available.

The working group will adapt and/or reuse existing protocols whenever
reasonable and possible. No new duplicate address detection mechanisms
are will be specified; it is expected that address uniqueness is
guaranteed by the central node alone.

2. Analysis of Problem Space for distributed address configuration and
service discovery. This analysis is necessary in order to understand
what type of distributed solution(s) can be standardized. There is
already quite a lot of material about possible solutions in the
literature.

The working group plans to establish design teams for rapidly advancing
towards initial submissions for these two work items. The group shall
also work with the 6LOWPAN and ROLL working group to ensure that
the results from AUTOCONF working group are useful for the larger
community and do not overlap with work already in progress in these
other working groups.

Goals and Milestones:

- Jan 2011 First working group draft of the "DHCPv6 operation over 
  MANET"
- Jan 2011 First working group draft of the "Analysis of Problem Space"
- Sep 2011 Submission of the "DHCPv6 operation over MANET" to the IESG 
  for publication as BCP
- Sep 2011 Submission of the "Analysis of Problem Space" the IESG for 
  publication as Informational RFC
- Oct 2011 First working group draft of the "Distributed Solution"
- Jun 2012 Submission of the "Distributed Solution" to the IESG for 
  publication as an Proposed Standard RFC
- Jun 2012 Rechartering or Closing WG
_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work

From Nicolas.Williams@oracle.com  Tue Nov 30 13:42:27 2010
Return-Path: <Nicolas.Williams@oracle.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 E72C73A6C30; Tue, 30 Nov 2010 13:42:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.531
X-Spam-Level: 
X-Spam-Status: No, score=-6.531 tagged_above=-999 required=5 tests=[AWL=0.067,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 oRVBWaRCrIfC; Tue, 30 Nov 2010 13:42:25 -0800 (PST)
Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 3FB953A6BB4; Tue, 30 Nov 2010 13:42:25 -0800 (PST)
Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oAULhQ05025567 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Nov 2010 21:43:27 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com [141.146.40.155]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oAUGD26X030070; Tue, 30 Nov 2010 21:43:25 GMT
Received: from abhmt020.oracle.com by acsmt354.oracle.com with ESMTP id 828577751291153296; Tue, 30 Nov 2010 13:41:36 -0800
Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 30 Nov 2010 13:41:36 -0800
Date: Tue, 30 Nov 2010 15:41:31 -0600
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: secdir@ietf.org, tim.polk@nist.gov, turners@ieca.com
Message-ID: <20101130214131.GL20162@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.20 (2010-03-02)
Cc: charliep@computer.org, dbj@cs.rice.edu, iesg@ietf.org, jari.arkko@ericsson.com
Subject: [secdir] secdir review of draft-ietf-mext-rfc3775bis-10
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: Tue, 30 Nov 2010 21:42:27 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This is a rather lengthy document.  I have begun by reviewing the
introductory sections, sections 5 and 6, and the security considerations
section.  The security considerations section of this I-D is very well
written and thorough, and I believe it covers all of the threats and
risks of IPv6 mobility support, though little is said about
cryptographic aspects of the protocol, nor cryptographic algorithm
agility.  A more thorough review may follow this one.

A few comments:

 - Bibliographic reference style.

   I find references with name anchors much easier to use than numeric
   anchors.  For example, "[RFC1234]" versus "[17]", as well as named
   references for references to documents other than RFCs.  I can very
   quickly decide whether I'm familiar with a given reference or must
   look it up, and the way I read I-Ds and RFCs I can more quickly
   lookup an RFC if I don't have to first jump to the references section
   of the document I'm reading.

   This is really a personal bias of mine, thus safely ignored.  If I
   were reading HTML renderings of this document I could just click
   through the references, but even so, it helps to be able to recognize
   a reference at a glance -- that's hard to do when references are
   numbered.

 - Binding of home addresses to mobile node credentials when using
   IKEv2.

   The security considerations text suggests that it will or may be
   common for home addresses to be listed in PKIX certificates as
   subject alternative names for the purpose of enabling home address
   authorization checks.  I believe that such an authorization approach
   requires at least additional text to the effect that the certificate
   issuer must check that home addresses claimed by requestors have not
   already been handed out to others whose certificates are still live.

   Given that a database is necessary in order to authorize home
   addresses, the only question is whether that database should be
   accessibly only by CAs or also by home agents, and I find no reason
   why home agents shouldn't have read access to it.  Besides, the IPsec
   model (RFC4301) already requires a DB that can easily be extended to
   host mobile address authorization information: the SAD.  I would
   prefer text discouraging the use of certificate subject alternative
   names (or any other certificate extensions) for authorization of home
   addresses as I suspect that CAs are not really and likely never will
   be prepared to perform the home address authorization check.

 - Enrolment/assignment of home address bindings to mobile node
   credentials.

   Nothing much is said about automation of enrolment of home address
   bindings to mobile node credentials.  I see that there is work in
   progress in that space, via CGA (cryptographically-generated
   addresses).  Such work should be referenced in both, the security
   considerations and future work sections of this I-D.

   If such work is not in progress, then such work ought to be, though
   there isn't anything that can be done about that here.  A dynamic
   association protocol seems likely to be quite useful in at least some
   scenarios.

 - Hash/MAC algorithm agility.

   This protocol uses SHA-1 and HMAC-SHA-1 for the return routability
   tests (whereby a mobile node's correspondent nodes test the mobile
   node's home and care-of addresses are both routable).  Nothing is
   said about hash agility, nor about the cryptographic properties of
   SHA-1 that the protocol depends on (collision resistance? first
   pre-image resistance? 2nd pre-image resistance? pseudo-random number
   generation?).

   We (the IETF) still believe that HMAC-SHA-1 is secure, therefore I
   will ignore that question for now.

   I believe that the protocol does not depend on collision resistance,
   since to find collisions an attacker would need to see the inputs to
   the hash function, and if it could see them then there are other
   attacks the attacker could mount.  I believe the protocol also does
   not depend on any pre-image resistance...

   ...I believe the protocol depends only on SHA-1 being a PRG.  As such
   I am not sure that hash agility is at all important.  And since it
   seems to me that hash agility could easily be added in the future
   (via a "mobile option" in Home Test Init, Care Of Test Init messages
   and their replies, as well as Binding messages), I think hash
   algorithm agility is a non-issue for this protocol.  However, a few
   words on the subject in the Security Considerations section may prove
   useful.

 - Mobile-to-mobile operation does not appear to be covered.  Is it
   supported?

   Are there any security considerations that might be special to
   mobile-to-mobile communications?

   I believe mobile-to-mobile operation is implicitly supported, and
   should work well enough.  I don't believe there's any special
   security considerations regarding mobile-to-mobile operation, but
   maybe I missed something?

Nico
-- 

From weiler+secdir@watson.org  Tue Nov 30 15:10:05 2010
Return-Path: <weiler+secdir@watson.org>
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 304C93A6C3B for <secdir@core3.amsl.com>; Tue, 30 Nov 2010 15:10:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.949
X-Spam-Level: 
X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=1.650,  BAYES_00=-2.599, GB_I_LETTER=-2]
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 MXCenukIRmPh for <secdir@core3.amsl.com>; Tue, 30 Nov 2010 15:10:03 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 8B9813A6A6E for <secdir@ietf.org>; Tue, 30 Nov 2010 15:10:03 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id oAUNBF4O009519 for <secdir@ietf.org>; Tue, 30 Nov 2010 18:11:15 -0500 (EST) (envelope-from weiler+secdir@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id oAUNBESS009516 for <secdir@ietf.org>; Tue, 30 Nov 2010 18:11:15 -0500 (EST) (envelope-from weiler+secdir@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Tue, 30 Nov 2010 18:11:14 -0500 (EST)
From: Samuel Weiler <weiler+secdir@watson.org>
X-X-Sender: weiler@fledge.watson.org
To: secdir@ietf.org
Message-ID: <alpine.BSF.2.00.1011301808250.3822@fledge.watson.org>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 30 Nov 2010 18:11:15 -0500 (EST)
Subject: [secdir] Assignments
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: secdir-secretary@mit.edu
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: Tue, 30 Nov 2010 23:10:05 -0000

We have a large list of new assignments this week (17?); please scroll 
through the whole message to check for your name, particularly if your 
last name begins with (one of the letters) E through L.

  Review instructions and related resources are at:
      http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

Chris Lonvick is next in the rotation.

For telechat 2010-12-02

Jeffrey Hutzelman      T 2010-10-13 draft-ietf-mpls-ldp-upstream-08
Russ Mundy             T 2010-11-10 draft-ietf-emu-eaptunnel-req-08
Eric Rescorla          T 2010-06-21 draft-ietf-simple-msrp-acm-09
Eric Rescorla          T 2010-11-08 draft-ietf-opsec-ip-security-04
Carl Wallace           TR2010-07-09 draft-stone-mgcp-vbd-08
Sam Weiler             T 2010-11-22 draft-ietf-dhc-leasequery-by-remote-id-07


For telechat 2010-12-16

Paul Hoffman           T 2010-12-07 draft-ietf-morg-fuzzy-search-02
Vincent Roca           T 2010-11-22 draft-ietf-mpls-tp-oam-framework-09


For telechat 2011-01-06

Charlie Kaufman        T 2010-12-14 draft-ietf-tls-rfc4347-bis-04
Barry Leiba            T 2010-12-22 draft-turner-md5-seccon-update-06


For telechat 2011-01-20

Julien Laganier        T 2010-12-21 draft-loreto-http-bidirectional-05

Last calls and special requests:

Derek Atkins             2010-12-02 draft-ietf-sieve-autoreply-02
Rob Austein              2010-12-15 draft-salowey-secsh-uri-
Dave Cridland            2010-12-03 draft-ietf-sipcore-sec-flows-03
Alan DeKok               -          draft-ohba-pana-relay-02
Donald Eastlake          2010-12-14 draft-ietf-avt-rtcp-port-for-ssm-03
Shawn Emery              2010-12-27 draft-arkko-ipv6-transition-guidelines-08
Stephen Farrell          2010-12-07 draft-ietf-bmwg-reset-02
Tobias Gondrom           2010-12-14 draft-ietf-avt-rtp-cnames-01
Phillip Hallam-Baker     2010-12-14 draft-ietf-ecrit-lost-servicelistboundary-04
Steve Hanna              2010-12-08 draft-ietf-ipfix-mediators-framework-09
Dan Harkins              2010-12-14 draft-ietf-isis-layer2-08
Sam Hartman              2010-12-14 draft-ietf-isis-trill-01
Love Hornquist-Astrand   2010-07-23 draft-ietf-pkix-ocspagility-09
Love Hornquist-Astrand   2010-12-06 draft-ietf-mpls-fastreroute-mib-14
Jeffrey Hutzelman        2010-12-06 draft-ietf-roll-trickle-04
Scott Kelly              2010-12-07 draft-ietf-tcpm-tcp-timestamps-00
Stephen Kent             2010-12-07 draft-ietf-v6ops-3177bis-end-sites-00
Tero Kivinen             2010-12-13 draft-ietf-v6ops-incremental-cgn-02
Barry Leiba             R2010-12-16 draft-saintandre-tls-server-id-check-10
David McGrew             -          draft-ietf-ecrit-framework-12
Brian Weis               2010-12-02 draft-linowski-netmod-yang-abstract-04
Tom Yu                   2010-12-09 draft-cdmi-mediatypes-02
Kurt Zeilenga            2010-12-02 draft-ietf-httpstate-cookie-17
Larry Zhu                2010-09-30 draft-lundberg-app-tei-xml-06
Larry Zhu                2010-11-30 draft-ietf-mpls-ip-options-05
Glen Zorn                2010-12-03 draft-ietf-opsec-protect-control-plane-04