Subject: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt

From: [email-masked]
Date: Tue, 04 Feb 2014 12:23:06 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : Domain Name Associations (DNA) in the Extensible Messaging and Presence Protocol (XMPP)
        Authors         : Peter Saint-Andre
                          Matthew Miller
	Filename        : draft-ietf-xmpp-dna-05.txt
	Pages           : 16
	Date            : 2014-02-04

Abstract:
   This document improves the security of the Extensible Messaging and
   Presence Protocol (XMPP) in two ways.  First, it specifies how
   "prooftypes" can establish a strong association between a domain name
   and an XML stream.  Second, it describes how to securely delegate a
   source domain to a derived domain, which is especially important in
   virtual hosting environments.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-dna-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-dna-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Matt Miller <[email-masked]>
Date: Tue, 4 Feb 2014 13:26:17 -0700

Updated references and authors.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

On 2/4/14, 1:23 PM, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Extensible Messaging
> and Presence Protocol Working Group of the IETF.
> 
> Title           : Domain Name Associations (DNA) in the Extensible
> Messaging and Presence Protocol (XMPP) Authors         : Peter
> Saint-Andre Matthew Miller Filename        :
> draft-ietf-xmpp-dna-05.txt Pages           : 16 Date            :
> 2014-02-04
> 
> Abstract: This document improves the security of the Extensible
> Messaging and Presence Protocol (XMPP) in two ways.  First, it
> specifies how "prooftypes" can establish a strong association
> between a domain name and an XML stream.  Second, it describes how
> to securely delegate a source domain to a derived domain, which is
> especially important in virtual hosting environments.
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> _______________________________________________ xmpp mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 26 Feb 2014 22:28:01 +0100

>   This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.
[...]

I've been prodded to give feedback again...
overall, I (still) think the technique described solve the problem.
The description still confuses me and I want to rewrite this from 
scratch, but lack the time to actually do this.

In part, this confusion seems to be caused by the attempt to do both C2S 
and S2S. DNA is needed for both, but the document mostly describes S2S, 
which is the more complicated case.

I think starting with a C2S scenario would be better. It's alot easier 
because only a single party does DNA. Explaining delegation and 
multi-tenancy is easier, too.

I have a problem with the description of S2S.
Bullet #6 in section 4 (as well as the flow chart) puts the creation of 
the association immediately after the TLS negotation.

While authentication happens during/after the TLS handshake and the 
subsequent exchange of stream headers, there is an identity assertion 
step which is done either using SASL (EXTERNAL) or <db:result/>.

IMO this is where the domain name association is created.
And it gets alot easier to explain the need for stuff like piggybacking 
in subsequent sections.

For C2S (or the client role of S2S), I actually agree that the client 
creates the association immediately after (or during) the TLS handshake, 
i.e. MUST check whether they like their counterparts authorization 
enough to continue. But clients have a concept of expected identity of 
the server (RFC 6125?)

Servers, however, do not yet know who their counterpart is or wants to 
act as (assuming they discarded all information that was obtained in an 
insecure way before the TLS handshake).

Additionally, there is no clear definition of what "A establishes DNA 
for B" actually means, which may be another source of confusion.
It seems to be an entry in a list of "i know who this guy is"-domains 
which can then be used in dialback.
However, so far I haven't felt a need to explicitly implement it that 
way, probably because most of the time a synchronus lookup in the list 
of domains contained in the cert was enough. DANE and POSH change that 
obviously.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 26 Feb 2014 21:41:25 +0000

On 26 February 2014 21:28, Philipp Hancke <[email-masked]> wrote:

> subsequent exchange of stream headers, there is an identity assertion step
> which is done either using SASL (EXTERNAL) or <db:result/>.
>

I think this is actually an authorization step. WHich seems the right place
for DNA to happen, yes.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 27 Feb 2014 09:32:42 -0600

(as co-chair)

On Feb 26, 2014, at 3:28 PM, Philipp Hancke <[email-masked]> wrote:

> In part, this confusion seems to be caused by the attempt to do both C2S and S2S. DNA is needed for both, but the document mostly describes S2S, which is the more complicated case.
> 
> I think starting with a C2S scenario would be better. It's alot easier because only a single party does DNA. Explaining delegation and multi-tenancy is easier, too.

That is probably because we are chartered for S2S, but not explicitly for C2S. That doesn't prevent a solution that solves both, but we need to solve S2S in order to claim victory. 

If we agree that C2S is a better problem to solve, then we would need to recharter for it. That's not a problem to do if we have reason.

Thanks!

Ben.

---

From: Matt Miller <[email-masked]>
Date: Thu, 27 Feb 2014 09:20:52 -0700

On 2/27/14, 8:32 AM, Ben Campbell wrote:
>> In part, this confusion seems to be caused by the attempt to do
>> both C2S and S2S. DNA is needed for both, but the document mostly
>> describes S2S, which is the more complicated case.
>> 
>> I think starting with a C2S scenario would be better. It's alot
>> easier because only a single party does DNA. Explaining
>> delegation and multi-tenancy is easier, too.
> 
> That is probably because we are chartered for S2S, but not
> explicitly for C2S. That doesn't prevent a solution that solves
> both, but we need to solve S2S in order to claim victory.
> 
> If we agree that C2S is a better problem to solve, then we would
> need to recharter for it. That's not a problem to do if we have
> reason.
> 

I don't think the suggestion is to abandon (for now) the S2S case, but
to show the C2S case first because there's a lot fewer moving parts.

- -- 
- - m&m