【図解】SASLとGSS-APIの仕組みと違い, LDAPやSMB2での利用例とシーケンス

SASL とは

Simple Authentication and Security Layer の略です。RFC4422 で定められています。

Web (http) やメール (SMTP, POP3, IMAP) 等では認証が必要になるケースが多いですが、アプリケーション開発者が毎回わざわざ認証モジュールを 1 から作るのはナンセンスです

SASL は認証 (Authentication) のやり取りと認証情報の保護 (Security) に関する仕組みをあらかじめアプリケーションが使いやすいようにプラグインとして用意しているフレームワークです

これにより、アプリケーション開発者は認証に関する開発は行わなくて済みます。

SASL を通して以下の 3 つのセキュリティ機能を提供します。

  1. 通信相手が正しいこと (認証: Authentication)
  2. 通信が改竄されていないこと (完全性: Integrity)
  3. 通信が盗聴されていないこと (機密性: Confidentiality)

といったセキュリティを提供することができますが、SASL では具体的な実現方法は規定されていません。

各プロトコルが SASL に対応している必要があります。例えば [ postfix : SMTP ], [ dovecot : POP3/IMAP4 ], [OpenLDAP : LDAP ] 等のアプリケーションやプロトコルが、SASL を認証モジュールとして使っています。

OpenLDAP 自体が postfix や dovecot へ認証機能を提供することも多いですが、ここでは OpenLDAP の機能 (例えば LDAP 検索) を使うための認証 (bind) で SASL が使える、ということを言っています。

SASL には利用できる『メカニズム』の一覧があります。これは IANA で管理されており、申請が通れば新規に登録することもできます。アプリケーション開発者は認証に関する開発をせずに、ただ、メカニズムを選択すればよいのです。

メカニズムの代表的なものとしては ANNONYMOUS, GSS-API (=KERBEROS_V5 のこと), NTLM, OAUTH, OTP, SAML20, SECURID 等があります。

詳細は以下 IANA のページを参照下さい。

http://www.iana.org/assignments/sasl-mechanisms/sasl-mechanisms.xhtml

ちなみに、SASL と SAML はともに認証関連のプロトコルではありますが、基本的に関連はありません。SAML は https ベースのシングルサインオンのためのプロトコルです。

関連記事

シングルサインオン(SSO)とは 一般的なシステムでは、各サーバ毎にユーザ ID とパスワードを各サーバが持っています。AD 連携、LDAP 連携や、さらにそれを束ねる『統合 ID 管理』ソリューションによって、ID / パスワードを共通[…]

GSS-API とは

Generic Security Standard Application Programming Interface の略です。

アプリケーションの認証方法について、通信プロトコルからの独立性・汎用性を高めるためのフレームワークです。

SASL ではクライアントが 1 つのサーバの 1 つのプロトコルに対しての認証・セキュリティに特化しているのに対し、GSS-API はプロトコルに依存しないため、1 つの認証行為を流用し、複数のプロトコルに展開して認証・セキュリティを提供する、シングルサインオンを実現することができます。

GSS-API は認証・セキュリティに使われる汎用的なメッセージのやり取りなどが『緩く』規定されており、ベンダが新たな開発もできるようにしてありますが、サーバとクライアントがともに GSS-API に準拠していれば互換性を持つことができます。

例えば GSS-API を使ったもので有名なのが Windows Active Directory で使われる SPNEGO です。

Active Directory においては Kerberos (TCP : 88) で認証したクライアントは、LDAP サーバへの LDAP (TCP : 389) 通信やファイルサーバへの SMB2 (TCP : 445) 通信の中に SPNEGO を加え、その中に Kerberos で受け取ったサービスチケットを埋め込み提示して認証することができます。

Kerberos と SPNEGO のより詳しい説明については以下をご参照下さい。

関連記事

Kerberos とは Kerberos (読み方:ケルベロス) とはシングルサインオンを実現する『認証・認可プロトコル』です。最新のバージョンは V5 で、RFC4120 にて規格化されています。TCP:88 番ポートを使います。 […]

SASL と GSS-API の違い

SASL は通信プロトコルに依存します。LDAP であれば LDAP 通信プロトコル自体が SASL を意識します。SASL はメカニズムを選択するだけです。

GSS-API は通信プロトコルに依存しません。どんなやり取りが必要になるかをあらかじめ決めてあり、汎用性を目的としているからです。GSS-API は枠組みだけなので具体的な実装が必要です。

以下にイメージ図を示します。

LDAP での利用例

以下に Kerberos 認証をした後に LDAP の BindRequest (認証) ~ SearchRequest (LDAP検索) の流れのパケットキャプチャを示します。

[ LDAP サーバへの BindRequest (認証) ]

SASL + GSS-API + SPNEGO (Kerberos) で Kerberos のチケットを提示

[ LDAP サーバからの BindResponse (認証成功) ]

[ LDAP サーバへの SearchRequest (検索) ]

認証成功後の通信にも SASL + GSS-API のレイヤーにより通信のセキュリティを保護している様子が確認できます。

SMB2 での利用例

以下に SMB2 での認証~ 共有アクセスの様子をパケットキャプチャで示します。

[ SMB2 ファイルサーバへの Session Setup Request (認証) ]

SASL はありませんが、GSS-API + SPNEGO (Kerberos) を使っています。

[ SMB2 ファイルサーバへの Session Setup Request (認証) ]

SMB2 としての Session Setup Request (認証) が成功していること、および GSS-API + SPNEGO が使われていることが分かります。

[ SMB2 ファイルサーバへの Tree Connect Request (共有アクセス要求) ]

GSS-API は出てきません。このあたりは SMB2 のプロトコルおよびアプリケーションの作り方に依るためです。

LDAP署名とLDAPチャネルバインディングについて

マイクロソフトから、2020年初めのアップデートにより、LDAP 署名と LDAP チャネルバインディングが既定で有効になるとアナウンスしています。

これらは SASL / GSS-API と関連があります。

詳細については以下をご参照下さい。

関連記事

LDAP署名とLDAPチャネルバインディングの既定有効化 2020 年 3 月のアップデートにより『LDAP 署名』と『LDAPチャネルバインディング』が既定で有効化となることがマイクロソフトからアナウンスされています。 既定 (デ[…]

IMG

IT/インフラエンジニアの地位とスキル向上のために

関連記事

IT 技術の進化はとどまることを知りません。矢継ぎ早に新たな技術が出てきたり、数年前の技術が時代遅れになったりと、IT エンジニアは勉強し続ける運命のようです。 それをどう思うかはあなた次第。 ビジネスの基本は『付加価値を与える[…]

IMG
関連記事

nesuke の考える NW エンジニアの2つの道 ネットワークエンジニアには 2 つの道があります。 1 つはネットワーク構築一筋で、L4 までをひたすらきっちりと構築していく道。 もう 1 つはネットワークを軸として深堀し[…]

IMG