SecureID® SASL メカニズム（RFC2808）

（seed）がdog2であることを表している。

シーケンス番号が１となったら再び初期化からやり直す。もちろん任意のシ ーケンス番号i > 1であっても初期化することが出来る。

このRFCではワンタイムパスワード生成器が生成した64ビットの値に2ビ ットのパリティを加えた66ビットの値をワンタイムパスワードとしてマニュ アルで入力するのは間違いやすいので、OTP生成器が計算した値をパスワード として入力するために、11ビットの値に対応する2048の4文字までのワード との対応表を参照し、このワードを6組使ってユーザがマニュアルでワンタイ ムパスワードを入力する支援システムを用意している。

例えば、生成したワンタイムパスワードは以下のようにコード化される。

    OUST COAT  FOAL MUG BEAK TOTE

この6組の文字はOTPシステムの対応表で66ビットのワンタイムパスワー ド値に変換される。

ワンタイムパスワード（OTP）システムはパスフレーズさえ秘密にしておけ ばクライアントにもサーバーにも秘密のデータを保持することも無く、平文の パスワードがネットワークを流れることもないので盗聴やリプレーアタックを 無効にする。しかし、初期化操作を行わなければならないこと、OTP生成器が 提示する6組のワードをパスワードとして入力しなければならない面倒さがあ り（自動化することも出来る）、またサーバー側はスタティックなパスワードテ ーブルではなく、毎回のログイン時の状態をダイナミックにデータベースに格 納し管理しなければならない問題がある。

このメカニズムは認証用のみであり、完全性や、機密性のサービスは提供し ない。また、プロトコルに影響を与えない。

このメカニズムはIMAP（RFC2060）、ACAP（RFC2244）、POP3(RFC1734)、 LDAPv3（RFC2251）等での使用が可能となっている。

本認証メカニズムは３つのエンティティ、SecureIDトークンを使っている ユーザー、ユーザーがアクセスしたいアプリケーションサーバー、認証サーバ ーを用いる。しかし、本仕様はユーザーと認証サーバー間の仕様は定めず、ユ ーザーとアプリケーションサーバー間の認証のメカニズムを規定する。

本メカニズムはユーザーのクレデンシャル（シード、PIN）をベースにし、

ユーザーと認証サーバーによって共有される。

秘密のシードはトークンに格納される。

ユーザーが認証で必要なのはトークンへの物理アクセスだけではなく、認証 を実行するためにPINも知っていなければいけない。

サーバーからシードを受け取ったユーザーは、その場でトークンにPINを入 力すると、ユーザーはパスコードを生成する。ユーザーはこのパスコードをサ ーバーへ送る。このとき、サーバーとユーザーの間で時間もチェックされてい るため、その場で生成したパスコードは速やかにサーバーへ送らなければ認証 できない。（時間がたっているとエラーになる）

認証手順は以下のとおりである。

(1) 初期化

クライアントはクレデンシャルをローカル情報（シード、現在時刻、ユ ーザーPIN）を使って生成する。

クライアントは最初のレスポンスメッセージで、サーバーへクレデンシ ャルを送る。若しくは、認証メカニズムの初期化のためにリクエストをサ ーバーへ送り、クレデンシャルはサーバーからの初期化リクエストに対す る返事の後でクレデンシャルを送る。

サーバーが新しいPINをリクエストしない限り、クライアントの初期化 リクエストに対するレスポンスのコンテンツは以下のようになる。

Authorization Identity

空の設定だった場合、このフィールドは使われない。これはシステム 管理者やプロキシサーバーが代わりに他のユーザーのIdentityでログイ ンする時に使用される。

このフィールドは255オクテット以下でなければいけない。

UTF-8-encoded（RFC2279）でのみ構成される。

Authentication Identity

使用されたパスコードのIDが入る。空の場合、別の手段でIDのチェ ックを行ったとみなされる。（例：プロトコルでIDチェックを行った場 合。LDAPv3等）

このフィールドは255オクテット以下でなければいけない。

UTF-8-encoded（RFC2279）でのみ構成される。

パスコード

認証で使用するワンタイムパスワード。このフィールドは４オクテッ トを超え、32オクテット以下でなければいけない。UTF-8-encoded

（RFC2279)でのみ構成される。

(2) 認証

サーバーは自身の情報を使ってこれらのクレデンシャルを検証し、成功 したら、サーバーはクライアントに成功を示すレスポンスを返す。このレ スポンスを受け取った後、クライアントは認証される。

このレスポンスが無い場合は、検証が失敗したか、サーバーが追加のク レデンシャルをユーザーに対して必要としているかである。

サーバーが追加クレデンシャルを必要としている場合、サーバーはユー ザーに対して、要求する。

このようなケースが発生するのはサーバーとユーザーで時間同期が取ら れていない場合である。

このSASLメカニズムはInformationalなRFCである。