Subject: Server Identity Verification in Application Protocols

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 02 Oct 2009 16:02:22 -0600

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.

Peter

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

---

From: Cyrus Daboo <[email-masked]>
Date: Sun, 04 Oct 2009 12:50:45 -0700

Hi Peter,

> relatively minor. Feedback is welcome.

Given the recent debate on the email SRV spec (which finished last call and 
I need to follow up on) should there be more discussion of exactly how a 
client should verify a server when it uses SRV to look it up? It seems to 
me it is not clear what a client should verify. i.e., client looks up the 
server._tcp name first, then connects to the server on the returned 
hostname. Should both the SRV name and the hostname in the SRV be verified 
in the cert?

I would much rather this server identity spec deals with this issue, and 
would prefer to reference it from the email SRV spec and CalDAV one.

-- 
Cyrus Daboo

---

From: "tom.petch" <[email-masked]>
Date: Tue, 6 Oct 2009 12:05:35 +0200

This specification disallows the use of * to wildcard the reference identity.

syslog over TLS not only uses this, but also allows the use of a wildcard
where it would not be allowed in the subjectAltName.

I would see this as quite common in networking scenarios, where the access
is many to many, and so would like a less severe prescription against it.

Tom Petch

----- Original Message ----- 
From: "Peter Saint-Andre" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, October 03, 2009 12:02 AM
Subject: Server Identity Verification in Application Protocols

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkrGeG4ACgkQNL8k5A2w/vzsrQCgzyFjxSkoQBp3PVqUmC4/p741
> 0HgAniMwjH+eUXwpokRKU8ZXcIJlEDLu
> =7pso
> -----END PGP SIGNATURE-----
> _______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: "tom.petch" <[email-masked]>
Date: Tue, 6 Oct 2009 12:09:19 +0200

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Oct 2009 17:15:02 -0500

I encountered this issue myself through IESG review of one of my documents.  It may have even been the document that triggered this change.

Many RFCs reference HTTP over TLS [RFC2818], which allows the 'f*' wildcard pattern.  In practice (at least for HTTP), this is rarely seen.

Are you aware of instances where this type of wildcard has been useful in practice for syslog?

Not being privy to the IESG discussion, I can only speculate on the reasons, but they make sense.  Consider common practice with respect to domain name allocations on the web.  The registry also fills the CA role and provides a certificate along with a domain name assignment.  Delegating 'f*' is not possible in DNS; '*' is.

--Martin

> -----Original Message-----
> From: [email-masked] [mailto:apps-discuss-
> [email-masked]] On Behalf Of tom.petch
> Sent: Tuesday, 6 October 2009 9:06 PM
> To: Peter Saint-Andre; [email-masked]
> Subject: * was Re: Server Identity Verification in Application
> Protocols
> 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 7 Oct 2009 09:14:09 +0200

> 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  
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

---

From: "tom.petch" <[email-masked]>
Date: Wed, 7 Oct 2009 16:09:53 +0200

---- Original Message ----- 
From: "Kurt Zeilenga" <[email-masked]>
Sent: Wednesday, October 07, 2009 9:14 AM
 
> 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 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."

Tom Petch
 
> application protocol specification from so doing.

<snip>

---

From: "tom.petch" <[email-masked]>
Date: Wed, 7 Oct 2009 17:56:28 +0200

----- Original Message -----
From: "Thomson, Martin" <[email-masked]>
Sent: Wednesday, October 07, 2009 12:15 AM

> I encountered this issue myself through IESG review of one of my documents.
It may have even been the document that triggered this change.
>
> Many RFCs reference HTTP over TLS [RFC2818], which allows the 'f*' wildcard
pattern.  In practice (at least for HTTP), this is rarely seen.
> Not being privy to the IESG discussion, I can only speculate on the reasons,
but they make sense.  Consider common practice with respect to domain name
allocations on the web.  The registry also fills the CA role and provides a
certificate along with a domain name assignment.  Delegating 'f*' is not
possible in DNS; '*' is.

Martin

I have no hard data but this was discussed on the syslog list in 2006.

An alternative proposal, to cover the case of large numbers of syslog
originators feeding through relays to collectors, was to give large numbers of
boxes one and the same certificate, ie to have a group identity.  This was not
seen as
terribly secure and so I see the wider use of wildcards as a counter to allowing
these generic certificates.

Tom Petch

<snip>

---

From: Kurt Zeilenga <[email-masked]>
Date: Thu, 8 Oct 2009 08:30:06 +0200

> 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.

> 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.

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Oct 2009 21:56:22 +0100

> Hi Peter,

Hi Cyrus,

> Given the recent debate on the email SRV spec (which finished last 
> call and I need to follow up on) should there be more discussion of 
> exactly how a client should verify a server when it uses SRV to look 
> it up? It seems to me it is not clear what a client should verify. 
> i.e., client looks up the server._tcp name first, then connects to the 
> server on the returned hostname. Should both the SRV name and the 
> hostname in the SRV be verified in the cert?

I tend to agree.

> I would much rather this server identity spec deals with this issue, 
> and would prefer to reference it from the email SRV spec and CalDAV one.

I think the email SRV spec needs to reference the IMAP STARTTLS/IMAPS 
spec, which should reference the server identity verification document.

---

From: Philip Guenther <[email-masked]>
Date: Thu, 8 Oct 2009 14:31:56 -0700

On Sun, 4 Oct 2009, Cyrus Daboo wrote:
...
> Given the recent debate on the email SRV spec (which finished last call 
> and I need to follow up on) should there be more discussion of exactly 
> how a client should verify a server when it uses SRV to look it up? It 
> seems to me it is not clear what a client should verify. i.e., client 
> looks up the server._tcp name first, then connects to the server on the 
> returned hostname. Should both the SRV name and the hostname in the SRV 
> be verified in the cert?

The client is 'connecting' to the SRV identifier; it's clearly necessary 
for the client to verify that the server's certificate lists that 
identifier to protect the SRV-specific parts of the lookup, but it really 
protects the entire notional 'connection' process of going from a name to 
TLS-protected stream.

Now, I'm sure there are attacks involving certificate compromise that 
could be made ineffective if the client also checked whether the cert 
contained the hostname.  If that's a concern, then why wouldn't we also 
specify checking of IP addresses in certs for the same reasons?  
Requiring the client to compare more than one value (SRV name, hostname, 
IP address) makes use of a compromised certificate more difficult at the 
cost of making it harder for the admin to actually use the flexability 
provided by the naming systems (SRV->host, host->IP).

Or am I just missing the attack on the SRV-aware lookup TLS verification 
that *doesn't* involve certificate compromise but that is blocked by 
having the client also check for the host name in the cert?

Philip Guenther

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 08 Oct 2009 15:48:31 -0600

> spec, which should reference the server identity verification document.

That sounds right to me. I have not had time to update the identity
verification document to reflect recent discussion, but I will try to do
so by the end of next week.

Peter

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

---

From: Shumon Huque <[email-masked]>
Date: Thu, 8 Oct 2009 21:57:30 -0400

> having the client also check for the host name in the cert?

I was assuming Cyrus meant "SRV name OR hostname" rather than AND, 
and I think hostname was referring to the "Name" portion of the 
SRV owner name rather than the hostname that is the target of
the SRV record. But I'm sure he'll correct me. Most implementations 
declare success if they can match any of the identities presented in 
the certificate. And section 3.1 of draft-saintandre-tls-server-id-check 
recommends the same.

But we also need to clearly state what certificate fields these
names are expected to be found in.

For application protocols that use SRV records to identify/locate
servers, I think the recommendation should be to look for the 
following in preference order:

	1. SRVName as specified in RFC 4985
	2. The name portion of the SRV owner name in dNSName

I don't particularly like (2) because it leaves open attacks I
already described earlier on this list. But it may be a practical
necessity if people are using CAs unwilling to issue certs with
SRVName (perhaps I'm being too practical).

There was a 3rd option proposed by Cyrus of putting the whole
SRV owner name (_server._proto.Name) into dNSName. I think we
were waiting for comments from security directorate folks about
that. This would be a better option than 2.

The potential case I see for matching both an SRV name AND a hostname 
would be for the hostname that is the target of the SRV record. In this 
case you could deploy a different certificate for each backend server 
tied to that server's name. And if one of the servers were compromised, 
could revoke and reissue the certificate for only that backend server 
without impacting the entire service. But this requires secure DNS (and 
application layer indicators of such) to securely obtain the SRV->hostname 
mapping.

--Shumon

---

From: Shumon Huque <[email-masked]>
Date: Thu, 8 Oct 2009 22:36:10 -0400

> so by the end of next week.

That would be great. Some other quick comments on your draft:

In Section 3.2.1, dNSName and SRVName are discussed without
too much distinction being made about the rules for using 
them. RFC 4985 Section 2 says SRVName must only be used if
the application protocol specifies the use of SRV records
(or local policy allows it). It would probably help to re-state
this restriction in the draft.

Section 3.1, bullet item 5 mentions DNSSEC in passing for
mapped names. I'd like to see some additional text around
the need for an explicit mechanism (eg. an enhanced name
resolution API) for the application to confirm that DNSSEC
was used to authenticate a mapped name. Otherwise it can
only guess. I discussed this briefly in:

  http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00941.html

Also, I've wondered this before, but are there any applications
that use subjectAltName->uniformResourceIdentifier for server
identity? A URI can specify an application protocol (scheme) and a 
service/host name, and it seems to me that this might be a more 
general purpose way of specifying service identities.

--Shumon.

---

From: "tom.petch" <[email-masked]>
Date: Wed, 14 Oct 2009 14:13:06 +0200

----- Original Message ----- 
From: "Kurt Zeilenga" <[email-masked]>
Sent: Thursday, October 08, 2009 8:30 AM

> 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

---

From: Kurt Zeilenga <[email-masked]>
Date: Wed, 14 Oct 2009 08:11:17 -0700

> any of the security credentials that the server regards as valid.

This sounds like normal TLS certificate verification, not client  
identity verification.

> in the server - that is just the way I see it done.

How does the server select the client reference identity to verify  
from these multiple reference identities?

> But I do see value
> which end is doing it.

> Otherwise, every application trying to use

Well, it doesn't cover all of the problem.  It doesn't discuss at all  
how a server would determine the reference identity to be checked.

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."