Skip to main content

HTTP Transport Authentication
draft-schinazi-httpbis-transport-auth-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author David Schinazi
Last updated 2020-03-13 (Latest revision 2020-01-08)
Replaced by draft-schinazi-httpbis-unprompted-auth
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-schinazi-httpbis-transport-auth-02
Internet-Draft        HTTP Transport Authentication           March 2020

   Transport-Authentication: Signature u="am9obi5kb2U=";a=1.3.101.112;
   p="SW5zZXJ0IHNpZ25hdHVyZSBvZiBub25jZSBoZXJlIHdo
   aWNoIHRha2VzIDUxMiBiaXRzIGZvciBFZDI1NTE5IQ=="

4.2.  HMAC

   The "HMAC" Transport Authentication Scheme uses symmetric
   cyptography.  User agents possess a user-id and a secret key, and
   origin servers maintain a mapping of authorized user-ids to their
   associated secret key.  When using this scheme, the "u", "p", and "a"
   directives are REQUIRED.  The TLS keying material export label for
   this scheme is "EXPORTER-HTTP-Transport-Authentication-HMAC" and the
   associated context is empty.  The nonce is then HMACed using the
   selected HMAC algorithm and transmitted as the proof directive.

   For example, the user-id "john.doe" authenticating using HMAC-SHA-512
   [RFC6234] could produce the following header (lines are folded to
   fit):

   Transport-Authentication: HMAC u="am9obi5kb2U=";a=2.16.840.1.101.3.4.2.3;
   p="SW5zZXJ0IEhNQUMgb2Ygbm9uY2UgaGVyZSB3aGljaCB0YWtl
   cyA1MTIgYml0cyBmb3IgU0hBLTUxMiEhISEhIQ=="

5.  Proxy Considerations

   Since Transport Authentication authenticates the underlying transport
   by leveraging TLS keying material exporters, it cannot be
   transparently forwarded by proxies that terminate TLS.  However it
   can be sent over proxied connections when TLS is performed end-to-end
   (e.g., when using HTTP CONNECT proxies).

6.  Security Considerations

   Transport Authentication allows a user-agent to authenticate to an
   origin server while guaranteeing freshness and without the need for
   the server to transmit a nonce to the user agent.  This allows the
   server to accept authenticated clients without revealing that it
   supports or expects authentication for some resources.  It also
   allows authentication without the user agent leaking the presence of
   authentication to observers due to clear-text TLS Client Hello
   extensions.

7.  IANA Considerations

Schinazi                Expires 13 September 2020               [Page 5]
Internet-Draft        HTTP Transport Authentication           March 2020

7.1.  Transport-Authentication Header Field

   This document, if approved, requests IANA to register the "Transport-
   Authentication" header in the "Permanent Message Header Field Names"
   registry maintained at https://www.iana.org/assignments/message-
   headers/ (https://www.iana.org/assignments/message-headers/).

     +--------------------------+----------+--------------+---------------+
     |    Header Field Name     | Protocol |    Status    |   Reference   |
     +--------------------------+----------+--------------+---------------+
     | Transport-Authentication |   http   | experimental | This document |
     +--------------------------+----------+--------------+---------------+

7.2.  Transport Authentication Schemes Registry

   This document, if approved, requests IANA to create a new HTTP
   Transport Authentication Schemes Registry with the following entries:

     +---------------------------------+---------------+
     | Transport Authentication Scheme |   Reference   |
     +---------------------------------+---------------+
     |            Signature            | This document |
     +---------------------------------+---------------+
     |              HMAC               | This document |
     +---------------------------------+---------------+

7.3.  TLS Keying Material Exporter Labels

   This document, if approved, requests IANA to register the following
   entries in the "TLS Exporter Labels" registry maintained at
   https://www.iana.org/assignments/tls-parameters/tls-
   parameters.xhtml#exporter-labels (https://www.iana.org/assignments/
   tls-parameters/tls-parameters.xhtml#exporter-labels)

     +--------------------------------------------------+
     |                       Value                      |
     +--------------------------------------------------+
     | EXPORTER-HTTP-Transport-Authentication-Signature |
     +--------------------------------------------------+
     | EXPORTER-HTTP-Transport-Authentication-HMAC      |
     +--------------------------------------------------+

   Both of these entries are listed with the following qualifiers:

Schinazi                Expires 13 September 2020               [Page 6]
Internet-Draft        HTTP Transport Authentication           March 2020

     +---------+-------------+---------------+
     | DTLS-OK | Recommended |   Reference   |
     +---------+-------------+---------------+
     |    N    |      Y      | This document |
     +---------+-------------+---------------+

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3061]  Mealling, M., "A URN Namespace of Object Identifiers",
              RFC 3061, DOI 10.17487/RFC3061, February 2001,
              <https://www.rfc-editor.org/info/rfc3061>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC5705]  Rescorla, E., "Keying Material Exporters for Transport
              Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
              March 2010, <https://www.rfc-editor.org/info/rfc5705>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <https://www.rfc-editor.org/info/rfc7230>.

   [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Authentication", RFC 7235,
              DOI 10.17487/RFC7235, June 2014,
              <https://www.rfc-editor.org/info/rfc7235>.

   [RFC7405]  Kyzivat, P., "Case-Sensitive String Support in ABNF",
              RFC 7405, DOI 10.17487/RFC7405, December 2014,
              <https://www.rfc-editor.org/info/rfc7405>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC

Schinazi                Expires 13 September 2020               [Page 7]
Internet-Draft        HTTP Transport Authentication           March 2020

              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

8.2.  Informative References

   [I-D.ietf-quic-http]
              Bishop, M., "Hypertext Transfer Protocol Version 3
              (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-
              quic-http-27, 21 February 2020, <http://www.ietf.org/
              internet-drafts/draft-ietf-quic-http-27.txt>.

   [I-D.ietf-quic-tls]
              Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
              Work in Progress, Internet-Draft, draft-ietf-quic-tls-27,
              21 February 2020, <http://www.ietf.org/internet-drafts/
              draft-ietf-quic-tls-27.txt>.

   [I-D.ietf-quic-transport]
              Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", Work in Progress, Internet-Draft,
              draft-ietf-quic-transport-27, 21 February 2020,
              <http://www.ietf.org/internet-drafts/draft-ietf-quic-
              transport-27.txt>.

   [I-D.pauly-quic-datagram]
              Pauly, T., Kinnear, E., and D. Schinazi, "An Unreliable
              Datagram Extension to QUIC", Work in Progress, Internet-
              Draft, draft-pauly-quic-datagram-05, 4 November 2019,
              <http://www.ietf.org/internet-drafts/draft-pauly-quic-
              datagram-05.txt>.

   [I-D.schinazi-masque]
              Schinazi, D., "The MASQUE Protocol", Work in Progress,
              Internet-Draft, draft-schinazi-masque-02, 8 January 2020,
              <http://www.ietf.org/internet-drafts/draft-schinazi-
              masque-02.txt>.

   [I-D.vvv-webtransport-http3]
              Vasiliev, V., "WebTransport over HTTP/3", Work in
              Progress, Internet-Draft, draft-vvv-webtransport-http3-01,
              3 November 2019, <http://www.ietf.org/internet-drafts/
              draft-vvv-webtransport-http3-01.txt>.

Schinazi                Expires 13 September 2020               [Page 8]
Internet-Draft        HTTP Transport Authentication           March 2020

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

   [RFC7427]  Kivinen, T. and J. Snyder, "Signature Authentication in
              the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
              DOI 10.17487/RFC7427, January 2015,
              <https://www.rfc-editor.org/info/rfc7427>.

   [RFC8410]  Josefsson, S. and J. Schaad, "Algorithm Identifiers for
              Ed25519, Ed448, X25519, and X448 for Use in the Internet
              X.509 Public Key Infrastructure", RFC 8410,
              DOI 10.17487/RFC8410, August 2018,
              <https://www.rfc-editor.org/info/rfc8410>.

Acknowledgments

   The authors would like to thank many members of the IETF community,
   as this document is the fruit of many hallway conversations.  Using
   the OID for the signature and HMAC algorithms was inspired by
   Signature Authentication in IKEv2 [RFC7427].

Author's Address

   David Schinazi
   Google LLC
   1600 Amphitheatre Parkway
   Mountain View, California 94043,
   United States of America

   Email: dschinazi.ietf@gmail.com

Schinazi                Expires 13 September 2020               [Page 9]