headers
tom.petch | 6 Oct 12:09

client was Re: Server Identity Verification in Application Protocols

This I-D is very hot on the fact that it is about Server Identity, yet
technically, I see no reason why the logic does not also apply equally 
to client identity.

In networking, with the networking box as server, and the client
being the one that wants to change the configuration, then client
identity is the one that matters, not server.

I would like to add an initial paragraph to the effect that although
the memo is written in terms of Server Identity, there is no 
technical reason why the processes described cannot be applied
to verifying the Client Identity.

Tom Petch

----- Original Message ----- 
From: "Peter Saint-Andre" <stpeter <at> stpeter.im>
To: <apps-discuss <at> ietf.org>
Sent: Saturday, October 03, 2009 12:02 AM
Subject: Server Identity Verification in Application Protocols

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> A new version of draft-saintandre-tls-server-id-check is available:
> 
> http://www.ietf.org/id/draft-saintandre-tls-server-id-check-02.txt
> 
> Other than the informational appendix, the diff from the -01 version is
> relatively minor. Feedback is welcome.
(Continue reading)

Permalink | Reply |
headers
Kurt Zeilenga | 7 Oct 09:14
Favicon

Re: client was Re: Server Identity Verification in Application Protocols


On Oct 6, 2009, at 12:09 PM, tom.petch wrote:

> This I-D is very hot on the fact that it is about Server Identity, yet
> technically, I see no reason why the logic does not also apply equally
> to client identity.
>
> In networking, with the networking box as server, and the client
> being the one that wants to change the configuration, then client
> identity is the one that matters, not server.
>
> I would like to add an initial paragraph to the effect that although
> the memo is written in terms of Server Identity, there is no
> technical reason why the processes described cannot be applied
> to verifying the Client Identity.

I'm not sure this makes sense.  The connection model assumed in this  
document is that the user (directly or via configuration) specifies  
the name of the server which than the client connects to, and this  
document then specifies how to match the user specified name (or a  
secure derivation of that name) to the subject of the certificate the  
server provides.

The technical reason why this cannot be applied to verifying the  
client identity is that server's operator has not specified any name  
to match up the subject in the client's certificate.   Also, the  
client certificate is likely to that associated with a human, not a  
service.  So the rules would differ significantly.

Now, in certain "server to server" applications, the application
(Continue reading)

Permalink | Reply |
headers
tom.petch | 7 Oct 16:09

Re: client was Re: Server Identity Verification in Application Protocols

---- Original Message ----- 
From: "Kurt Zeilenga" <Kurt.Zeilenga <at> Isode.com>
Sent: Wednesday, October 07, 2009 9:14 AM

> On Oct 6, 2009, at 12:09 PM, tom.petch wrote:
> 
> > This I-D is very hot on the fact that it is about Server Identity, yet
> > technically, I see no reason why the logic does not also apply equally
> > to client identity.
> >
> > In networking, with the networking box as server, and the client
> > being the one that wants to change the configuration, then client
> > identity is the one that matters, not server.
> >
> > I would like to add an initial paragraph to the effect that although
> > the memo is written in terms of Server Identity, there is no
> > technical reason why the processes described cannot be applied
> > to verifying the Client Identity.
> 
> I'm not sure this makes sense.  The connection model assumed in this  
> document is that the user (directly or via configuration) specifies  
> the name of the server which than the client connects to, and this  
> document then specifies how to match the user specified name (or a  
> secure derivation of that name) to the subject of the certificate the  
> server provides.
> 
> The technical reason why this cannot be applied to verifying the  
> client identity is that server's operator has not specified any name  
> to match up the subject in the client's certificate.   Also, the  
> client certificate is likely to that associated with a human, not a
(Continue reading)

Permalink | Reply |
headers
Kurt Zeilenga | 8 Oct 08:30
Favicon

Re: client was Re: Server Identity Verification in Application Protocols


On Oct 7, 2009, at 4:09 PM, tom.petch wrote:

> ---- Original Message -----
> From: "Kurt Zeilenga" <Kurt.Zeilenga <at> Isode.com>
> Sent: Wednesday, October 07, 2009 9:14 AM
>
>> On Oct 6, 2009, at 12:09 PM, tom.petch wrote:
>>
>>> This I-D is very hot on the fact that it is about Server Identity,  
>>> yet
>>> technically, I see no reason why the logic does not also apply  
>>> equally
>>> to client identity.
>>>
>>> In networking, with the networking box as server, and the client
>>> being the one that wants to change the configuration, then client
>>> identity is the one that matters, not server.
>>>
>>> I would like to add an initial paragraph to the effect that although
>>> the memo is written in terms of Server Identity, there is no
>>> technical reason why the processes described cannot be applied
>>> to verifying the Client Identity.
>>
>> I'm not sure this makes sense.  The connection model assumed in this
>> document is that the user (directly or via configuration) specifies
>> the name of the server which than the client connects to, and this
>> document then specifies how to match the user specified name (or a
>> secure derivation of that name) to the subject of the certificate the
>> server provides.
(Continue reading)

Permalink | Reply |
headers
tom.petch | 14 Oct 14:13

Re: client was Re: Server Identity Verification in Application Protocols

----- Original Message ----- 
From: "Kurt Zeilenga" <Kurt.Zeilenga <at> Isode.com>
Sent: Thursday, October 08, 2009 8:30 AM

> On Oct 7, 2009, at 4:09 PM, tom.petch wrote:
> 
> > ---- Original Message -----
> > From: "Kurt Zeilenga" <Kurt.Zeilenga <at> Isode.com>
> > Sent: Wednesday, October 07, 2009 9:14 AM
> >
> >> On Oct 6, 2009, at 12:09 PM, tom.petch wrote:
> >>
> >>> This I-D is very hot on the fact that it is about Server Identity,  
> >>> yet
> >>> technically, I see no reason why the logic does not also apply  
> >>> equally
> >>> to client identity.
> >>>
> >>> In networking, with the networking box as server, and the client
> >>> being the one that wants to change the configuration, then client
> >>> identity is the one that matters, not server.
> >>>
> >>> I would like to add an initial paragraph to the effect that although
> >>> the memo is written in terms of Server Identity, there is no
> >>> technical reason why the processes described cannot be applied
> >>> to verifying the Client Identity.
> >>
> >> I'm not sure this makes sense.  The connection model assumed in this
> >> document is that the user (directly or via configuration) specifies
> >> the name of the server which than the client connects to, and this
(Continue reading)

Permalink | Reply |
headers
Kurt Zeilenga | 14 Oct 17:11
Favicon

Re: client was Re: Server Identity Verification in Application Protocols


On Oct 14, 2009, at 5:13 AM, tom.petch wrote:

> ----- Original Message -----
> From: "Kurt Zeilenga" <Kurt.Zeilenga <at> Isode.com>
> Sent: Thursday, October 08, 2009 8:30 AM
>
>> On Oct 7, 2009, at 4:09 PM, tom.petch wrote:
>>
>>> ---- Original Message -----
>>> From: "Kurt Zeilenga" <Kurt.Zeilenga <at> Isode.com>
>>> Sent: Wednesday, October 07, 2009 9:14 AM
>>>
>>>> On Oct 6, 2009, at 12:09 PM, tom.petch wrote:
>>>>
>>>>> This I-D is very hot on the fact that it is about Server Identity,
>>>>> yet
>>>>> technically, I see no reason why the logic does not also apply
>>>>> equally
>>>>> to client identity.
>>>>>
>>>>> In networking, with the networking box as server, and the client
>>>>> being the one that wants to change the configuration, then client
>>>>> identity is the one that matters, not server.
>>>>>
>>>>> I would like to add an initial paragraph to the effect that  
>>>>> although
>>>>> the memo is written in terms of Server Identity, there is no
>>>>> technical reason why the processes described cannot be applied
>>>>> to verifying the Client Identity.
(Continue reading)

