SASL とは
Simple Authentication and Security Layer の略です。RFC4422 で定められています。
Web (http) やメール (SMTP, POP3, IMAP) 等では認証が必要になるケースが多いですが、アプリケーション開発者が毎回わざわざ認証モジュールを 1 から作るのはナンセンスです。
SASL は認証 (Authentication) のやり取りと認証情報の保護 (Security) に関する仕組みをあらかじめアプリケーションが使いやすいようにプラグインとして用意しているフレームワークです。
これにより、アプリケーション開発者は認証に関する開発は行わなくて済みます。
SASL を通して以下の 3 つのセキュリティ機能を提供します。
- 通信相手が正しいこと (認証: Authentication)
- 通信が改竄されていないこと (完全性: Integrity)
- 通信が盗聴されていないこと (機密性: Confidentiality)
といったセキュリティを提供することができますが、SASL では具体的な実現方法は規定されていません。
各プロトコルが SASL に対応している必要があります。例えば [ postfix : SMTP ], [ dovecot : POP3/IMAP4 ], [OpenLDAP : LDAP ] 等のアプリケーションやプロトコルが、SASL を認証モジュールとして使っています。
SASL には利用できる『メカニズム』の一覧があります。これは IANA で管理されており、申請が通れば新規に登録することもできます。アプリケーション開発者は認証に関する開発をせずに、ただ、メカニズムを選択すればよいのです。
メカニズムの代表的なものとしては ANNONYMOUS, GSS-API (=KERBEROS_V5 のこと), NTLM, OAUTH, OTP, SAML20, SECURID 等があります。
詳細は以下 IANA のページを参照下さい。
ちなみに、SASL と SAML はともに認証関連のプロトコルではありますが、基本的に関連はありません。SAML は https ベースのシングルサインオンのためのプロトコルです。
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 のより詳しい説明については以下をご参照下さい。
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 と関連があります。
詳細については以下をご参照下さい。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント