$Date:: 2005-09-28 17:47:03 +0900 #$ Kerberos5 いろいろ replay protection ----------------- * AS-REQ リプレイ以前に、誰でも AS-REQ し放題。 同一の AS-REQ を受け取った場合でも、AS-REP を返さなければならないが、 同一の AS-REP を返してもよい [CLAR 3.1.2]、と書かれているので、 (少なくとも encrypted timestamp で) preauth するなら、 リプレイ防御可能だろうが、spec 的にどうなっているかは不明。 * AS-REP AS-REQ に入れておいた nonce と返ってきた nonce が一致するか 確認する。 (この nonce は AS-REQ と AS-REP を対応づけるためにも使う) * TGS-REQ padata フィールドにエンコードされた AP-REQ を含む。 AP-REQ には authenticator が入っているので、AP-REQ と同様の リプレイチェックを行う。 * TGS-REP TGS-REQ に入れておいた nonce と返ってきた nonce が一致するか 確認する。 * AP-REQ client が authenticator に時間を入れる。 - server は、allowable clock skew よりずれていたら、 再送かどうか判別できないので拒否する。(KRB_AP_ERR_SKEW) - server は、allowable clock skew よりずれが小さい範囲は、 見たことのある authenticator を replay cache に覚えておいて、 比較する。一致したら拒否する。(KRB_AP_ERR_REPEAT) 覚えておくのは、 - server name - client name - time - microsecond * AP-REP server は authenticator に入っていた ctime/cusec を AP-REP に入れて返す。client はそれらが自分の送ったものと 等しいかどうかチェックする。これは mutual authentication の ための処理でもあるが、client が ctime/cusec を再利用しない ことで、リプレイ防御にも用いられる。 mutual authentication --------------------- mutual authentication を行う場合には、AP-REP が必須。 1. client は、MUTUAL-REQUIRED フラグを立てて AP-REQ する。 2. server は、authenticator の中に入っていた ctime, cusec を AP-REP の暗号化部分に入れて返す。 3. client は、返ってきた ctime, cusec が、自分の送ったものと 等しいかどうかチェックし、等しければ正しい server からの 返事だと思う。 principal が KDC を信用しているとは、どういうことか。 - realm A は、KDC of A が発行するチケットの cname が正しいと 信用している。(AS が cname に正しく対応する鍵を使うか。 TGS が正しく TGT を検証するか。) --> client 認証 - realm A は、KDC of A が発行するチケットの sname が正しいと 信用している。(チケットを発行するとき、要求された sname に対応する 鍵が正しく使われると信用している。) --> server 認証 (mutual authentication) pre-authentication ------------------ PA-DATA に pre-authentication 用の情報を入れる。[CLAR] PA-DATA は本来 preauth のためだったが、今では別の目的にも使われる。 preauth には、PA-ENC-TIMESTAMP 型が使われる。(たぶん) preauth 必須な KDC が preauth のない AS-REQ を受け取ったら KDC_ERR_PREAUTH_REQUIRED を返す。そのとき PA-DATA を返せる。[PREAUTH] PA-ETYPE-INFO 型を返す [CLAR]。どの鍵で preauth するかを etype で指定するんだろうか。 PKINIT ------ 外から見た PKINIT - client が KDC に登録されていなくてもいい。 (KDC は証明書を見て、その client にチケットを発行するかどうか 決められる) - PA_PK_AS_REQ/PA_PK_AS_REP が飛ぶと、TGT が現れる。 (Kerberos 的) 共有鍵は、PKINIT 後も生成されない。 ところで、PKINIT の時、クライアントはどうやって返事がが正しい KDC から 来たか知ることができるのか。 KDC がサインするんだろうけど、要確認。 --> KDC は、ReplyKeyPack 中の asChecksum に AS-REQ の checksum を 入れる [PKINIT]。(pk-init-27 から) Specifications -------------- - RFC 1510 The Kerberos Network Authentication Service (V5) - draft-ietf-krb-wg-kerberos-clarifications-XX.txt 1510bis に相当。 2005 年 7 月に RFC 4120 になった。 - RFC 3961 (draft-ietf-krb-wg-crypto-XX.txt) encryption type を定義。 clarifications と組になって、RFC 1510 を置き換える。 通称 kcrypto。 2005 年 2 月に RFC 3961 になった。 - RFC 3962 (draft-raeburn-krb-rijndael-krb-XX.txt) kcrypto の元で、AES を使った encryption type を定義。 2005 年 2 月に RFC 3962 になった。 - draft-ietf-krb-wg-rfc1510ter-XX.txt 1510ter。元 draft-yu-krb-wg-kerberos-extensions-XX.txt。 いずれ clarifications を置き換えるものになるらしい。 clarifications がまだ RFC になっていないうちから、 やっている。 - その他いろいろ References ---------- [CLAR] RFC 4120 [PREAUTH] draft-ietf-krb-wg-preauth-framework-02.txt [PKINIT] draft-ietf-cat-kerberos-pk-init-28.txt