GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6506

Internet Engineering Task Force (IETF) M. Bhatia Request for Comments: 6506 Alcatel-Lucent Category: Standards Track V. Manral ISSN: 2070-1721 Hewlett Packard

                                                             A. Lindem
                                                              Ericsson
                                                         February 2012
            Supporting Authentication Trailer for OSPFv3

Abstract

 Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism
 for authenticating protocol packets.  This behavior is different from
 authentication mechanisms present in other routing protocols (OSPFv2,
 Intermediate System to Intermediate System (IS-IS), RIP, and Routing
 Information Protocol Next Generation (RIPng)).  In some environments,
 it has been found that IPsec is difficult to configure and maintain
 and thus cannot be used.  This document defines an alternative
 mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does
 not only depend upon IPsec for authentication.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6506.

Copyright Notice

 Copyright (c) 2012 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must

Bhatia, et al. Standards Track [Page 1] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................2
    1.1. Requirements ...............................................3
 2. Proposed Solution ...............................................4
    2.1. AT-Bit in Options Field ....................................4
    2.2. Basic Operation ............................................5
    2.3. IPv6 Source Address Protection .............................5
 3. OSPFv3 Security Association .....................................6
 4. Authentication Procedure ........................................8
    4.1. Authentication Trailer .....................................8
         4.1.1. Sequence Number Wrap ...............................10
    4.2. OSPFv3 Header Checksum ....................................10
    4.3. Cryptographic Authentication Procedure ....................10
    4.4. Cross-Protocol Attack Mitigation ..........................11
    4.5. Cryptographic Aspects .....................................11
    4.6. Message Verification ......................................13
 5. Migration and Backward Compatibility ...........................15
 6. Security Considerations ........................................15
 7. IANA Considerations ............................................16
 8. References .....................................................17
    8.1. Normative References ......................................17
    8.2. Informative References ....................................17
 Appendix A.  Acknowledgments ......................................19

1. Introduction

 Unlike Open Shortest Path First version 2 (OSPFv2) [RFC2328], OSPF
 for IPv6 (OSPFv3) [RFC5340] does not include the AuType and
 Authentication fields in its headers for authenticating protocol
 packets.  Instead, OSPFv3 relies on the IPsec protocols
 Authentication Header (AH) [RFC4302] and Encapsulating Security
 Payload (ESP) [RFC4303] to provide integrity, authentication, and/or
 confidentiality.
 [RFC4552] describes how IPv6 AH and ESP extension headers can be used
 to provide authentication and/or confidentiality to OSPFv3.
 However, there are some environments, e.g., Mobile Ad Hoc Networks
 (MANETs), where IPsec is difficult to configure and maintain, and
 this mechanism cannot be used.

Bhatia, et al. Standards Track [Page 2] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 [RFC4552] discusses, at length, the reasoning behind using manually
 configured keys, rather than some automated key management protocol
 such as Internet Key Exchange version 2 (IKEv2) [RFC5996].  The
 primary problem is the lack of a suitable key management mechanism,
 as OSPFv3 adjacencies are formed on a one-to-many basis and most key
 management mechanisms are designed for a one-to-one communication
 model.  This forces the system administrator to use manually
 configured security associations (SAs) and cryptographic keys to
 provide the authentication and, if desired, confidentiality services.
 Regarding replay protection, [RFC4552] states that:
    Since it is not possible using the current standards to provide
    complete replay protection while using manual keying, the proposed
    solution will not provide protection against replay attacks.
 Since there is no replay protection provided there are a number of
 vulnerabilities in OSPFv3 that have been discussed in [RFC6039].
 Since there is no deterministic way to differentiate between
 encrypted and unencrypted ESP packets by simply examining the packet,
 it could be difficult for some implementations to prioritize certain
 OSPFv3 packet types, e.g., Hello packets, over the other types.
 This document defines a new mechanism that works similarly to OSPFv2
 [RFC5709] to provide authentication to the OSPFv3 packets and
 attempts to solve the problems related to replay protection and
 deterministically disambiguating different OSPFv3 packets as
 described above.
 This document adds support for the Secure Hash Algorithms (SHAs)
 defined in the US NIST Secure Hash Standard (SHS), which is specified
 by NIST FIPS 180-3.  [FIPS-180-3] includes SHA-1, SHA-224, SHA-256,
 SHA-384, and SHA-512.  The Hashed Message Authentication Code (HMAC)
 authentication mode defined in NIST FIPS 198-1 [FIPS-198-1] is used.
 It is believed that HMAC as defined in [RFC2104] is mathematically
 identical to [FIPS-198-1]; it is also believed that algorithms in
 [RFC6234] are mathematically identical to [FIPS-198-1].

1.1. Requirements

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in RFC 2119 [RFC2119].

Bhatia, et al. Standards Track [Page 3] RFC 6506 Authentication Trailer for OSPFv3 February 2012

2. Proposed Solution

 To perform non-IPsec Cryptographic Authentication, OSPFv3 routers
 append a special data block, henceforth referred to as the
 Authentication Trailer, to the end of the OSPFv3 packets.  The length
 of the Authentication Trailer is not included in the length of the
 OSPFv3 packet but is included in the IPv6 payload length, as shown in
 Figure 1.
  +---------------------+ --              --  +----------------------+
  | IPv6 Payload Length | ^               ^   | IPv6 Payload Length  |
  | PL = OL + LL        | |               |   | PL = OL + LL + AL    |
  |                     | v               v   |                      |
  +---------------------+ --              --  +----------------------+
  | OSPFv3 Header       | ^               ^   | OSPFv3 Header        |
  | Length = OL         | |               |   | Length = OL          |
  |                     | |    OSPFv3     |   |                      |
  |.....................| |    Packet     |   |......................|
  |                     | |    Length     |   |                      |
  | OSPFv3 Packet       | |               |   | OSPFv3 Packet        |
  |                     | v               v   |                      |
  +---------------------+ --              --  +----------------------+
  |                     | ^               ^   |                      |
  | Optional LLS        | |    LLS Data   |   | Optional LLS         |
  | LLS Block Len = LL  | |    Block      |   | LLS Block Len = LL   |
  |                     | v    Length     v   |                      |
  +---------------------+ --              --  +----------------------+
                                          ^   |                      |
                     AL = PL - (OL + LL)  |   | Authentication       |
                                          |   | AL = Fixed Trailer + |
                                          v   |      Digest Length   |
                                          --  +----------------------+
              Figure 1: Authentication Trailer in OSPFv3
 The presence of the Link-Local Signaling (LLS) [RFC5613] block is
 determined by the L-bit setting in the OSPFv3 Options field in OSPFv3
 Hello and Database Description packets.  If present, the LLS data
 block is included along with the OSPFv3 packet in the Cryptographic
 Authentication computation.

2.1. AT-Bit in Options Field

 A new AT-bit (AT stands for Authentication Trailer) is introduced
 into the OSPFv3 Options field.  OSPFv3 routers MUST set the AT-bit in
 OSPFv3 Hello and Database Description packets to indicate that all
 the packets on this link will include an Authentication Trailer.  For
 OSPFv3 Hello and Database Description packets, the AT-bit indicates

Bhatia, et al. Standards Track [Page 4] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 the AT is present.  For other OSPFv3 packet types, the OSPFv3 AT-bit
 setting from the OSPFv3 Hello/Database Description setting is
 preserved in the OSPFv3 neighbor data structure.  OSPFv3 packet types
 that don't include an OSPFv3 Options field will use the setting from
 the neighbor data structure to determine whether or not the AT is
 expected.
          0                   1                      2
          0 1 2 3 4 5 6 7 8 9 0 1 2 3  4 5  6 7 8  9 0 1  2 3
         +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
         | | | | | | | | | | | | | |AT|L|AF|*|*|DC|R|N|MC|E|V6|
         +-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+--+-+-+--+-+-+--+-+--+
                    Figure 2: OSPFv3 Options Field
 The AT-bit, as shown in the figure above, MUST be set in all OSPFv3
 Hello and Database Description packets that contain an Authentication
 Trailer.

2.2. Basic Operation

 The procedure followed for computing the Authentication Trailer is
 much the same as described in [RFC5709] and [RFC2328].  One
 difference is that the LLS data block, if present, is included in the
 Cryptographic Authentication computation.
 The way the authentication data is carried in the Authentication
 Trailer is very similar to how it is done in case of [RFC2328].  The
 only difference between the OSPFv2 Authentication Trailer and the
 OSPFv3 Authentication Trailer is that information in addition to the
 message digest is included.  The additional information in the OSPFv3
 Authentication Trailer is included in the message digest computation
 and is therefore protected by OSPFv3 Cryptographic Authentication as
 described herein.
 Consistent with OSPFv2 Cryptographic Authentication [RFC2328], both
 OSPFv3 header checksum calculation and verification are omitted when
 the OSPFv3 authentication mechanism described in this specification
 is used.

2.3. IPv6 Source Address Protection

 While OSPFv3 always uses the Router ID to identify OSPFv3 neighbors,
 the IPv6 source address is learned from OSPFv3 Hello packets and
 copied into the neighbor data structure [RFC5340].  Hence, OSPFv3 is
 susceptible to Man-in-the-Middle attacks where the IPv6 source
 address is modified.  To thwart such attacks, the IPv6 source address
 will be included in the message digest calculation and protected by

Bhatia, et al. Standards Track [Page 5] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 OSPFv3 authentication.  Refer to Section 4.5 for details.  This is
 different than the procedure specified in [RFC5709] but consistent
 with [MANUAL-KEY].

3. OSPFv3 Security Association

 An OSPFv3 Security Association (SA) contains a set of parameters
 shared between any two legitimate OSPFv3 speakers.
 Parameters associated with an OSPFv3 SA are as follows:
 o  Security Association Identifier (SA ID)
    This is a 16-bit unsigned integer used to uniquely identify an
    OSPFv3 SA, as manually configured by the network operator.
    The receiver determines the active SA by looking at the SA ID
    field in the incoming protocol packet.
    The sender, based on the active configuration, selects an SA to
    use and puts the correct Key ID value associated with the SA in
    the OSPFv3 protocol packet.  If multiple valid and active OSPFv3
    SAs exist for a given interface, the sender may use any of those
    SAs to protect the packet.
    Using SA IDs makes changing keys while maintaining protocol
    operation convenient.  Each SA ID specifies two independent parts,
    the authentication algorithm and the Authentication Key, as
    explained below.
    Normally, an implementation would allow the network operator to
    configure a set of keys in a key chain, with each key in the chain
    having a fixed lifetime.  The actual operation of these mechanisms
    is outside the scope of this document.
    Note that each SA ID can indicate a key with a different
    authentication algorithm.  This allows the introduction of new
    authentication mechanisms without disrupting existing OSPFv3
    adjacencies.
 o  Authentication Algorithm
    This signifies the authentication algorithm to be used with this
    OSPFv3 SA.  This information is never sent in clear text over the
    wire.  Because this information is not sent on the wire, the
    implementer chooses an implementation-specific representation for
    this information.

Bhatia, et al. Standards Track [Page 6] RFC 6506 Authentication Trailer for OSPFv3 February 2012

    Currently, the following algorithms are supported:
  • HMAC-SHA-1,
  • HMAC-SHA-256,
  • HMAC-SHA-384, and
  • HMAC-SHA-512.
 o  Authentication Key
    This value denotes the Cryptographic Authentication Key associated
    with this OSPFv3 SA.  The length of this key is variable and
    depends upon the authentication algorithm specified by the OSPFv3
    SA.
 o  KeyStartAccept
    The time that this OSPFv3 router will accept packets that have
    been created with this OSPFv3 SA.
 o  KeyStartGenerate
    The time that this OSPFv3 router will begin using this OSPFv3 SA
    for OSPFv3 packet generation.
 o  KeyStopGenerate
    The time that this OSPFv3 router will stop using this OSPFv3 SA
    for OSPFv3 packet generation.
 o  KeyStopAccept
    The time that this OSPFv3 router will stop accepting packets
    generated with this OSPFv3 SA.
 In order to achieve smooth key transition, KeyStartAccept SHOULD be
 less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than
 KeyStopAccept.  If KeyStartGenerate or KeyStartAccept are left
 unspecified, the time will default to 0, and the key will be used
 immediately.  If KeyStopGenerate or KeyStopAccept are left
 unspecified, the time will default to infinity, and the key's
 lifetime will be infinite.  When a new key replaces an old, the
 KeyStartGenerate time for the new key MUST be less than or equal to
 the KeyStopGenerate time of the old key.

Bhatia, et al. Standards Track [Page 7] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 Key storage SHOULD persist across a system restart, warm or cold, to
 avoid operational issues.  In the event that the last key associated
 with an interface 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 operator and treat the key as
 having an infinite lifetime until the lifetime is extended, the key
 is deleted by the network operator, or a new key is configured.

4. Authentication Procedure

4.1. Authentication Trailer

 The Authentication Trailer that is appended to the OSPFv3 protocol
 packet is described below:
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Authentication Type      |        Auth Data Len          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |   Security Association ID     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Cryptographic Sequence Number (High-Order 32 Bits)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Cryptographic Sequence Number (Low-Order 32 Bits)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                Authentication Data (Variable)                 |
   ~                                                               ~
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 3: Authentication Trailer Format
 The various fields in the Authentication Trailer are:
 o  Authentication Type
    16-bit field identifying the type of authentication.  The
    following values are defined in this specification:
       0 - Reserved.
       1 - HMAC Cryptographic Authentication as described herein.

Bhatia, et al. Standards Track [Page 8] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 o  Auth Data Len
    The length in octets of the Authentication Trailer (AT) including
    both the 16-octet fixed header and the variable length message
    digest.
 o  Reserved
    This field is reserved.  It SHOULD be set to 0 when sending
    protocol packets and MUST be ignored when receiving protocol
    packets.
 o  Security Association Identifier (SA ID)
    16-bit field that maps to the authentication algorithm and the
    secret key used to create the message digest appended to the
    OSPFv3 protocol packet.
    Though the SA ID implicitly implies the algorithm, the HMAC output
    size should not be used by implementers as an implicit hint
    because additional algorithms may be defined in the future that
    have the same output size.
 o  Cryptographic Sequence Number
    64-bit strictly increasing sequence number that is used to guard
    against replay attacks.  The 64-bit sequence number MUST be
    incremented for every OSPFv3 packet sent by the OSPFv3 router.
    Upon reception, the sequence number MUST be greater than the
    sequence number in the last OSPFv3 packet accepted from the
    sending OSPFv3 neighbor.  Otherwise, the OSPFv3 packet is
    considered a replayed packet and dropped.
    OSPFv3 routers implementing this specification MUST use available
    mechanisms to preserve the sequence number's strictly increasing
    property for the deployed life of the OSPFv3 router (including
    cold restarts).  One mechanism for accomplishing this would be to
    use the high-order 32 bits of the sequence number as a wrap/boot
    count that is incremented anytime the OSPFv3 router loses its
    sequence number state.  Sequence number wrap is described in
    Section 4.1.1.
 o  Authentication Data
    Variable data that is carrying the digest for the protocol packet
    and optional LLS data block.

Bhatia, et al. Standards Track [Page 9] RFC 6506 Authentication Trailer for OSPFv3 February 2012

4.1.1. Sequence Number Wrap

 When incrementing the sequence number for each transmitted OSPFv3
 packet, the sequence number should be treated as an unsigned 64-bit
 value.  If the lower-order 32-bit value wraps, the higher-order
 32-bit value should be incremented and saved in non-volatile storage.
 If by some chance the OSPFv3 router is deployed long enough that
 there is a possibility that the 64-bit sequence number may wrap, all
 keys, independent of their key distribution mechanism, MUST be reset
 to avoid the possibility of replay attacks.  Once the keys have been
 changed, the higher-order sequence number can be reset to 0 and saved
 to non-volatile storage.

4.2. OSPFv3 Header Checksum

 Both OSPFv3 header checksum calculation and verification are omitted
 when the OSPFv3 authentication mechanism described in this
 specification is used.  This implies:
 o  For OSPFv3 packets to be transmitted, the OSPFv3 header checksum
    computation is omitted, and the OSPFv3 header checksum SHOULD be
    set to 0 prior to computation of the OSPFv3 Authentication Trailer
    message digest.
 o  For received OSPFv3 packets including an OSPFv3 Authentication
    Trailer, OSPFv3 header checksum verification MUST be omitted.
    However, if the OSPFv3 packet does include a non-zero OSPFv3
    header checksum, it will not be modified by the receiver and will
    simply be included in the OSPFv3 Authentication Trailer message
    digest verification.

4.3. Cryptographic Authentication Procedure

 As noted earlier, the SA ID maps to the authentication algorithm and
 the secret key used to generate and verify the message digest.  This
 specification discusses the computation of OSPFv3 Cryptographic
 Authentication data when any of the NIST SHS family of algorithms is
 used in the Hashed Message Authentication Code (HMAC) mode.

Bhatia, et al. Standards Track [Page 10] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 The currently valid algorithms (including mode) for OSPFv3
 Cryptographic Authentication include:
 o  HMAC-SHA-1,
 o  HMAC-SHA-256,
 o  HMAC-SHA-384, and
 o  HMAC-SHA-512.
 Of the above, implementations of this specification MUST include
 support for at least HMAC-SHA-256 and SHOULD include support for
 HMAC-SHA-1 and MAY also include support for HMAC-SHA-384 and
 HMAC-SHA-512.
 Implementations of this specification MUST use HMAC-SHA-256 as the
 default authentication algorithm.

4.4. Cross-Protocol Attack Mitigation

 In order to prevent cross-protocol replay attacks for protocols
 sharing common keys, the two-octet OSPFv3 Cryptographic Protocol ID
 is appended to the Authentication Key prior to use.  Other protocols
 using Cryptographic Authentication as specified herein MUST similarly
 append their respective Cryptographic Protocol IDs to their keys in
 this step.  Refer to the IANA Considerations (Section 7).

4.5. Cryptographic Aspects

 In the algorithm description below, the following nomenclature, which
 is consistent with [FIPS-198-1], is used:
 H is the specific hashing algorithm (e.g., SHA-256).
 K is the Authentication Key from the OSPFv3 Security Association.
 Ks is a Protocol-Specific Authentication Key obtained by appending
 Authentication Key (K) with the two-octet OSPFv3 Cryptographic
 Protocol ID.
 Ko is the cryptographic key used with the hash algorithm.

Bhatia, et al. Standards Track [Page 11] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 B is the block size of H, measured in octets rather than bits.  Note
 that B is the internal block size, not the hash size.
    For SHA-1 and SHA-256: B == 64
    For SHA-384 and SHA-512: B == 128
 L is the length of the hash, measured in octets rather than bits.
 XOR is the exclusive-or operation.
 Opad is the hexadecimal value 0x5c repeated B times.
 Ipad is the hexadecimal value 0x36 repeated B times.
 Apad is a value that is the same length as the hash output or message
 digest.  The first 16 octets contain the IPv6 source address followed
 by the hexadecimal value 0x878FE1F3 repeated (L-16)/4 times.  This
 implies that hash output is always a length of at least 16 octets.
 1.  Preparation of the Key
     The OSPFv3 Cryptographic Protocol ID is appended to the
     Authentication Key (K) yielding a Protocol-Specific
     Authentication Key (Ks).  In this application, Ko is always L
     octets long and is computed as follows:
        If the Protocol-Specific Authentication Key (Ks) is L octets
        long, then Ko is equal to K.  If the Protocol-Specific
        Authentication Key (Ks) is more than L octets long, then Ko is
        set to H(Ks).  If the Protocol-Specific Authentication Key
        (Ks) is less than L octets long, then Ko is set to the
        Protocol-Specific Authentication Key (Ks) with zeros appended
        to the end of the Protocol-Specific Authentication Key (Ks)
        such that Ko is L octets long.
 2.  First-Hash
     First, the OSPFv3 packet's Authentication Data field in the
     Authentication Trailer is filled with the value Apad.  This is
     very similar to the appendage described in [RFC2328], Section
     D.4.3, Items (6)(a) and (6)(d)).
     Then, a First-Hash, also known as the inner hash, is computed as
     follows:
        First-Hash = H(Ko XOR Ipad || (OSPFv3 Packet))

Bhatia, et al. Standards Track [Page 12] RFC 6506 Authentication Trailer for OSPFv3 February 2012

        Implementation Note: The First-Hash above includes the
        Authentication Trailer, as well as the OSPFv3 packet, as per
        [RFC2328], Section D.4.3, and, if present, the LLS data block
        [RFC5613].
     The definition of Apad (above) ensures it is always the same
     length as the hash output.  This is consistent with RFC 2328.
     Note that the "(OSPFv3 Packet)" referenced in the First-Hash
     function above includes both the optional LLS data block and the
     OSPFv3 Authentication Trailer.
     The digest length for SHA-1 is 20 octets; for SHA-256, 32 octets;
     for SHA-384, 48 octets; and for SHA-512, 64 octets.
 3.  Second-Hash
     Then a Second-Hash, also known as the outer hash, is computed as
     follows:
        Second-Hash = H(Ko XOR Opad || First-Hash)
 4.  Result
     The resulting Second-Hash becomes the authentication data that is
     sent in the Authentication Trailer of the OSPFv3 packet.  The
     length of the authentication data is always identical to the
     message digest size of the specific hash function H that is being
     used.
     This also means that the use of hash functions with larger output
     sizes will also increase the size of the OSPFv3 packet as
     transmitted on the wire.
        Implementation Note: [RFC2328], Appendix D specifies that the
        Authentication Trailer is not counted in the OSPF packet's own
        Length field but is included in the packet's IP Length field.
        Similar to this, the Authentication Trailer is not included in
        the OSPFv3 header length but is included in the IPv6 header
        payload length.

4.6. Message Verification

 A router would determine that OSPFv3 is using an Authentication
 trailer by examining the AT-bit in the Options field in the OSPFv3
 header for Hello and Database Description packets.  The specification
 in the Hello and Database Description options indicates that other
 OSPFv3 packets will include the Authentication Trailer.

Bhatia, et al. Standards Track [Page 13] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 The Authentication Trailer (AT) is accessed using the OSPFv3 packet
 header length to access the data after the OSPFv3 packet and, if an
 LLS data block [RFC5613] is present, using the LLS data block length
 to access the data after the LLS data block.  The L-bit in the OSPFv3
 options in Hello and Database Description packets is examined to
 determine if an LLS data block is present.  If an LLS data block is
 present (as specified by the L-bit), it is included along with the
 OSPFv3 Hello or Database Description packet in the cryptographic
 authentication computation.
 Due to the placement of the AT following the LLS data block and the
 fact that the LLS data block is included in the Cryptographic
 Authentication computation, OSPFv3 routers supporting this
 specification MUST minimally support examining the L-bit in the
 OSPFv3 options and using the length in the LLS data block to access
 the AT.  It is RECOMMENDED that OSPFv3 routers supporting this
 specification fully support OSPFv3 Link-Local Signaling [RFC5613].
 If usage of the Authentication Trailer (AT), as specified herein, is
 configured for an OSPFv3 link, OSPFv3 Hello and Database Description
 packets with the AT-bit clear in the options will be dropped.  All
 OSPFv3 packet types will be dropped if AT is configured for the link
 and the IPv6 header length is less than the amount necessary to
 include an Authentication Trailer.
 If the cryptographic sequence number in the AT is less than or equal
 to the last sequence number successfully received from the neighbor,
 the OSPFv3 packet MUST be dropped, and an error event SHOULD be
 logged.
 Authentication-algorithm-dependent processing needs to be performed,
 using the algorithm specified by the appropriate OSPFv3 SA for the
 received packet.
 Before an implementation performs any processing, it needs to save
 the values of the Authentication Data field from the Authentication
 Trailer appended to the OSPFv3 packet.
 It should then set the Authentication Data field with Apad before the
 authentication data is computed (as described in Section 4.5).  The
 calculated data is compared with the received authentication data in
 the Authentication Trailer.  If the two do not match, the packet MUST
 be discarded and an error event SHOULD be logged.
 After the OSPFv3 packet has been successfully authenticated,
 implementations MUST store the 64-bit cryptographic sequence number
 for future replay checks.

