RFC 7615

HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields

📅 published September 2015, from ietf

HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields ✨

Okay bestie, this one is from J. Reschke at greenbytes, and it's a Standards Track doc, which means it's the real deal 💅 It was published in September 2015 as RFC 7615, and it obsoletes RFC 2617 🎀 Its whole job is defining two response header fields, "Authentication-Info" and "Proxy-Authentication-Info," for HTTP auth schemes that need to send extra info back once the client's credentials have been accepted 🔐

Abstract

okay so the gist is this: this spec defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields. They're for HTTP authentication schemes that need to hand back some info after the client's credentials are accepted 🦋

Status of This Memo

this is an Internet Standards Track document 🌸 It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑 If you want more on Internet Standards, check Section 2 of RFC 5741. For the current status, any errata, or how to give feedback, go to http://www.rfc-editor.org/info/rfc7615 ✨

Copyright (c) 2015 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) as in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include the Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in that license 🫶

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The people who control the copyright in some of that material might not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 🙈 So unless you get an adequate license from those copyright holders, this document can't be modified outside the IETF Standards Process, and derivative works of it can't be created outside it either. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Notational Conventions  . . . . . . . . . . . . . . . . . . .   3
3.  The Authentication-Info Response Header Field . . . . . . . .   3
  3.1.  Parameter Value Format  . . . . . . . . . . . . . . . . .   4
4.  The Proxy-Authentication-Info Response Header Field . . . . .   4
5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
  7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   6
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1. Introduction 🧚

so this spec defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HTTP authentication schemes ([RFC7235]) that need to return info once the client's credentials have been accepted 💖

Both of these were originally defined in Section 3 of [RFC2617], which defined the HTTP "Digest" authentication scheme 🍓 This doc generalizes that description so it can be used not just for "Digest" ([RFC7616]), but also for other future schemes that have the same need to carry extra info during authentication ✨

2. Notational Conventions 🎀

This spec uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], plus a list extension from Section 7 of [RFC7230]. That extension lets you define comma-separated lists compactly with a '#' operator, kinda like how '*' means repetition 💅 The ABNF production for "auth-param" is defined in Section 2.1 of [RFC7235] 🦋

3. The Authentication-Info Response Header Field 🔐

HTTP auth schemes can use the Authentication-Info response header field to communicate info after the client's credentials have been accepted. This info can include a finalization message from the server, like server authentication 🫶

The field value is a list of parameters (name/value pairs) using the "auth-param" syntax from Section 2.1 of [RFC7235]. This spec only describes the generic format. Auth schemes that use Authentication-Info will define the individual parameters themselves. The "Digest" Authentication Scheme, for instance, defines multiple parameters in Section 3.5 of [RFC7616] 🌸

Authentication-Info = #auth-param

The Authentication-Info header field can be used in any HTTP response, no matter the request method or status code 🌈 Its semantics are defined by the authentication scheme named in the Authorization header field ([RFC7235], Section 4.2) of the corresponding request 👑

a proxy forwarding a response is not allowed to modify the field value in any way 🚫

Authentication-Info can also be used inside trailers ([RFC7230], Section 4.1.2), but only when the auth scheme explicitly allows it 🧚

3.1. Parameter Value Format 🍓

Parameter values can be written either as "token" or as "quoted-string" (Section 3.2.6 of [RFC7230]) ✨

Auth scheme definitions need to allow both notations, for both senders and recipients. That way recipients can use generic parsing components, no matter which auth scheme is in use 💖

For backwards compatibility, auth scheme definitions can restrict senders to one of the two variants. This can matter a lot when it's known that deployed implementations will fail when they run into one of the two formats 😭

4. The Proxy-Authentication-Info Response Header Field 🦋

The Proxy-Authentication-Info response header field is basically the same as Authentication-Info, except it applies to proxy authentication ([RFC7235], Section 2). Its semantics are defined by the auth scheme named in the Proxy-Authorization header field ([RFC7235], Section 4.4) of the corresponding request 💜

Proxy-Authentication-Info = #auth-param

Here's the twist, though: unlike Authentication-Info, Proxy-Authentication-Info only applies to the next outbound client on the response chain 🔥 That's because only the client that picked a given proxy is likely to have the credentials needed for authentication. Now, when multiple proxies live in the same administrative domain, like office and regional caching proxies inside a big corporate network, it's common for the user agent to generate credentials and pass them through the hierarchy until one of them gets used 🏢 So in that kind of setup, it'll look like Proxy-Authentication-Info is being forwarded, because each proxy sends the same field value 🙈✨

5. Security Considerations 💀

Adding info to HTTP responses that get sent over an unencrypted channel can affect security and privacy 🚨 The presence of these header fields alone tells everyone that HTTP authentication is in use. Any extra info could also get exposed through the contents of the authentication-scheme specific parameters, so the definitions of those schemes will have to take this into account 🔐

6. IANA Considerations 🌸

HTTP header fields are registered in the "Message Headers" registry, located at http://www.iana.org/assignments/message-headers, as defined by [BCP90] 📋

This document updates the definitions of the "Authentication-Info" and "Proxy-Authentication-Info" header fields, so the "Permanent Message Header Field Names" registry has been updated to match 🎀

+---------------------------+----------+----------+-----------------+
| Header Field Name         | Protocol | Status   | Reference       |
+---------------------------+----------+----------+-----------------+
| Authentication-Info       | http     | standard | Section 3 of    |
|                           |          |          | this document   |
| Proxy-Authentication-Info | http     | standard | Section 4 of    |
|                           |          |          | this document   |
+---------------------------+----------+----------+-----------------+

7. References 📚

7.1. Normative References 💖

7.2. Informative References 🦋

Acknowledgements 🫶

This doc is based on the header field definitions in RFCs 2069 and 2617, whose authors are John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, Eric W. Sink, and Lawrence C. Stewart 👑

Extra thanks go to the members of the HTTPAUTH and HTTPBIS Working Groups: Amos Jeffries, Benjamin Kaduk, Alexey Melnikov, Mark Nottingham, Yutaka Oiwa, Rifaat Shekh-Yusef, and Martin Thomson 🌈

Author's Address 🧚

Julian F. Reschke
greenbytes GmbH
Hafenweg 16
Muenster, NW  48155
Germany

Email: julian.reschke@greenbytes.de
URI:   http://greenbytes.de/tech/webdav/
📦 where this page comes from