Java Generic Security ServicesおよびKerberos

Javaに追加された拡張機能

このページでは、メジャー・バージョン番号v1.4からv1.8でJava Generic Security Services API (Java GSS)およびKerberosに追加されたセキュリティ機能および拡張機能について説明し、一覧表示します。

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

Java SE 8用Java Generic Security Services APIおよびKerberosの拡張機能

Java SE 8のJava GSS APIおよびKerberos実装には、次の拡張機能が追加されました。

JDK 8用MS-SFU Kerberosの拡張機能

MS-SFUは、サービスがクライアントに代わってKerberosサービス・チケットを取得できるMicrosoft Kerberos 5の拡張機能を表します。これは、Kerberosによってクライアントとこのサービス間の認証が確立されない(したがって標準Kerberos委任を使用できない)が、サービスがクライアントの名前でKerberosでセキュリティ保護されたバックエンドサーバーにアクセスする必要がある場合に便利です。

MS-SFU拡張機能のサポートはJDK 8で追加されました。これには、MS-SFUで定義するように、S4U2selfおよびS4U2proxyプロトコルのサポートが含まれます。

この機能はセキュアなエンタープライズ・デプロイできわめて便利です。たとえば、一般的なネットワーク・サービスで、フロント・エンド(Webサーバーなど)は、クライアントの代わりにバックエンド(データベース・サーバーなど)にアクセスする必要がある場合があります。標準のKerberos 5は委任をサポートしますが、このチェーン内のすべてのレイヤーが各ステップで明示的にKerberos認証を使用することを必要するため、これは常に可能で、望ましいとは限らない場合があります。

たとえば、クライアントがDigest認証を使用して、Webサーバーにログインした場合、委任されるKerberosクレデンシャルがないため、通常のステップ・バイ・ステップのKerberos 5認証を行うことができません。ただし、MS-SFUでは、フロント・エンドがクライアントのKerberosクレデンシャルを提示しなくてもクライアントの代わりにバック・エンドにアクセスすることができるように、Service for User (S4U2self)拡張を定義しているため、MS-SFUはこの状況でも認証を提供できます。

さらに、標準Kerberos 5委任メカニズム(Microsoftではこれをオープン委任と呼ぶ)には、潜在的なセキュリティ・ギャップがあります。このメカニズムでは、サービス・アカウントがクライアントの委任されたクレデンシャルを持っていると、任意のサービスにアクセスできます。そのため、オープン委任には十分に注意する必要があります。

対照的に、MS-SFU委任(S4U2proxyに実装)ははるかに安全です。ここでは、管理者が、特定のサービスで委任できるサービスを厳密に制御できます。 (Microsoftではこれを制約付き委任と呼びます)。

MS-SFUの実装の詳細

元のKerberos 5プロトコルはRFC 4120で定義されています。 MS-SFUでは、そのプロトコルに2つの拡張を追加しており、Service for User to Self (S4U2self)はフロントエンド・サービスがユーザーの代わりに自分自身へのKerberosサービス・チケットを取得できるようにし、Service for User to Proxy (S4U2proxy)はユーザーの代わりに2番目のバックエンド・サービスへのサービス・チケットを取得できるようにします。

これらの2つの拡張はともに、フロントエンド・サービスがユーザーに代わってKerberosサービス・チケットを取得できるようにします。結果のサービス・チケットはローカルまたはリモート・マシンのその他のサービスへのアクセスに使用できます。

これらの拡張を実装するために、新しいpublicメソッド(GSSCredential::impersonate)がcom.sun.security.jgssパッケージに追加されました。

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

Java SE 6のJava Generic Security Services API (Java GSS)およびKerberos実装には、次の拡張機能が追加されました。

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

Java SE 5.0は、次の別名を持つDESとトリプルDES暗号化タイプとサポートしています。

des-cbc-md5 des-cbc-crc des3-cbc-sha1Java SE 6から、Java GSS/KerberosのAES暗号化タイプ(AES128とAES256Triple DES暗号化タイプが指定されている)を使用できるようになります。これにより、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-crc default_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暗号化タイプのサポート

Java SE 5.0は、次の別名を持つDESおよびトリプルDES暗号化タイプをサポートしています。
des-cbc-md5 des-cbc-crc des3-cbc-sha1Java SE 6から、Java GSS/KerberosのRC4-HMAC暗号化タイプを使用できるようになります。これにより、Windows、Solaris 10、MIT Kerberosなどの他のKerberos実装と、Java SE Kerberos実装の相互運用性が改善されています。 Windows Active Directoryは、RC4-HMACをデフォルトのKerberos暗号化タイプとしてサポートしています。

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-crc default_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 APIでのSPNEGOのサポート

Java SEは、Java GSS APIでSPNEGOメカニズムをサポートするようになりました。

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

Java GSSアプリケーションは現在、基礎となるセキュリティ・メカニズムを選択するための一意のオブジェクト識別子(OID)を指定します。たとえば、Java GSSアプリケーションは、Kerberosメカニズムを使用するためにOID "1.2.840.113554.1.2.2を指定します。これは、follows:
Oid mechOid = new 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は、オペレーティング・システム固有の名前を使用してネイティブGSSライブラリを検索します。たとえば、Solarisの場合にlibgss.so、またはLinuxの場合にlibgssapi.soなどです。必要な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
```

Java SE 5.0用Java Generic Security Services APIおよびKerberosの拡張機能

Java SE 5.0のJava Generic Security Services API (Java GSS)およびKerberos実装には、次の拡張機能が追加されました。

トリプル DES 暗号化タイプのサポート
Java SE 5.0より前は、DES暗号化タイプのみがサポートされていました。 Java SE 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アドレスがサポートされています。 Java SE 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リファレンス・ガイド』のセクション「Kerberos要件」で説明されている、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 API(JGSS)を使用する際に useSubjectCredsOnly プロパティがtrueに設定されている場合は、Ticket Granting Ticket (TGT)がサブジェクトから取得され、GSSセキュリティ・コンテキストを確立するために使用されていました。また、取得されたサービス・チケットは、サブジェクトに保管されませんでした。 useSubjectCredsOnlyがtrueであれば、サービス・チケットもサブジェクトに保管されるようになりました。

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

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

連絡先