Attached is my suggested starting point for the “how to use a token” part of
OAuth.
It defines 3 schemes:
Authorization: ID a=”…” (or in URI or POST)
* quite like WRAP, but with shorter labels, a smidgen of “discovery”, and no
explicit tie to OAuth delegation
Authorization: MAC m=”hmac-sha-256” u=”user-id” a=”authz-info” …
s=”hgasdag76sa7as”
* a MAC over selected parts of an HTTP request, with a bit of negotiation, and
no explicit tie to OAuth delegation
Authorization: SIG m=”rsa…” … s=”hgasjGHfHGFhgFHGfHGFGFghfHdag76sa7as”
* a digital signature over selected parts of an HTTP request, like MAC but with
public-key crypto
P.S. It is formatted as an (incomplete) internet-draft since that is what it
needs to head to, but it has not be submitted to the IETF draft system.
--
James Manger
> ----------
> From: Eran Hammer-Lahav
> Sent: Friday, 5 February 2010 6:29 PM
> To: OAuth WG ([email protected])
> Subject: [OAUTH-WG] Which draft to use as a starting point for 'using a
> token'?
>
> …
> We have three options for moving forward with 'how to use a token'.
> Start with:
>
> 1. draft-ietf-oauth-authentication
> 2. draft-hammer-http-token-auth
> 3. something else*
> …
> Pick.
Network Working Group James Manger
Internet-Draft
Intended status: Standards Track February 13, 2010
Expires: August 17, 2010
ID, MAC and SIG authentication schemes for HTTP
draft-manger-id-mac-sig
Abstract
This document specifies three schemes for carrying authentication
and/or authorization information in HTTP requests.
The MAC scheme signs an HTTP request with a symmetric shared secret.
The SIG scheme signs an HTTP request with an asymmetric key,
ie using public key cryptography.
The ID scheme does not authenticate the client, but transports
some authorization information (eg a bearer token).
Status of this Memo
This document describes ideas for the "use a token" (a.k.a
authentication) part of the IETF OAuth groups work
(as opposed to the "get a token" (authorization) part that
is the groups primary purpose).
It is formatted like an internet-draft, but has not been
submitted as one.
1. Introduction
This document specifies three schemes for carrying authentication
and/or authorization information in HTTP requests.
The MAC scheme signs an HTTP request with a symmetric shared secret.
The SIG scheme signs an HTTP request with an asymmetric key,
ie using public key cryptography.
The ID scheme does not authenticate the client, but is still useful
where being the bearer of authorization information is sufficient.
The schemes operate in 1 pass. That is, they do not require a
challenge from the server before a request can be made.
This is important for efficient operation in some situations,
but it does limit the security properties that the schemes can offer.
For instance, the schemes do not authenticate the server to the
client. It also limits the replay protection that is likely to be
provided by many servers.
2. ID scheme
The ID scheme conveys authorization information from a client to
a server.
A server can indicate that it supports the ID scheme by returning
a WWW-Authentication response header, typically in a
"401 Unauthorized" response to a request missing any authorization
information.
WWW-Authenticate: ID realm="..." [q="..."] [p="..."]
The "realm" parameter is specified in RFC2617.
The "q" parameter specifies the name of a URI query parameter.
The presence of the "q" parameter indicates that the client MAY
provide the authorization information as the value of a URI query
parameter with the given name.
The "p" parameter specifies the name of a form parameter.
The presence of the "p" parameter indicates that the client MAY
provide the authorization information as the value of a parameter
with the given name in a application/x-www-form-urlencoded
request body.
The client MAY always send the authorization information in an
Authorization request header, regardless of the presence or absence
or the "q" and "p" parameters in a WWW-Authenticate header.
Clients are RECOMMENDED to use the Authorization request header
whenever possible so any intermediary components can recognize
that the authorization information is security-related.
Authorization: ID a="..."
The "a" parameter holds the authorization information.
The authorization information SHALL only use the following
65 characters: A-Z a-z 0-9 . - _
This avoids the need to escape the authorization information
regardless of how it is transported. This character restriction
applies even if the server does not support the "p" or "q" options.
The base64url encoding [RFC4648] can be used to convert arbitrary
bytes into a string using only the characters allowed for the
authorization information.
3. MAC scheme
The MAC scheme calculates a message authentication code over
selected portions of an HTTP request, using a symmetric shared
secret.
3.1. WWW-Authenticate response header
A server can indicate that it supports the MAC scheme by returning
a WWW-Authentication response header, typically in a
"401 Unauthorized" response to an unauthenticated request.
WWW-Authenticate: MAC realm="..."
m="alg [alg]..."
c="part [part]..."
[o="part [part]..."]
part = "_base" | "_host" | "_body" | header-name | header-prefix "*"
The "realm" parameter is specified in RFC2617.
The "m" parameter is a space-separated list of MAC algorithms
and hash algorithms supported by the server. Hash algorithms need
to be included if, and only if, the "c" or "o" parameters include
the "_body" part.
The "c" parameter is a space-separated list of parts of the request
that SHALL be covered by the MAC.
The "o" parameter is a space-separated list of parts of the request
that MAY be covered by the MAC, at the client's discretion.
A client SHALL ignore any additional unrecognized parameters.
3.2. Authorization request header
The message authentication code SHALL be conveyed in an
Authorization header.
Authorization: MAC
m="mac_alg"
c="part [part]..."
t="yyyy-mm-ddThh:mm:ss[.s...]Z"
u="key_id"
[a="authz_info"]
[cb="channel_binding"]
[h="hash_alg" b="body_hash"]
s="sig"
The "m" parameter is the name of the MAC algorithm.
The "c" parameter is a space-separated list of the parts of the request
covered by the MAC.
The "t" parameter is the time the request was made. The value SHALL be
unique (to high probability) for all requests signed with a given key.
A client may need to make up extra digits beyond the precision of its
clock to achieve this, either randomly or with a counter.
The server can use this parameter to detect (and reject) replays.
The "u" parameter is an identifier for the symmetric shared key used
to sign the request. Typically it is a user-id.
The optional "a" parameter is authorization information about the
identity or permission that the client wants to act as or with.
The server is responsible for verifying that the authorization
information is allowed for the authenticated identity ("u" parameter).
The optional "cb" parameter identifies an underlying secure channel
carrying the request (eg TLS or IPsec channel).
The optional "h" parameter is hash algorithm used to calculate the
value of the "b" parameter.
The optional "b" parameter is the base64url-encoded [RFC4648] hash
of the bytes of the request body, after removing any transfer-encoding.
The "s" parameter is the base64url-encoded MAC calculated over selected
parts of the request formatted as described in section 5.
A server SHALL ignore any additional unrecognized parameters,
though they are included in the MAC calculation.
4. SIG scheme
The SIG scheme digitally signs selected portions of an HTTP request,
using an asymmetric key.
4.1. WWW-Authenticate response header
A server can indicate that it supports the SIG scheme by returning
a WWW-Authentication response header, typically in a
"401 Unauthorized" response to an unauthenticated request.
WWW-Authenticate: SIG realm="..."
m="alg [alg]..."
c="part [part]..."
[o="part [part]..."]
The parameters have the same meanings as for the MAC scheme,
except the algorithms are signature algorithms, instead of MAC algorithms.
A client SHALL ignore any additional unrecognized parameters.
4.2. Authorization request header
The digital signature SHALL be conveyed in an
Authorization header.
Authorization: SIG
m="sig_alg"
c="part [part]..."
t="yyyy-mm-ddThh:mm:ss[.s...]Z"
u="key_id"
[p="cert_url"]
[a="authz_info"]
[cb="channel_binding"]
[h="hash_alg" b="body_hash"]
s="sig"
The parameters have the same meanings as for the MAC scheme,
except the algorithms are signature algorithms, instead of MAC algorithms.
The optional "p" parameter is a URI of a certificate for the public-key
that can verify the signed request.
A server SHALL ignore any additional unrecognized parameters,
though they are included in the signature verification.
5. Request parts to be signed
This section describes how to contruct a normalized byte string from
selected parts of a request. The resulting bytes can be signed with
a MAC or signature algorithm.
[[
Perhaps 1 line for <method> <url - including host & port (even default)>
Then a sorted list of selected normalized header lines.
The Authorization header is always included, with the "s" parameter
set to an empty string (eg s="").
Any other headers whose name or prefix is listed in the "c" parameter
is also included.
Normalization consists of: converting header names to lower case;
collaping header values that extend over multiple lines onto a
single line; stripping leading and trailing space from header values.
]]
7. Signing algorithms
7.1. MAC algorithm hmac-sha-1
7.2. MAC algorithm hmac-sha-256
7.3. SIG algorithm rsassa-pkcs1-v1.5-sha-256
8. Security Considerations
[[
An WWW-Authenticate header from a server are not protected
by the MAC or SIG scheme. Neither the client nor the server
should assume that the value they received or sent is the same
as the value the other party sent or received.
Consequently, a server must check that the algorithm and parts
received in a request are sufficient, instead of assuming they
are sufficient because only sufficient values are advertised
in WWW-Authenticate responses.
Similarly, a client must check that any algorithm and parts
in a WWW-Authenticate response are sufficient, instead of
assuming they come from a trusted server.
Lots of other good security considerations from other OAuth drafts
and specs.
]]
9. References
9.1. Normative References
[RFC4648] "The Base16, Base32, and Base64 Data Encodings",
RFC 4648, by S. Josefsson, October 2006.
Author's Address
James Manger
Telstra
Email: [email protected]
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
