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