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

["tom.petch" <cfinss at dial.pipex.com>]

----- 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
> >> 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.
> >
> > I part company with you here.
> >
> > In the field of Operations and Management, then the (network)
> > box is the server and is configured with the identifiers of those
> > who may access it eg to update the configuration, so yes, the
> > reference identity is pre-configured in the server.  This may be
> > an IP address, a host name, an e-mail address etc etc.
> >
> > The latest I-D includes a quote from the syslog RFC but omits
> > the earlier statement in that RFC
> >
> > "   Both syslog transport sender (TLS client) and syslog transport
> >   receiver (TLS server) MUST implement certificate-based
> >   authentication. "
> >
> > so without rules for the server to follow, this I-D would be of
> > no use to syslog (and similar operational applications).
> 
> I disagree.  A syslog document can provide the text necessary to  
> describe how the process detailed in this I-D is applied to syslog.   
> It has to do this anyways.
> 
> The only think this text makes explicit is that the process defined by  
> this I-D could be used for client identity verification.  I don't see  
> any reason why this actually needs to be said.  I worry that saying it  
> might lead to implementations using this process for client identity  
> verification without fully considering the implications.   I rather  
> leave it to protocol specifications which make use of the verification  
> process for client identity verification to discuss the implications,  
> especially the security implications associated with one determines  
> which reference identity to use as input to a client identity  
> verification process.
> 
> > I would (still) suggest adding to Section 1
> >
> > "This memo is written in terms of a client authenticating the identity
> > of a server.  Where the server is configured with reference identities
> > for clients, and the client certificate contains an identity of the  
> > types
> > described in section 3.2, then this process MAY be used by a
> > server to authenticate the identity of a client."
> 
> How does the server determine which of the reference identities it has  
> been configured with ought to be the one used to verify the  
> certificate the client provided?
> Why is a "configuration" approach needed?  Maybe the application  
> protocol wants to just use the client IP address as the reference  
> identity, or use a DNS-based reverse lookup of the client IP address,  
> or some other approach.
> 
> I think for the verification process defined by this I-D to be used  
> for client identity verification, there must be additional text  
> describing the process for determining which reference identity to use  
> as input to client identity verification process.  There will be  
> security considerations specific to the process of determining the  
> reference identity input which ought to be discussed.

My view of a server seems a little different, that is, a server is the 
end that supports multiple clients, so the server will have multiple
valid values for security credentials, and the match can be with
any of the security credentials that the server regards as valid.
There is no way, in general, for a server to know which certificate
to expect when it receives a particular TLS connection request (no equivalent
of an SSH username) and that is ok because that is what a server does:-)

I am not tied to the multiple reference identities being configured
in the server - that is just the way I see it done.  But I do see value
in making it clear in this I-D that the steps described for matching
a set of reference identities to a certificate are valid regardless of
which end is doing it.  Otherwise, every application trying to use
this I-D for client authentication is likely to meet objections along 
the lines that this I-D does not cover the case.

My focus is on OAM mostly (syslog, SNMP, netconf), but I note 
that SIP needs client authentication, XMPP describes its processes
in terms of peer (not server) while the SMTP TLS RFC3207 notes
that the server should authenticate the client (without giving any
details - nowadays, given the amount of damage caused to the
Internet by unauthenticated e-mail clients, I would expect such
a specification to say much more).

So, I see the checking of client certificates as a necessary function
for us to cover.

Tom Petch

> 
> I see the determination process as being quite application protocol  
> specific.  That is, what process syslog might want to use might well  
> be different from a process used in say XMPP server-to-server  
> communications.   I think it best to leave all of client identity  
> verification, especially determination of the reference identity  
> input, to protocol specifications calling for the use of process  
> defined here for server identity verification for client identity  
> verification.
> 
> -- Kurt
> 
> 
> 
> >
> > Tom Petch
> >
> >> Now, in certain "server to server" applications, the application
> >> server which initiates the TLS connection is the TLS "client" under
> >> this model and this document would seem to naturally apply.  But this
> >> document doesn't not seem to naturally apply for the application
> >> server accepting the connection, the TLS "server", to verify the
> >> identity of the TLS "client".  While it certainly could apply with
> >> some additional text, that text, I think would likely be application
> >> protocol specific.
> >>
> >> In short, I rather no confuse this document by noting that an
> >> application protocol could use this specification for "client
> >> Identity" checking.  Instead, I rather leave this as something
> >> particular application protocols specifications could call for if and
> >> when appropriate.  I see nothing in the I-D which precludes an
> >> application protocol specification from so doing.
> >>
> >> -- Kurt
> >>
> >>>
> >>> Tom Petch
> >
> > <snip>
> > _______________________________________________
> > Apps-Discuss mailing list
> > Apps-Discuss at ietf.org
> > https://www.ietf.org/mailman/listinfo/apps-discuss
>