home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_q_t
/
draft-ietf-rsvp-md5-03.txt
< prev
next >
Wrap
Text File
|
1997-05-28
|
34KB
|
901 lines
Draft RSVP Cryptographic Authentication May 1997
RSVP Cryptographic Authentication |
draft-ietf-rsvp-md5-03.txt |
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 valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as a "work in progress". |
Comments should be made on the list rsvp@isi.edu.
Abstract
This document describes the format and use of RSVP's INTEGRITY
object to provide hop-by-hop integrity and authentication of
RSVP messages.
Fred Baker Expiration: November 1997 [Page 1]
Draft RSVP Cryptographic Authentication May 1997
1. Introduction |
The Resource ReSerVation Protocol RSVP [1] is a protocol for
setting up distributed state in routers and hosts, and in
particular for reserving resources to implement integrated
service. RSVP allows particular users to obtain preferential
access to network resources, under the control of an admission
control mechanism. Permission to make a reservation will
depend both upon the availability of the requested resources
along the path of the data, and upon satisfaction of policy
rules.
To protect the integrity of this admission control mechanism,
RSVP requires the ability to protect its messages against
corruption and spoofing. This document proposes a mechanism
to protect RSVP message integrity hop-by-hop. The proposed
scheme transmits the result of applying a cryptographic |
algorithm to a one-way function or "digest" of the message
together with a secret Authentication Key. This scheme
affords protection against forgery or message modification,
but not replays. It is possible to replay a message until the
sequence number changes, but the sequence number makes replays
less of an issue. The proposed mechanism does not afford
confidentiality, since messages stay in the clear; however,
the mechanism is also exportable from most countries, which
would be impossible were a privacy algorithm to be used.
The proposed mechanism is independent of a specific
cryptographic algorithm, but the document describes the use of |
Keyed-Hashing for Message Authentication using H-MD5 [7] [9] |
for this purpose. As noted in [9], there exist stronger |
hashes, such as H-SHA-1; where warranted, implementations will |
do well to make them available. However, in the general case, |
[9] suggests that H-MD5 is adequate to the purpose at hand and |
has preferable performance characteristics. [9] also offers |
source code and test vectors for this algorithm, a boon to |
those who would test for interoperability. The author |
therefore suggests that H-MD5 should be the baseline, |
universally implemented by RSVP implementations implementing |
cryptographic authentication, with other proposals optional.
The cost of computing an H-MD5 message digest far exceeds the |
cost of computing an RSVP checksum; therefore the RSVP
checksum should be disabled (set to zero) ifH-MD5 |
authentication is used, as theH-MD5 digest is a much stronger
integrity check.
Fred Baker Expiration: November 1997 [Page 2]
Draft RSVP Cryptographic Authentication May 1997
Two uses are envisioned: authentication of RSVP messages or
message fragments (should a fragmentation procedure be defined
in the future), and authentication of sessions. The INTEGRITY
object used in both is the same, and is defined in this
document. The use of the INTEGRITY object for those purposes
is defined in other more appropriate documents [1] [8]. |
1.1. Why not use the Standard IPSEC Authentication Header? |
One obvious question is why, since there exists a standard
mechanism for authentication, we would choose to not use it.
This was discussed at length in the working group, and was
rejected due to the operational impact of manually opening a
new security association among the routers that a flow
traverses for each flow making reservations. In addition, it |
was noted that neighbor relationships between RSVP systems are |
not limited to those which face one another across a |
communication channel; RSVP relationships across non-RSVP |
clouds, such as those described in section 2.8 of [1], are not |
necessarily visible to the sending system, suggesting that key |
management based on the source address may be a simpler key |
management strategy.
It is also not clear that RSVP messages are well defined for
the security associations, as a router must forward PATH and
PATH TEAR messages using the same source address as the sender
listed in the SENDER TEMPLATE, as in RSVP traffic may |
otherwise not follow exactly the same IP path as data traffic.
These matters are simplified if a secure key management
protocol exists which can be used to open and key the security
associations; should such a protocol come into existence, it
may be worthwhile reviewing this decision. However, the non- |
RSVP cloud considerations conspire against using the same |
solution as one which would work for IPSEC. Therefore, this
consideration cannot be understood as a promise that this
procedure will go away.
2. Data Structures
2.1. INTEGRITY Object Format *
The RSVP Message consists of a sequence of "objects," which
are type-length-value encoded fields having specific purposes.
The information required for hop-by-hop integrity checking is
Fred Baker Expiration: November 1997 [Page 3]
Draft RSVP Cryptographic Authentication May 1997
carried in an INTEGRITY object.
The contents of INTEGRITY object are defined as a "Keyed
Message Digest" structure, with one of the following formats:
IP4 Keyed Message Digest INTEGRITY Object: Class = 4, |
C-Type = 1
+-------------+-------------+-------------+-------------+ *
| Key Identifier |
+-------------+-------------+-------------+-------------+
| Sequence Number |
+-------------+-------------+-------------+-------------+
| Sending System IP4 Address |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Keyed Message Digest |
| |
+ +
| |
+-------------+-------------+-------------+-------------+
IP6 Keyed Message Digest INTEGRITY Object: Class = 4, *
C-Type = 2
+-------------+-------------+-------------+-------------+ *
| Key Identifier |
+-------------+-------------+-------------+-------------+
| Sequence Number |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Sending System IP6 Address +
| |
+ +
| |
+-------------+-------------+-------------+-------------+
| |
+ +
| |
+ Keyed Message Digest +
| |
+ +
| |
Fred Baker Expiration: November 1997 [Page 4]
Draft RSVP Cryptographic Authentication May 1997
+-------------+-------------+-------------+-------------+
(1) Key Identifier |
An unsigned 32-bit number that acts as a key selector.
With the key, the system stores an algorithm for its
application.
(2) Sending System Address
This is the same address as would be carried in the
Next Hop or Previous Hop object, the address of the
interface of the RSVP system that sent this message.
(3) Sequence Number
unsigned 32-bit non-decreasing sequence number. |
Any non-decreasing sequence of numbers may be used as
Sequence Number values. For example, a timestamp on
the message's creation or a simple message counter
might be used.
This sequence number is reset to zero upon any key
change. |
Note that when procedures such as the Network Time |
Protocol [10] are in use to synchronize clocks, it is |
feasible and advisable to use the current time as a |
sequence number. Doing this obviates the need to |
store sequence numbers in memory that survives a |
system or process failure.
(4) Keyed Message Digest
The digest must be a multiple of 4 octets long. For |
H-MD5, it will be 16 bytes long.
2.2. H-MD5 Message Header and Trailer |
The H-MD5 algorithm requires affixing a header and trailer to |
the message to be sent before the hash is computed. This |
extra information is not transmitted, since the receiver can
reconstruct it knowing the message length and hash algorithm.
The content of this trailer is specified by [7] and [9]. |
Fred Baker Expiration: November 1997 [Page 5]
Draft RSVP Cryptographic Authentication May 1997
3. Message Processing Rules
3.1. Message Generation *
An RSVP message is created as specified in [1], with these |
exceptions: *
(1) The RSVP checksum is not calculated, but is set to zero. |
(2) The INTEGRITY object is inserted in the appropriate
place, and its location in the message is remembered for
later use.
(3) The current sequence number is placed in the Sequence
Number field of the INTEGRITY object.
If several messages are being created simultaneously (for
example, in a periodic refresh generated by a router),
the messages should all use the same sequence number.
This is to assure that message reordering between RSVP
peers (in non-FIFO queues or in an RSVP tunnel) does not
cause authentication to fail for some of them.
(4) The appropriate Authentication Key is selected and placed
in the Keyed Message Digest field of the INTEGRITY
object.
(5) The Key Identifier is placed into the INTEGRITY object.
(6) The H-MD5 message header and trailer are placed in memory |
as described in [7] and [9].
(7) A Keyed Message Digest of the augmented message is
calculated using the appropriate hash algorithm. When |
the H-MD5 algorithm is used, the hash calculation is |
described in [7] and [9].
(8) The digest is written into the Cryptographic Digest field
of the INTEGRITY object, overlaying the Authentication
Key.
In the sender, Authentication Key selection is based on the *
interface through which the message is sent, there being a key
configured per interface. While administrations may configure
all the routers and hosts on a subnet (or for that matter, in
their network) with the same key, implementations should
assume that each sender may send with a different key on each
Fred Baker Expiration: November 1997 [Page 6]
Draft RSVP Cryptographic Authentication May 1997
numbered interface, and that they keys are simplex - the key
that a system uses to sign its messages need he same key that
its recievers use to sign theirs. Implementations SHOULD |
maintain a separate key per ip address that they sign with.
This restriction to numbered interfaces is intentional; if an
RSVP system peers with another through a set of non-RSVP
routers, and it might be able to reach systems through that
domain from either a numbered interface or an unnumbered
interface using the same address as a router id, the choice of
key would otherwise be ambiguous. Therefore, on unnumbered
interfaces, an RSVP router must use the same key as it uses on
the related numbered interface. User interfaces SHOULD
provide convenient ways to configure these keys. *
3.2. Message Reception
When the message is received, the process is reversed:
(1) The RSVP checksum is not calculated.
(2) The Cryptographic Digest field of the INTEGRITY object is
set aside.
(3) The Key Identifer field and Sending System Address are
used to determine the Authentication Key and the hash
algorithm to be used. Implementations SHOULD maintain a
key per neighboring RSVP system address or CIDR prefix,
as the keys used by neighbors to sign their messages need
not be the same key that the recieving system uses.
(4) If the received sequence number is less than the last
sequence number received from the sending system with
that key identifier, the message is discarded
unprocessed.
(5) The Cryptographic Digest field of the INTEGRITY object is
overlaid with the Authentication Key.
(6) The message header and trailer are reconstructed. |
(7) A new digest is calculated using the indicated algorithm. |
(8) If the calculated digest does not match the received
digest, the message is discarded without further |
processing.
Fred Baker Expiration: November 1997 [Page 7]
Draft RSVP Cryptographic Authentication May 1997
If a system detects the loss of a neighbor or interface, or
the RSVP process is restarted on a system, the system should
start with a new key if possible. In this way, the sequence
number may be reset without exposure to a replay attack. In
the event that no other key is available, the sequence number
should be stored in non-volatile memory around failures, so |
that it may continue without decreasing, or (if the NTP |
timestamp is being used as a sequence number), RSVP |
resynchronization should await NTP synchronization.
4. Key Management
It is likely that the IETF will define a standard key *
management protocol. It is strongly desirable to use that key
management protocol to distribute RSVP Authentication Keys
among communicating RSVP implementations. Such a protocol
would provide scalability and significantly reduce the human
administrative burden. The Key ID can be used as a hook
between RSVP and such a future protocol. Key management
protocols have a long history of subtle flaws that are often
discovered long after the protocol was first described in
public. To avoid having to change all RSVP implementations
should such a flaw be discovered, integrated key management
protocol techniques were deliberately omitted from this
specification.
4.1. Key Management Procedures
Each key has a lifetime associated with it. No key is ever
used outside its lifetime. If more than one key is currently
alive, then the youngest key (the key whose lifetime most
recently started) should be sent, and all "live" keys should |
be tested upon message receipt.
Possible mechanisms for managing key lifetime include: the use |
of the Network Time Protocol, hardware time-of-day clocks, or
waiting some time before emitting the first message to
determine what key other systems are signing with. The matter
is left for the implementor. Note that the concept of a "key
lifetime" does not require a hardware time-of-day clock or the
use of NTP, although one or the other is advised; it merely
requires that the earliest and latest times that the key is
valid must be programmable in a way the system understands.
To maintain security, it is advisable to change the RSVP |
Authentication Key on a regular basis. It should be possible |
Fred Baker Expiration: November 1997 [Page 8]
Draft RSVP Cryptographic Authentication May 1997
to switch the RSVP Authentication Key without loss of RSVP
state or denial of reservation service, and without requiring
people to change all the keys at once. This requires the RSVP
implementation to support the storage and use of more than one
RSVP Authentication Key on a given interface at the same time.
For each key there will be a locally-stored Key Identifier.
The combination of the Key Identifier and the interface
associated with the message uniquely identifies the
cryptographic algorithm and Authentication Key in use by RSVP.
As noted above, the party creating the RSVP message will
select a valid key from the set of valid keys for that
interface. The receiver will use the Key Identifier and
interface to determine which key to use for authentication of
the received message. More than one key may be associated
with an interface at the same time.
To ensure a smooth switch-over, each communicating RSVP system
must be updated with the new key before the current key will |
expire and before the new key lifetime begins. The new key
should have a lifetime that starts several minutes before the
old key expires. This gives time for each system to learn of
the new RSVP Authentication Key before that key will be used.
It also ensures that the new key will begin being used and the
current key will go out of use before the current key's
lifetime expires. For the duration of the overlap in key
lifetimes, a system may receive messages using either key and
authenticate the message.
There are four important times for each key:
+ KeyStartReceive: the time the system starts accepting
received packets signed with the key.
+ KeyStartSign: the time the system starts signing packets
with the key.
+ KeyStopSign: the time the system stops signing packets
with the key, which implies that it starts signing with
the next key, if any.
+ KeyStopReceive: the time the system stops accepting
received packets signed with the key.
The times in the order listed SHOULD form a non-decreasing
sequence. There needs to be some distance between start times
and stop times, to achieve a seamless transition. Each system
Fred Baker Expiration: November 1997 [Page 9]
Draft RSVP Cryptographic Authentication May 1997
sends using the key with the most recent "start" time and
makes its first attempt at validation of incoming traffic with
this same key. If this validation fails and another (older)
key is also active, the system should attempt to validate with
any other active keys it may possess. *
4.2. Key Management Requirements
Requirements on an implementation are as follows. *
(1) It is strongly desirable that a hypothetical security
breach in one Internet protocol not automatically
compromise other Internet protocols. The Authentication
Key of this specification SHOULD NOT be stored using
protocols or algorithms that have known flaws.
(2) An implementation MUST support the storage of more than
one key at the same time, although normally only one key
will be active on an interface.
(3) An implementation MUST associate a specific lifetime
(i.e., KeyStartSign and KeyStopSign) with each key and
corresponding Key Identifier.
(4) An implementation MUST support manual key distribution
(e.g., the privileged user manually typing in the key,
key lifetime, and key identifier on the console). The
lifetime may be infinite.
(5) If more than one algorithm is supported, then the
implementation MUST require that the algorithm be
specified for each key at the time the other key
information is entered.
(6) Keys that are out of date MAY be deleted at will by the
implementation without requiring human intervention.
(7) Manual deletion of active keys SHOULD also be supported.
(8) Key storage SHOULD persist across a system restart, warm
or cold, to avoid operational issues, and an acceptable |
sequence number SHOULD be derivable either from non- |
volatile memory or a procedure such as NTP.
Fred Baker Expiration: November 1997 [Page 10]
Draft RSVP Cryptographic Authentication May 1997
4.3. Pathological Cases
An implementation of this document must handle two
pathological cases. Both of these should be exceedingly rare.
(1) During key switch-over, devices may exist which have not
yet been successfully configured with the new key.
Therefore, systems MAY implement (and would be well
advised to implement) an algorithm that detects the set
of keys being used by its neighbors, and transmits its
messages using both the new and old keys until all the
neighbors are using the new key or the lifetime of the
old key expires. Under normal circumstances, this
elevated transmission rate will exist for a single
refresh interval.
(2) It is possible that the last key associated with an
interface may expire.
When this happens, it is unacceptable to revert to an
unauthenticated condition, and not advisable to disrupt
current reservations. Therefore, the system should send
a "last authentication key expiration" notification to
the network manager and treat the key as having an
infinite lifetime until the lifetime is extended, the key
is deleted by network management, or a new key is
configured. *
5. Conformance Requirements
To conform to this specification, an implementation MUST
support all of its aspects. The H-MD5 authentication |
algorithm defined in [7] and [9] MUST be implemented by all
conforming implementations. A conforming implementation MAY
also support other authentication algorithms such as NIST's
Secure Hash Algorithm (SHA). Manual key distribution as
described above MUST be supported by all conforming
implementations. All implementations MUST support the smooth
key rollover described under "Key Change Procedures."
The user documentation provided with the implementation MUST
contain clear instructions on how to ensure that smooth key
rollover occurs.
Implementations SHOULD support a standard key management
protocol for secure distribution of RSVP Authentication Keys
Fred Baker Expiration: November 1997 [Page 11]
Draft RSVP Cryptographic Authentication May 1997
once such a key management protocol is standardized by the
IETF. |
6. Acknowledgments |
This document is derived directly from similar work done for
OSPF and RIP Version II, jointly by Ran Atkinson and Fred |
Baker. Significant editing was sone by Bob Braden, resulting |
in increased clarity. (if you think this document was hard to |
read, think about what Bob read). Signifiant comments were |
submitted by Steve Bellovin, who actually understands this |
stuff.
7. References
[1] Braden, R., Ed., Zhang, L., Estrin, D., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specificationq. Internet Draft |
draft-ietf-rsvp-spec-14.ps, January 1997.
[2] S. Bellovin, "Security Problems in the TCP/IP Protocol *
Suite", ACM Computer Communications Review, Volume 19,
Number 2, pp.32-48, April 1989. |
[3] N. Haller, R. Atkinson, "Internet Authentication
Guidelines", Request for Comments 1704, October 1994. |
[4] R. Braden, D. Clark, S. Crocker, & C. Huitema,
"Report of IAB Workshop on Security in the Internet
Architecture", Request for Comments 1636, June 1994. |
[5] R. Atkinson, "IP Authentication Header", Request for |
Comments 1826, August 1995. |
[6] R. Atkinson, "IP Encapsulating Security Payload", |
Request for Comments 1827, August 1995. |
[7] P. Metzger, W. Simpson, "IP Authentication using H- |
MD5", Request for Comments 1828, August 1995. |
[8] S. Herzog,
"RSVP Extensions for Policy Control", draft-ietf-rsvp- |
policy-ext-02.txt, March 1997. |
Fred Baker Expiration: November 1997 [Page 12]
Draft RSVP Cryptographic Authentication May 1997
[9] Krawczyk, Bellare, and Canetti, |
"HMAC: Keyed-Hashing for Message Authentication", Request |
for Comments 2104, March 1996.
Fred Baker Expiration: November 1997 [Page 13]
Draft RSVP Cryptographic Authentication May 1997
8. Security Considerations
This entire memo describes and specifies an authentication
mechanism for RSVP that is believed to be secure against
active and passive attacks. Passive attacks are widespread in |
the Internet at present. Protection against active attacks is
also needed even though such attacks are not as widespread. |
Users need to understand that the quality of the security
provided by this mechanism depends completely on the strength
of the implemented authentication algorithms, the strength of
the key being used, and the correct implementation of the
security mechanism in all communicating RSVP implementations.
This mechanism also depends on the RSVP Authentication Keys
being kept confidential by all parties. If any of these |
assumptions are incorrect or procedures are insufficiently |
secure, then no real security will be provided to the users of |
this mechanism.
Confidentiality is not provided by this mechanism; if this is |
required, IPSEC ESP may be the best approach, although it is |
subject to the same criticisms as IPSEC Authetication, and |
therefore would be applicable only in specific environments.
Protection against traffic analysis is also not provided.
Mechanisms such as bulk link encryption might be used when
protection against traffic analysis is required. *
9. Author's Address
Fred Baker
Cisco Systems
519 Lado Drive
Santa Barbara,
California 93111
Phone: (408) 526-4257
Email: fred@cisco.com
Fred Baker Expiration: November 1997 [Page 14]
Draft RSVP Cryptographic Authentication May 1997
Table of Contents
1 Introduction .......................................... 2
1.1 Why not use the Standard IPSEC Authentication
Header? ........................................... 3
2 Data Structures ....................................... 3
2.1 INTEGRITY Object Format ............................. 3
2.2 H-MD5 Message Header and Trailer .................... 5
3 Message Processing Rules .............................. 6
3.1 Message Generation .................................. 6
3.2 Message Reception ................................... 7
4 Key Management ........................................ 8
4.1 Key Management Procedures ........................... 8
4.2 Key Management Requirements ......................... 10
4.3 Pathological Cases .................................. 11
5 Conformance Requirements .............................. 11
6 Acknowledgments ....................................... 12
7 References ............................................ 12
8 Security Considerations ............................... 14
9 Author's Address ...................................... 14
Fred Baker Expiration: November 1997 [Page 15]
