Internet Engineering Task Force T. Przygienda
INTERNET DRAFT Bell Labs, Lucent Technologies
5 November 1997
BGP-4 MD5 Authentication
<draft-przygienda-bgp-md5-00.txt>
Status of This Memo
This document is an Internet Draft, and can be found as
draft-przygienda-bgp-md5-00.txt in any standard internet drafts
repository. 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 six
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 a
``working draft'' or ``work in progress.''
Please check the I-D abstract listing contained in each Internet
Draft directory to learn the current status of this or any other
Internet Draft.
Abstract
This memo describes MD5 authentication scheme for BGP-4 routing
protocol analogous to the one proposed for SNMP Version 2 and RIP-2.
The mechanism provides greatly enhanced probability for a system
attacked to detect and ignore messages received. A sequence number
improves additionally the resistance against replay attacks.
1. Use of Imperatives
Throughout this document, the words that are used to define the
significance of particular requirements are capitalized. These words
are:
Przygienda Expires 10 May 1998 [Page 1]
Internet Draft BGP-4 MD5 Authentication 5 November
1997
MUST This word or the adjective "REQUIRED" means that the item is
an
absolute requirement of this specification.
MUST NOT This phrase means that the item is an absolute prohibition of
this specification.
SHOULD This word or the adjective "RECOMMENDED" means that there may
exist valid reasons in particular circumstances to ignore
this
item, but the full implications should be understood and the
case
carefully weighed before choosing a different course.
SHOULD NOT This phrase means that there may exist valid reasons in
particular circumstances when the listed behavior is
acceptable
or even useful, but the full implications should be
understood
and the case carefully weighed before implementing any
behavior
described with this label.
MAY This word or the adjective "OPTIONAL" means that this item is
truly optional. One vendor may choose to include the item
because a particular marketplace requires it or because it
enhances the product, for example; another vendor may omit
the
same item.
2. Introduction
Recent developments in the Internet has introduced a stronger
need for improved authentication of routing information. RIP-2
and OSPF provide originally for unauthenticated service and
clear-text password authentication. Both are not sufficient to
withstand attacks currently widespread in the Internet. In case
of disabled authentication only misconfiguration can be detected
and clear password protections can be intercepted easily by an
hostile attacker. Recently, both OSPF [Moy97] and RIP-2 [BA97]
(1)
added additional mechanisms using well-known MD-5 signature
algorithms [Riv92] that is considered to be secure and fast
enough
for protection of routing protocol data units [Tou95]. BGP-4
[RL95, RL97] contains already authentication information marker
in the message header that can be used for a MD5 signature. Its
fixed length however prevents a more generic approach using keyed
___________________________________________
1. on which large parts of this document are based
Przygienda Expires 10 May 1998
[Page 2]
Internet Draft BGP-4 MD5 Authentication 5 November 1997
algorithms generating more than 128 bits long signatures without
redefining its meaning.
This memo proposes an authentication algorithm, as was originally
proposed for SNMP Version 2, augmented by a sequence number. Keyed
MD5 is chosen here as the authentication algorithm for BGP-4.
This mechanism will provide a greatly enhanced probability that a
system being attacked will detect and ignore hostile information.
This property derives from the fact that only the output of an
authentication algorithm (e.g., Keyed MD5) rather than the secret
Authentication Key is transmited. This output is a one-way
function of a message and a secret Authentication Key. Again, the
Authentication Key is never sent over the network unencrypted,
therefore providing protection against passive attacks.
Protection against forgery or message modification is inherent to
this scheme. A sequence number is provided that makes a replay
attack much harder. It is possible to replay a message until
the sequence number changes. The mechanism does not provide
confidentiality. The messages are not encrypted. Such a protection
is provided in other protocols such as PNNIv2 [AF97] or IETF's recent
work [Atk95] and could be considered in the future.
Keyed MD5 is being used for OSPF cryptographic authentication
[Moy97], and is therefore present in routers already, as is some form
of password management.
3. Method Description
The method requires three issues to be addressed:
1. Changed packet formats,
2. Authentication procedures, and
3. Management controls.
3.1. OPEN Message Extensions
The OPEN message in BGP-4 specifies an optional parameter that
is specifically reserved for authentication purposes. For MD-5
purposes the authentication code with value 1 MAY be used by an
Przygienda Expires 10 May 1998 [Page 3]
Internet Draft BGP-4 MD5 Authentication 5 November 1997
implementation. In case this authentication code is used, the OPEN
message contains the parameter and it MUST be formatted the following
way:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The meaning of fields specified reads as:
1. The "Authentication Code" is Keyed Message Digest Algorithm,
indicated by the value 1.
All other octets are reserved and MUST be set to 0.
3.2. Message Header Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth. Type | 0x000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Auth Data Len | 0x000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | 0x000000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The message header format for the OPEN and subsequent UPDATE and
KEEPALIVE messages MUST have the marker formatted in the following
way:
Przygienda Expires 10 May 1998 [Page 4]
Internet Draft BGP-4 MD5 Authentication 5 November 1997
1. The "Authentication Type" is Keyed Message Digest Algorithm,
indicated by the value 1.
2. An unsigned 8-bit field that contains the length in octets of the
trailing Authentication Data field. The presence of this field
permits other algorithms (e.g., Keyed SHA) to be substituted for
Keyed MD5 if desired.
3. An unsigned 32 bit sequence number. The sequence number MUST be
non-decreasing for all messages sent with the same Key ID.
4. An unsigned 8-bit field that contains the Key Identifier or
Key-ID. This identifies the key used to create the Authentication
Data for this BGP-4 message. In implementations supporting more
than one authentication algorithm, the Key-ID also indicates
the authentication algorithm in use for this message. A key is
associated with a session.
The trailer consists of the Authentication Data, which is the output
of the Keyed Message Digest Algorithm. When the Authentication
Algorithm is Keyed MD5, the output data is 16 bytes; during digest
calculation, this is effectively followed by a pad field and a length
field as defined by [Riv92].
3.3. UPDATE and KEEPALIVE Message Trailer
The OPEN and all subsequent UPDATE and KEEPALIVE messages MUST be
trailed after length padded to 32-bit boundary with the indicated
length of authentication data.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BGP Header
+ ...............
| BGP Data
+ ...............
| Padding to 32-bit boundary with reserved 0 octets
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ 0xFFFF | 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ Authentication Data (var. length; 16 bytes with Keyed MD5) /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Przygienda Expires 10 May 1998 [Page 5]
Internet Draft BGP-4 MD5 Authentication 5 November 1997
In memory, the following trailer is appended by the MD5 algorithm and
treated as though it were part of the message.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sixteen octets of MD5 "secret" |
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more pad bytes (defined by RFC 1321 when MD5 is used) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length MSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 64 bit message length LSW |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.4. Message Generation
The BGP-4 packet is created as usual, except that the marker is set
to contain the authentication type (1), the authentication data
length, the sequence number and the Key Identifier.
The value used in the sequence number is arbitrary, but two
suggestions are the time of the message's creation or a simple
message counter.
The BGP-4 Authentication Key is selected by the sender based on the
session. Each key has a lifetime associated with it. No key is ever
used outside its lifetime.
1. The BGP-4 header's packet length field indicates the standard
BGP-4 portion of the packet.
2. The Authentication Data Offset, Key Identifier, and
Authentication Data size fields are filled in appropriately.
3. The BGP-4 Authentication Key, which is 16 bytes long when the
Keyed MD5 algorithm is used, is now appended to the data. For
all algorithms, the BGP-4 Authentication Key is never longer than
the output of the algorithm in use.
Przygienda Expires 10 May 1998 [Page 6]
Internet Draft BGP-4 MD5 Authentication 5 November 1997
4. Trailing pad and length fields are added and the digest
calculated using the indicated algorithm. When Keyed MD5 is the
algorithm in use, these are calculated per [Riv92].
5. The digest is written over the BGP-4 Authentication Key. When
MD5 is used, this digest will be 16 bytes long.
The trailing pad is not actually transmitted, as it is entirely
predictable from the message length and algorithm in use.
3.5. Message Reception
When the message is received, the process is reversed:
1. The digest is set aside,
2. The appropriate algorithm and key are determined from the value
of the Key Identifier field,
3. The BGP-4 Authentication Key is written into the appropriate
number (16 when Keyed MD5 is used) of bytes starting at the
offset indicated,
4. Appropriate padding is added as needed, and
5. A new digest calculated using the indicated algorithm.
If the calculated digest does not match the received digest,
the message is discarded and appropriate Authentication failed
NOTIFICATION sent. The connection is closed subsequently.
If the sequence number is not zero and smaller than the last received
one, the message is discarded and appropriate Authentication failed
NOTIFICATION sent. The connection is closed subsequently.
A router that has forgotten its current sequence number but remembers
its key and Key-ID MUST send its next packet with a sequence number
of zero. This leaves a small opening for a replay attack although
appropriate procedures can be provided by an implementation to report
excessive zero key usage. Router vendors are encouraged to provide
stable storage for keys, key lifetimes, Key-IDs, and the related
sequence numbers.
Przygienda Expires 10 May 1998 [Page 7]
Internet Draft BGP-4 MD5 Authentication 5 November 1997
Acceptable messages are now truncated to a BGP-4 message itself and
treated normally.
4. New UPDATE Message Error Subcode
A new UPDATE Message Error subcode with the value 12 - Authentication
Failure MUST be understood by all implementations supporting keyed
authentication.
5. Management Procedures
5.1. Key Management Requirements
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.
Implementations MUST support the storage of more than one key at
the same time, although it is recognized that only one key will
normally be active on a session. They MUST associate a specific
lifetime (i.e., date/time first valid and date/time no longer valid)
and a key identifier with each key, and MUST support manual key
distribution (e.g., the privileged user manually typing in the
key, key lifetime, and key identifier on the router console). The
lifetime may be infinite. 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. Keys
that are out of date MAY be deleted at will by the implementation
without requiring human intervention. Manual deletion of active keys
SHOULD also be supported.
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 BGP-4 Authentication Keys among communicating
BGP-4 implementations. Such a protocol would provide scalability
and significantly reduce the human administrative burden. The Key
ID can be used as a hook between BGP-4 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 BGP-4 implementations
Przygienda Expires 10 May 1998 [Page 8]
Internet Draft BGP-4 MD5 Authentication 5 November 1997
should such a flaw be discovered, integrated key management protocol
techniques were deliberately omitted from this specification.
5.2. Key Management Procedures
As with all security methods using keys, it is necessary to change
the BGP-4 Authentication Key on a regular basis. To maintain routing
stability during such changes, implementations MUST be able to store
and use more than one BGP-4 Authentication Key for a given session at
the same time.
Each key will have its own Key Identifier, which is stored locally.
The combination of the Key Identifier and the session associated with
the message uniquely identifies the Authentication Algorithm and
BGP-4 Authentication Key in use.
The party creating the BGP-4 message will select a valid key from
the set of valid keys for that session. The receiver will use
the Key Identifier and session to determine which key to use for
authentication of the received message. More than one key may be
associated with a session at the same time.
Hence it is possible to have fairly smooth BGP-4 Authentication
Key rollovers without losing legitimate BGP-4 messages because the
stored key is incorrect and without requiring people to change all
the keys at once. To ensure a smooth rollover, each communicating
BGP-4 system must be updated with the new key several minutes before
the current key will expire and several minutes 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 BGP-4 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. The Key-ID in the received message is used to select the
appropriate key for authentication.
Przygienda Expires 10 May 1998 [Page 9]
Internet Draft BGP-4 MD5 Authentication 5 November 1997
5.3. Pathological Cases
Two pathological cases exist which must be handled, which are
failures of the network manager. Both of these should be exceedingly
rare.
During key switchover, devices may exist which have not yet been
successfully configured with the new key. Therefore, routers SHOULD
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 of
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 update interval.
In the event that the last key associated with an session expires,
it is unacceptable to revert to an unauthenticated condition, and
not advisable to disrupt routing. Therefore, the router 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.
6. Conformance Requirements
To conform to this specification, an implementation MUST support
all of its aspects. The Keyed MD5 authentication algorithm MUST
be implemented by all conforming implementations. MD5 is defined
in [Riv92]. A conforming implementation MAY also support other
authentication algorithms such as Keyed 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 BGP-4 Authentication Keys once such a key
management protocol is standardized by the IETF.
Przygienda Expires 10 May 1998 [Page 10]
Internet Draft BGP-4 MD5 Authentication 5 November 1997
7. Security Consideration
This memo describes and specifies an authentication mechanism for the
BGP-4 routing protocol that is believed to be secure against active
and passive attacks.
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 communicating
BGP-4 implementations. This mechanism also depends on the BGP-4
Authentication Key being kept confidential by all parties. If any of
these incorrect or insufficiently secure, then no real security will
be provided to the users of this mechanism.
Specifically with respect to the use of SNMP, compromise of
SNMP security has the necessary result that the various BGP-4
configuration parameters (e.g. routing table, BGP-4 Authentication
Key) manageable via SNMP could be compromised as well. Changing
Authentication Keys using non-encrypted SNMP is no more secure than
sending passwords in the clear.
Confidentiality is not provided by this mechanism.
8. Acknowledgements
Large parts of this memo are based or has been taken over from the
RIP-2 MD-5 authentication [BA97].
References
[AF97] ATM-Forum. Private Network-Network Interface Specification
Version 2.0. ATM Forum, work in progress, 1997.
[Atk95] R. Atkinson. IP Encapsulating Security Payload. Internet
Engineering Task Force, August 1995.
[BA97] F. Baker and R. Atkinson. RIP-2 MD5 Authentication.
Internet Engineering Task Force, January 1997.
Przygienda Expires 10 May 1998 [Page 11]
Internet Draft BGP-4 MD5 Authentication 5 November 1997
[Moy97] J. Moy. OSPFv2, RFC 2178. Internet Engineering Task Force,
July 1997.
[Riv92] R. Rivest. The MD5 Message-Digest Algorithm, RFC 1321.
Internet Engineering Task Force, April 1992.
[RL95] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4),
RFC 1771. Internet Engineering Task Force, March 1995.
[RL97] Y. Rekhter and T. Li. A Border Gateway Protocol 4 (BGP-4).
Internet Draft, 1997.
[Tou95] J. Touch. Report on MD5 Performance, RFC 1810. Internet
Engineering Task Force, June 1995.
Authors' Addresses
Tony Przygienda
Bell Labs, Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ 07733-3030
prz@dnrc.bell-labs.com
Przygienda Expires 10 May 1998 [Page 12]