[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] [xmpp] Review of draft-saintandre-tls-server-id-check
From: Bernard Aboba <bernard.aboba () gmail ! com>
Date: 2010-09-08 15:38:30
Message-ID: AANLkTikeUiwjZYEBYzc7CYEEvZGafakP0QbmJyzMuwc0 () mail ! gmail ! com
[Download RAW message or body]
Here's a forwarded message from the author of RFC 4985:
-----Original Message-----
From: Stefan Santesson [mailto:stefan@aaa-sec.com]
Sent: Wednesday, September 08, 2010 7:21 AM
To: Bernard Aboba; daedulus@btconnect.com; ietf@ietf.org; stpeter@stpeter.im
Subject: Re: Review of draft-saintandre-tls-server-id-check
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@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_aboba@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
>
[Attachment #3 (text/html)]
Here's a forwarded message from the author of RFC 4985:<br><br><meta \
http-equiv="Content-Type" content="text/html; charset=utf-8"><meta name="ProgId" \
content="Word.Document"><meta name="Generator" content="Microsoft Word 14"><meta \
name="Originator" content="Microsoft Word 14"><link rel="File-List" \
href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C02%5Cclip_filelist.xml"><link \
rel="themeData" href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C02%5Cclip_themedata.thmx"><link \
rel="colorSchemeMapping" \
href="file:///C:%5CUsers%5Cbernarda%5CAppData%5CLocal%5CTemp%5Cmsohtmlclip1%5C02%5Cclip_colorschememapping.xml"><style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;
mso-font-alt:"Times New Roman";
mso-font-charset:0;
mso-generic-font-family:swiss;
mso-font-pitch:variable;
mso-font-signature:-520092929 1073786111 9 0 415 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-unhide:no;
mso-style-qformat:yes;
mso-style-parent:"";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
a:link, span.MsoHyperlink
{mso-style-noshow:yes;
mso-style-priority:99;
color:blue;
mso-themecolor:hyperlink;
text-decoration:underline;
text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-noshow:yes;
mso-style-priority:99;
color:purple;
mso-themecolor:followedhyperlink;
text-decoration:underline;
text-underline:single;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
mso-bidi-font-size:10.5pt;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-unhide:no;
mso-style-locked:yes;
mso-style-link:"Plain Text";
mso-bidi-font-size:10.5pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-hansi-font-family:Calibri;}
.MsoChpDefault
{mso-style-type:export-only;
mso-default-props:yes;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:Calibri;
mso-fareast-theme-font:minor-latin;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;
mso-header-margin:.5in;
mso-footer-margin:.5in;
mso-paper-source:0;}
div.WordSection1
{page:WordSection1;}
-->
</style>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText"><a name="_MailOriginal">-----Original Message-----<br>
From: Stefan Santesson [mailto:stefan@aaa-sec.com] <br>
Sent: Wednesday, September 08, 2010 7:21 AM<br>
To: Bernard Aboba; daedulus@btconnect.com; ietf@ietf.org; stpeter@stpeter.im<br>
Subject: Re: Review of draft-saintandre-tls-server-id-check</a></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">My apology,</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">I just realized
that the document defines "source domain" as what I thought would be
the "target domain"</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style=""><span style=""> </span>source domain:<span \
style=""> </span>The fully-qualified DNS domain name that a client</span></p>
<p class="MsoPlainText"><span style=""><span style=""> </span>expects an \
application service to present in the certificate.</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">Which makes my
comments below a bit wrong.</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">I think it would
be better to discuss this in terms of "reference identifier" and
"presented Identifier".</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style=""><span style=""> </span>presented \
identifier:<span style=""> </span>An identifier that is presented by a server \
to</span></p>
<p class="MsoPlainText"><span style=""><span style=""> </span>a client within \
the server's PKIX certificate when the client</span></p>
<p class="MsoPlainText"><span style=""><span style=""> </span>attempts to \
establish a secure connection with the server; the</span></p>
<p class="MsoPlainText"><span style=""><span style=""> </span>certificate can \
include one or more presented identifiers of</span></p>
<p class="MsoPlainText"><span style=""><span style=""> </span>different \
types.</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style=""><span style=""> </span>reference \
identifier:<span style=""> </span>An identifier that is used by the client \
for</span></p>
<p class="MsoPlainText"><span style=""><span style=""> </span>matching purposes \
when checking the presented identifiers; the</span></p>
<p class="MsoPlainText"><span style=""><span style=""> </span>client can attempt \
to match multiple reference identifiers of</span></p>
<p class="MsoPlainText"><span style=""><span style=""> </span>different \
types.</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">I see no problem
in obtaining the reference identifier from a DNS lookup an the comparing it
with a presented identifier in the certificate.</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">Why would you
require the reference identity to be provided by a human user?</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">/Stefan</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">On 10-09-08 3:40
PM, "Stefan Santesson" <</span><a href="mailto:stefan@aaa-sec.com"><span \
style=""><span style="color: windowtext; text-decoration: \
none;">stefan@aaa-sec.com</span></span></a><span style="">> wrote:</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">> Being the
author of RFC 4985 I agree with most of you say here.</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> Comments in
line;</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> On 10-09-06
8:48 PM, "Bernard Aboba" <</span><a \
href="mailto:bernard_aboba@hotmail.com"><span style=""><span style="color: \
windowtext; text-decoration: none;">bernard_aboba@hotmail.com</span></span></a><span \
style="">> wrote:</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">>> That
was in fact my original question.</span></p>
<p class="MsoPlainText"><span style="">>> </span></p>
<p class="MsoPlainText"><span style="">>> Section
5.1 states that the source domain and service type MUST be </span></p>
<p class="MsoPlainText"><span style="">>>
provided by a human user, and can't be derived.<span style="">
</span>Yet in an SRV or </span></p>
<p class="MsoPlainText"><span style="">>> DDDS
lookup, it is not the source domain that is derived, it is the </span></p>
<p class="MsoPlainText"><span style="">>> target
domain.<span style=""> </span>Given that, it's not clear to me
what types of DNS </span></p>
<p class="MsoPlainText"><span style="">>>
resolutions are to be discouraged.</span></p>
<p class="MsoPlainText"><span style="">>> </span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> This
puzzled me as well. The domain of interest is the domain where </span></p>
<p class="MsoPlainText"><span style="">> the
requested service is located = target domain.</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">>> As
noted elsewhere, RFC 4985 appears to require matching of the </span></p>
<p class="MsoPlainText"><span style="">>> source
domain/service type to the SRV-ID in the certificate.</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> It is not.
RFC 4985 says the following in section 2:</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">><span style=""> \
</span>_Service.Name</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">>
<snip></span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">><span style=""> \
</span>Name</span></p>
<p class="MsoPlainText"><span style="">><span style=""> </span>The DNS \
domain name of the domain where the specified service</span></p>
<p class="MsoPlainText"><span style="">><span style=""> </span>is \
located.</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">>><span style=""> \
</span>Such</span></p>
<p class="MsoPlainText"><span style="">>> a
process would be consistent with a match between user inputs (the </span></p>
<p class="MsoPlainText"><span style="">>> source
domain and service type) and the presented identifier (the </span></p>
<p class="MsoPlainText"><span style="">>> SRV-ID).</span></p>
<p class="MsoPlainText"><span style="">>> </span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> Since this
is not the definition of SRVName, this type of matching </span></p>
<p class="MsoPlainText"><span style="">> does not
apply.</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">>> </span></p>
<p class="MsoPlainText"><span style="">>>>
Yet, Section 5.1 states:</span></p>
<p class="MsoPlainText"><span style="">>>> </span></p>
<p class="MsoPlainText"><span style="">>>>
When the connecting application is an interactive client, the source</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>domain \
name and service type MUST be provided by a human user (e.g.</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>when \
specifying the server portion of the user's account name on the</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>server \
or when explicitly configuring the client to connect to a</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> \
</span>particular host or URI as in [SIP-LOC]) and MUST NOT be derived \
from</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>the user \
inputs in an automated fashion (e.g., a host name or domain</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>name \
discovered through DNS resolution of the source domain).<span style=""> \
</span>This</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>rule is \
important because only a match between the user inputs (in</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>the form \
of a reference identifier) and a presented identifier</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>enables \
the client to be sure that the certificate can legitimately</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>be used \
to secure the connection.</span></p>
<p class="MsoPlainText"><span style="">>>> </span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>However, \
an interactive client MAY provide a configuration setting</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>that \
enables a human user to explicitly specify a particular host</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>name or \
domain name (called a "target domain") to be checked for</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> \
</span>connection purposes.</span></p>
<p class="MsoPlainText"><span style="">>>> </span></p>
<p class="MsoPlainText"><span style="">>>>
[TP] what I thought was about to be raised here was a contradiction </span></p>
<p class="MsoPlainText"><span style="">>>>
that</span></p>
<p class="MsoPlainText"><span style="">>>>
RFC4985</span></p>
<p class="MsoPlainText"><span style="">>>> is
all about information gotten from a DNS retrieval whereas the </span></p>
<p class="MsoPlainText"><span style="">>>>
wording of</span></p>
<p class="MsoPlainText"><span style="">>>>
s5.1</span></p>
<p class="MsoPlainText"><span style="">>>> in
this I-D</span></p>
<p class="MsoPlainText"><span style="">>>> </span></p>
<p class="MsoPlainText"><span style="">>>>
"the source</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>domain \
name and service type<span style=""> </span>...<span style=""> </span>MUST NOT be \
derived from</span></p>
<p class="MsoPlainText"><span style="">>>><span style=""> </span>the user \
inputs in an automated fashion (e.g., ... discovered </span></p>
<p class="MsoPlainText"><span style="">>>>
through DNS resolution ... "</span></p>
<p class="MsoPlainText"><span style="">>>> </span></p>
<p class="MsoPlainText"><span style="">>>>
would appear to exclude DNS resolution.<span style="">
</span>If DNS resolution is off </span></p>
<p class="MsoPlainText"><span style="">>>>
limits, then</span></p>
<p class="MsoPlainText"><span style="">>>>
RFC4985 would appear not to apply.</span></p>
<p class="MsoPlainText"><span style="">>>> </span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> RFC 4985
provides the client with a way to authenticate a host that it </span></p>
<p class="MsoPlainText"><span style="">> believes is
authorized to provide a specific service in the target domain.</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> It does not
matter from where the client has obtained that </span></p>
<p class="MsoPlainText"><span style="">>
authorization information or whether that information is trustworthy.</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> A client
may very well do an insecure DNS lookup to discover what host </span></p>
<p class="MsoPlainText"><span style="">> is
providing the requested service. The client would then contact that </span></p>
<p class="MsoPlainText"><span style="">> host and
obtained it's certificate. If the certificate is trusted and </span></p>
<p class="MsoPlainText"><span style="">> it's
SRVName matches the information provided from the DNS server, then everything
is fine.</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> The client
now has assurance from the CA that this host is in fact </span></p>
<p class="MsoPlainText"><span style="">> authorized
to provide this service.</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style="">> /Stefan</span></p>
<p class="MsoPlainText"><span style="">> </span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<span style=""></span>
<p class="MsoPlainText"> </p>
<br>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic