Java Generic Security Services: (Java GSS) および Kerberos

Java に追加された拡張機能

セキュリティーの目次

このページでは、メジャーバージョン番号 v1.4 から v6 で Java に追加されたセキュリティー機能および拡張機能について説明し、そのリストを示します。

注: このドキュメントで説明する API および機能は、変更される場合があります。

Java SE 6 用 Java Generic Security Services (Java GSS) および Kerberos の拡張機能

Java SE 6 の Java GSS/Kerberos 実装には、次の拡張機能が追加されました。

AES 暗号化タイプのサポート

J2SE 5.0 は、次のエイリアスを使用して DES とトリプル DES の暗号化タイプをサポートしています。

des-cbc-md5 des-cbc-crc des3-cbc-sha1 Java SE 6 以降、Java GSS/Kerberos で AES 暗号化タイプ (AES128 および AES256) をサポートしています。これにより、Solaris 10 や MIT Kerberos などのほかの Kerberos 実装と、Java SE Kerberos 実装の相互運用性が改善されています。

AES 暗号化タイプは、Kerberos 構成ファイルの libdefaults セクションで指定されます。次のタグを使用して指定されます。default_tkt_enctypes, default_tgs_enctypes, permitted_enctypes.

(AES128 暗号化タイプ)

aes128-cts aes128-cts-hmac-sha1-96 (AES256 暗号化タイプ)

aes256-cts aes256-cts-hmac-sha1-96 注:JDK の JCE フレームワークには、アプリケーションから利用可能な暗号化アルゴリズムおよび最大暗号化強度に関する制限を施行する機能が含まれます。これらの制限はすべて、「管轄ポリシーファイル」に指定されます。Java SE にバンドルされている管轄ポリシーファイルによって鍵の最大長が制限されています。このため、AES256 暗号化タイプを使用するには、制限のない JCE 暗号化ポリシーをインストールして 256 ビットの鍵の AES を許可する必要があります。

たとえば、構成ファイルの libdefaults セクションには次のような行があります。

default_tkt_enctypes = aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc default_tgs_enctypes = aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crc permitted_enctypes = aes128-cts des3-cbc-sha1 des-cbc-md5 des-cbc-crcdefault_tkt_enctypes は、Ticket-Granting-Ticket のセッション鍵で使用する暗号化タイプを指定するために使用されます。クライアントはこれを使用して、KDC との通信で使用されるセッション鍵の暗号化タイプを制限します。デフォルト値は des-cbc-md5 des-cbc-crc des3-cbc-sha1 aes128-cts です。

default_tgs_enctypes は、サービスチケットのセッション鍵で使用する暗号化タイプを指定するために使用されます。クライアントはこれを使用して、クライアントとサーバーによって共有されるセッション鍵の暗号化タイプを制限します。デフォルト値は des-cbc-md5 des-cbc-crc des3-cbc-sha1 aes128-cts です。

permitted_enctypes は、サービスによる使用が許可された暗号化タイプを指定するために使用されます。サーバーはこれを使用して、サーバーが受け入れるセッション鍵の暗号化タイプを制限します。デフォルト値は des-cbc-md5 des-cbc-crc des3-cbc-sha1 aes128-cts です。
RC4-HMAC 暗号化タイプのサポート

J2SE 5.0 は、次のエイリアスを使用して DES とトリプル DES の暗号化タイプをすでにサポートしています。
des-cbc-md5 des-cbc-crc des3-cbc-sha1 Java SE 6 以降、Java GSS/Kerberos で RC4-HMAC 暗号化タイプをサポートしています。これにより、Windows、Solaris 10 や MIT Kerberos などのほかの Kerberos 実装と、Java SE Kerberos 実装の相互運用性が改善されています。Windows Active Directoiory は、デフォルトの Kerberos 暗号化タイプとして RC4-HMAC をサポートしています。

RC4-HMAC 暗号化タイプは、Kerberos 構成ファイルの libdefaults セクションで指定されます。次のタグを使用して指定されます。default_tkt_enctypes, default_tgs_enctypes, permitted_enctypes.

rc4-hmac arcfour-hmac arcfour-hmac-md5 たとえば、構成ファイルの libdefaults セクションには次のような行があります。

default_tkt_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc default_tgs_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crc permitted_enctypes = aes128-cts des3-cbc-sha1 rc4-hmac des-cbc-md5 des-cbc-crcdefault_tkt_enctypes は、Ticket-Granting-Ticket のセッション鍵で使用する暗号化タイプを指定するために使用されます。クライアントはこれを使用して、KDC との通信で使用されるセッション鍵の暗号化タイプを制限します。デフォルト値は des-cbc-md5 des-cbc-crc rc4-hmac des3-cbc-sha1 aes128-cts です。

default_tgs_enctypes は、サービスチケットのセッション鍵で使用する暗号化タイプを指定するために使用されます。クライアントはこれを使用して、クライアントとサーバーによって共有されるセッション鍵の暗号化タイプを制限します。デフォルト値は des-cbc-md5 des-cbc-crc rc4-hmac des3-cbc-sha1 aes128-cts です。

permitted_enctypes は、サービスによる使用が許可された暗号化タイプを指定するために使用されます。サーバーはこれを使用して、サーバーが受け入れるセッション鍵の暗号化タイプを制限します。デフォルト値は des-cbc-md5 des-cbc-crc rc4-hmac des3-cbc-sha1 aes128-cts です。
Java GSS での SPNEGO のサポート

Java SE は、Java GSS で SPNEGO メカニズムをサポートします。

Java GSS は、複数のセキュリティーメカニズムをサポートするフレームワークです。ただし、GSS-API は、GSS-API ピアが共通のセキュリティーメカニズムを持つかどうかを確立する場合に使用するメソッドを規定しません。擬似セキュリティーメカニズムである Simple and Protected GSS-API Negotiation (SPNEGO) メカニズムを使用すると、GSS-API ピアは、使用する共通のセキュリティーメカニズムとセキュアにネゴシエーションを行うことができます。SPNEGO プロトコルは、採用するセキュリティーメカニズムについてネゴシエーションを行う場合に使用します。

Java GSS アプリケーションは、現在、ベースとなるセキュリティーメカニズムを選択するための一意のオブジェクト識別子 (OID) を指定しています。たとえば、Java GSS アプリケーションは、Kerberos メカニズム Oid mechOid = new Oid("1.2.840.113554.1.2.2"); を使用するために Kerberos メカニズム OID "1.2.840.113554.1.2.2 を指定します。

SPNEGO セキュリティーメカニズムを選択するには、Java GSS アプリケーションは SPNEGO メカニズム OID "1.3.6.1.5.5.2". Oid mechOid = new Oid("1.3.6.1.5.5.2); を指定する必要があります。

SPNEGO のサポートによって、Microsoft 製品との相互運用性が向上しています。SPNEGO プロトコルは、主に HTTP を介して Microsoft サーバーと相互運用したり、Negotiate プロトコルを介して HTTP ベースのクロスプラットフォーム認証をサポートしたりする場合に使用されます。Java SE は、HTTP で SPNEGO 認証スキームもサポートします。Java SE 6 の新規のネットワーク機能のリストを確認してください。
新規の事前認証メカニズムのサポート

Java SE は、新規の事前認証メカニズムをサポートします。

Kerberos は、プリンシパルのアイデンティティーを確認するためのプロトコルです。Kerberos プロトコルは、プリンシパルのアイデンティティーを証明し、プリンシパルの長期秘密の保護機能を高める、事前認証と呼ばれるメカニズムを提供します。

Kerberos 仕様は、Kerberos の事前認証メカニズムのフレームワークを定義しています。最新の Kerberos 仕様は、使用する鍵、salt 更新、およびその他のパラメータについてクライアントに通知する新しい事前認証メカニズムを定義しています。新しい事前認証メカニズムは、追加の事前認証の要件を示しています。

新しい事前認証メカニズムがサポートされたことによって、Java GSS/Kerberos クライアントは必要に応じて salt 値の更新を処理できます。
ネイティブプラットフォーム GSS 統合

この機能を使用すると、Java アプリケーションは、プラットフォームで使用可能なネイティブ GSS 実装の機能を利用できます。Java GSS によるネイティブ GSS ライブラリおよびネイティブメカニズムのリストへの委譲を有効にするには、システムプロパティー「sun.security.jgss.native」を true に設定します。有効にすると、Java GSS は、オペレーティングシステム固有の名前 (たとえば、Solaris: libgss.so、Linux: libgssapi.so) を使用してネイティブ GSS ライブラリを検索します。必要な GSS ライブラリの名前が異なっているか、またはこのライブラリがシステムライブラリのディレクトリにない場合は、システムプロパティー「sun.security.jgss.lib」を使用してフルパスを指定する必要があります。

Java SE 6 では、ネイティブ GSS サポートは Solaris および Linux に限定されています。ネイティブ GSS 統合がサポートされていないプラットフォーム上でこれらのシステムプロパティーを設定しても無視されます。

最初のクレデンシャル取得を JAAS KerberosLoginModule に依存しているデフォルトの Java GSS 実装とは異なり、ネイティブ GSS を使用する場合は、最初のクレデンシャルを事前に取得しておく必要があります。たとえば、JGSS API を呼び出す前に kinit を取得しておく必要があります。

また、Subject.doAs(...) や Subject.doAsPrivileged(...) などの特定のサブジェクトとして操作を行う場合は、使用する GSSCredential をサブジェクトの private クレデンシャルセットに追加する必要があります。このようにしない場合、クレデンシャルが見つからないため GSS 操作が失敗します。
JAAS ログインエントリ名の変更

SunJSSE と JGSS の両方の JAAS ログインエントリ名が統一されたため、異なるメカニズムに対して個別に指定できます。Kerberos 5 の場合、名前は次のとおりです。
```
com.sun.security.jgss.krb5.initiate
com.sun.security.jgss.krb5.accept
```

J2SE 5.0 用 Java Generic Security Services (Java GSS) および Kerberos の拡張機能

J2SE 5.0 の Java GSS/Kerberos 実装には、次の拡張機能が追加されました。

トリプル DES 暗号化タイプのサポート。
J2SE 5.0 より前は、DES 暗号化タイプのみがサポートされていました。J2SE 5.0 では、DES とトリプル DES の両方の暗号化タイプがサポートされています。これにより、Solaris 10 や MIT Kerberos などのほかの Kerberos 実装と、Java SE Kerberos 実装の相互運用性が改善されています。
トリプル DES 暗号化タイプは、Kerberos 構成ファイルの「libdefaults」セクションで指定されます。ファイル中では「des3-cbc-sha1」として指定され、default_tkt_enctypes、default_tgs_enctypes、および permitted_enctypes というタグが付きます。「dec3-cbc-sha1」には次の別名があります。
```
des3-hmac-sha1
des3-cbc-sha1-kd
des3-cbc-hmac-sha1-kd
```
たとえば、構成ファイルの libdefaults セクションには次のような行があります。
```
default_tkt_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
default_tgs_enctypes = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
permitted_enctypes   = des3-cbc-sha1 des-cbc-md5 des-cbc-crc
```
default_tkt_enctypes は、Ticket-Granting-Ticket のセッション鍵で使用する暗号化タイプを指定するために使用されます。クライアントはこれを使用して、KDC との通信で使用されるセッション鍵の暗号化タイプを制限します。デフォルト値は「des-cbc-md5 des-cbc-crc des3-cbc-sha1」です
default_tgs_enctypes は、サービスチケットのセッション鍵で使用する暗号化タイプを指定するために使用されます。クライアントはこれを使用して、クライアントとサーバーによって共有されるセッション鍵の暗号化タイプを制限します。デフォルト値は「des-cbc-md5 des-cbc-crc des3-cbc-sha1」です。

permitted_enctypes は、サービスによる使用が許可された暗号化タイプを指定するために使用されます。サーバーはこれを使用して、サーバーが受け入れるセッション鍵の暗号化タイプを制限します。デフォルト値は「des-cbc-md5 des-cbc-crc des3-cbc-sha1」です。
TCP と UDP の優先設定
Java SE では、Kerberos 構成ファイル (krb5.conf) で「udp_preference_limit」プロパティーがサポートされるようになりました。
KDC にメッセージを送信するときにメッセージのサイズが udp_preference_list よりも大きい場合、Java SE Kerberos ライブラリは TCP を使用します。メッセージのサイズが udp_preference_list より小さい場合は、UDP が 3 回まで試行されます。要求のサイズが大きすぎるという応答が KDC からあると、Java SE Kerberos ライブラリは TCP を使用します。
Kerberos での IPv6 のサポート
Java SE では、Kerberos チケットで IPv6 アドレスがサポートされています。J2SE 5 より前のチケットでは、IPv4 アドレスのみがサポートされていました。
TGT の更新
JDK 5.0 の Java Authentication and Authorizaton Server (JAAS) Kerberos ログインモジュール Krb5LoginModule では、Ticket Granting Ticket (TGT) の更新をサポートしています。これにより、ユーザーによる操作やサービスの再起動を必要とせずに、長時間実行されるサービスの TGT を自動的に更新できます。
この機能により、Krb5LoginModule がチケットキャッシュから期限切れのチケットを取得した場合でも、TGT は自動的に更新され、チケットを要求した呼び出し側のサブジェクトに追加されます。何らかの理由でチケットを更新できない場合、Krb5LoginModule は構成済みのコールバックハンドラを使用してユーザー名とパスワードを検索し、新規 TGT を取得します。

この機能を使用するには、チケットキャッシュを使用するように Krb5LoginModule を構成し、新しく取り入れられた renewTGT オプションを true に設定します。TGT の更新を要求する JAAS ログイン構成ファイルの例を次に示します。
```
server {
  com.sun.security.auth.module.Krb5LoginModule required
        principal=principal@your_realm
        useTicketCache=true
        renewTGT=true;
};
```
renewTGT が true に設定されている場合は、useTicketCache も true に設定する必要があります。設定しない場合は構成エラーが発生します。
SunJSSE のログインエントリ名
JDK 5.0 の SunJSSE プロバイダは、RFC 2712 および『JSSE リファレンスガイド』の「J2SE 5.0 の JSSE の新機能」で説明されている、Kerberos 暗号化方式群をサポートするようになりました。この機能のために、次の JAAS ログイン構成インデックス名が予約されています。
```
com.sun.net.ssl.server
com.sun.net.ssl.client
```
JSSE アプリケーションが明示的な JAAS プログラムなしで Kerberos 暗号化方式群を使用すると、SunJSSE プロバイダはこれらのインデックス名を使用して JAAS ログインモジュールを検出および構成し、必要な Kerberos クレデンシャルを取得します。たとえば、そのようなアプリケーションには次の JAAS 構成ファイルがあります。
```
 com.sun.net.ssl.server {
  com.sun.security.auth.module.Krb5LoginModule required
        principal=service_principal@your_realm
        useKeyTab=true
        keyTab=keytab_name
        storeKey=true;
};
```
エントリが検出されない場合は、デフォルトの「ほかの」インデックス名が使用されます。TLS のサービス名は「host」です。たとえば、「KRBNT-OPERATIONS.EXAMPLE.COM」というレルム内の「raven.example.com」という名前のマシンで TLS サービスを実行する場合、サービスプリンシパル名は次のようになります
```
host/raven.example.com@KRBNT-OPERATIONS.EXAMPLE.COM
```
TLS クライアントには何の制限もないので、有効な Kerberos プリンシパル名であれば使用可能です。
JSSE アプリケーションが明示的な JAAS プログラムとともに Kerberos 暗号化方式群を使用する場合は、上述のインデックス名を含め、任意のインデックス名を使用できます。

Java 2 SDK, Standard Edition, v 1.4.2 の Java GSS の新機能

構成可能な Kerberos 設定
Kerberos Key Distribution Center (KDC) の名前とレルム設定は、Kerberos 構成ファイルによって指定されるか、システムプロパティー java.security.krb5.kdc および java.security.krb5.realm を介して指定されます。前のリリースでは、Kerberos 構成値への変更は、アプリケーションが再起動された場合にのみ有効になりました。
Java プラットフォームの 1.4.2 リリースでは、JAAS 構成ファイルの Krb5LoginModule へのエントリに、新しい boolean 型オプション refreshKrb5Config を指定できます。このオプションが true に設定されている場合は、Krb5LoginModule の login メソッドが呼び出される前に、構成値がリフレッシュされます。
スレーブ Kerberos Key Distribution Center のサポート
Kerberos ではスレーブ KDC を使用できるので、マスター KDC が対応できない場合は、スレーブ KDC がユーザーの要求に応答します。Java SE の初期リリースにおける Sun の Kerberos 実装では、マスター KDC にのみ要求を出していました。そのため、Kerberos 構成ファイルで指定されたデフォルト KDC タイムアウト以内に、またはタイムアウトが指定されていない場合は 30 秒以内に応答がなければ、通信を終了するしかありませんでした。
今回の 1.4.2 リリースにおける Sun の Kerberos 実装では、指定されていればスレーブ KDC に再要求します。スレーブ KDC は、Kerberos 構成ファイルで指定するか、システムプロパティー java.security.krb5.kdc のコロン (:) で区切られた KDC リストを介して指定することができます。
Kerberos Key Distribution Center トランスポート用の TCP をサポート
Sun の Kerberos 実装では、RFC 1510 に従って Kerberos バージョン 5 を実装し、チケット要求に UDP トランスポートを使用します。新しいインターネットドラフトではこの RFC が更新されています。UDP に加えて TCP をトランスポートとしてサポートするには、追加された機能の 1 つが必要です。これにより KDC は、Kerberos チケットが UDP パケットサイズの制限値を超えた場合に、要求を TCP で再送するように指示するエラーコードを返します。
現行の 1.4.2 リリースでの Sun の Kerberos 実装では、TCP の自動フォールバックをサポートするようになりました。したがって、UDP を使用する Kerberos チケット要求が失敗して KDC からエラーコード KRB_ERR_RESPONSE_TOO_BIG が返されると、TCP が自動的にデフォルトトランスポートとなります。
サブジェクトの非公開クレデンシャルの Kerberos サービスチケット
Kerberos サービスチケットは、サブジェクトの非公開クレデンシャルに保管されます。この変更によってアプリケーション開発者は、サービスチケットにアクセスすることにより、JGSS の外部でチケットを利用できます (たとえば、ネイティブアプリケーションや独自の使用など)。さらに、同じサービスに対してアプリケーションがふたたびセキュリティーコンテキストを確立しようとする場合、サービスチケットを再利用できるようになりました。サービスチケットは、再利用できるように有効にしてください。
これまでは、Kerberos V5 で Java Generic Security Services (JGSS) を使用する際に useSubjectCredsOnly プロパティーが true に設定されている場合は、Ticket Granting Ticket (TGT) がサブジェクトから取得され、GSS セキュリティーコンテキストを確立するために使用されていました。また、取得されたサービスチケットは、サブジェクトに保管されませんでした。useSubjectCredsOnly が true であれば、サービスチケットもサブジェクトに保管されるようになりました。

クライアントアプリケーションがサブジェクトの非公開クレデンシャルを検索しても、前のリリースでは TGT のみが検出されました。現行のリリースでは、取得したサービスチケットがすべて検出されます。

この変更に関するバグ報告については、4688866 を参照してください。

連絡先