The security of this approach to application service location is only
as good as the security of the DNS queries along the way. If any of
them is compromised, bogus NAPTR and SRV records could be inserted to
redirect clients to unintended destinations. This problem is hardly
unique to S-NAPTR (or NAPTR in general). A full discussion of the
security threats pertaining to DNS can be found in [11].
To protect against DNS-vectored attacks, secured DNS (DNSSEC) [12]
can be used to ensure the validity of the DNS records received.
Whether or not DNSSEC is used, applications should define some form
of end-to-end authentication to ensure that the correct destination
has been reached. Many application protocols such as HTTPS, BEEP,
and IMAP define the necessary handshake mechanisms to accomplish this
task. Newly defined application protocols should take this into
consideration and incorporate appropriate mechanisms.
The basic mechanism works as follows:
1. During some portion of the protocol handshake, the client sends to
the server the original name of the desired destination (i.e., no
transformations that may have resulted from NAPTR replacements,
SRV targets, or CNAME changes). In certain cases where the
application protocol does not have such a feature but TLS may be
used, it is possible to use the "server_name" TLS extension.
2. The server sends back to the client a credential with the
appropriate name. For X.509 certificates, the name would be in
either the subjectDN or the subjectAltName field. For Kerberos,
the name would be a service principle name.
3. Using the matching semantics defined by the application protocol,
the client compares the name in the credential with the name sent
to the server.
4. If the names match and the credentials have integrity, there is
reasonable assurance that the correct end point has been reached.
5. The client and server establish an integrity-protected channel.
Note that this document does not define either the handshake
mechanism, the specific credential naming fields, nor the name-
matching semantics. Definitions of S-NAPTR for particular
application protocols MUST define these.
