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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf