One document matched: draft-ietf-sipp-sa-02.txt
Differences from draft-ietf-sipp-sa-01.txt
Network Working Group Randall Atkinson
INTERNET DRAFT Naval Research Laboratory
draft-ietf-sipp-sa-02.txt 19 April 1994
SIPP Security Architecture
STATUS OF THIS MEMO
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its working groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of 6
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as "work in
progress".
This particular Internet Draft is a product of the IETF's SIPP
working group. It is intended that a future version of this draft be
submitted to the IPng Area Directors and the IESG for possible
publication as a standards-track protocol (as a part of the SIPP
proposal for IPng). Discussion of this draft normally takes place on
the SIPP Working Group mailing list: sipp@sunroof.eng.sun.com
1. INTRODUCTION
This memo describes the overall SIPP Security Architecture. The
security architecture is a high-level description of the several
security mechanisms for the SIPP protocol and their relationship.
Each security mechanism is specified separately.
2. KEY MANAGEMENT
The Key Management protocol that will be used with SIPP has not
been specified yet. However, because the key management protocol is
coupled to the other security mechanisms only via the Security
Association Identifier (SAID), those other security mechanisms have
already been defined. What follows in this section is a brief
discussion of a few alternative approaches to key management.
Atkinson [Page 1]
Internet Draft 19 April 1994
The simplest form of key management is manual key management, where
a person manually configures each system with its own key and also
with the keys of other communicating systems. This is quite
practical in small, static environments but does not scale at all.
It is not a viable medium-term or long-term approach, but might be
appropriate in a small LAN environment or with routers that only need
to authenticate routing updates with adjacent routers. All
implementations of the SIPP Security Mechanisms must support manual
key management.
In order for SIPP security to become obiquitous, an Internet-
standard scalable key management protocol will be required. Ideally
such a protocol would support a number of protocols in the Internet
protocol suite, not just SIPP security. There are a number of key
management algorithms that have been proposed in the public
literature. Needham & Schroeder have proposed a key management
algorithm which relies on a centralised key distribution system. [11,
12] This algorithm is used in the Kerberos Authentication System
developed at MIT under Project Athena. [10] More recently, Diffie &
Hellman have devised an algorithm which does not require a
centralised key distribution system. [13] Unfortunately, the original
Diffie-Hellman technique is vulnerable to an active attack. However,
this vulnerability can be mitigated by using signed keys to bootstrap
into the Diffie-Hellman exchange. The Internet's Privacy Enhanced
Mail (PEM) uses a kind of key certificate that appears suitable for
use with the Diffie-Hellman key management algorithm. [14] However,
such a hybrid key management protocol requires several exchanges to
setup a session key between the two parties. It is desirable to
minimise the number of exchanges required to setup a session key.
There are several means by which a key certificate might be
distributed. One obvious choice would be to add some kind of host
key certificate into the Domain Name System as a new resource record
type. Another approach would be for each party to have a host key
certificate available via a UDP service. Then the originating party
would authenticate key management traffic to the other key management
party using an asymmetric algorithm. The two parties would then have
a secure communications channel that could be used to create a shared
session key.
SIPP implementations must support manual key configuration. SIPP
implementations should support a standard key management protocol
once the latter is defined. Widespread use of the SIPP security
mechanisms described below relies on adequate key management
mechanisms being widely deployed.
Atkinson [Page 2]
Internet Draft 19 April 1994
3.0 SIPP SECURITY MECHANISMS
There are two security mechanisms in SIPP. The first is the
Authentication Payload which provides integrity and authentication
without confidentiality. The second is the Encapsulating Security
Payload which provides integrity, authentication, and
confidentiality. These may be combined if appropriate.
3.1 AUTHENTICATION HEADER
The SIPP Authentication Header (AH) seeks to provide integrity and
authentication for SIPP datagrams. Non-repudiation may be provided
by an authentication algorithm used with AH, but it is not provided
by all authentication algorithms that might be used with AH.
Confidentiality, and protection from traffic analysis are not
provided by AH. Users desiring confidentiality should use the SIPP
Encapsulating Security Protocol (ESP).
The SIPP Authentication Header (AH) holds authentication
information for its SIPP datagram. This authentication information is
calculated using all of the fields in the SIPP datagram which do not
change during transit from the originator to the recipient. All SIPP
headers, payloads, and the user data are included in this
calculation. The only exception is that fields which need to change
in transit (e.g. SIPP Header's "Hop Count" or the SIPP Routing
Header's "Next Address") are omitted when the authentication data is
calculated.
Use of AH will increase the SIPP protocol processing costs in
participating end systems and will also increase the communications
latency. The increased latency is primarily due to the calculation
of the authentication data by the sender and the calculation and
comparison of the authentication data by the receiver for each SIPP
datagram containing an Authentication Header (AH).
All SIPP implementations should implement the Authentication
Header. Implementation of AH provides much stronger security than
exists in most of the current Internet and should not affect
exportability or significantly increase implementation cost. While
AH could be implemented by a security gateway on behalf of hosts on a
trusted network behind that security gateway, this mode of operation
is not encouraged. Instead, all SIPP-capable hosts must implement
the SIPP Authentication Header with at least the MD5 algorithm using
a 128-bit key. Other authentication algorithms may also be
implemented.
Atkinson [Page 3]
Internet Draft 19 April 1994
3.2 ENCAPSULATING SECURITY PAYLOAD
The SIPP Encapsulating Security Payload (ESP) seeks to provide
integrity, authentication, and confidentiality to SIPP datagrams. It
does this by encapsulating either an entire SIPP datagram or only the
upper-layer protocol data inside the ESP, encrypting most of the ESP
contents, and then using the ESP as the user data for a cleartext
SIPP datagram. This cleartext SIPP datagram carries the protected
data through the internetwork. The recipient of the cleartext
datagram removes and discards the cleartext SIPP header and cleartext
SIPP options, decrypts the ESP, removes the ESP headers, and then
processes the (now decrypted) original SIPP datagram or upper-layer
protocol data as per the normal SIPP protocol specification.
ESP works between hosts, between a host and a security gateway, or
between security gateways. This support for security gateways permits
trusted networks to exist without the performance and monetary costs
of security, while providing security for traffic transiting
untrustworthy network segments. When both hosts directly implement
ESP and there is no intervening security gateway, then they may use
the mode where only the upper layer protocol data (e.g. TCP or UDP)
is encrypted. This mode reduces both the bandwidth consumed and the
protocol processing costs for users that don't need to keep the
entire SIPP datagram confidential. ESP works with both unicast and
multicast traffic, though published key management mechanisms do not
scale well to large or highly dynamic multicast groups.
It is important to understand that the security properties that ESP
provides come from the encryption mechanisms used with ESP rather
than from the ESP itself. Consequently the implementer's choice of
encryption algorithms, modes, key management schemes, and keys will
strongly influence the quality of the security provided.
The encapsulating security approach used by ESP can noticeably
impact network performance. SIPP protocol processing will be more
complex, requiring both more time and more processing power. Using
ESP will also increase the communications latency. The increased
latency is primarily due to the encryption and decryption required
for each SIPP datagram containing an Encapsulating Security Payload.
The precise cost of ESP will vary with the specifics of the
implementation, including the encryption algorithm, key size, and
other factors. Because of the performance impact, users not
requiring confidentiality will probably prefer to use the SIPP
Authentication Header instead of ESP. For interoperability
throughout the worldwide Internet, the use of the Data Encryption
Standard (DES) in Cipher-Block Chaining (CBC) Mode is required of all
systems which implement SIPP ESP. Other confidentiality algorithms
and modes may also be implemented.
Atkinson [Page 4]
Internet Draft 19 April 1994
3.3 COMBINING SECURITY MECHANISMS
In some cases it might be desirable to combine the SIPP
Authentication Header (AH) with the SIPP Encapsulating Security
Protocol (ESP) to obtain higher quality security. AH always provides
integrity and authentication and can provide non-repudiation if used
with certain authentication algorithms. ESP always provides
integrity and confidentiality and can provide authentication if used
with certain authenticating encryption algorithms and schemes.
Adding the Authentication Header to a SIPP datagram prior to
encapsulating that datagram using ESP might be desirable for users
wishing to have strong integrity, authentication, confidentiality,
and perhaps non-repudiation. When the two mechanisms are combined,
the placement of the SIPP Authentication Header makes clear which
part of the data is being authenticated. Details on combining the
two mechanisms are provided in the SIPP Encapsulating Security
Payload specification. [2]
3.4 OTHER SECURITY MECHANISMS
Protection from traffic analysis is not provided by any of the
security mechanisms described above. It is unclear whether
meaningful protection from traffic analysis can be provided
economically at the Internet Layer and it appears that few Internet
users are concerned about traffic analysis. One traditional method
for protection against traffic analysis is the use of suitable link
encryption. Another technique is to send false traffic in order to
increase the noise in the data provided by traffic analysis. The
reader is referred to [15] for more information on traffic analysis
issues.
4. DESIGN OBJECTIVES
This section describes some of the design objectives of this
security architecture and its component mechanisms. The primary
objective of this work is to ensure that SIPP will have solid
security mechanisms available to users who desire security. These
mechanisms are designed such that Internet users who do not employ
these mechanisms will not be negatively impacted in their use of
SIPP. These mechanisms seek to be algorithm-independent so that the
cryptography might be changed in the future without affecting the
other parts of the implementation. SIPP Security requires that all
conforming implementations support at least the default standard
algorithm. This helps to ensure interoperability in the global
Internet. The algorithms used in SNMPv2 are used as the default
standard algorithms for SIPP Security (i.e. MD5 for authentication
and DES CBC for confidentiality). The SIPP Security mechanisms seek
to be general-purpose and to avoid restricting the security policies
Atkinson [Page 5]
Internet Draft 19 April 1994
that might be enforced.
5. SECURITY CONSIDERATIONS
This entire draft discusses the SIPP Security Architecture.
Users need to understand that the quality of the security provided
by the mechanisms provided by SIPP depends completely on the strength
of the implemented cryptographic algorithms, the strength of the key
being used, the correct implementation of the cryptographic
algorithms, the security of the key management protocol, and the
correct implementation of SIPP and the several security mechanisms in
all of the participating systems. The security of the implementation
is in part related to the security of the operating system which
embodies the security implementations. For example, if the operating
system does not keep the private cryptologic keys confidential, then
traffic using those keys will not be secure. If any of these is
incorrect or insufficiently secure, little or no real security will
be provided to the user.
Certain security properties (e.g. traffic analysis protection) are
not provided by any of these mechanisms. One possible approach to
traffic analysis protection is appropriate use of link encryption.
[15] Users must carefully consider which security properties they
require and take active steps to ensure that their needs are met by
these or other mechanisms.
Certain applications (e.g. electronic mail) probably need to have
application-specific security mechanisms. Application-specific
security mechanisms are out of the scope of the SIPP Security
Architecture. Users interested in electronic mail security should
consult the RFCs describing the Internet's Privacy-Enhanced Mail
system. Users concerned about other application-specific mechanisms
should consult the online RFCs to see if suitable Internet Standard
mechanisms exist.
ACKNOWLEDGEMENTS
Many of the concepts here are derived from or were influenced by
the US Government's SDNS security protocol specifications, the
ISO/IEC's NLSP specification, or from the proposed swIPe security
protocol. [3, 4, 5, 6, 7] The work done for SNMP and SNMPv2 Security
influenced the choice of default cryptological algorithms and modes.
[8] Steve Bellovin, Steve Deering, George Kamis, Phil Karn, and Dave
Mihelcic provided critiques of earlier versions of this draft.
Atkinson [Page 6]
Internet Draft 19 April 1994
REFERENCES
[1] Randall Atkinson, SIPP Authentication Header, Internet Draft,
draft-ietf-sip-ap-03.txt, 19 April 1994.
[2] Randall Atkinson, SIPP Encapsulating Security Payload, Internet
Draft, draft-ietf-sip-esp-02.txt, 19 April 1994.
[3] SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, published
in NIST Publication NIST-IR-90-4250, February 1990.
[4] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.
[5] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: The IP
Security Protocol", unpublished draft, 14 April 1993.
[6] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer
Security for IP", presentation at the Spring 1993 IETF Meeting,
Columbus, Ohio.
[7] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, Section 13.4.1, page 33, International Standards
Organisation, Geneva, Switzerland, 29 November 1992.
[8] James Galvin & Keith McCloghrie, Security Protocols for version 2
of the Simple Network Management Protocol (SNMPv2), RFC-1446,
DDN Network Information Center, April 1993.
[9] Steve Deering, Simple Internet Protocol Plus (SIPP) Specification,
draft-ietf-sipp-spec-00.txt, 21 February 1994
[10] J. Kohl & B. Neuman, The Kerberos Network Authentication Service (V5),
RFC-1510, DDN Network Information Center, 10 September 1993.
[11] R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication
in Large Networks of Computers", Communications of the ACM, Vol. 21,
No. 12, December 1978, pp. 993-999.
[12] R.M. Needham & M.D. Schroeder, "Authentication Revisted", ACM
Operating Systems Review, Vol. 21, No. 1.
[13] W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE
Transactions on Information Theory, Vol. IT-22, No. 6, November
1976, pp. 644-654.
[14] Steve Kent, Privacy Enhancement for Internet Electronic Mail:
Atkinson [Page 7]
Internet Draft 19 April 1994
Part II: Certificate-Based Key Management, RFC-1422, DDN Network
Information Center, 10 February 1993.
[15] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
DISCLAIMER
The views expressed in this note are those of the author and are not
necessarily those of his employer. The Naval Research Laboratory has
not passed judgement on the merits, if any, of this work. The author
and his employer specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
design.
AUTHOR INFORATION
Randall Atkinson <atkinson@itd.nrl.navy.mil>
Information Technology Division
Naval Research Laboratory
Washington, DC 20375-5320
USA
Atkinson [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-24 02:56:21 |