Bhatia, et al. Standards Track [Page 14] RFC 6506 Authentication Trailer for OSPFv3 February 2012

5. Migration and Backward Compatibility

 All OSPFv3 routers participating on a link SHOULD be migrated to
 OSPFv3 Authentication at the same time.  As with OSPFv2
 authentication, a mismatch in the SA ID, Authentication Type, or
 message digest will result in failure to form an adjacency.  For
 multi-access links, communities of OSPFv3 routers could be migrated
 using different Interface Instance IDs.  However, at least one router
 would need to form adjacencies between both the OSPFv3 routers
 including and not including the Authentication Trailer.  This would
 result in sub-optimal routing as well as added complexity and is only
 recommended in cases where authentication is desired on the link and
 migrating all the routers on the link at the same time isn't
 feasible.
 In support of uninterrupted deployment, an OSPFv3 router implementing
 this specification MAY implement a transition mode where it includes
 the Authentication Trailer in transmitted packets but does not verify
 this information in received packets.  This is provided as a
 transition aid for networks in the process of migrating to the
 authentication mechanism described in this specification.

6. Security Considerations

 The document proposes extensions to OSPFv3 that would make it more
 secure than [RFC5340].  It does not provide confidentiality as a
 routing protocol contains information that does not need to be kept
 secret.  It does, however, provide means to authenticate the sender
 of the packets that are of interest.  It addresses all the security
 issues that have been identified in [RFC6039].
 It should be noted that the authentication method described in this
 document is not being used to authenticate the specific originator of
 a packet but is rather being used to confirm that the packet has
 indeed been issued by a router that has access to the Authentication
 Key.
 Deployments SHOULD use sufficiently long and random values for the
 Authentication Key so that guessing and other cryptographic attacks
 on the key are not feasible in their environments.  Furthermore, it
 is RECOMMENDED that Authentication Keys incorporate at least 128
 pseudo-random bits to minimize the risk of such attacks.  In support
 of these recommendations, management systems SHOULD support
 hexadecimal input of Authentication Keys.

Bhatia, et al. Standards Track [Page 15] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 The mechanism described herein is not perfect and does not need to be
 perfect.  Instead, this mechanism represents a significant increase
 in the effort required for an adversary to successfully attack the
 OSPFv3 protocol while not causing undue implementation, deployment,
 or operational complexity.
 Refer to [RFC4552] for additional considerations on manual keying.

7. IANA Considerations

 IANA has allocated the AT-bit (0x000400) in the "OSPFv3 Options (24
 bits)" registry as described in Section 2.1.
 IANA has created the "OSPFv3 Authentication Trailer Options"
 registry.  This new registry initially includes the "OSPFv3
 Authentication Types" registry, which defines valid values for the
 Authentication Type field in the OSPFv3 Authentication Trailer.  The
 registration procedure is Standards Action.
       +-------------+-----------------------------------+
       | Value/Range | Designation                       |
       +-------------+-----------------------------------+
       | 0           | Reserved                          |
       |             |                                   |
       | 1           | HMAC Cryptographic Authentication |
       |             |                                   |
       | 2-65535     | Unassigned                        |
       +-------------+-----------------------------------+
                  OSPFv3 Authentication Types

Bhatia, et al. Standards Track [Page 16] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 Finally, IANA has created the "Keying and Authentication for Routing
 Protocols (KARP) Parameters" category.  This new category initially
 includes the "Authentication Cryptographic Protocol ID" registry,
 which provides unique protocol-specific values for cryptographic
 applications, such as but not limited to, prevention of cross-
 protocol replay attacks.  Values can be assigned for both native
 IPv4/IPv6 protocols and UDP/TCP protocols.  The registration
 procedure is Standards Action.
       +-------------+----------------------+
       | Value/Range | Designation          |
       +-------------+----------------------+
       | 0           | Reserved             |
       |             |                      |
       | 1           | OSPFv3               |
       |             |                      |
       | 2-65535     | Unassigned           |
       +-------------+----------------------+
            Cryptographic Protocol ID

