Design Considerations for Protocol Extensions
draft-iab-extension-recs-17



Internet Engineering Task Force (IETF)                     M. Sahni, Ed.
Request for Comments: 8954                            Palo Alto Networks
Updates: 6960                                              November 2020
Category: Standards Track                                               
ISSN: 2070-1721

       Online Certificate Status Protocol (OCSP) Nonce Extension

Abstract

   This document specifies the updated format of the Nonce extension in
   the Online Certificate Status Protocol (OCSP) request and response
   messages.  OCSP is used to check the status of a certificate, and the
   Nonce extension is used to cryptographically bind an OCSP response
   message to a particular OCSP request message.  This document updates
   RFC 6960.

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 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8954.

Copyright NoticeThis document shows some of the current implementations on the
      market have already outstripped the capabilities of the RADIUS
      protocol.  A quite a few features have been developed completely
      outside the protocol.  These features use the RADIUS protocol
      structure and format, but employ operations and semantics well
      beyond the RFC documents.

   The limited set of data types defined in [RFC2865] has lead to
   subsequent documents defining new data types.  Since new data types
   are typically defined implicitly as part of defining a new attribute,
   and because RADIUS client and server implementations differ in their
   support of these additional specifications, there is no definitive
   registry of RADIUS data types and data type support has been
   inconsistent.  To catalog commonly implemented data types as well as
   to provide guidance for implementers as well as attribute designers,
   "RADIUS Design Guidelines" [RFC6158] Section 2.1 includes advice on
   basic and complex data types.  Unfortunately, these guidelines were
   published 14 years after the RADIUS protocol was first documented in
   [RFC2058].

   Section 6.2 of the RADIUS specification [RFC2865] defines a mechanism
   for Vendor-Specific extensions (Attribute 26), and states that use of
   Vendor-Specific extensions:

      should be encouraged instead of allocation of global attribute
      types, for functions specific only to one vendor's implementation
      of RADIUS, where no interoperability is deemed useful.

   However, in practice usage of Vendor-Specific Attributes (VSAs) has
   been considerably broader than this.  In particular, VSAs have been
   used by Standards Development Organizations (SDOs) to define their
   own extensions to the RADIUS protocol.  This has caused a number of
   problems.

   One issue concerns the data model for VSAs.  Since it was not
   envisaged that multi-vendor VSA implementations would need to
   interoperate, the RADIUS specification [RFC2865] does not define the
   data model for VSAs, and allows multiple sub-attributes to be
   included within a single Attribute of type 26.  Since this enables
   VSAs to be defined which would not be supportable by current
   implementations if placed within the standard RADIUS attribute space,
   this has caused problems in standardizing widely deployed VSAs, as
   discussed in "RADIUS Design Guidelines" BCP 158 [RFC6158] Section
   2.4:

      RADIUS attributes can often be developed within the vendor space
      without loss (and possibly even with gain) in functionality.  As a
      result, translation of RADIUS attributes developed within the

IAB                           Informational                    [Page 36]
Internet-Draft    Design Considerations for Extensions      26 June 2012

      vendor space into the standard space may provide only modest
      benefits, while accelerating the exhaustion of the standard space.
      We do not expect that all RADIUS attribute specifications
      requiring interoperability will be developed within the IETF, and
      allocated from the standard space.  A more scalable approach is to
      recognize the flexibility of the vendor space, while working
      toward improvements in the quality and availability of RADIUS
      attribute specifications, regardless of where they are developed.

      It is therefore NOT RECOMMENDED that specifications intended
      solely for use by a vendor or SDO be translated into the standard
      space.

   Another issue is how implementations should handle unknown VSAs.
   [RFC2865] Section 5.26 states:

      Servers not equipped to interpret the vendor-specific information
      sent by a client MUST ignore it (although it may be reported).
      Clients which do not receive desired vendor-specific information
      SHOULD make an attempt to operate without it, although they may do
      so (and report they are doing so) in a degraded mode.

   However, since VSAs do not contain a "mandatory" bit, RADIUS clients
   and servers may not know whether it is safe to ignore unknown VSAs.
   For example, in the case where VSAs pertain to security (e.g.,
   Filters), it may not be safe to ignore them.  As a result, "Common
   Remote Authentication Dial In User Service (RADIUS) Implementation
   Issues and Suggested Fixes" [RFC5080] Section 2.5 includes the
   following caution:

      To avoid misinterpretation of service requests encoded within
      VSAs, RADIUS servers SHOULD NOT send VSAs containing service
      requests to RADIUS clients that are not known to understand them.
      For example, a RADIUS server should not send a VSA encoding a
      filter without knowledge that the RADIUS client supports the VSA.

   In addition to extending RADIUS by use of VSAs, SDOs have also
   defined new values of the Service-Type attribute in order to create
   new RADIUS commands.  Since the RADIUS specification [RFC2865]
   defined Service-Type values as being allocated First Come, First
   Served (FCFS), this permitted new RADIUS commands to be allocated
   without IETF review.  This oversight has since been fixed in "IANA
   Considerations for RADIUS" [RFC3575].

A.3.  TLS Extensions

   The Secure Sockets Layer (SSL) v2 protocol was developed by Netscape
   to be used to secure online transactions on the Internet.  It was

IAB                           Informational                    [Page 37]
Internet-Draft    Design Considerations for Extensions      26 June 2012

   later replaced by SSL v3, also developed by Netscape.  SSL v3 was
   then further developed by the IETF as the Transport Layer Security
   (TLS) 1.0 [RFC2246].

   The SSL v3 protocol was not explicitly specified to be extended.
   Even TLS 1.0 did not define an extension mechanism explicitly.
   However, extension "loopholes" were available.  Extension mechanisms
   were finally defined in "Transport Layer Security (TLS) Extensions"
   [RFC4366]:

      o  New versions
      o  New cipher suites
      o  Compression
      o  Expanded handshake messages
      o  New record types
      o  New handshake messages

   The protocol also defines how implementations should handle unknown
   extensions.

   Of the above extension methods, new versions and expanded handshake
   messages have caused the most interoperability problems.
   Implementations are supposed to ignore unknown record types but to
   reject unknown handshake messages.

   The new version support in SSL/TLS includes a capability to define
   new versions of the protocol, while allowing newer implementations to
   communicate with older implementations.  As part of this
   functionality, some Key Exchange methods include functionality to
   prevent version rollback attacks.

   The experience with this upgrade functionality in SSL and TLS is
   decidedly mixed:

    o  SSL v2 and SSL v3/TLS are not compatible.  It is possible to use
       SSL v2 protocol messages to initiate a SSL v3/TLS connection, but
       it is not possible to communicate with a SSL v2 implementation
       using SSL v3/TLS protocol messages.
    o  There are implementations that refuse to accept handshakes using
       newer versions of the protocol than they support.
    o  There are other implementations that accept newer versions, but
       have implemented the version rollback protection clumsily.

   The SSL v2 problem has forced SSL v3 and TLS clients to continue to
   use SSL v2 Client Hellos for their initial handshake with almost all
   servers until 2006, much longer than would have been desirable, in
   order to interoperate with old servers.

IAB                           Informational                    [Page 38]
Internet-Draft    Design Considerations for Extensions      26 June 2012

   The problem with incorrect handling of newer versions has also forced
   many clients to actually disable the newer protocol versions, either
   by default, or by automatically disabling the functionality, to be
   able to connect to such servers.  Effectively, this means that the
   version rollback protection in SSL and TLS is non-existent if talking
   to a fatally compromised older version.

   SSL v3 and TLS also permitted expansion of the Client Hello and
   Server Hello handshake messages.  This functionality was fully
   defined by the introduction of TLS Extensions, which makes it
   possible to add new functionality to the handshake, such as the name
   of the server the client is connecting to, request certificate status
   information, indicate Certificate Authority support, maximum record
   length, etc.  Several of these extensions also introduce new
   handshake messages.

   It has turned out that many SSL v3 and TLS implementations that do
   not support TLS Extensions, did not, as required by the protocol
   specifications, ignore the unknown extensions, but instead failed to
   establish connections.  Several of the implementations behaving in
   this manner are used by high profile Internet sites, such as online
   banking sites, and this has caused a significant delay in the
   deployment of clients supporting TLS Extensions, and several of the
   clients that have enabled support are using heuristics that allow
   them to disable the functionality when they detect a problem.

   Looking forward, the protocol version problem, in particular, can
   cause future security problems for the TLS protocol.  The strength of
   the digest algorithms (MD5 and SHA-1) used by SSL and TLS is
   weakening.  If MD5 and SHA-1 weaken to the point where it is feasible
   to mount successful attacks against older SSL and TLS versions, the
   current error recovery used by clients would become a security
   vulnerability (among many other serious problems for the Internet).

   To address this issue, TLS 1.2 [RFC5246] makes use of a newer
   cryptographic hash algorithm (SHA-256) during the TLS handshake by
   default.  Legacy ciphersuites can still be used to protect
   application data, but new ciphersuites are specified for data
   protection as well as for authentication within the TLS handshake.
   The hashing method can also be negotiated via a Hello extension.
   Implementations are encouraged to implement new ciphersuites, and to
   enable the negotiation of the ciphersuite used during a TLS session
   to be governed by policy, thus enabling a more rapid transition away
   from weakened ciphersuites.

   The lesson to be drawn from this experience is that it isn't
   sufficient to design extensibility carefully; it must also be
   implemented carefully by every implementer, without exception.  Test