Permalink | Reply |
headers
Peter Saint-Andre | 1 Dec 19:47
Favicon

Re: client was Re: Server Identity Verification in Application Protocols

On 10/14/09 9:11 AM, Kurt Zeilenga wrote:

> I would find it less objectionable for this I-D to simply say something
> like:
>    "This document details a process for client verification of the
> server's identity.  It is possibly that this process be used in server
> verification of a client's identity, however this document does not
> consider or detail how this might be done."

After thinking about Kurt's argument further and discussing the topic at
IETF 76, I agree that verification of client identities is out of scope
for this I-D. Interesting problem, but to be discussed elsewhere.

In my working copy, I have the following text:

      Note: This document applies only to server identities, only to
      TLS, and only to the PKI.  Similar considerations might apply to
      client identities (e.g., for mutual authentication), to security
      protocols such as [IPSEC] and [DTLS], and to keys or certificates
      created outside the context of the PKI (e.g., where a dependency
      on Certificate Revocation Lists or the Online Certificate Status
      Protocol might introduce unacceptable latency or denial of service
      attacks).  Indeed, some aspects of the encapsulation and
      verification rules provided in this document might apply to those
      scenarios, as well; however, those scenarios are outside the scope
      of this document and need to be addressed by separate
      specifications.

Peter
(Continue reading)

Permalink | Reply |
headers
Alexey Melnikov | 2 Dec 11:21
Favicon

Re: client was Re: Server Identity Verification in Application Protocols

Peter Saint-Andre wrote:

>On 10/14/09 9:11 AM, Kurt Zeilenga wrote:
>  
>
>>I would find it less objectionable for this I-D to simply say something
>>like:
>>   "This document details a process for client verification of the
>>server's identity.  It is possibly that this process be used in server
>>verification of a client's identity, however this document does not
>>consider or detail how this might be done."
>>    
>>
>After thinking about Kurt's argument further and discussing the topic at
>IETF 76, I agree that verification of client identities is out of scope
>for this I-D. Interesting problem, but to be discussed elsewhere.
>
>In my working copy, I have the following text:
>
>      Note: This document applies only to server identities, only to
>      TLS, and only to the PKI.  Similar considerations might apply to
>      client identities (e.g., for mutual authentication), to security
>      protocols such as [IPSEC] and [DTLS], and to keys or certificates
>      created outside the context of the PKI (e.g., where a dependency
>      on Certificate Revocation Lists or the Online Certificate Status
>      Protocol might introduce unacceptable latency or denial of service
>      attacks).  Indeed, some aspects of the encapsulation and
>      verification rules provided in this document might apply to those
>      scenarios, as well; however, those scenarios are outside the scope
>      of this document and need to be addressed by separate
(Continue reading)

Permalink | Reply |
headers
Dave CROCKER | 2 Dec 15:08

Re: client was Re: Server Identity Verification in Application Protocols


Alexey Melnikov wrote:
>> In my working copy, I have the following text:
>>
>>      Note: This document applies only to server identities, only to
>>      TLS, and only to the PKI.  Similar considerations might apply to
>>      client identities (e.g., for mutual authentication), to security
>>      protocols such as [IPSEC] and [DTLS], and to keys or certificates
>>      created outside the context of the PKI (e.g., where a dependency
>>      on Certificate Revocation Lists or the Online Certificate Status
>>      Protocol might introduce unacceptable latency or denial of service
>>      attacks).  Indeed, some aspects of the encapsulation and
>>      verification rules provided in this document might apply to those
>>      scenarios, as well; however, those scenarios are outside the scope
>>      of this document and need to be addressed by separate
>>      specifications.
>>
> I like that.

The beginning of the paragraph says what is in scope.  The second half of the 
last sentence says that everything else is outside of scope.  So it might not be 
essential to clarify what:

    "some aspects of the encapsulation and verification rules provided in this 
document might apply to those scenarios"

means, but I do not understand it at all.  "aspect applies"  seems to be what is 
causing my confusion.

d/
(Continue reading)

Permalink | Reply |

Gmane