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

From: [email-masked]
Date: Thu, 14 Jan 2010 06:15:07 -0800 (PST)

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, S. Farrell
	Filename        : draft-ietf-xmpp-dna-00.txt
	Pages           : 18
	Date            : 2010-01-14

An application-level approach to asserting and proving the delegated
ownership of a domain name for XMPP.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 18, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.  Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-xmpp-dna-00.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: Stephen Farrell <[email-masked]>
Date: Thu, 14 Jan 2010 14:25:09 +0000

So this is the same as draft-hildebrand-dna-00 just with
the new authors.

If there're change people want made, I guess around about
now's a good time to suggest those on the list.

Cheers,
Stephen.

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

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 14 Jan 2010 22:55:51 -0700

(as individual)

It has been suggested that we add a second proof type that's a little easier
on the math than AC's.  The idea that has been kicked around:

Put an XML file on a HTTPS URL that contains the delegation.  The proof
contains just the URL.  The server serving the URL has to offer a cert
signed by a well-known CA that proves an identity of the server associated
with the XMPP domain you're trying to delegate.  By "associated", I mean it
either has the same name, or the XMPP domain name with "www." prepended to
it.  The XML file has a pointer to the cert that is offered on the XMPP
stream (e.g. CN+fingerprint).

Concretely, whenever webex.com changes its XMPP cert, it generates a new
version of the XML file.  Customers that have delegated XMPP hosting to us
put that file on their web server, and put the URL to it into the
provisioning tool.  The first steps can be easily automated on the customer
side with a cron job that calls wget/curl.

-- 
Joe Hildebrand

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Jan 2010 11:40:26 +0000

I think that's a reasonably nice scheme. I'd worry about the
'proof' (the xml file content + origin-authentication) being
so dependent on the hoster's server cert though - it might be
that we'd be better off with the xml file containing the
hoster's name and hoster's CA's name & public key (probably
in the form of the CA's cert or self-signed cert).

The concrete delegation statement is then along the lines
of "I have delegated XMPP hosting to whoever has the
private key that goes with a public key that VeriSign have
bound to webex.com." Then if webex are the hoster and don't
change their CA they can update their certs without requiring
a change of proof. They'd be stuck with VeriSign though,
sorry:-)

I guess, as a higher level issue, I'd wonder why more than
one form of proof is really needed? Or, put another way,
if this xml-file-proof works ok, then what's the remaining
use-case for ACs? (Or vice-versa, if ACs work ok, then why
do we want this as well.) Maybe that's already been
discussed though.

S.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 15 Jan 2010 12:45:25 +0000

> do we want this as well.) Maybe that's already been

You don't actually need a cert or a private key, you need an  
identifier that can be provably asserted by the hoster, to which you  
then securely bind an identifier that can be provably asserted by the  
delegator. The hoster's identifier we already have - their XMPP  
domain for their server - and we already have protocol and running  
code to assert such identity and validate others assertions.

So the minimum is that you have a hunk of data that says "My XMPP is  
hosted by webex.com", signed by a certificate ['s private key] which  
validates for "delegator.com". That signing could be done by hosting  
it on HTTPS, or by having a signed file.

Next, you need some mechanisms to ensure that when the delegator  
changes their mind, that change is clearly signalled out, and you  
might do that by no longer hosting it on HTTPS, or by having some  
kind of other form of online revocation.

If you assume OCSP or similar as your online revocation, and a ASN.1  
certificate-like thing as your signed file, then you have an  
Attribute Certificate - and the nice things about those is that we  
already have parsers and validators for X.509 Certificates. The  
downside is that those parsers currently assume there's a public key  
in the cert, too.

Solutions to the latter problem are either:

a) We fix the software to handle AC's, or:

b) We have a dummy public key present, in effect making a Public Key  
Certificate which we then use solely as an Attribute Certificate, or:

c) We throw away X.509 entirely for this and have to design a stable  
online revocation mechanism, too. (Note that I'm not 100% convinced  
about "no longer hosting", I think you need to say something explicit  
about the state of the old information). I'm not really all that keen  
to attempt reinventing 90% of PKIX.

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Jan 2010 13:08:32 +0000

Dave Cridland wrote:

> validates for "delegator.com". That signing could be done by hosting it
> on HTTPS, or by having a signed file.
> 
> Next, you need some mechanisms to ensure that when the delegator changes
> their mind, that change is clearly signalled out, and you might do that
> by no longer hosting it on HTTPS, or by having some kind of other form
> of online revocation.

I guess that raises another question I have - aside from security stuff,
what actions are required when delegating XMPP to some provider, when
moving/changing the delegation from one provider to another and when
bringing XMPP back "in-house"? Is any of that written down somewhere?
(Even if in a product/implementation specific manner.)

I guess that creating and/or withdrawing the putative "delegation proof"
is just one step in a larger sequence of things that need to be done.
I'd like to understand that larger sequence a bit better before I'd be
confident of how to best handle revocation or the like.

S.