Web Services Security 補遺

[アーティクル]
03/31/2008

Version 1.0

August 18, 2002

日本語版編者 (あいうえお順):
加藤健二 (マイクロソフト株式会社)
田口慶二 (日本ベリサイン株式会社)
田村健人 (日本アイ・ビー・エム株式会社)

執筆者

Giovanni Della-Libera (Microsoft)
Phillip Hallam-Baker (VeriSign)
Maryann Hondo (IBM)
Chris Kaler (編集者) (Microsoft)
丸山宏 (IBM)
Anthony Nadalin (IBM)
Nataraj Nagaratnam (IBM)
Hemma Prafullchandra (VeriSign)
John Shewchuk (Microsoft)
田村健人 (IBM)
Hervey Wilson (Microsoft)

Copyright Notice

The presentation, distribution or other dissemination of the information contained in this specification is not a license, either expressly or impliedly, to any intellectual property owned or controlled by IBM or Microsoft or VeriSign and/or any other third party. IBM, Microsoft, VeriSign and\or any other third party may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. The furnishing of this document does not give you any license to IBM's or Microsoft's or VeriSign's or any other third party's patents, trademarks, copyrights, or other intellectual property. The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, places, or events is intended or should be inferred.

This specification and the information contained herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, IBM and Microsoft and VeriSign provides the document AS IS AND WITH ALL FAULTS, and hereby disclaims all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the document. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS WITH REGARD TO THE DOCUMENT.

IN NO EVENT WILL IBM OR MICROSOFT OR VERISIGN BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

この翻訳文書の元になったオリジナルの英語版がこの仕様の正式版です。内容に隔たりがある場合、英語版が正しいものです。また、日本語版の著作権は、日本アイ・ビー・エム株式会社、日本ベリサイン株式会社、マイクロソフト株式会社が所有します。

概要

本ドキュメントは、WS-Security 仕様の明確化、改善、推奨例、および訂正を記述したものです。

ステータス

WS-Security と関連仕様は、現状有姿のまま、レビューと評価の目的のみに提供されています。IBM、Microsoft、および VeriSign は近い将来に、読者からの寄稿と提案を募る予定です。IBM、Microsoft、および VeriSign は、これらの仕様に関して、いかなる形の保証や表明も行いません。

1. はじめに

WS-Security 仕様の発表以降に行った追加レビューと実装経験により、元の仕様に対して追加、明確化、および訂正を提案します。

1.1. 表記規則

このドキュメントのキーワード "MUST" (しなければならない)、"MUST NOT" (してはならない)、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD" (する必要がある)、"SHOULD NOT" (しないほうがよい)、"RECOMMENDED" (推奨される)、"MAY" (してもよい)、および "OPTIONAL" は、RFC2119 の記述に従って解釈されるものとします。

（"some-URI" という一般的な形式の) 名前空間 URI は、RFC2396 で定義されている何らかのアプリケーション依存またはコンテキスト依存の URI を表します。

WS-Security は、一般的な SOAP メッセージ構造とメッセージ処理モデルを使って機能するようにデザインされているので、WS-Security は任意のバージョンの SOAP に適用される必要があります。本仕様では詳しい例を示すために現行の SOAP 1.2 名前空間 URI を使用していますが、本仕様の適用範囲を SOAP の 1 つのバージョンに制限する意図はありません。

このドキュメントは、読者が Internet Security Glossary に収録されている用語についての知識があることを前提にしています。

1.2. 名前空間

この追加仕様の実装で使用しなければならない (MUST) XML 名前空間 URI は、以下の URI です。(なお、その他の異なる要素については、異なる名前空間からのものになります。)

        https://schemas.xmlsoap.org/ws/2002/07/secext 
        https://schemas.xmlsoap.org/ws/2002/07/utility

このドキュメントでは、以下の名前空間を使用しています。

プレフィックス	名前空間
S	http://www.w3.org/2001/12/soap-envelope
ds	http://www.w3.org/2000/09/xmldsig#
xenc	http://www.w3.org/2001/04/xmlenc#
m	https://schemas.xmlsoap.org/rp/
wsse	https://schemas.xmlsoap.org/ws/2002/07/secext
wsu	https://schemas.xmlsoap.org/ws/2002/07/utility
xsd	http://www.w3.org/2001/XMLSchema

2. 訂正

元の仕様のセクション 4.6.2 の例で <xenc:EncryptedData> 要素は、鍵情報として <ds:KeyInfo> 要素を持たないほうがよい。むしろ <wsse:Security> ヘッダ内の <xenc:ReferenceList> 要素として鍵の名前を指定する必要があります。

3. ID 参照

元の仕様のセクション 4.5 で <ds:Signature> 要素の使用について、署名対象の要素を指定するときはID 参照を使用してもよい (MAY) と説明しています。ただし、任意の ID 型属性に対応するためには、スキーマが利用可能でそれを処理する必要があるので、署名内で参照できる ID 型属性を以下のものに制限します。

XML 署名 (XML Signature) で定義しているID 型属性
XML 暗号化 (XML Encryption) で定義しているID 型属性
以下で説明する wsu:Id グローバル属性

さらに、本文などのエンベロープの一部に署名するときは、XPath を始めとするより一般的な変換の代わりに、ID 参照の使用が推奨されます (RECOMMENDED)。これにより処理が単純になります。

本仕様では、wsu 名前空間のグローバル属性を採用するために、 wsse 名前空間から "Id" 属性が削除されたことに注意する必要があります。その結果、元の WS-Security 仕様の例は、"Id" 属性を "wsu:Id" に変更し wsu 名前空間を定義しないと、新しい wsse スキーマでは機能しないでしょう。

3.1. Id 属性

SOAP メッセージ内の要素を参照する必要がある状況は数多く存在します。たとえば、SOAP メッセージに署名するときに、選択した要素が署名に含められます。 XML Schema Part 2 は、要素の識別や参照に使用する可能性がある組み込みのデータ型をいくつか提供しています。しかし、SOAP メッセージのコンシューマがそれらのデータ型を使用するには、コンシューマも識別や参照のメカニズムを定義するスキーマを持っているか、入手できる必要があります。たとえば、中間ノードなどでは、場合によってはデータ型の使用で問題が発生しやすくなることがあります。

その結果、要素の識別と参照を行う、SOAP 基盤に基づくメカニズムが必要になります。このメカニズムは、要素を使用するコンテキストのスキーマの完全な情報には依存しません。この機能は SOAP プロセッサに統合できるので、動的にスキーマを発見、処理しなくても、要素の識別や参照は可能です。

ここでは、要素を識別するために名前空間で修飾されたグローバル属性を示します。この属性は、任意の属性を許可する、または具体的にこの属性を許可するすべての要素に適用できます。

3.2. Id スキーマ

中間ノードと受信者の処理を単純化するために、要素を識別する共通の属性を定義します。この属性は、XML スキーマの ID 型を利用し、要素の情報を示すための共通の属性を指定します。

この属性の構文は、以下のとおりです。

<anyElement wsu:Id="...">...</anyElement>

以下で、上記の属性を説明します。

.../@wsu:Id
xsd:ID 型として定義するこの属性は、要素のローカル ID を指定する属性を提供します。

1 つの XML ドキュメント内の 2 つの wsu:Id 属性は、同じ値を持ってはならない (MUST NOT)。実装は、基本的に内部ドキュメントの一意性を保証する XML スキーマの検証に依存してよい (MAY)。しかし、アプリケーションは一意性を設定するために、スキーマの検証だけに依存しないほうがよい (SHOULD NOT)。

この属性の使用法については指定しません。また、他の仕様がこの属性を使用するための付加的なセマンティクス (または制限) を追加してもよい (MAY)。

以下の例は、この属性を使用して要素を識別する方法を示します。

<x:myElement wsu:Id="ID1" xmlns:x="..." 
           xmlns:wsu="https://schemas.xmlsoap.org/ws/2002/07/utility"/>

XML スキーマをサポートするプロセッサは、グローバル属性宣言を使用して定義されているかのようにこの属性を扱わなければならない (MUST)。

XML スキーマや DTD をサポートしないプロセッサは、この属性の情報項目の PSVI が、 {target namespace} が "http://www.w3.org/2001/XMLSchema"で、{name} が "Id" の [type definition] を持っているものとして、この情報項目を処理することを強く推奨します。特に実装においては、XPointer ショートハンドポインタとして使用するために、WS-Security の有効な識別子としてwsu:Id の値をサポートしてもよい (MAY)。

4. X.509 証明書の配置

WS-Security 仕様は X.509 証明書を <ds:KeyInfo> 要素の内部に記述してもよい (MAY) ことを示しています。ただし、この場合 <wsse:BinarySecurityToken> を使用して指定することを推奨します (RECOMMENDED)。しかし、実装において <ds:KeyInfo> を使用する必要がある場合、署名に埋め込むのではなく、 <wsse:Security> ヘッダの子要素として <ds:KeyInfo> 要素を配置する必要があります (SHOULD)。この結果、受信者が単一の処理モデルを持つことができます。

5. メッセージのタイムスタンプ

要求者とサービスがメッセージを交換しているときに、メッセージの "新しさ" を理解できることが重要になることがよくあります。場合によっては、メッセージが "古い" ために、受信者がそのメッセージを無視することを決定することがあります。

本仕様では、時間の同期を取るメカニズムを提供していません。受信者が時間の同期を取るメカニズム (例 NTP) を使用しているか、また連合するアプリケーションでよく行われる、3 つの要因に基づいて時間に関する評価を行っていることを想定しています。3 つの要因とは、メッセージの作成時刻、伝送チェックポイント、および伝送の遅延です。

受信者がメッセージの古さの評価を行うことを支援するために、要求者が推奨有効期限を提示したいと考える場合があります。推奨有効期限とは、その期限を超えたメッセージを要求者が無視することを推奨する期限です。本仕様で、要求者がメッセージの有効期限を表明できる XML 要素を提供します。その要素とは、メッセージを作成した時点の要求者の時計の時刻、(アクタがメッセージを受信したときの) 通信パス上にあるチェックポイントのタイムスタンプ、および伝送と、作成後のその他の要因に伴う遅延です。遅延の精度は、実際の遅延をどの程度厳密に反映しているか (たとえば、変換の遅延をどの程度厳密に反映するかなど) によって変わります。

これは、アサーションを行ったり、サービスがメッセージの生成や処理を行う時間や速度を判断するためのプロトコルではないことに注意してください。

本仕様では、XML スキーマで定義される dateTime 型を用いて、時間参照を定義および説明します。すべての時間参照がこの型を使用することを推奨します (RECOMMENDED)。さらに、すべての参照を UTC 時刻で表現することを推奨します (RECOMMENDED)。もし他の時刻型を使用する場合は、時刻形式のデータ型を示すために (後述する) ValueType 属性を指定しなければならない (MUST)。

5.1. モデル

本仕様は、受信者が要求者の提示した有効期限を評価するためのツールをいくつか提供します。最初は作成時刻です。受信者はこの値を使用して、時計同期で発生する可能性のある問題を評価できます。しかし、この評価を行うために、要求者から受信者までの伝送所要時間も役に立つ場合があります。このため、2 つのメカニズムを提供しています。最初のメカニズムは、中間ノードがメッセージを受信した時刻を示すタイムスタンプ要素を追加できることです。この情報はメッセージ経路に沿った時刻の総合的な視点を得るのに役立ちます。2 番目のメカニズムは、中間ノードがメッセージを配信するときに生じる遅延を特定できることです。物理的な伝送時間や報告されないノードなど、すべての遅延が考慮されるわけではないことに注意してください。受信者は時刻の信頼性を評価するときに、この点を考慮に入れる必要があります。

5.2. タイムスタンプ要素

本仕様では、以下のメッセージのタイムスタンプ要素を定義します。これらの要素を SOAP メッセージの <Timestamp> ヘッダで使用するように定義していますが、作成、有効期限、および中間ノードのマーカーが必要な場所であればどこでも使用できます。

5.2.1. 有効期限

<Expires> 要素は有効期限のタイムスタンプを指定します。有効期限の正確な意味と処理の規則は、要素を使用するコンテキストによって異なります。この要素の構文は、以下のとおりです。

    <wsu:Expires  ValueType="..." wsu:Id="...">...</wsu:Expires>

以下で、上記のスキーマで示した属性と要素を説明します。

/Expires
この要素の値が有効期限を表します。指定する時刻は、ValueType 属性で指定した型の UTC 時刻である必要があります(SHOULD) (デフォルトは XML スキーマの dateTime 型です)。
/Expires/@ValueType
この属性は省略可能で、時刻データの型を指定します。この属性は XML スキーマの型として指定します。この属性を指定していない場合のデフォルト値は xsd:dateTime です。
/Expires/@wsu:Id
この属性は省略可能で、この要素を参照するための ID を指定します。

有効期限は要求者の時計に連動します。受信者は有効期限を評価するために、要求者の時計と受信者の時計との同期が取られていない可能性があることを認識しておく必要があります。受信者は、受信者の時計ではなく、要求者の時計と比べて有効期限が過ぎたかどうかを評価することが求められるので、受信者は、要求者の時計を使って信頼のレベルの評価を行う必要があります。受信者は、すでにオフラインで結ばれた時計同期プロトコルなど、本仕様に記載されていない方法で要求者の時計の予想される現在時刻を判断する場合があります。また、受信者は作成時刻や中間ノードアクタによって生じる遅延を考慮して、時計の同期の程度を推定する場合もあります。

以下は、同期を推定する数式の推奨案です。

    skew = 受信者の受信時刻 - 作成時刻 - 伝送時間

遅延する要因がある場合はそれを合計して、伝送時間を推定できます。遅延の推定に物理的な伝送時間を含めたとしても、物理的な伝送時間は全伝送時間の一部に過ぎないことに注意してください。それ以外の場合は、伝送時間には物理的な伝送時間を反映しません。遅延がない場合、処理時間に関する特別な想定はありません。

5.2.2. 作成

created 要素は作成のタイムスタンプを指定します。作成の正確な意味とセマンティクスは、要素を使用するコンテキストによって異なります。この要素の構文は、以下のとおりです。

    <wsu:Created ValueType="..." wsu:Id="...">...</wsu:Created>

以下で、上記のスキーマで示した属性と要素を説明します。

/Created
この要素の値が作成のタイムスタンプです。指定する時刻は、ValueType 属性で指定した型の UTC 時刻である必要があります(SHOULD) (デフォルトは XML スキーマの dateTime 型です)。
/Created/@ValueType
この属性は省略可能で、時刻データの型を指定します。この属性は XML スキーマの型として指定します。この属性を指定しない場合のデフォルト値は xsd:dateTime です。
/Created/@wsu:Id
この属性は省略可能で、この要素を参照するための ID を指定します。

5.2.3. 中間ノード

Received 要素は、受信のタイムスタンプを指定します。処理の遅延に関する情報も付けることができます。正確な意味とセマンティクスは要素を使用するコンテキストによって異なります。この要素の構文は、以下のとおりです。

    <wsu:Received Actor="..." Delay="..." ValueType="..."
                  wsu:Id="...">...</wsu:Received>

以下で、上記のスキーマで示した属性と要素を説明します。

/Received
この要素の値が受信のタイムスタンプです。指定する時刻は、ValueType 属性で指定した型の UTC 時刻である必要があります (SHOULD) (デフォルトは XML スキーマの dateTime 型です)。
/Received/@Actor
必須の属性である Actor は、受信者を表すアクタを示します。WS-Routing ヘッダがメッセージに存在する場合は常に、アクタは要素を通じて対応する WS-Routing が示すアクタ値と一致する値を持つこの属性を含む必要があります (SHOULD)。
/Received/@Delay
この属性の値はアクタに関連する遅延をミリ秒単位で表します。
/Received/@ValueType
この属性は省略可能で、時刻データ (要素の値) の型を指定します。この属性は XML スキーマの型として指定します。この属性を指定しない場合のデフォルト値は xsd:dateTime です。
/Received/@wsu:Id
この属性は省略可能で、この要素を参照するための ID を指定します。

Delay 属性はアクタ (中間ノードプロセッサ) で生じる遅延時間を示します。場合によってはこの属性は不明ですが、既知の場合 "アクタの送信時刻 - アクタの受信時刻" として算出できます。

それぞれの遅延量は小数部分を持たないミリ秒単位で示します。遅延量がデータ型で表現できる最大値を超過する場合は、そのデータ型の最大値に設定されます。

5.3. Timestamp ヘッダ

<Timestamp> ヘッダは、メッセージの作成時刻と有効期限以外に、メッセージ経路上で発生するすべての遅延を表現するメカニズムを提供します。具体的には、メッセージの作成、受信、および処理のコンテキストで以前に定義した要素を使用します。

XML スキーマの型 (dateTime) で指定するときは、すべての時刻は UTC 形式である必要があります (SHOULD)。時刻は XML スキーマ仕様で定義されているとおりの時刻の精度をサポートすることに注意してください。

<Timestamp> ヘッダは、異なるアクタを対象としていれば複数指定できます。以下でヘッダ内での順序を説明します。

このヘッダ内の要素の順序は固定で、中間ノードでも保持されなければならない (MUST)。

それぞれの Timestamp ヘッダの完全性をすべて保持するため、各アクタが特定のアクタ用の適切な Timestamp ヘッダを作成または更新することを強く推奨します (RECOMMENDED)。また、このヘッダは変わりやすいため、各アクタが Timestamp ヘッダに署名するのではなく、要素の ID を参照することで要素に署名することが強く推奨されます (RECOMMENDED)。

<Timestamp> ヘッダのスキーマの概要は、以下のとおりです。

    <wsu:Timestamp wsu:Id="...">
        <wsu:Created>...</wsu:Created>
        <wsu:Expires>...</wsu:Expires>
        <wsu:Received>...</wsu:Received>
        ...
    </wsu:Timestamp>

以下で、上記のスキーマで示した属性と要素を説明します。

/Timestamp
メッセージのタイムスタンプを示すヘッダです。
/Timestamp/Created
メッセージの作成時刻を表します。この要素は省略可能ですが、Timestamp ヘッダで 1 回しか指定できません。SOAP 処理モデル内部では、作成は情報セットが伝送のためにシリアル化された時点です。メッセージの作成時刻は伝送時刻と大幅には異ならないほうがよい (SHOULD NOT)。
/Timestamp/Expires
メッセージの有効期限を表します。この要素は省略可能ですが、Timestamp ヘッダで 1 回しか指定できません。有効期限になると、要求者はメッセージが有効でなくなったことをアサート (assert) します。(このメッセージを処理するすべての) 受信者が有効期限を過ぎたメッセージを破棄 (無視) することが強く推奨されます (RECOMMENDED)。受信者が要求者にメッセージの有効期限が切れたことを通知する場合、フォールトコード (wsu:MessageExpired) を提供します。サービスは、メッセージの有効期限が切れたことを示すフォールトを発行してもよい (MAY)。
/Timestamp/Received
特定のアクタがメッセージを受信した時点を表します。この要素は省略可能ですが、Timestamp ヘッダでアクタごとに 1 回指定する必要があります (SHOULD)。(ループがある場合は複数のエントリが存在してもよい (MAY) が、値は異なっていなければならない (MUST))
/Timestamp/{any}
これは、付加的な要素をヘッダに追加することを可能にする拡張性メカニズムです。
/Timestamp/@wsu:Id
この属性は省略可能で、この要素を参照するための ID を指定します。
/Timestamp/@{any}
これは、付加的な属性をヘッダに追加することを可能にする拡張性メカニズムです。

以下の例で、<Timestamp> 要素とそのコンテンツの使用法を説明します。

<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope"
            xmlns:wsu="https://schemas.xmlsoap.org/ws/2002/07/utility">
  <S:Header>
    <wsu:Timestamp>
       <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>
       <wsu:Expires>2001-10-13T09:00:00Z</wsu:Expires>
    </wsu:Timestamp>
    ...
  </S:Header>
  <S:Body>
    ...
  </S:Body>
</S:Envelope>

以下の例で、<Timestamp> ヘッダ、および受信後 1 分間の処理遅延を示す Received 要素を持つコンテンツの使用法を説明します。受信は作成の 2 分後に行われました。

<S:Envelope xmlns:S="http://www.w3.org/2001/12/soap-envelope" 
            xmlns:wsu="https://schemas.xmlsoap.org/ws/2002/07/utility">
  <S:Header>
    <wsu:Timestamp>
       <wsu:Created>2001-09-13T08:42:00Z</wsu:Created>
       <wsu:Expires>2001-10-13T09:00:00Z</wsu:Expires>
       <wsu:Received Actor="http://x.com/" Delay="60000">
                2001-09-13T08:44:00Z</wsu:Received>
    </wsu:Timestamp>
    ...
  </S:Header>
  <S:Body>
    ...
  </S:Body>
</S:Envelope>

6. パスワードの送信

元の仕様のセクション 4.1 で、<wsse:UsernameToken> 要素について説明しています。この要素内で、<wsse:Password> 要素を指定できます。パスワードは、wsse:PasswordText または wsse:PasswordDigest のいずれかと関連付けられた型を持ちます。元の仕様では wsse:PasswordText を "そのユーザ名の実際のパスワード" と記載しています。しかし、PasswordText は実際のパスワードのみに限定されません。派生パスワード、S/KEY (ワンタイムパスワード) などパスワード相当のものを使用できます。

元の仕様では、wsse:PasswordDigest を "そのユーザ名のパスワードのダイジェスト。値は、UTF8 エンコードされたパスワードの SHA1 ハッシュ値を取り、それを base64 エンコードしたものです。" と記載しています。しかし、このダイジェストされたパスワードはセキュリティで保護されたチャネルで送信されない限り、ダイジェストパスワードは実際には wsse:PasswordText 以上の付加的なセキュリティを提供しません。

この問題に対処するため、 <wsse:UsernameToken> に省略可能な新しい要素である <wsse:Nonce> と <wsu:Created> を導入します。2 つのうちいずれかが存在する場合、両者は以下のようにダイジェスト値に含まれます。

Password_digest = SHA1 ( nonce + created + password )

つまり、nonce 値、作成タイムスタンプ、およびパスワード (または共有秘密鍵かパスワード相当物) を連結し、それらを組み合わせたダイジェストを渡します。これによって、パスワードの特定が困難になり、リプレイ攻撃を防止する基盤を築きます。タイムスタンプと nonce 値は、リプレイを検出するために最短でも 5 分間はキャッシュすること、および 5 分以上経過したタイムスタンプは拒否することが推奨されます (RECOMMENDED)。

なお、nonce 値は復号化された値のオクテット列を使用してハッシュされますが、タイムスタンプは要素のコンテンツで指定したとおりに UTF8 で符号化したオクテット列を使用してハッシュされます。

以下に、この要素の構文を例示します。

<wsse:UsernameToken>
    <wsse:Username>...</wsse:Username>
    ...
    <wsse:Nonce EncodingType="...">...</wsse:Nonce>
    <wsu:Created>...</wsu:Created>
</wsse:UsernameToken>

以下で、上記の例で示した属性と要素を説明します。

/wsse:Nonce

この要素は省略可能で、暗号的にランダムな nonce 値を指定します。

/wsse:Nonce/@EncodingType

この属性は省略可能で、nonce 値の符号化の種類を指定します (BinarySecurityToken の有効値に関する WS-Security の定義を参照してください)。この値を指定しない場合、デフォルトの Base64 符号化が使用されます。

/wsu:Created

この要素は省略可能で、タイムスタンプを指定します。

要求者と受信者の両方が平文のパスワード、秘密鍵、パスワード相当物のいずれかを利用できるようになるまでは、これらの拡張オプションを使用しないほうがよい (SHOULD NOT)。

以下の例は、nonce 値とタイムスタンプの両方を使用してハッシュされたパスワードを示します。

以下に、この要素の構文を例示します。

<wsse:UsernameToken 
            xmlns:wsse="https://schemas.xmlsoap.org/ws/2002/07/secext"
            xmlns:wsu="https://schemas.xmlsoap.org/ws/2002/07/utility">
    <wsse:Username>NNK</wsse:Username>
    <wsse:Password Type="wsse:PasswordDigest ">FEdR...</wsse:Password>
    <wsse:Nonce>FKJh...</wsse:Nonce>
    <wsu:Created>2001-10-13T09:00:00Z </wsu:Created>
</wsse:UsernameToken>

7. 鍵識別子

鍵名ではなく鍵識別子を使用して、セキュリティトークンを指定または参照することが推奨されます (RECOMMENDED)。識別子を使用してトークンを参照するために <wsse:SecurityTokenReference> 要素に <wsse:KeyIdentifier> 要素を配置します。この要素はすべての鍵識別子で使用する必要があります (SHOULD)。

この処理モデルは、セキュリティトークンの鍵識別子が定数であることを想定しています。そのため、鍵識別子を処理するときは単に、鍵識別子が指定値と一致するセキュリティトークンを検出します。

以下は、構文の概要です。

<wsse:SecurityTokenReference>
   <wsse:KeyIdentifier wsu:Id="..." 
                       ValueType="..."
                       EncodingType="...">
      ...
   </wsse:KeyIdentifier>
</wsse:SecurityTokenReference>

以下で、上記の例で示した属性と要素を説明します。

/KeyIdentifier
この要素は、バイナリエンコードされた鍵識別子を含めるために使用します。
/KeyIdentifier/@wsu:Id
この識別子の省略可能な文字列ラベル。
/KeyIdentifier/@ValueType
ValueType 属性を使用して、特定の識別子を持つトークンの種類を任意に指定します。この属性を指定すると、受信者への "ヒント" になります。ここでバイナリセキュリティトークンに指定する値や、XML トークン要素 QName (例、wsse:X509v3) を指定します。この属性を指定しない場合、識別子は任意の種類のトークンに適用されます。
/KeyIdentifier/@EncodingType
EncodingType 属性は省略可能で、QName を使用して、バイナリデータの符号化形式 (wsse:Base64Binary など) を示すために使用します。WS-Security で定義した値を使用します。

QName 説明

wsse:Base64Binary XML スキーマ Base 64 符号化 (デフォルト)

wsse:HexBinary XML スキーマ 16 進符号化
/KeyIdentifier/@{any}
これは、付加的な属性をスキーマに基づいて追加することを可能にする拡張性メカニズムです。

QName	説明
wsse:Base64Binary	XML スキーマ Base 64 符号化 (デフォルト)
wsse:HexBinary	XML スキーマ 16 進符号化

8. 鍵の名前

上記で説明したように、鍵識別子を使用することが強く推奨されます (RECOMMEND)。ただし、鍵名を使用する場合、<ds:KeyName> 要素が相互運用性を得るために RFC 2253 のセクション 2.3 (<X509SubjectName>) 要素のためにXML 署名にて推奨されています) の属性名に準拠していることが強く推奨されます (RECOMMENDED)。

さらに、電子メールアドレスの表記法を以下のように定義します。これは RFC 822 に準拠する必要があります (SHOULD)。

     EmailAddress=ckaler@microsoft.com

9. トークン参照の処理順序

XML 署名、WS-Security、および本仕様に、セキュリティトークンを参照するためのメカニズムが多数記載されています。あいまいさを排除するため、以下の参照処理順序を使用する必要があります (SHOULD)。

<wsse:Reference> 要素を解決します。(<wsse:SecurityTokenReference> で指定されます)。
<wsse:KeyIdentifier> 要素を解決します。(<wsse:SecurityTokenReference> で指定されます)。
<ds:KeyName> 要素を解決します。
その他の <ds:KeyInfo> 要素を解決します。

10. 暗号化された鍵

XML 暗号化は <xenc:EncryptedData> 要素で <xenc:EncryptedKey> 要素を指定してもよい (MAY) ことを指定していますが、<xenc:EncryptedKey> 要素を <wsse:Security> ヘッダに配置することが強く推奨されます (RECOMMEND)。

11. 復号化順序

<wsse:Security> ヘッダの順序付けセマンティクスは、暗号化されているデータ対しての署名か、暗号化されていないデータに対してのものかを判断するには十分です。しかし、署名がある <wsse:Security> ヘッダに含まれるときに、別の <wsse:Security> ヘッダで暗号化が行われると、順序を明確に理解できない場合があります。

送信者が、中間ノードが転送経路に沿って順番に暗号化されるメッセージに署名をすることを希望する場合、送信者は、Decryption Transform for XML Signature を使用して復号化の順序を明示的に指定してもよい (MAY)。

12. 証明書のコレクション

あるサービスにおいて階層化された認証機関などの証明書のコレクションを渡すときは <wsse:BinarySecurityToken> を使用してそのコレクションを渡す必要があります (SHOULD)。以下の、標準的なコレクションの形式を渡す新しいトークンの種類を定義します。

QName	説明
wsse:PKCS7	証明書になる重要なフィールドを 1 つだけ持つ PKCS#7 SignedData オブジェクト。特に、署名とコンテンツが無視されます。証明書が存在しない場合、長さ 0 の CertPath が想定されます。警告 : PKCS#7 は証明書パスの証明書の順序を保持しません。つまり、CertPath を PKCS#7 で符号化したバイトに変換してから元に戻すと、証明書の順序が変わって、CertPath が無効になる場合があります。ユーザはこの現象を認識しておく必要があります。詳細については、「http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html」(英語) を参照してください。
wsse:PKIPath	ASN.1 DER で符号化した一連の証明書です。次のように定義されます。 PkiPath ::= SEQUENCE OF Certificate このシーケンス内では、証明書の順序は最初の証明書の主体(subject)が 2 番目の証明書の発行者というようになっています。PkiPath の各証明書は一意である必要があります。証明書は PkiPath の Certificate の値に複数回表われてはいけません。PkiPath 形式は、X.509 (2000) に対する欠陥レポート 279 で定義されており、X.509 第 4 版 (2000) の Draft Technical Corrigenda 2 に組み込まれています。詳細については、「ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8%7CX.509-TC1(4th).pdf」(英語) を参照してください。

wsse:PKCS7

証明書になる重要なフィールドを 1 つだけ持つ PKCS#7 SignedData オブジェクト。特に、署名とコンテンツが無視されます。証明書が存在しない場合、長さ 0 の CertPath が想定されます。警告 : PKCS#7 は証明書パスの証明書の順序を保持しません。つまり、CertPath を PKCS#7 で符号化したバイトに変換してから元に戻すと、証明書の順序が変わって、CertPath が無効になる場合があります。ユーザはこの現象を認識しておく必要があります。詳細については、「http://www.rsasecurity.com/rsalabs/pkcs/pkcs-7/index.html」(英語) を参照してください。

wsse:PKIPath

ASN.1 DER で符号化した一連の証明書です。次のように定義されます。

PkiPath ::= SEQUENCE OF Certificate

このシーケンス内では、証明書の順序は最初の証明書の主体(subject)が 2 番目の証明書の発行者というようになっています。PkiPath の各証明書は一意である必要があります。証明書は PkiPath の Certificate の値に複数回表われてはいけません。PkiPath 形式は、X.509 (2000) に対する欠陥レポート 279 で定義されており、X.509 第 4 版 (2000) の Draft Technical Corrigenda 2 に組み込まれています。詳細については、「ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8%7CX.509-TC1(4th).pdf」(英語) を参照してください。

13. セキュリティの考慮事項

ID とタイムスタンプを "信頼" するために、WS-Security で概要を述べたメカニズムを使用して、ID とタイムスタンプに署名する必要があります (SHOULD)。ID やタイムスタンプの情報を表示すれば、ID やタイムスタンプが何らかの方法で偽造または改変されていないことを確認できるようになります。ID とタイムスタンプには署名することが強く推奨されます (RECOMMENDED)。なお、Timestamp ヘッダは変わりやすいため、署名を個別の要素に関連付ける必要があります。

また、タイムスタンプを使用すると、リプレイ攻撃を軽減できます。署名済みのタイムスタンプを使用して (おそらく特定サービスの最新タイムスタンプをキャッシュすることで) メッセージを監視し、以前のメッセージのリプレイを検出してよい (MAY)。タイムスタンプと nonce 値は、リプレイを検出するために最短で 5 分間はキャッシュすること、および対話処理を行う場合は 5 分以上経過したタイムスタンプは拒否することが推奨されます (RECOMMENDED)。

14. 謝辞

本仕様は、以下を含めた多くの個人およびチームとの合同作業の結果として開発されました。

Keith Ballinger (Microsoft)
Joel Farrell (IBM)
Mark Hayes (VeriSign)
Dan Simon (Microsoft)
Wayne Vicknair (IBM)

15. 参考文献

[KEYWORDS]
S. Bradner, "Key Words for Use in RFCs to Indicate Requirement Levels," RFC 2119, Harvard University, March 1997.
[RFC822]
"Standard for the Format of ARPA Internet Messages", RFC 822, University of Delaware, August 1982.
[RFC2253]
"Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", Wahl, Kille, Howes, December 1997.
[RFC2459]
"Internet X.509 Public Key Infrastructure Certificate and CRL Profile", Housley, Ford, Polk, Solo, January 1999.
[SHA-1]
FIPS PUB 180-1. Secure Hash Standard. U.S. Department of Commerce / National Institute of Standards and Technology. http://csrc.nist.gov/publications/fips/fips180-1/fip180-1.txt
[SOAP]
W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 2000.
[URI]
T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," RFC 2396, MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998.
[XML-Encrypt]
W3C Working Draft, "XML Encryption Syntax and Processing," 04 March 2002.
[XML-ns]
W3C Recommendation, "Namespaces in XML," 14 January 1999.
[XML-Schema1]
W3C Recommendation, "XML Schema Part 1: Structures," 2 May 2001.
[XML-Schema2]
W3C Recommendation, "XML Schema Part 2: Datatypes," 2 May 2001.
[XML Signature]
W3C Recommendation, "XML Signature Syntax and Processing," 12 February 2002.
[XPointer]
"XML Pointer Language (XPointer) Version 1.0, Candidate Recommendation", DeRose, Maler, Daniel, 11 September 2001.
[WS-Routing]
"Web Services Routing Protocol", Microsoft, October 2001.
(日本語版: Web Services Routing Protocol)
[WS-Security]
"Web Services Security Language", IBM, Microsoft, VeriSign, April 2002.
(日本語版: Web Services Security)
[X509]
S. Santesson, et al,"Internet X.509 Public Key Infrastructure Qualified Certificates Profile". http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.509-200003-I
[XPath]
W3C Recommendation, "XML Path Language", 16 November 1999.

Web Services Security 補遺

Version 1.0

執筆者

Copyright Notice

概要

ステータス

目次

1. はじめに

1.1. 表記規則

1.2. 名前空間

2. 訂正

3. ID 参照

3.1. Id 属性

3.2. Id スキーマ

4. X.509 証明書の配置

5. メッセージのタイムスタンプ

5.1. モデル

5.2. タイムスタンプ要素

5.2.1. 有効期限

5.2.2. 作成

5.2.3. 中間ノード

5.3. Timestamp ヘッダ

6. パスワードの送信

7. 鍵識別子

8. 鍵の名前

9. トークン参照の処理順序

10. 暗号化された鍵

11. 復号化順序

12. 証明書のコレクション

13. セキュリティの考慮事項

14. 謝辞

15. 参考文献

その他のリソース