My apology, I just realized that the document defines "source domain" as what I thought would be the "target domain"
source domain: The fully-qualified DNS domain name that a client expects an application service to present in the certificate. Which makes my comments below a bit wrong. I think it would be better to discuss this in terms of "reference identifier" and "presented Identifier". presented identifier: An identifier that is presented by a server to a client within the server's PKIX certificate when the client attempts to establish a secure connection with the server; the certificate can include one or more presented identifiers of different types. reference identifier: An identifier that is used by the client for matching purposes when checking the presented identifiers; the client can attempt to match multiple reference identifiers of different types. I see no problem in obtaining the reference identifier from a DNS lookup an the comparing it with a presented identifier in the certificate. Why would you require the reference identity to be provided by a human user? /Stefan On 10-09-08 3:40 PM, "Stefan Santesson" <ste...@aaa-sec.com> wrote: > Being the author of RFC 4985 I agree with most of you say here. > > Comments in line; > > On 10-09-06 8:48 PM, "Bernard Aboba" <bernard_ab...@hotmail.com> wrote: > >> That was in fact my original question. >> >> Section 5.1 states that the source domain and service type MUST be >> provided by a human user, and can't be derived. Yet in an SRV or >> DDDS lookup, it is not the source domain that is derived, it is the >> target domain. Given that, it's not clear to me what types of DNS >> resolutions are to be discouraged. >> > > This puzzled me as well. The domain of interest is the domain where the > requested service is located = target domain. > >> As noted elsewhere, RFC 4985 appears to require matching of the >> source domain/service type to the SRV-ID in the certificate. > > It is not. RFC 4985 says the following in section 2: > > _Service.Name > > <snip> > > Name > The DNS domain name of the domain where the specified service > is located. > > >> Such >> a process would be consistent with a match between user inputs >> (the source domain and service type) and the presented identifier >> (the SRV-ID). >> > > Since this is not the definition of SRVName, this type of matching does not > apply. > >> >>> 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. >>> >>> [TP] what I thought was about to be raised here was a contradiction that >>> RFC4985 >>> is all about information gotten from a DNS retrieval whereas the wording of >>> s5.1 >>> in this I-D >>> >>> "the source >>> domain name and service type ... MUST NOT be derived from >>> the user inputs in an automated fashion (e.g., ... discovered through DNS >>> resolution ... " >>> >>> would appear to exclude DNS resolution. If DNS resolution is off limits, >>> then >>> RFC4985 would appear not to apply. >>> > > RFC 4985 provides the client with a way to authenticate a host that it > believes is authorized to provide a specific service in the target domain. > > It does not matter from where the client has obtained that authorization > information or whether that information is trustworthy. > > A client may very well do an insecure DNS lookup to discover what host is > providing the requested service. The client would then contact that host and > obtained it's certificate. If the certificate is trusted and it's SRVName > matches the information provided from the DNS server, then everything is fine. > > The client now has assurance from the CA that this host is in fact authorized > to provide this service. > > > /Stefan > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf