On 8/24/10 6:38 PM, Bernard Aboba wrote:
I reviewed draft-saintandre-tls-server-id-check.
Thanks. To ensure appropriate review, I've copied the discussion lists
of the working groups that were asked to look at this I-D (PKIX and
TLS), as well as the author of draft-daboo-srv-email (which normatively
references this I-D).
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).
I think the issue here is an ambivalence in the assumptions underlying
RFC 4985, because an SRV record can be used for two quite different
purposes:
1. To point from an application service name to a particular host/domain
name in the same administrative domain (e.g., _imap._example.com points
to mailhost.example.com for its IMAP service).
2. To delegate an application service name to a hosting provider outside
in the administrative domain of the application service (e.g.,
example.com delegates its IMAP service to apps.example.net).
(I freely grant that it's not always easy to tell up front which of
these is happening, and that the concept of "administrative domain" is
itself a bit vague -- e.g., what if the same provider runs both
example.com and apps.example.net?)
As I see it, RFC 4985 glosses over the foregoing distinction.
Some folks seem to like the SRV-ID construct because it enables them to
more tightly scope the certificates issued to an administrative domain,
so that they can limit a cert to usage within the context of their email
service or IM service or HTTP service or whatever (the IM cert can't be
used for the email service, etc.). That's the usage Jeff Hodges and I
had in mind for this I-D.
However, the question arises: what is the client supposed to check if an
SRV lookup for _imap._example.com yields apps.example.net? My reading of
RFC 4985 leads me to think that the certificate presented by
apps.example.net is supposed to contain an SRV-ID of _imap.example.com,
which means roughly "this certificate indicates that this provider is
authorized to provide IMAP service for the example.com domain". (How the
certification authority determines that the delegation is indeed
authorized is outside the scope of this I-D.)
That is my reading of RFC 4985 because:
1. RFC 4985 defines "Name" as "The DNS domain name of the domain where
the specified service is located." (In RFC 2782, "Name" is defined as
"The domain this RR refers to.")
2. RFC 4985 states of the name form "_Service.Name" that "The content of
the components of this name form MUST be consistent with the
corresponding definition of these components in an SRV RR according to
RFC 2782."
3. RFC 2782 defines the format of the SRV RR as follows:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
Note well that the name form in RFC 4985 is *not* "_Service.Target", it
is "_Service.Name". Using the terminology that Jeff and I defined in
draft-saintandre-tls-server-id-check, this means that the name component
of the SRV-ID is the "source domain", not the "target domain".
Now, perhaps I am horribly mistaken about RFC 4985 and the intent is to
present an SRV-ID of the form "_Service.Target", but if so then I think
that RFC 4985 needs to be revved through a bis draft, because a plain
reading of RFC 4985 would indicate otherwise. Yes, the description of
"Name" in RFC 4985 as "the DNS domain name of the domain where the
specified service is located" might be construed as referring to the
target domain instead of the source domain (although that interpretation
hinges on the meaning of the vague word "located"), but if so then RFC
4985 is changing the definition of "Name" provided in RFC 2782. Given
that (i) RFC 4985 explicitly states that the components of the name form
"_Service.Name" MUST be consistent with the definitions in RFC 2782 and
(ii) RFC 4985 does not update RFC 2782, I think we need to assume that
"Name" in RFC 4985 does not mean "Target" from RFC 2782.
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.
I agree that the text "or, in some cases, target domain" does not
provide enough detail. The concept here is that a user might have
explicitly "authorized" the target domain to provide application
services for the source domain, either through client configuration
(e.g., account setup that specifies an IMAP server of apps.example.net
despite the fact that the DNS domain name portion of the full username
is example.com) or user interaction (overriding an identity mismatch for
the life of the application session or permanently, which is described
as "pinning" in <http://www.w3.org/TR/2010/WD-wsc-ui-20100309>). These
matters are explained in Sections 4.6.3.1 and 5.1 of the I-D, so at the
least I think that the text in Section 4.1 needs to reference those
sections.
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf