MAC Access Authenticationの仕様をキャッチアップ

以前から注目していたMAC Access Authenticationですが、いつのまにか仕様が更新されたようなのでキャッチアップします。

以前のエントリ

最新の仕様はこちら。
draft-ietf-oauth-v2-http-mac-00 - OAuth 2.0 Message Authentication Code (MAC) Tokens

改めて、MAC Access AuthNとは

This specification defines the HTTP MAC access authentication scheme,
providing a method for making authenticated HTTP requests with
partial cryptographic verification of the request, covering the HTTP
method, request URI, host, and in some cases the request body.

まぁ、署名付きのHTTPリクエストの作り方の定義であることは変わっていません。
MAC Credentialsと呼ばれる、サーバ/クライアント間のshared symmetric keyやアルゴリズムなどを共有し、
その値を用いて計算された署名などをAuthorization Headerに突っ込んで送ります。

MAC Credentials

  • MAC key identifier :
  • MAC key : shared symmetric secret
  • MAC algorithm : MACアルゴリズムの指定。"hmac-sha-1","hmac-sha-256"もしくは拡張として登録される値。
  • Issue time : Credentialsが発行された時間。HTTPレスポンスで渡されるときは、Clientが受け取った時刻。

上の３つは以前からあったパラメータの呼び名が変わっています。
Issue timeが新規に追加されています。

Authorization Request Headerのフォーマット

Authorization: MAC id="(MAC key identifier)",
nonce="(nonceの値)",
bodyhash="(bodyhashの値)",
ext="(追加の情報)",
mac="(署名文字列)"

timestampがなくなっている代わり、nonceパラメータの中に時間に関するデータが含まれます。
nonceは"(Age):(Random string)"の形式となっており、AgeとはMAC CredentialsのIssue timeからの経過時間(秒)になります。

Age: 264095
Random string: dj83hs9s
Nonce: 264095:dj83hs9s

bodyhashについては変更ありません。HTTP request payload bodyをhmac-sha-1/hmac-sha-256して、Base64エンコードしたものです。
extについては省略します。
あとは、macパラメータで指定される署名文字列の作成方法が変わっていないかどうかですね。

ここからは、前回のエントリ同様にClient/Serverがそれぞれ行うこととしてまとめます。

Clientがやること

1. MAC Credential(token,secret,algorithm)を用意

例：
MAC key identifier: h480djs93hd8
MAC key: 489dks293j39
MAC algorithm: hmac-sha-1
Issue time: Thu, 02 Dec 2010 21:39:45 GMT

この部分ですが、2種類考慮されています。

  • OAuth 2.0のアクセストークン取得のフロー
  • HTTPレスポンスヘッダの "Set-Cookie" フィールドから取得

詳細は"5. Use with OAuth 2.0","6. Use with Set-Cookie"にあります。長くなりすぎるので省略します。
以前はOAuth 2.0の拡張専用という感じでしたが、2番目のSet-Cookieで取得するパターンについては、"ブラウザがClientとして、受け取ったCookieを用いてHTTPリクエストに署名をする"というユースケースを想定しているように思えます。
Set-Cookieヘッダの拡張が必要ですし、ブラウザというかHTTP Client単位で対応していくとなると結構大変ですが、Mozillaの人もAuthorsに含まれていますし今後どのように広がるのか楽しみですね。

ちなみに、今の"もらったCookieをそのまま送り続ける仕様"はOAuth 2.0でいうとbearer tokenですよね。

2. nonceを生成

上記の説明の通りです。

Age: 264095
Random string: 7d8f3e4a
Nonce: 264095:7d8f3e4a

3. MAC計算に必要なリクエストデータを改行コードで連結
  • nonce
  • HTTP request method
  • HTTP request-URI
  • hostname
  • port
  • request payload body
  • "ext"パラメータ

例：
POST /request?b5=%3D%253D&a3=a&c%40=&a2=r%20b&c2&a3=2+q HTTP/1.1
Host: example.com

Hello World!

"ext" : a,b,c

↓

264095:7d8f3e4a\n
POST\n
/request?b5=%3D%253D&a3=a&c%40=&a2=r%20b&c2&a3=2+q\n
example.com\n
80\n
Lve95gjOVATpfV8EL5X4nxwjKHE=\n
a,b,c\n

以前はクエリパラメータの処理がめんどくさい感じでしたが、request-URIでそのまま使うので簡単そうですね。

4. 署名作成

3で作った文字列を、MAC keyの値をSecretとしてMAC algorithmで署名文字列を作成します。

5. Authorization Header作成

できあがりですね。

Serverがやること

1. リクエストの値を取得

環境変数などからリクエストの中身を取得します。

  • AuthZ Header
  • method
  • url
  • entitybody
2. AuthZ Header中の必須パラメータチェック

これらの値がなければエラーですね。

request payload bodyがあるときはbodyhash

3. bodyhash検証

request payload bodyに値が存在する場合はbodyhashを検証します。

4. MAC key identifierとnonceの組み合わせを検証

事前に使われていないかのチェックですね。

5. MAC credentialsの検証

Scopeとか有効性を確認します。

まとめ

  • 用語の名前が少し変わってた
  • MAC作成処理が少し簡単になっていた
  • Cookieベースのユースケースのための仕様が追加されていた

facebookの開発者ブログのエントリからも参照されたりしているので、そろそろ注目されてきそうな予感です。

A secure signed cookie specification. While we're moving Facebook to use HTTPS, the vast majority of the Internet still sets session cookies in the clear. The MAC Access Authentication specification is a secure session cookie protocol designed to provide cryptographic protection against stealing session cookies transmitted without HTTPS. We’re working with Yahoo!, Google and Mozilla on this specification in order to give all websites a way to ensure that session information has not been altered or tampered with.

ページが見つかりません - 開発者向けFacebook

この前作ったオレオレライブラリも早速直さないといけませんな。
ではまた！