Subject: [xmpp] DNA/S2S Part 2: Authentication

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 15 Jul 2011 17:46:16 -0400

One challenge for server-to-server connections is how a server initiating a connection can verify that the server it connects to is authorized to represent a delegated domain, without requiring the server to have a general certificate for that domain.  (For more detail, see draft-ietf-xmpp-dna-01.)

The current document focuses on the use of DNSSEC-signed SRV records for this purpose.  Ekr mentioned at the last IETF meeting that he would prefer a system that didn't rely on DNSSEC.  He followed up recently with a more concrete suggestion, based on having servers certificates with only the xmppId Subject Alternative Name, and no Common Name.   These certs would thus be usable only for XMPP, not other services (SMTP, HTTP) for the delegated domain.  (I'll leave it to Ekr to provide more detail.)

Given that, some of the trade-offs between the two approaches are:
- Issuance: Signing a zone vs. Getting a CA to issue an XMPP cert
- Verification: Validating DNSSEC vs. Validating PKIX
- Revocation: Limited by DNS TTLs vs. PKIX revocation (CRL/OCSP) 
Also, in the PKIX-based approach, the server still uses the target (customer/outsourced) domain name, instead of its own name, so there's not necessarily a need to update the authentication procedure in RFC 6120.

There is may also be some interaction here with the XMPP dialback mechanism (XEP-220).  In the current document, when a server receives a dialback request, it uses DNSSEC to verify the remote server's authorization for a given domain, rather than a dialback "verify" transaction.  In the PKIX-based option, the server would presumably still use the "verify" transaction, but the authenticated identity of the server that responds to the "verify" request could be different than the identity of the server that sent the dialback request.  
Init.             Recv/a.com      Recv/b.com
  |                   |               |
  |<----<db:result>---|               |
  |<---------[ auth as b.com ]------->|
  |<-----------<db:verify/>---------->|

In either case, there's a chance that there will be a change in how a server responds to a <db:result> message.  So there's a question of whether this behavior should be specified in the base dialback specification (either a XEP or an RFC, to be coordinated with XSF).

QUESTION-1: Does the group find DNSSEC-signed SRV records or XMPP-only certificates to be the preferable solution to the problem of providing authenticating that a given server is authorized to use a domain?  Should this process be integrated with the dialback specification?

---

From: Dave Cridland <[email-masked]>
Date: Mon, 18 Jul 2011 11:32:12 +0100

On Fri Jul 15 22:46:16 2011, Richard L. Barnes wrote:
> QUESTION-1: Does the group find DNSSEC-signed SRV records or  
> XMPP-only certificates to be the preferable solution to the problem  
> of providing authenticating that a given server is authorized to  
> use a domain?  Should this process be integrated with the dialback  
> specification?

There's only one question, and it has multiple questions. Positively  
theological.

So, my answer are:

It's not clear to me that we need an actual decision, here. I think  
one of the original suggestions, albeit using attribute certificates  
in lieu of public key certificates, was that you'd proceed using  
DNSSEC if you could, and drop back to using ACs if you couldn't.

I don't think this is much different. It'd be possible to have the  
same number of RTTs whether or not using PKIX, I think, but what  
unnerves me somewhat is that DNSSEC *should* allow us to connect  
directly without any PKIX overhead, and I'm not clear that's possible  
without having an additional RTT.

I wouldn't want to abandon DNSSEC entirely - I think it's a sensible  
direction, and although "CA's are free these days", there is a  
certain degree of getting what one pays for, and it seems to me that  
DNSSEC should dilute in this manner to a lesser degree.

In general terms, though, whatever system we use will be made  
substantially easier if integrated into XEP-0220, which is by far the  
most common authentication form in deployment.

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: Peter Saint-Andre <[email-masked]>
Date: Tue, 19 Jul 2011 10:46:25 -0600

A few thoughts on tradeoffs...

On 7/15/11 3:46 PM, Richard L. Barnes wrote:

> Given that, some of the trade-offs between the two approaches are: -
> Issuance: Signing a zone vs. Getting a CA to issue an XMPP cert

IMHO signing a zone is a lot easier than getting a CA to issue an
XMPP-only certificate. As one data point, the XSF used to run an
intermediate CA, and did convince the root CA we were working with at
the time to issue certs containing id-on-XmppAddr fields. However, that
required retooling at the CA and they did it because they were small and
nimble. Convincing a larger CA to do that kind of thing might be a bit
of a challenge because tooling changes might be necessary, and what CA
wants to make such changes if they don't need to? By contrast, signing
your own zone is relatively straightforward. Furthermore, a change to
using XMPP-only certificates somewhat goes against what we mandate in
RFC 6120 (Section 13.7.1.2), i.e., MUST support DNS-ID.

> - Verification: Validating DNSSEC vs. Validating PKIX

Assuming we're using "normal" PKIX certificates and not attribute
certificates, here validating PKIK is probably easier, although we'd
need to do some research into things like support for SRV-IDs in
existing TLS libraries, vs. support for (and application access to) 
DNSSEC in common DNS libraries.

> - Revocation: Limited by DNS TTLs vs. PKIX revocation (CRL/OCSP)

Interesting question, given long-lived TCP connections in XMPP.	It seems 
to me that in the DNSSEC case, you're generating your own credential and 
placing it in the DNS, so if you decide to rekey you could simply 
restart streams that are using the older key.

Peter

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