With any certificate scheme, trust depends on two primary
characteristics. First, it must start from a known-reliable source,
either an X.509 root, or someone highly trusted by the verifier,
often him or herself. Second, the chain of signatures must be
reliable. That is, each node in the certification graph is crucial;
if it is dishonest or has been compromised, any certificates it has
vouched for cannot be trusted. All other factors being equal (and
they rarely are), shorter chains are preferable.
Some of the differences reflect a tension between two philosophical
positions represented by these technologies. Others resulted from
having separate design teams.
S/MIME is designed to be "fool proof". That is, very little end-user
configuration is required. Specifically, end-users do not need to be
aware of trust relationships, etc. The idea is that if an S/MIME
client says, "This signature is valid", the user should be able to
"trust" that statement at face value without needing to understand
the underlying implications.
To achieve this, S/MIME is typically based on a limited number of
"root" Certifying Authorities (CAs). The goal is to build a global
trusted certificate infrastructure.
The down side to this approach is that it requires a deployed public
key infrastructure before it will work. Two end-users may not be
able to simply obtain S/MIME-capable software and begin communicating
securely. This is not a limitation of the protocol, but a typical
configuration restriction for commonly available software. One or
both of them may need to obtain a certificate from a mutually trusted
CA; furthermore, that CA must already be trusted by their mail
handling software. This process may involve cost and legal
obligations. This ultimately results in the technology being harder
to deploy, particularly in an environment where end-users do not
necessarily appreciate the value received for the hassle incurred.
The PGP "web of trust" approach has the advantage that two end-users
can just obtain PGP software and immediately begin to communicate
securely. No infrastructure is required and no fees and legal
agreements need to be signed to proceed. As such PGP appeals to
people who need to establish ad-hoc security associations.
The down side to PGP is that it requires end-users to have an
understanding of the underlying security technology in order to make
effective use of it. Specifically it is fairly easy to fool a naive
users to accept a "signed" message that is in fact a forgery.
To date PGP has found great acceptance between security-aware
individuals who have a need for secure e-mail in an environment
devoid of the necessary global infrastructure.
By contrast, S/MIME works well in a corporate setting where a secure
internal CA system can be deployed. It does not require a lot of
end-user security knowledge. S/MIME can be used between institutions
by carefully setting up cross certification, but this is harder to do
than it seems.
As of this writing a global certificate infrastructure continues to
elude us. Questions about a suitable business model, as well as
privacy considerations, may prevent one from ever emerging.
3.11. Firewalls and Topology
Firewalls are a topological defense mechanism. That is, they rely on
a well-defined boundary between the good "inside" and the bad
"outside" of some domain, with the firewall mediating the passage of
information. While firewalls can be very valuable if employed
properly, there are limits to their ability to protect a network.
The first limitation, of course, is that firewalls cannot protect
against inside attacks. While the actual incidence rate of such
attacks is not known (and is probably unknowable), there is no doubt
that it is substantial, and arguably constitutes a majority of
security problems. More generally, given that firewalls require a
well-delimited boundary, to the extent that such a boundary does not
exist, firewalls do not help. Any external connections, whether they
are protocols that are deliberately passed through the firewall,
links that are tunneled through, unprotected wireless LANs, or direct
external connections from nominally-inside hosts, weaken the
protection. Firewalls tend to become less effective over time as
users tunnel protocols through them and may have inadequate security
on the tunnel endpoints. If the tunnels are encrypted, there is no
way for the firewall to censor them. An oft-cited advantage of
firewalls is that they hide the existence of internal hosts from
outside eyes. Given the amount of leakage, however, the likelihood
of successfully hiding machines is rather low.
In a more subtle vein, firewalls hurt the end-to-end model of the
Internet and its protocols. Indeed, not all protocols can be passed
safely or easily through firewalls. Sites that rely on firewalls for
security may find themselves cut off from new and useful aspects of
the Internet.
Firewalls work best when they are used as one element of a total
security structure. For example, a strict firewall may be used to
separate an exposed Web server from a back-end database, with the
only opening the communication channel between the two. Similarly, a
firewall that permitted only encrypted tunnel traffic could be used
to secure a piece of a VPN. On the other hand, in that case the
other end of the VPN would need to be equally secured.
3.12. Kerberos
Kerberos [RFC1510] provides a mechanism for two entities to
authenticate each other and exchange keying material. On the client
side, an application obtains a Kerberos "ticket" and "authenticator".
These items, which should be considered opaque data, are then
communicated from client to server. The server can then verify their
authenticity. Both sides may then ask the Kerberos software to
provide them with a session key which can be used to protect or
encrypt data.
Kerberos may be used by itself in a protocol. However, it is also
available as a mechanism under SASL and GSSAPI. It has some known
vulnerabilities [KRBATTACK] [KRBLIM] [KRB4WEAK], but it can be used
securely.
3.13. SSH
SSH provides a secure connection between client and server. It
operates very much like TLS; however, it is optimized as a protocol
for remote connections on terminal-like devices. One of its more
innovative features is its support for "tunneling" other protocols
over the SSH-protected TCP connection. This feature has permitted
knowledgeable security people to perform such actions as reading and
sending e-mail or news via insecure servers over an insecure network.
It is not a substitute for a true VPN, but it can often be used in
place of one.
4. Insecurity Mechanisms
Some common security mechanisms are part of the problem rather than
part of the solution.
4.1. Plaintext Passwords
Plaintext passwords are the most common security mechanism in use
today. Unfortunately, they are also the weakest. When not protected
by an encryption layer, they are completely unacceptable. Even when
used with encryption, plaintext passwords are quite weak, since they
must be transmitted to the remote system. If that system has been
compromised or if the encryption layer does not include effective
authentication of the server to the client, an enemy can collect the
passwords and possibly use them against other targets.
Another weakness arises because of common implementation techniques.
It is considered good form [MT79] for the host to store a one-way
hash of the users’ passwords, rather than their plaintext form.
However, that may preclude migrating to stronger authentication
mechanisms, such as HMAC-based challenge/response.
The strongest attack against passwords, other than eavesdropping, is
password-guessing. With a suitable program and dictionary (and these
are widely available), 20-30% of passwords can be guessed in most
environments [Klein90].
4.2. Address-Based Authentication
Another common security mechanism is address-based authentication. At
best, it can work in highly constrained environments. If your
environment consists of a small number of machines, all tightly
administered, secure systems run by trusted users, and if the network
is guarded by a router that blocks source-routing and prevents
spoofing of your source addresses, and you know there are no wireless
bridges, and if you restrict address-based authentication to machines
on that network, you are probably safe. But these conditions are
rarely met.
Among the threats are ARP-spoofing, abuse of local proxies,
renumbering, routing table corruption or attacks, DHCP, IP address
spoofing (a particular risk for UDP-based protocols), sequence number
guessing, and source-routed packets. All of these can be quite
potent.
4.3. Name-Based Authentication
Name-based authentication has all of the problems of address-based
authentication and adds new ones: attacks on the DNS [Bell95] and
lack of a one to one mapping between addresses and names. At a
minimum, a process that retrieves a host name from the DNS should
retrieve the corresponding address records and cross-check.
Techniques such as DNS cache contamination can often negate such
checks.
DNSSEC provides protection against this sort of attack. However, it
does nothing to enhance the reliability of the underlying address.
Further, the technique generates a lot of false alarms. These
lookups do not provide reliable information to a machine, though they
might be a useful debugging tool for humans and could be useful in
logs when trying to reconstruct how and attack took place.
5. Security Considerations
No security mechanisms are perfect. If nothing else, any network-
based security mechanism can be thwarted by compromise of the
endpoints. That said, each of the mechanisms described here has its
own limitations. Any decision to adopt a given mechanism should
weigh all of the possible failure modes. These in turn should be
weighed against the risks to the endpoint of a security failure.
6. IANA Considerations
There are no IANA considerations regarding this document.
7. Acknowledgements
Brian Carpenter, Tony Hain, and Marcus Leech made a number of useful
suggestions. Much of the substance comes from the participants in
the IAB Security Architecture Workshop.
8. Informative References
[Bell95] "Using the Domain Name System for System Break-Ins".
Proc. Fifth Usenix Security Conference, 1995.
[Bell98] "Cryptography and the Internet", S.M. Bellovin, in
Proceedings of CRYPTO ’98, August 1998.
[DSS] "Digital Signature Standard". NIST. May 1994. FIPS
186.
[Klein90] "Foiling the Cracker: A Survey of, and Implications to,
Password Security". D. Klein. Usenix UNIX Security
Workshop, August 1990.
[KRBATTACK] "A Real-World Analysis of Kerberos Password Security".
T. Wu. Network and Distributed System Security Symposium
(NDSS ’99). January 1999.
[KRBLIM] "Limitations of the Kerberos Authentication System".
Proceedings of the 1991 Winter USENIX Conference, 1991.
[KRB4WEAK] "Misplaced trust: Kerberos 4 session keys". Proceedings
of the Internet Society Network and Distributed Systems
Security Symposium, March 1997.
[MT79] "UNIX Password Security", R.H. Morris and K. Thompson,
Communications of the ACM. November 1979.
[NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in the
IKE", Work in Progress, June 2002.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC1510] Kohl, J. and C. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
[RFC1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
"Security Multiparts for MIME: Multipart/Signed and
Multipart/Encrypted", RFC 1847, October 1995.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[RFC2222] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2289] Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-
Time Password System", STD 61, RFC 2289, February 1998.
[RFC2316] Bellovin, S., "Report of the IAB Security Architecture
Workshop", RFC 2316, April 1998.
[RFC2385] Hefferman, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2744] Wray, J., "Generic Security Service API Version 2: C-
bindings", RFC 2744, January 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, R., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY
Resource Record (RR)", RFC 3445, December 2002.
[RSA] Rivest, R., Shamir, A. and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key
Cryptosystems", Communications of the ACM, February 1978.
9. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF’s procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
10. Author Information
This document is a publication of the Internet Architecture Board.
Internet Architecture Board Members at the time this document was
completed were:
Bernard Aboba
Harald Alvestrand
Rob Austein
Leslie Daigle, Chair
Patrik Faltstrom
Sally Floyd
Jun-ichiro Itojun Hagino
Mark Handley
Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla
Michael StJohns
Internet Architecture Board
EMail: iab@iab.org
Steven M. Bellovin, Editor
EMail: bellovin@acm.org
Jeffrey I. Schiller, Editor
EMail: jis@mit.edu
Charlie Kaufman, Editor
EMail: charliek@microsoft.com
11. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.