• 検索結果がありません。

ISO/IEC9798-3 認証 SASL メカニズム(RFC3163)

ドキュメント内 「本人認証の現状に関する調査報告書」 (ページ 95-99)

3 認証技術の標準化動向

3.1. ネットワーク認証プロトコル及び API 標準

3.1.5 公開鍵による認証

3.1.5.2 ISO/IEC9798-3 認証 SASL メカニズム(RFC3163)

ンにはクライアントの証明書や乱数R_B、R_AおよびサーバーID への署名を含む

・  クライアントはこのトークンをサーバに送る

・  サーバーはこのトークンを検証する、すなわち TokenABの署名の検証

サーバが送った乱数R_Bが正しいものかを検証

サーバーIDが自身のサーバー識別子と同じかどうかの検証 をする。

(3) 双方向認証

上記のクライアント認証の手順は同じで、以下のサーバ認証の手順が加えら れる。

・  サーバーはトークンTokenBAを作る。このトークンには、乱数R_C、 サーバー証明書、乱数R_A、R_B、T_CおよびクライアントIDへ の署名が含まれる

・  サーバーはこのトークンをクライアントに送る

・  クライアントはこのトークンを以下のように検証する サーバーの署名検証

乱数R_Bが最初にサーバーから送られてきたものと同値かの検 証

乱数R_Aがクライアントの送ったものと同値かの検証 クライアントIDが自分の識別子と同じかどうかの検証

以下にここで用いるトークンのデータ構造を示す。ここではTokenBAは用 途に応じてTokenBA1とTokenBA2に分けられる。

・TokenABはクライアントが作成して、サーバーへ送る認証のためのデータ

で、一方向認証、双方向認証の両方で使われる。

・TokenBA1は一方向認証、双方向認証の両方で使われ、サーバーによって

クライアントへ送られるデータである。TokenBA1はランダム値とオプション としてサーバー名、証明書情報を含む。

・TokenBA2は双方向認証で使われ、サーバーによってクライアントへ送ら

れるデータである。TokenBA2はランダム値、クライアントの名前(オプショ ン)、証明書情報、署名が含まれる。

certフィールドにはRFC2459(現:RFC3280)で定義している証明書パス を含む。

これらのトークンはDERエンコードされる。

TokenAB ::= SEQUENCE {

randomA RandomNumber,

entityB [0] GeneralNames OPTIONAL, certA [1] CertData,

authID [2] GeneralNames OPTIONAL, signature SIGNATURE { TBSDataAB } }

TokenBA1 ::= SEQUENCE {

randomB RandomNumber,

entityB [0] GeneralNames OPTIONAL,

certPref [1] SEQUENCE SIZE (1..MAX) OF TrustedAuth OPTIONAL

}

TokenBA2 ::= SEQUENCE {

randomC RandomNumber,

entityA [0] GeneralNames OPTIONAL, certB [1] CertData,

signature SIGNATURE { TBSDataBA } }

ここでTokenBA1に含まれるTrustedAuthはサーバーがクライアントに示 すトラストアンカー(信頼点)の情報のリストである。ここにはCA名、発行 者名のハッシュ値、発行者鍵のハッシュ値、CA証明書、PKCS#15の鍵ハッシ ュ値が含まれる。

(4) 定義済みのアルゴリズム

  ここで使われるアルゴリズムとしては以下の表 3-4 アルゴリズム定義 が定義可能となっている。

特に、RSA-SHA1-ENCを推奨している。

表  3‑ 4    アルゴリズム定義 

Key        Objec t  Id        Body  R S A- S HA1- E NC   1.2.840.113549.1.1.5      R S A  DS A- S HA1        1.2.840.10040.4.3  ANS I 

E C DS A- S HA1        1.2.840.10045.4.1        ANS I 

(5) IMAP4の例

以下の例はIMAP4に本メカニスムを実装した例である。

S: * OK IMAP4 server ready

C: A001 AUTHENTICATE 9798-U-RSA-SHA1 //一方向認証

S: + MAoECBI4l1h5h0eY //サーバーからの乱数

C:MIIBAgQIIxh5I0h5RYegD4INc2FzbC1yLXVzLmNvbaFPFk1odHRwOi 8vY2VydHMtci11cy5jb20vY2VydD9paD1odmNOQVFFRkJRQURnWUVBZ 2hBR2hZVFJna0ZqJnNuPUVQOXVFbFkzS0RlZ2pscjCBkzANBgkqhkiG9 w0BAQUFAAOBgQCkuC2GgtYcxGG1NEzLA4bh5lqJGOZySACMmc+mDr V7A7KAgbpO2OuZpMCl7zvNt/L3OjQZatiX8d1XbuQ40l+g2TJzJt06o7ogo mxdDwqlA/3zp2WMohlI0MotHmfDSWEDZmEYDEA3/eGgkWyi1v1lEVdF

uYmrTr8E4wE9hxdQrA== //クライアントのトークン

S: A001 OK Welcome, 9798-U-RSA-SHA1 authenticated user: Magnus

//認証成功

このISO9798認証SASLメカニズムはシンプルで、様々な認証プロトコル

への実装が可能な柔軟な方法である。ここでは認証のメカニズムのみを提供し ているが、下位のIPsecと組み合わせて秘匿のメカニズムも実装することが出 来る。

ドキュメント内 「本人認証の現状に関する調査報告書」 (ページ 95-99)