IAB                           Informational                    [Page 39]
Internet-Draft    Design Considerations for Extensions      26 June 2012

   suites and certification programs can help provide incentives for
   implementers to pay attention to implementing extensibility
   mechanisms correctly.

A.4.  L2TP Extensions

   Layer Two Tunneling Protocol (L2TP) [RFC2661] carries Attribute-Value
   Pairs (AVPs), with most AVPs having no semantics to the L2TP protocol
   itself.  However, it should be noted that L2TP message types are
   identified by a Message Type AVP (Attribute Type 0) with specific AVP
   values indicating the actual message type.  Thus, extensions relating
   to Message Type AVPs would likely be considered major extensions.

   L2TP also provides for Vendor-Specific AVPs.  Because everything in
   L2TP is encoded using AVPs, it would be easy to define vendor-
   specific AVPs that would be considered major extensions.

   L2TP also provides for a "mandatory" bit in AVPs.  Recipients of L2TP
   messages containing AVPs they do not understand but that have the
   mandatory bit set, are expected to reject the message and terminate
   the tunnel or session the message refers to.  This leads to
   interesting interoperability issues, because a sender can include a
   vendor-specific AVP with the M-bit set, which then causes the
   recipient to not interoperate with the sender.  This sort of behavior
   is counter to the IETF ideals, as implementations of the IETF
   standard should interoperate successfully with other implementations
   and not require the implementation of non-IETF extensions in order to
   interoperate successfully.  Section 4.2 of the L2TP specification
   [RFC2661] includes specific wording on this point, though there was
   significant debate at the time as to whether such language was by
   itself sufficient.

   Fortunately, it does not appear that the potential problems described
   above have yet become a problem in practice.  At the time of this
   writing, the authors are not aware of the existence of any vendor-
   specific AVPs that also set the M-bit.

Change log [RFC Editor: please remove this section]

   -17: 2012-6-27.  Resolved issue 133.
   -16: 2012-6-26.  Resolved issue 176.
   -15: 2012-6-25.  Resolved issues 174 and 175.
   -14: 2012-6-09.  Resolved issue 169.
   -13: 2012-6-03.  Resolved issue 166.
   -12: 2012-5-27.  Resolved issues 127, 128, 129 and 161.
   -11: 2012-2-22.  Resolved issue 126.
   -10: 2012-2-12.  Resolved issues 106 and 108.
   -09: 2011-10-30. Resolved additional issues.

IAB                           Informational                    [Page 40]
Internet-Draft    Design Considerations for Extensions      26 June 2012

   -08: 2011-10-22. Resolved additional issues.
   -07: 2011-7-24.  Resolved issues raised in Call for Comment.
   -06: 2011-3-01.  Incorporated corrections and organizational updates.
   -05: 2011-2-04.  Added to the Security Considerations section.
   -04: 2011-2-01.  Added material on cryptographic agility.
   -03: 2011-1-25.  Updates and reorganization.
   -02: 2010-7-12.  Updates by Bernard Aboba.
   -01: 2010-4-07.  Updates by Stuart Cheshire.
   -00: 2009-4-24.  Updated boilerplate, author list.

   -04: 2008-10-24. Updated author addresses, editorial fixes.
   -03: 2008-10-17. Updated references, added material on versioning.
   -02: 2007-06-15. Reorganized Sections 2 and 3.
   -01: 2007-03-04. Updated according to comments, especially the wording
                    about TLS, added various specific examples.

   draft-carpenter-extension-recs-00: original version, 2006-10-12.
   Derived from draft-iesg-vendor-extensions-02.txt dated 2004-06-04 by
   focusing on architectural issues; the procedural issues were moved to
   RFC 4775.

Authors' Addresses

   Brian Carpenter
   Department of Computer Science
   University of Auckland
   PB 92019
   Auckland,   1142
   New Zealand

   Email: brian.e.carpenter@gmail.com

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   EMail: bernard_aboba@hotmail.com

   Stuart Cheshire
   Apple Computer, Inc.
   1 Infinite Loop
   Cupertino, CA 95014

   EMail: cheshire@apple.com

IAB                           Informational                    [Page 41]