21. その他の認証情報

cXML では、共有シークレット以外の認証方法でも、cXML ドキュメントの送信者を検証できます。

21.1 メッセージ認証コード (MAC)

21.1.1 MAC の概要
21.1.2 計算アルゴリズム
21.1.3 作成日と有効期限
21.1.4 計算プロセス
21.1.4.1 ハッシュによる入力の生成
21.1.4.2 入力値の正規化
21.1.4.3 MAC アルゴリズム
21.1.5 ProfileResponse
21.1.6 CredentialMac

21.2 Auth トランザクション

21.2.1 AuthRequest
21.2.1.1 Credential
21.2.1.2 X509Data
21.2.2 AuthResponse

21.1 メッセージ認証コード (MAC)

メッセージ認証コード (MAC : Message Authentication Code) を使用すると、(ネットワークハブなどの) 信頼できるサードパーティを経由せずに、クライアントからサーバーに直接送信されたドキュメントを認証できます。このようなドキュメントは、信頼できるサードパーティと受信者によってのみ解読可能な認証コードを持つ認証情報を含んでおり、送信者は解読できません。MAC を含む Credential 要素 (element) のフォーマットについては、Credential [29 ページ] で説明しています。

21.1.1 MAC の概要

MAC の主な目的は、受信者の共有シークレットを、送信者に対して明らかにせずに伝達することです。MAC では、ハッシュを使用してエンコードすることで、共有シークレットの安全性を確保しています。MAC は、共有シークレットと同様に安全です。送信者は、共有シークレットと同様に注意深く MAC を取り扱う必要があります。たとえ断片的であっても、情報の漏洩について妥協することは、取引先を危険にさらす恐れがあります。MAC 認証を使用するには、信頼できるサードパーティと受信者の両方で MAC を計算できるようにする必要があります。

21.1.2 計算アルゴリズム

MAC は、信頼できるサードパーティと受信者の両者にとって既知のデータを組み合わせるアルゴリズムによって生成されます。cXML では、IETF RFC 2104 の「HMAC: Keyed-Hashing for Message Authentication」に記述されている HMACSHA1 アルゴリズムを使用するように指定されています。HMAC-SHA1 アルゴリズムは、cXML に必要な安全性を提供します。このアルゴリズムは、基になるハッシュアルゴリズムと同様に安全であることが正式に証明されています。IETF RFC 2104 の詳細については、www.ietf.org/rfc/rfc2104.txt を参照してください。

21.1.3 作成日と有効期限

作成日と有効期限を指定することで、MAC の安全性が向上します。MAC が盗まれた場合、送信者の共有シークレットを変更しても効果はありません。MAC を無効にするため、送信者が受信者に帯域外で連絡することを期待することは現実的ではありません。これは、両者の間に取引関係が確立されていない場合もあるためです。この問題に対処するため、MAC には、作成日 (creationDate) と有効期限(expirationDate) が組み込まれています。有効期限を指定し、MAC が期限切れになることで、MAC の盗難による被害を最小限に抑えます。有効期限が短いほど、安全性は向上します。受信者は、expirationDate 後に受け取った MAC を却下する必要があります。受信者は、作成日からの経過日数に基づいて、期限切れになっていない MAC を拒否することもできます。たとえば、数年前に作成され、受信の翌日に期限切れになる MAC を受信した場合、受信者はその MAC の受け入れを望まないかもしれません。この判断は、受信システムの実装者に委ねられています。受信者は、作成日が過去の日付で有効期限が未来の日付であることを確認し、どちらか一方でも条件が満たされていない場合は、その MAC を拒否する必要があります。しかし、作成日が古すぎる場合に、拒否するかどうかは、受信者側の任意です。受信者は、MAC が有効なことを確認するのみでなく、MAC で認証されたデータが受け入れ可能かどうかも確認する必要があります。特に、From と Sender の認証情報で認識されるエンティティからのメッセージを受け入れることが妥当かどうかを検証する作業が必要です。

21.1.4 計算プロセス

この項では、type=”FromSenderCredentials” の MAC を計算する方法について説明します。この方法で MAC に入力するデータは、信頼できるサードパーティと受信者のみに既知です。信頼できるサードパーティは、この計算方法で ProfileResponse Option 要素を作成し、受信側のサーバーは同じ計算方法で CredentialMac 要素を検証します。

21.1.4.1 ハッシュによる入力の生成

MAC 関数の入力には、データ入力と秘密鍵入力の 2 つが必要です。

  • 入力するデータは、次の各値を、正規化した上で値の末尾に 1 つのヌルバイト (0x00) を付加し、下に示す順番どおりに並べて UTF-8 でエンコードしたバイト表現です。
  • 入力する秘密鍵は、受信者とサードパーティとの間で使用される cXML 共有シークレットです。
  • 21.1.4.2 入力値の正規化

    前述した値は、計算の前に、大文字と小文字の違いやフォーマットの違いを取り除くために正規化します。

    正規化の内容正規化された例
    domainたとえば、「AribaNetworkUserId」のように大文字と小文字を区別する場合を除き、小文字の文字列を使用します。「NetworkId」と「DUNS」は、大文字と小文字が区別されないことに注意してください。networkid
    Identity先頭と末尾の空白文字は削除し、小文字の文字列を使用します。an9900000100, creationDate
    expirationDate正規化の必要はありません。これらは、日付、時刻およびその他のデータタイプ [25 ページ]で説明している ISO8601 フォーマットで記述されているためです。2003-01-15T11:42:46-08:00

    共有シークレットは、正規化しないでください。

    21.1.4.3 MAC アルゴリズム

    サポートされている MAC アルゴリズムの値は “HMAC-SHA1-96” のみです。これは、HMAC-SHA1 アルゴリズムに対応し、160 ビット (20 バイト) の出力を生成し、左側の 96 ビット (12 バイト) のみを保持します。この 12 バイトはさらに Base-64 でエンコードされ、[A-Z a-z 0-9 +/] の文字セットのみで構成される 16 バイトの文字列を生成します。MAC を計算する手順は、次のとおりです。

    1. 次に示す各文字列の末尾にヌルバイト (0x00) を付加し、それを UTF-8 でエンコードしたバイト表現にして連結します。(各文字列は、前述の方法で正規化されています。)

      “networkid”、“an9900000100”、“networkid”、“an9900000100”、“2003-01-15T08:42:46-08:00”、“2003-01-15T11:42:46-08:00”

      文字列を連結すると、次のバイトシーケンスが得られます。

      6e 65 74 77 6f 72 6b 69 64 00 61 6e 39 39 30 30
      30 30 30 31 30 30 00 6e 65 74 77 6f 72 6b 69 64
      00 61 6e 39 39 30 30 30 30 30 31 30 30 00 32 30
      30 33 2d 30 31 2d 31 35 54 30 38 3a 34 32 3a 34
      36 2d 30 38 3a 30 30 00 32 30 30 33 2d 30 31 2d
      31 35 54 31 31 3a 34 32 3a 34 36 2d 30 38 3a 30
      30 00

    2. 上記のシーケンスを、HMAC-SHA1 を使用して受信者の共有シークレットでハッシュ化します。たとえば、共有シークレットが「abracadabra」 (61 62 72 61 63 61 64 61 62 72 61) の場合は、次のようになります。

      71 1e 89 a7 3e 7c 9e b8 97 11 10 cd 78 57 fd a0 94 da fd

      共有シークレットは、正規化しないでください。また、終端処理も行わないでください。

    3. 上記の結果から 96 ビット (12 バイト) を残して切り捨てます。

      71 1e 89 a7 3e 7c 9e b8 97 11 10 cd

      切り捨て処理によって、ハッシュのセキュリティが向上します。

    4. 上記の結果を Base-64 でエンコードして、次の最終結果を得ます。

      cR6Jpz58nriXERDN

      信頼できるサードパーティは、ProfileResponse ドキュメントに最終結果を挿入して、クライアントとなるエンティティ (ドキュメントの送信者) に送信します。クライアントは、サーバー (ドキュメントの受信者) と直接行うすべての通信で、CredentialMac 要素にその最終結果を挿入します。

    21.1.5 ProfileResponse

    次の cXML の例は、信頼できるサードパーティ (ネットワークハブなど) からクライアント (購買アプリケーションなど) に送信される ProfileResponse の例です。クライアントは、これにより受信サーバーに要求を直接送信できるようになります。

    21.1.6 CredentialMac

    次に示す cXML ドキュメントの一部は、CredentialMac 要素の例です。クライアントは、このような内容を、サーバーに直接送信するドキュメントに挿入します。

    21.2 Auth トランザクション

    Auth トランザクションを利用すると、受信者は、相互に信頼しているサードパーティを通じて、組織の認証情報を検証できます。このトランザクションは、共有シークレットや MAC が含まれていないドキュメントを受け取ったときの認証に使用します。受信者は、送信者 (プリンシパル) の認証情報を AuthRequest ドキュメントに入れ、信頼できるサードパーティに送信して検証を依頼します。プリンシパルがデジタル証明書を使用してクライアント認証を行おうとしている場合、受信者が、プリンシパルの認証情報と、デジタル証明書に関する情報の両方を AuthRequest ドキュメントに含めます。(受信者は、この証明書情報を、その Web サーバーまたは SSL/TLS 実装から取得します。)信頼できるサードパーティは、AuthRequest を受け取り、プリンシパルの認証情報を照会して、プリンシパルが認識されている組織かどうかを確認します。プリンシパルの証明書情報が含まれていた場合、信頼できるサードパーティは、その証明書が有効であることと、その証明書が認証情報に関連付けられている組織のものであることを確認します。認証情報 (および、指定されていれば証明書) による認証が完了すると、信頼できるサードパーティは、検証済みの認証情報が含まれる肯定の AuthResponse で応答します。認証情報が無効な場合、信頼できるサードパーティは、空の cXML Response である状況 403 (Forbidden) を返します。受信者は、AuthResponse で示される有効期限まで、Auth トランザクションの結果をキャッシュすることができます。この期間にプリンシパルから同じ認証情報と証明書が提示された場合、同じ AuthRequest を受信者が再度送信する必要はありません。

    21.2.1 AuthRequest

    エンティティを認証するために、相互に信頼しているサードパーティに送信する要求です。次の例には、X509 証明書情報が含まれています。このデジタル証明書で、要求元エンティティのクライアント認証が行われます。

    21.2.1.1 Credential

    cXML の認証情報です。Credential [29 ページ] を参照してください。

    21.2.1.2 X509Data

    認証に使用する X.509 クライアント証明書を示します。

    X509IssuerSerial

    X.509 証明書のシリアル番号と発行者名を定義します。X509IssuerSerialChild には以下の要素が含まれます。

  • X509IssuerName
    X.509 証明書の発行者の識別名です。この識別名は、RFC 2253 に従って LDAP 識別名を文字列表現したものです。たとえば、次のようになります。

    C=US, O=”Mega Data Security, Inc.”, OU=Secure Server CA

  • X509SerialNumber
    X.509 証明書のシリアル番号です。

    X509SKI

    X.509 証明書のサブジェクトキー識別子です。

    X509 SubjectName

    X.509 証明書のサブジェクトの識別名です。この識別名は、RFC 2253 に従って LDAP 識別名を文字列表現したものです。

    X509CertificDte

    Base-64 でエンコードした X.509v3 証明書です。

    X509CRL

    Base-64 でエンコードした X.509v3 証明書の失効リストです。

    21.2.2 AuthResponse

    AuthRequest ドキュメントの個人エンティティの有効な認証情報のリストを返します。なお、この Response は認証に成功した場合のみ送信します。AuthResponse には次の属性があります。

    属性説明
    expirationDateここに示された日付以降は、AuthResponse に含まれている情報を破棄すべきであることを意味します。この属性が記述されている場合、受信者が expirationDate まで AuthResponse 情報をキャッシュできることを意味します。

    expirationDate が記述されていない場合、キャッシュ処理は禁止されていると解釈する必要があります。