doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc5304.txt b/doc/rfc/rfc5304.txt
new file mode 100644
index 0000000..cdf373f
--- /dev/null
+++ b/doc/rfc/rfc5304.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                              T. Li
+Request for Comments: 5304                        Redback Networks, Inc.
+Obsoletes: 3567                                              R. Atkinson
+Updates: 1195                                     Extreme Networks, Inc.
+Category: Standards Track                                   October 2008
+
+
+                   IS-IS Cryptographic Authentication
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes the authentication of Intermediate System to
+   Intermediate System (IS-IS) Protocol Data Units (PDUs) using the
+   Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5)
+   algorithm as found in RFC 2104.  IS-IS is specified in International
+   Standards Organization (ISO) 10589, with extensions to support
+   Internet Protocol version 4 (IPv4) described in RFC 1195.  The base
+   specification includes an authentication mechanism that allows for
+   multiple authentication algorithms.  The base specification only
+   specifies the algorithm for cleartext passwords.  This document
+   replaces RFC 3567.
+
+   This document proposes an extension to that specification that allows
+   the use of the HMAC-MD5 authentication algorithm to be used in
+   conjunction with the existing authentication mechanisms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li & Atkinson               Standards Track                     [Page 1]
+
+RFC 5304           IS-IS Cryptographic Authentication       October 2008
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Authentication Procedures . . . . . . . . . . . . . . . . . . . 3
+     2.1.  Implementation Considerations . . . . . . . . . . . . . . . 5
+   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+     3.1.  Security Limitations  . . . . . . . . . . . . . . . . . . . 5
+     3.2.  Assurance . . . . . . . . . . . . . . . . . . . . . . . . . 6
+     3.3.  Key Configuration . . . . . . . . . . . . . . . . . . . . . 6
+     3.4.  Other Considerations  . . . . . . . . . . . . . . . . . . . 7
+     3.5.  Future Directions . . . . . . . . . . . . . . . . . . . . . 7
+   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
+   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
+     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li & Atkinson               Standards Track                     [Page 2]
+
+RFC 5304           IS-IS Cryptographic Authentication       October 2008
+
+
+1.  Introduction
+
+   The IS-IS protocol, as specified in [ISO-10589], provides for the
+   authentication of Link State Protocol Data Units (LSPs) through the
+   inclusion of authentication information as part of the LSP.  This
+   authentication information is encoded as a Type-Length-Value (TLV)
+   tuple.  The use of IS-IS for IPv4 networks is described in [RFC1195].
+
+   The type of the TLV is specified as 10.  The length of the TLV is
+   variable.  The value of the TLV depends on the authentication
+   algorithm and related secrets being used.  The first octet of the
+   value is used to specify the authentication type.  Type 0 is
+   reserved, type 1 indicates a cleartext password, and type 255 is used
+   for routing domain private authentication methods.  The remainder of
+   the TLV value is known as the Authentication Value.
+
+   This document extends the above situation by allocating a new
+   authentication type for HMAC-MD5 and specifying the algorithms for
+   the computation of the Authentication Value.  This document also
+   describes modifications to the base protocol to ensure that the
+   authentication mechanisms described in this document are effective.
+
+   This document is a publication of the IS-IS Working Group within the
+   IETF.  This document replaces [RFC3567], which is an Informational
+   RFC.  This document is on the Standards Track.  This document has
+   revised Section 3, with the significant addition of a discussion of
+   recent attacks on MD5 in Section 3.2.  This document has also added a
+   substantive "IANA Considerations" section to create a missing
+   codepoint registry.
+
+   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 [RFC2119].
+
+2.  Authentication Procedures
+
+   The authentication type used for HMAC-MD5 is 54 (0x36).  The length
+   of the Authentication Value for HMAC-MD5 is 16, and the length field
+   in the TLV is 17.
+
+   The HMAC-MD5 algorithm requires a key K and text T as input
+   [RFC2104].  The key K is the password for the PDU type, as specified
+   in ISO 10589.  The text T is the IS-IS PDU to be authenticated with
+   the Authentication Value field (inside of the Authentication
+   Information TLV) set to zero.  Note that the Authentication Type is
+   set to 54 and the length of the TLV is set to 17 before
+   authentication is computed.  When LSPs are authenticated, the
+
+
+
+
+Li & Atkinson               Standards Track                     [Page 3]
+
+RFC 5304           IS-IS Cryptographic Authentication       October 2008
+
+
+   Checksum and Remaining Lifetime fields are set to zero (0) before
+   authentication is computed.  The result of the algorithm is placed in
+   the Authentication Value field.
+
+   When calculating the HMAC-MD5 result for Sequence Number PDUs, Level
+   1 Sequence Number PDUs SHALL use the Area Authentication string as in
+   Level 1 Link State PDUs.  Level 2 Sequence Number PDUs SHALL use the
+   domain authentication string as in Level 2 Link State PDUs.  IS-IS
+   Hello PDUs SHALL use the Link Level Authentication String, which MAY
+   be different from that of Link State PDUs.  The HMAC-MD5 result for
+   the IS-IS Hello PDUs SHALL be calculated after the packet is padded
+   to the MTU size, if padding is not disabled.  Implementations that
+   support the optional checksum for the Sequence Number PDUs and IS-IS
+   Hello PDUs MUST NOT include the Checksum TLV.
+
+   To authenticate an incoming PDU, a system should save the values of
+   the Authentication Value field, the Checksum field, and the Remaining
+   Lifetime field, set these fields to zero, compute authentication, and
+   then restore the values of these fields.
+
+   An implementation that implements HMAC-MD5 authentication and
+   receives HMAC-MD5 Authentication Information MUST discard the PDU if
+   the Authentication Value is incorrect.
+
+   An implementation MAY have a transition mode where it includes HMAC-
+   MD5 Authentication Information in PDUs but does not verify the HMAC-
+   MD5 Authentication Information.  This is a transition aid for
+   networks in the process of deploying authentication.
+
+   An implementation MAY check a set of passwords when verifying the
+   Authentication Value.  This provides a mechanism for incrementally
+   changing passwords in a network.
+
+   An implementation that does not implement HMAC-MD5 authentication MAY
+   accept a PDU that contains the HMAC-MD5 Authentication Type.  ISes
+   (routers) that implement HMAC-MD5 authentication and initiate LSP
+   purges MUST remove the body of the LSP and add the authentication
+   TLV.  ISes implementing HMAC-MD5 authentication MUST NOT accept
+   unauthenticated purges.  ISes MUST NOT accept purges that contain
+   TLVs other than the authentication TLV.  These restrictions are
+   necessary to prevent a hostile system from receiving an LSP, setting
+   the Remaining Lifetime field to zero, and flooding it, thereby
+   initiating a purge without knowing the authentication password.
+
+
+
+
+
+
+
+
+Li & Atkinson               Standards Track                     [Page 4]
+
+RFC 5304           IS-IS Cryptographic Authentication       October 2008
+
+
+2.1.  Implementation Considerations
+
+   There is an implementation issue that occurs just after password
+   rollover on an IS-IS router and that might benefit from additional
+   commentary.  Immediately after password rollover on the router, the
+   router or IS-IS process may restart.  If this happens, this causes
+   the LSP Sequence Number to restart from the value 1 using the new
+   password.  However, neighbors will reject those new LSPs because the
+   Sequence Number is smaller.  The router cannot increase its own LSP
+   Sequence Number because it fails to authenticate its own old LSP that
+   neighbors keep sending to it.  So the router cannot update its LSP
+   Sequence Number to its neighbors until all the neighbors time out all
+   of the original LSPs.  One possible solution to this problem is for
+   the IS-IS process to detect if any inbound LSP with an authentication
+   failure has the local System ID and also has a higher Sequence Number
+   than the IS-IS process has.  In this event, the IS-IS process SHOULD
+   increase its own LSP Sequence Number accordingly and re-flood the
+   LSPs.  However, as this scenario could also be triggered by an active
+   attack by an adversary, it is recommended that a counter be kept on
+   this case to mitigate the risk from such an attack.
+
+3.  Security Considerations
+
+   This document enhances the security of the IS-IS routing protocol.
+   Because a routing protocol contains information that need not be kept
+   secret, privacy is not a requirement.  However, authentication of the
+   messages within the protocol is of interest in order to reduce the
+   risk of an adversary compromising the routing system by deliberately
+   injecting false information into that system.
+
+3.1.  Security Limitations
+
+   The technology in this document provides an authentication mechanism
+   for IS-IS.  The mechanism described here is not perfect and does not
+   need to be perfect.  Instead, this mechanism represents a significant
+   increase in the work function of an adversary attacking the IS-IS
+   protocol, while not causing undue implementation, deployment, or
+   operational complexity.  It provides improved security against
+   passive attacks, as defined in [RFC1704], when compared to cleartext
+   password authentication.
+
+   This mechanism does not prevent replay attacks; however, in most
+   cases, such attacks would trigger existing mechanisms in the IS-IS
+   protocol that would effectively reject old information.  Denial-of-
+   service attacks are not generally preventable in a useful networking
+   protocol [DoS].
+
+
+
+
+
+Li & Atkinson               Standards Track                     [Page 5]
+
+RFC 5304           IS-IS Cryptographic Authentication       October 2008
+
+
+   The mechanisms in this document do not provide protection against
+   compromised, malfunctioning, or misconfigured routers.  Such routers
+   can, either accidentally or deliberately, cause malfunctions that
+   affect the whole routing domain.  The reader is encouraged to consult
+   [RFC4593] for a more comprehensive description of threats to routing
+   protocols.
+
+3.2.  Assurance
+
+   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 IS-IS implementations.  This mechanism also depends on
+   the IS-IS Authentication Key being kept confidential by all parties.
+   If any of these are incorrect or insufficiently secure, then no real
+   security will be provided to the users of this mechanism.
+
+   Since Dobbertin's attacks on MD5 [Dobb96a] [Dobb96b] [Dobb98] were
+   first published a dozen years ago, there have been growing concerns
+   about the effectiveness of the compression function within MD5.  More
+   recent work by Wang and Yu [WY05] accentuates these concerns.
+   However, despite these research results, there are no published
+   attacks at present on either Keyed-MD5 or HMAC-MD5.  A recent paper
+   by Bellare [Bell06a] [Bell06b] provides new proofs for the security
+   of HMAC that require fewer assumptions than previous published proofs
+   for HMAC.  Those proofs indicate that the published issues with MD5
+   (and separately with SHA-1) do not create an attack on HMAC-MD5 (or
+   HMAC SHA-1).  Most recently, Fouque and others [FLN07] have published
+   new attacks on NMAC-MD4, HMAC-MD4, and NMAC-MD5.  However, their
+   attacks are non-trivial computationally, and they have not found an
+   equivalent attack on HMAC-MD5.  So, despite the published issues with
+   the MD5 algorithm, there is currently no published attack that
+   applies to HMAC-MD5 as used in this IS-IS specification.  As with any
+   cryptographic technique, there is the possibility of the discovery of
+   future attacks against this mechanism.
+
+3.3.  Key Configuration
+
+   It should be noted that the key configuration mechanism of routers
+   may restrict the possible keys that may be used between peers.  It is
+   strongly recommended that an implementation be able to support, at
+   minimum, a key composed of a string of printable ASCII of 80 bytes or
+   less, as this is current practice.
+
+
+
+
+
+
+
+Li & Atkinson               Standards Track                     [Page 6]
+
+RFC 5304           IS-IS Cryptographic Authentication       October 2008
+
+
+3.4.  Other Considerations
+
+   Changes to the authentication mechanism described here (primarily: to
+   add a Key-ID field such as that of OSPFv2 and RIPv2) were considered
+   at some length, but ultimately were rejected.  The mechanism here was
+   already widely implemented in 1999.  As of this writing, this
+   mechanism is fairly widely deployed within the users interested in
+   cryptographic authentication of IS-IS.  The improvement provided by
+   the proposed revised mechanism was not large enough to justify the
+   change, given the installed base and lack of operator interest in
+   deploying a revised mechanism.
+
+   If and when a key management protocol appears that is both widely
+   implemented and easily deployed to secure routing protocols such as
+   IS-IS, a different authentication mechanism that is designed for use
+   with that key management schema could be added if desired.
+
+3.5.  Future Directions
+
+   If a stronger authentication were believed to be required, then the
+   use of a full digital signature [RFC2154] would be an approach that
+   should be seriously considered.  It was rejected for this purpose at
+   this time because the computational burden of full digital signatures
+   is believed to be much higher than is reasonable, given the current
+   threat environment in operational commercial networks.
+
+   If and when additional authentication mechanisms are defined (for
+   example, to provide a cryptographically stronger hash function), it
+   will also be necessary to define mechanisms that allow graceful
+   transition from the existing mechanisms (as defined in this document)
+   to any future mechanism.
+
+4.  IANA Considerations
+
+   IANA has created a new codepoint registry to administer the
+   Authentication Type codepoints for TLV 10.  This registry is part of
+   the existing IS-IS codepoints registry as established by [RFC3563]
+   and [RFC3359].  This registry is managed using the Designated Expert
+   policy as described in [RFC5226] and is called "IS-IS Authentication
+   Type Codes for TLV 10".
+
+   The values in the "IS-IS Authentication Type Codes for TLV 10"
+   registry should be recorded in decimal and should only be approved
+   after a designated expert, appointed by the IESG area director, has
+   been consulted.  The intention is that any allocation will be
+   accompanied by a published RFC.  However, the designated expert can
+   approve allocations once it seems clear that an RFC will be
+   published, allowing for the allocation of values prior to the
+
+
+
+Li & Atkinson               Standards Track                     [Page 7]
+
+RFC 5304           IS-IS Cryptographic Authentication       October 2008
+
+
+   document being approved for publication as an RFC.  New items should
+   be documented in a publicly and freely available specification.  We
+   should also allow external specifications to allocate and use the
+   IS-IS Authentication Type Codes maintained by this registry.
+
+   Initial values for the "IS-IS Authentication Type Codes for TLV 10"
+   registry are given below; future assignments are to be made through
+   Expert Review.  Assignments consist of an authentication type name
+   and its associated value.
+
+   +---------------------------------------------+-------+-------------+
+   | Authentication Type Code                    | Value | Reference   |
+   +---------------------------------------------+-------+-------------+
+   | Reserved                                    | 0     | [ISO-10589] |
+   | Cleartext Password                          | 1     | [ISO-10589] |
+   | ISO 10589 Reserved                          | 2     | [ISO-10589] |
+   | HMAC-MD5 Authentication                     | 54    | RFC 5304    |
+   | Routeing Domain private authentication      | 255   | [ISO-10589] |
+   | method                                      |       |             |
+   +---------------------------------------------+-------+-------------+
+
+5.  Acknowledgements
+
+   The authors would like to thank (in alphabetical order) Stephen
+   Farrell, Dave Katz, Steven Luong, Tony Przygienda, Nai-Ming Shen, and
+   Henk Smit for their comments and suggestions on this document.
+
+6.  References
+
+6.1.  Normative References
+
+   [ISO-10589]  ISO, "Intermediate System to Intermediate System intra-
+                domain routeing information exchange protocol for use in
+                conjunction with the protocol for providing the
+                connectionless-mode network service (ISO 8473)",
+                International Standard 10589:2002, Second Edition, 2002.
+
+   [RFC2104]    Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+                Hashing for Message Authentication", RFC 2104,
+                February 1997.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+Li & Atkinson               Standards Track                     [Page 8]
+
+RFC 5304           IS-IS Cryptographic Authentication       October 2008
+
+
+6.2.  Informative References
+
+   [Bell06a]    Bellare, M., "New Proofs for NMAC and HMAC: Security
+                without Collision-Resistance", Preliminary Version, in
+                Proceedings of Crypto 2006, Lecture Notes in Computer
+                Science, Vol. 4117, August 2006.
+
+   [Bell06b]    Bellare, M., "New Proofs for NMAC and HMAC: Security
+                without Collision-Resistance", August 2006, <http://
+                www-cse.ucsd.edu/users/mihir/papers/hmac-new.html>.
+
+   [DoS]        Voydock, V. and S. Kent, "Security Mechanisms in High-
+                level Networks", ACM Computing Surveys Vol. 15, No. 2,
+                June 1983.
+
+   [Dobb96a]    Dobbertin, H., "Cryptanalysis of MD5 Compress",
+                EuroCrypt Rump Session 1996, May 1996.
+
+   [Dobb96b]    Dobbertin, H., "The Status of MD5 After a Recent
+                Attack", CryptoBytes, Vol. 2, No. 2, 1996.
+
+   [Dobb98]     Dobbertin, H., "Cryptanalysis of MD4", Journal of
+                Cryptology, Vol. 11, No. 4, 1998.
+
+   [FLN07]      Fouque, P., Leurent, G., and P. Nguyen, "Full Key-
+                Recovery Attacks on HMAC/NMAC-MD5 and NMAC-MD5",
+                Proceedings of Crypto 2007, August 2007.
+
+   [RFC1195]    Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
+                dual environments", RFC 1195, December 1990.
+
+   [RFC1704]    Haller, N. and R. Atkinson, "On Internet
+                Authentication", RFC 1704, October 1994.
+
+   [RFC2154]    Murphy, S., Badger, M., and B. Wellington, "OSPF with
+                Digital Signatures", RFC 2154, June 1997.
+
+   [RFC3359]    Przygienda, T., "Reserved Type, Length and Value (TLV)
+                Codepoints in Intermediate System to Intermediate
+                System", RFC 3359, August 2002.
+
+   [RFC3563]    Zinin, A., "Cooperative Agreement Between the ISOC/IETF
+                and ISO/IEC Joint Technical Committee 1/Sub Committee 6
+                (JTC1/SC6) on IS-IS Routing Protocol Development",
+                RFC 3563, July 2003.
+
+
+
+
+
+
+Li & Atkinson               Standards Track                     [Page 9]
+
+RFC 5304           IS-IS Cryptographic Authentication       October 2008
+
+
+   [RFC3567]    Li, T. and R. Atkinson, "Intermediate System to
+                Intermediate System (IS-IS) Cryptographic
+                Authentication", RFC 3567, July 2003.
+
+   [RFC4593]    Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
+                Routing Protocols", RFC 4593, October 2006.
+
+   [RFC5226]    Narten, T. and H. Alvestrand, "Guidelines for Writing an
+                IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+                May 2008.
+
+   [WY05]       Wang, X. and H. Yu, "How to Break MD5 and Other Hash
+                Functions", Proceedings of EuroCrypt 2005, Lecture Notes
+                in Computer Science, Vol. 3494, 2005.
+
+Authors' Addresses
+
+   Tony Li
+   Redback Networks, Inc.
+   300 Holger Way
+   San Jose, CA  95134
+   USA
+
+   Phone: +1 408 750 5160
+   EMail: tony.li@tony.li
+
+
+   R. Atkinson
+   Extreme Networks, Inc.
+   3585 Monroe St.
+   Santa Clara, CA  95051
+   USA
+
+   Phone: +1 408 579 2800
+   EMail: rja@extremenetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Li & Atkinson               Standards Track                    [Page 10]
+
+RFC 5304           IS-IS Cryptographic Authentication       October 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Li & Atkinson               Standards Track                    [Page 11]
+