Subject: [xmpp] I-D ACTION:draft-ietf-xmpp-dna-01.txt

From: [email-masked]
Date: Mon, 14 Mar 2011 13:45:01 -0700

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 Assertions
    Author(s)     : J. Lindberg, et al
    Filename      : draft-ietf-xmpp-dna-01.txt
    Pages         : 18
    Date          : 2011-03-14
    
The current authentication process in XMPP requires the XMPP server
   for a domain to present a certificate that contains that domain's
   name.  This requirement causes several problems in scenarios where
   XMPP services have been delegated from one domain to another,
   especially when one domain provides XMPP services for many domains.
   This document describes an extension to the XMPP authentication
   process that allows domains to be securely delegated, simplifying
   authorization in delegation scenarios.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xmpp-dna-01.txt

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 14 Mar 2011 17:00:53 -0400

Hey all,

As we discussed at the interim meeting in Brussels, Jonas and I took a stab at an approach to DNA that uses DNSSEC as the mechanism for securing the delegation of services.  This draft isn't quite complete, but it gives a pretty detailed view of the overall process: How two servers authenticate delegations using DNSSEC and use them to multiplex multiple XMPP sessions onto a single connection.

We'll have some discussion on this in Prague, but comments are welcome in the interim.

Thanks,
--Richard

On Mar 14, 2011, at 4:45 PM, [email-masked] wrote:

> <Mail Attachment>_______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 15 Mar 2011 18:52:33 +0100

> We'll have some discussion on this in Prague, but comments are welcome in the interim.

First, I think Dave Cridland owes you a beer (or something else) for 
documenting a certain kind of D-W-D, which he actually promised to do 
almost two years ago. :-p

Some comments, mostly on section 6. It looks quite good, "piggybacking" 
is certainly the right approach, especially given that we have bidi + 
d-w-d nowadays. However, note that RFC 3920 actually broke it and you 
have to make sure that the peer supports the dialback errors introduced 
in XEP-220 before attempting to piggyback another target domain 
(otherwise you might get a stream error and your connection gets 
terminated).

originating server, step 2:
type can be (the 220-extensions to rfc3920) either 'valid', 'invalid' or 
'error'. "In the case of 'invalid'" should be "case of 'error'".

originating server, step 3 or 4:
if bidi is enabled, the server should now also accept stanzas trom the 
target domain for the sender domain.

receiving server, step 2 and 3:
those errors are dialback errors?

revoking authorization:
What happens if a server revokes authorization but receives a stanza 
with that domain pair which was sent before the peer has 
received/processed the revoke? I think I would prefer sending an empty
<db:result from='sender.tld' to='target.tld'/>
without character data to revoke authorization (acknowledged by target.tld)

cheers

philipp