Re: [certid] [Gen-art] Gen-ART LC Review of draft-saintandre-tls-server-id-check-11

[Ben Campbell <[e-mail]>]

On Dec 8, 2010, at 9:45 AM, Peter Saint-Andre wrote:

[...]

>>> 
>>> Well, I do think a using protocol does need to specify which URI
>>> scheme names are acceptable for the application protocol. You
>>> wouldn't want a client to think that fubar://example.com identifies
>>> a SIP service. The tel: URI scheme is an interesting
>>> counter-example in some ways.
>> 
>> Not to mention "im:" and "pres:" :-)
>> 
>> Am I correct in assuming you mean that in the context of what schemes
>> they will put in a certificate, or match to a certificate, right? 
> 
> Correct. I think this text is clearer in Section 3.1:
> 
>   3.  If the service using the certificate deploys a technology in
>       which a server is programatically associated with a URI for
>       security purposes (e.g., this is true of [SIP] as specified by
>       [SIP-CERTS]), but not true of [HTTP] since [HTTP-TLS] does not
>       describe usage of a URI-ID for HTTP services), then the
>       certificate SHOULD include a URI-ID; the scheme SHALL be that of
>       the protocol associated with the service type and the "authority"
>       component SHALL be the fully-qualified DNS domain name of the
>       service.  A specification that re-uses this one MUST specify
>       which URI schemes are to be considered acceptable in URI-IDs
>       contained in PKIX certificates used for the application protocol
>       (e.g., "sip" but not "sips" or "tel" for SIP as described in
>       [SIP-SIPS], or perhaps http and https for HTTP as might be
>       described in a future specification).
> 

WFM

[...]

> 
>>>>>> -- 4.2.2:
>>>>>> 
>>>>>> Can we have a URI-ID example?
>>>>> 
>>>>> How's this?
>>>>> 
>>>>> A voice-over-IP (VoIP) user agent that is connecting via SIP
>>>>> to the voice service at "voice.example.edu" might have only
>>>>> one reference identifier: a URI-ID of "sip:voice.example.edu"
>>>>> (see [SIP-CERTS]).
>>>>> 
>>>> 
>>>> Would it make sense to say something to indicate this is true,
>>>> even though the connection may have been opened based on a URI
>>>> of "sip:[e-mail]"? (I'm trying to figure out the
>>>> best way to word that without trying to invoke SIP request-URI vs
>>>> route set complexities, but my brain is tired. I will think
>>>> further about it.)
>>> 
>>> What do you mean by "the connection was opened based on a URI of 
>>> sip:[e-mail]"? Yes, the client might know that it is 
>>> configured for an account with that URI, but in order to
>>> communicate with the application service it will need to resolve
>>> the DNS domain name (and application type) to an IP address. So
>>> that's the reference identifier. The presented identifier in the
>>> certificate will also be of the form sip:domain, not
>>> sip:user@domain.
>>> 
>> 
>> Sure, and I guess what I am talking about is how one derives a
>> reference identifier of sip:voice.example.edu from an address of
>> record (AoR) of sip:[e-mail]. For example, I click on
>> the AoR on a web page, or I type it from Mr. User's business card. I
>> guess my point is it would be useful for the example to show that,
>> given the URI of a _resource_, you derive (extract?) a URI of a
>> _service_ to be the reference entry. You've mentioned that in text,
>> but it would be useful for the example to show it as well.
> 
> Isn't that a matter for the application protocol?
> 
> I want to authenticate with my IMAP server as [e-mail], so
> my client needs to figure out which DNS domain name(s) it will attempt
> to resolve in order to communicate with the right IMAP server (perhaps
> the client checks its configuration or simply chops off the "user@" from
> the front). The result of that process is the source domain that's used
> as input to the verification procedures described in this I-D. It seems
> to me that the same goes for XMPP, SIP, etc.
> 
> In Section 1.2 define source domain as:
> 
>   source domain:  The fully-qualified DNS domain name that a client
>      expects an application service to present in the certificate
>      (e.g., "www.example.com"), typically input by a human user,
>      configured into a client, or provided by reference such as in a
>      hyperlink.  The combination of a source domain and, optionally, a
>      service type enables a client to construct one or more reference
>      identifiers.
> 
> In Section 2.1 we say:
> 
>   From the perspective of the application client or user, some names
>   are direct because they are provided directly by a human user (e.g.,
>   via runtime input, prior configuration, or explicit acceptance of a
>   client connection attempt) whereas other names are indirect because
>   they are automatically resolved by the client based on user input
>   (e.g., a target name resolved from a source name using DNS SRV
>   records).  This dimension matters most for certificate consumption,
>   specifically verification as discussed in this document.
> 
> In Section 4.2.1 we say:
> 
>   The inputs used by the client to construct its list of reference
>   identifiers might be a URI that a user has typed into an interface
>   (e.g., an HTTPS URL for a web site), configured account information
>   (e.g., the domain name of a particular host or URI used for
>   retrieving information or connecting to a network, which might be
>   different from the server portion of the user's account name), a
>   hyperlink in a web page that triggers a browser to retrieve a media
>   object or script, or some other combination of information that can
>   yield a source domain and a service type.
> 
>   The client might need to extract the source domain and service type
>   from the input(s) it has received.  The extracted data MUST include
>   only information that can be securely parsed out of the inputs (e.g.,
>   extracting the fully-qualified DNS domain name from the "authority"
>   component of a URI or extracting the service type from the scheme of
>   a URI) or information for which the extraction is performed in a
>   manner that is not subject to subversion by network attackers (e.g.,
>   pulling the data from a delegated domain that is explicitly
>   established via client or system configuration, resolving the data
>   via [DNSSEC], or obtaining the data from a third-party domain mapping
>   service in which a human user has explicitly placed trust and with
>   which the client communicates over a connection that provides both
>   mutual authentication and integrity checking).  These considerations
>   apply only to extraction of the source domain from the inputs;
>   naturally, if the inputs themselves are invalid or corrupt (e.g., a
>   user has clicked a link provided by a malicious entity in a phishing
>   attack), then the client might end up communicating with an
>   unexpected application service.
> 
> Do you feel we need to say more about how an application client
> determines the source domain? Is there something special about SIP AORs
> that this document does not cover (but should be covering)?
> 


As you mention, 4.2.1 says "The inputs used by the client to construct its list of reference identifiers might be a URI that a user has typed into an interface..." and "The client might need to extract the source domain and service type from the input(s) it has received."

In the case of SIP (and of HTTP if we pretended it used URI-IDs, that input as typed in by a user is likely to contain stuff that has to be stripped out of the reference identifier. For example, in SIP, this input is very likely to be the AoR of the person you want to call. i.e. a URI identifying a user. I am suggesting a soup to nuts example of how a real world input such as that gets converted to a resulting URI reference identity.

I don't think this is peculiar to SIP, other than due to the fact that SIP uses URI-IDs. If HTTP were to use URI-IDs, then you would have similar issues of getting from the URI as entered by a user to a source identifier in URI  form.


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