8. References

8.1. Normative References

 [RFC2119]     Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2328]     Moy, J., "OSPF Version 2", STD 54, RFC 2328,
               April 1998.
 [RFC5340]     Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
               for IPv6", RFC 5340, July 2008.
 [RFC5709]     Bhatia, M., Manral, V., Fanto, M., White, R., Barnes,
               M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA
               Cryptographic Authentication", RFC 5709, October 2009.

8.2. Informative References

 [FIPS-180-3]  US National Institute of Standards and Technology,
               "Secure Hash Standard (SHS)", FIPS PUB 180-3,
               October 2008.
 [FIPS-198-1]  US National Institute of Standards and Technology, "The
               Keyed-Hash Message Authentication Code (HMAC)", FIPS
               PUB 198, July 2008.

Bhatia, et al. Standards Track [Page 17] RFC 6506 Authentication Trailer for OSPFv3 February 2012

 [MANUAL-KEY]  Bhatia, M., Hartman, S., Zhang, D., and A. Lindem,
               "Security Extension for OSPFv2 when using Manual Key
               Management", Work in Progress, October 2011.
 [RFC2104]     Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
               Keyed-Hashing for Message Authentication", RFC 2104,
               February 1997.
 [RFC4302]     Kent, S., "IP Authentication Header", RFC 4302,
               December 2005.
 [RFC4303]     Kent, S., "IP Encapsulating Security Payload (ESP)",
               RFC 4303, December 2005.
 [RFC4552]     Gupta, M. and N. Melam, "Authentication/Confidentiality
               for OSPFv3", RFC 4552, June 2006.
 [RFC5613]     Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
               Yeung, "OSPF Link-Local Signaling", RFC 5613,
               August 2009.
 [RFC5996]     Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
               "Internet Key Exchange Protocol Version 2 (IKEv2)",
               RFC 5996, September 2010.
 [RFC6039]     Manral, V., Bhatia, M., Jaeggli, J., and R. White,
               "Issues with Existing Cryptographic Protection Methods
               for Routing Protocols", RFC 6039, October 2010.
 [RFC6234]     Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
               (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.

Bhatia, et al. Standards Track [Page 18] RFC 6506 Authentication Trailer for OSPFv3 February 2012

Appendix A. Acknowledgments

 First and foremost, thanks to the authors of RFC 5709 [RFC5709], from
 which this work was derived.
 Thanks to Sam Hartman for discussions on replay mitigation and the
 use of a 64-bit strictly increasing sequence number.  Also, thanks to
 Sam for comments during IETF last call with respect to the OSPFv3 SA
 and sharing of key between protocols.
 Thanks to Michael Barnes for numerous comments and strong input on
 the coverage of LLS by the Authentication Trailer (AT).
 Thanks to Rajesh Shetty for numerous comments, including the
 suggestion to include an Authentication Type field in the
 Authentication Trailer for extendibility.
 Thanks to Uma Chunduri for suggesting that we may want to protect the
 IPv6 source address even though OSPFv3 uses the Router ID for
 neighbor identification.
 Thanks to Srinivasan KL, Shraddha H, Alan Davey, Russ White, Stan
 Ratliff, and Glen Kent for their support and review comments.
 Thanks to Alia Atlas for comments made under the purview of the
 Routing Directorate review.
 Thanks to Stephen Farrell for comments during the IESG review.
 Stephen was also involved in the discussion of cross-protocol
 attacks.

Bhatia, et al. Standards Track [Page 19] RFC 6506 Authentication Trailer for OSPFv3 February 2012

Authors' Addresses

 Manav Bhatia
 Alcatel-Lucent
 Bangalore
 India
 EMail: manav.bhatia@alcatel-lucent.com
 Vishwas Manral
 Hewlett Packard
 USA
 EMail: vishwas.manral@hp.com
 Acee Lindem
 Ericsson
 102 Carric Bend Court
 Cary, NC 27519
 USA
 EMail: acee.lindem@ericsson.com

Bhatia, et al. Standards Track [Page 20]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6506.txt · Last modified: 2012/02/14 06:11 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki