Subject: [xmpp] Fwd: I-D Action:draft-saintandre-tls-server-id-check-09.txt

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 06 Aug 2010 19:54:21 -0600

FYI. Feedback and reviews are still needed on this spec, which is
referenced from Section 13.7 of 3920bis. Thanks!

/psa

-------- Original Message --------
Subject: I-D Action:draft-saintandre-tls-server-id-check-09.txt
Date: Fri,  6 Aug 2010 18:45:02 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Representation and Verification of Domain-Based
Application Service Identity in Certificates Used with Transport Layer
Security
	Author(s)       : P. Saint-Andre, J. Hodges
	Filename        : draft-saintandre-tls-server-id-check-09.txt
	Pages           : 41
	Date            : 2010-08-06

Many application technologies enable a secure connection between two
entities using certificates in the context of Transport Layer
Security (TLS).  This document specifies best current practices for
representing and verifying the identity of application services in
such interactions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-saintandre-tls-server-id-check-09.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: Philipp Hancke <[email-masked]>
Date: Sat, 14 Aug 2010 20:58:19 +0200

> referenced from Section 13.7 of 3920bis. Thanks!

That draft seems ready to go, but would be alot more credible if 
jabber.org would practice what is preached in section 4.6.3.2.

But I am remarking that since 2007 to no avail.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 16 Aug 2010 14:03:20 -0600

> But I am remarking that since 2007 to no avail.

You mean this in draft-saintandre-tls-server-id-check?

   4.6.3.2. Automated Client

   If the client is an automated application that is not directly
   controlled by a natural person, then it SHOULD terminate the
   connection with a bad certificate error and log the error to an
   appropriate audit log.  An automated application MAY provide a
   configuration setting that disables this check, but MUST enable the
   check by default.

I don't see how that applies to a server...

Peter

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

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 28 Aug 2010 21:15:02 -0700

I reviewed draft-saintandre-tls-server-id-check.

In a number of instances, this document is vague on the verification of an
SRV-ID, and in one instance, it appears to contradict RFC 4985, even though
it does
not update that document.

Section 2.1 states:

o An SRV-ID can be either direct (provided by a user) or more
typically indirect (resolved by a client) and is restricted (can
be used for only a single application).

This is consistent with RFC 4985 Section 2.1 which states:

The SRVName, if present, MUST contain a service name and a domain
name in the following form:

_Service.Name

Yet, Section 5.1 states:

When the connecting application is an interactive client, the source
domain name and service type MUST be provided by a human user (e.g.
when specifying the server portion of the user's account name on the
server or when explicitly configuring the client to connect to a
particular host or URI as in [SIP-LOC]) and MUST NOT be derived from
the user inputs in an automated fashion (e.g., a host name or domain
name discovered through DNS resolution of the source domain). This
rule is important because only a match between the user inputs (in
the form of a reference identifier) and a presented identifier
enables the client to be sure that the certificate can legitimately
be used to secure the connection.

However, an interactive client MAY provide a configuration setting
that enables a human user to explicitly specify a particular host
name or domain name (called a "target domain") to be checked for
connection purposes.

[BA] As I understand RFC 4985, the SRV-ID provided in the target certificate
is to be
matched against components (service name and domain name) of the SRV RR
obtained
via lookup within the source domain. As a result, I don't believe that RFC
4985 is
consistent with this advice (e.g. the reference identifier is not matched
against the
SRV-ID).

Section 4.1 is not as clear as it could be on this point, given that it
talks about both
matching of the source domain and the target domain:

4. When checking a reference identifier against a presented
identifier, the client (a) MUST match the source domain (or, in
some cases, target domain) of the identifiers and (b) MAY also
match the service type of the identifiers.

Implementation Note: Naturally, in addition to checking
identifiers, a client might complete further checks to ensure that
the server is authorized to provide the requested service.
However, such checking is not a matter of verifying the
application service identity presented in a certificate, and
therefore methods for doing so (e.g., consulting local policy
information) are out of scope for this document.