Automated Certificate Management Environment (ACME) Extension for Single Sign On Challenges
voluntas概要
本文書は、ACMEサーバがシングルサインオン（SSO）技術を用いてクライアントの電子メール識別子の管理を検証できるようにするためのACMEプロトコル[RFC8555]の拡張機能を規定するものである。また、CAA[RFC8659]のリソースレコード仕様の拡張が定義されており、ドメイン所有者が、ドメイン上の識別子の検証にSSOを採用する際にACMEサーバが依拠するSSOプロバイダのセットを宣言する手段を提供する。
voluntas1. はじめに
最近のアプリケーションでは、ユーザのコンテンツを保護するためにエンド・ツー・エンドの暗号化を使用するケースが増えており、ユーザの識別に電子メールアドレスを使用することが多くなっています。このような状況では、電子メールアドレスと公開鍵を結びつけるX.509証明書を使用することは、自然な認証メカニズムです。証明書の発行者がアプリケーション・プロバイダとは別に存在し、アプリケーション・プロバイダとは独立して電子メールアドレスの管理を検証する場合、アプリケーション・プロバイダが認証されたユーザになりすますことができないという意味で、結果として得られる証明書はエンド・ツー・エンドの認証に使用することができます。
歴史的に、電子メールアドレスの証明書を取得することは困難でした。現在のエンド・ツー・エンドの暗号化された通信アプリケーションは、一般的に、不透明な「セキュリティコード」や「安全番号」の比較に基づいた、手間がかかり、エラーが発生しやすい手動の認証プロセスに依存しています。そのため、実際には、エンド・ツー・エンドの暗号化通信は、通常、アプリケーション・プロバイダーによるなりすまし攻撃に対して脆弱です。
ACMEが導入された当初は、ドメイン名に対する証明書の発行に主眼が置かれており、基本仕様には、ドメイン名の識別子に対するクライアントのコントロールを検証するための課題が含まれていました[RFC8555]。ACMEはその後、電子メールアドレスを含む証明書の発行をサポートするために、電子メール識別子の検証をサポートするように拡張されました[I-D.ietf-acme-email-smime]。後者の仕様では、SMTPを使った検証方法が定義されていますが、これはMUA以外のアプリケーションには適していません。
本仕様では、SAML[SAML]やOpenID Connect[OPENID]などの一般的なWeb指向のシングル・サインオン（SSO）アイデンティティ規格を使用した電子メール識別子の検証を可能にするために、新しいACMEチャレンジ・タイプを導入しています。これらの規格は一般的に、クライアントがブラウザで何らかのサービスを要求して認証を開始し、サービスがクライアントをアイデンティティ・プロバイダにリダイレクトし、プロバイダがクライアントを認証し、プロバイダがクライアントのアイデンティティに関する何らかのアサーションとともにクライアントをサービスにリダイレクトし、最後にサービスがクライアントに対して何らかのクレデンシャルまたはリソース認証を生成するというパターンをとっています。
上述のインタラクションの詳細は複雑になる可能性があり、前述の仕様で十分に文書化されている。しかし、これらはウェブベースのインタラクションであるため、ACMEクライアントは、ブラウザのコンテキスト内で所定のURLを開いて最初の認証要求を開始し、そのインタラクションが終了したことを認識する方法を知っているだけでよい。ACMEクライアントは、チャレンジが成功したかどうかをACMEサーバに問い合わせ、成功した場合には標準的なACME発行フローを完了することができます。この拡張機能をアプリケーションに適切に統合すれば、ユーザーの操作を一切必要としない、完全に自動化された証明書の発行が可能になります。
ACME サーバと依存する ID プロバイダとの間のすべてのやりとりは、これらのサービスがサポートする Web ベースの認証プロトコルの仕様によって管理されることに留意されたい。したがって、これらは本文書の対象外であると考えられる。
また、本文書は、電子メール・ドメインの運用者が電子メール証明書に関連する認証ポリシーを表現できるようにする認証局認証（CAA）のDNSリソース・レコード・タイプの拡張を定義する。
voluntas3. プロトコルの概要
SSO チャレンジの一般的な流れを、標準的な ACME 証明書発行オーダーの文脈で以下に示す。これは、サーバーへの新規注文要求と、クライアントが満たす必要のある認証を示す応答から始まります。クライアントは、これらの認証のうちの 1 つについてリクエストを実行し、サーバのレスポンスには、認証を満たすために使用される可能性のある一連のチャレンジが含まれています。これらの中には、ブラウザベースの認証フローを開始するための明確な「開始URL」を持つ、SSO-01型の1つまたは複数のチャレンジが含まれている場合がある。
クライアントがすでにブラウザベースである場合、クライアントは単にSSO開始URLに直接ナビゲートし、認証フローの完了時に制御が最終的にクライアントに戻ることができるように、リダイレクトURLをクエリパラメータとして提供してもよい。クライアントがブラウザベースでない場合は、ネイティブブラウザまたは組み込みブラウザを起動して、SSO 開始 URL に誘導することができます。多くの場合、この最初のリクエストはACMEサーバによって直接処理されるが、これは必須ではない。最初のリクエストは、採用されているSSO標準に固有のリクエスト・オブジェクト(例: SAMLリクエスト)とともに、最終的にクライアントをIDプロバイダにリダイレクトする。
Client ACME Server
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
request new order ------->
<------- required authorizations
request authorization ------->
<------- SSO challenge with start URL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Browser ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
request on SSO start URL ------->
<------- ACME redirect to provider
w/ authentication request
provider authenticates client (not shown)
provider redirect to ACME ------->
w/ identity assertion
validate provider assertion
record challenge as valid
<------- redirect to client
~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ACME client ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
request challenge ------->
<------- valid
request finalize (CSR) ------->
<------- finalize URL
finalize ------->
<------- certificate
SSOチャレンジフローの概要
ID プロバイダの認証に成功すると、クライアントはプロバイダ・リクエストの発信元にリダイレクトされ、そこでプロバイダのアサーション（SAML アサーションなど）が検証され、ACME サーバは関連するチャレンジが検証された（またはされなかった）ことを記録する。その後、クライアントは、最初のSSO開始リクエストのパラメータとしてオプションで提供されたリダイレクトURIにリダイレクトされることがあります。
ブラウザがリダイレクトURLに戻ることは、認証フローが完了したことをクライアントに示 す。この時点でクライアントは、チャレンジURLを呼び出して、それが有効と記録されたかどうかを 判断し、その後、通常のACME発行フローを完了することができる。
voluntas4. ACME電子メール識別子タイプ
本文書に記載されているSSO-01チャレンジタイプは、「エンドユーザS/MIME証明書のための自動証明書管理環境の拡張」[I-D.ietf-acme-email-smime]で詳述されているように、「e-mail」タイプの識別子を持つ注文要求にのみ適用される。実装は、非電子メール型識別子の検証オプションとして、SSO-01型の課題を提示してはならない[MUST NOT]。
"identifier": { "type": "email", "value":"alice@example.org"}
5. ACME sso-01 チャレンジタイプ
sso-01のチャレンジタイプは、指定されたsso_urlを参照して、その識別子のSSOログインを完了する ことで、クライアントが識別子を制御していることを証明することをチャレンジする。このタイプのチャレンジは、[RFC8555]のセクション8で述べられているすべての 必須フィールドを含まなければならない[MUST]。さらに、以下のフィールドはこの特定のタイプのチャレンジのために定義されている。
sso_url (required, string): Web ベースの識別子検証フローを開始するための URL です。サーバは、SSO プロバイダがクライアントをサーバにリダイレクトする際にチャレンジのステータスを更新できるように、リクエストを特定のチャレンジに関連付けるための十分な情報を URL に含める必要があります。
sso_provider（オプション、文字列）: このチャレンジに依存するSSOプロバイダのドメイン。ACMEサーバは、指定された識別子の検証にいくつものプロバイダを利用してもよいが、各プロバイダはchallenges配列の別個のエントリとして表されなければならない（MUST）。これにより、クライアントはプロバイダのリストを曖昧にして、最も適切なプロバイダを選択することができます。
オプションの sso_provider フィールドは、どの sso-01 チャレンジを実行するかをクライアントが選択する際のガイドとして提供される。たとえば、特定のSSOプロバイダの認証状態をすでに持っているブラウジングコンテキストにアクセスできるクライアントは、ユーザとの対話の必要性を回避するために、そのプロバイダのチャレンジを使用することを選択できる。sso_providerの値が指定されていない場合、sso_urlフィールドで示されるWebページでは、ログインに使用するSSOプロバイダをユーザーが選択できるようにすべきである（SHOULD）。サーバーは、フィールドが提供されていない「値」を含めて、同じ sso_provider 値を持つ 1 つの認可において複数の sso-01 チャレンジを提示してはならない（つまり、最大で 1 つの sso-01 チャレンジが sso_provider フィールドを省略できる）。
クライアントは、まずACMEレスポンスを送信し、次にSSOのURLにアクセスすることで、チャレンジを実行します。チャレンジレスポンスには、オプションのフィールドが1つあります。
redirect_uri（オプション、文字列）：このフィールドがある場合、クライアントはSSO-01チャレンジの完了時に指定されたURIにリダイレクトされます。
redirect_uriの値は、sso-01タイプのチャレンジの終了時に、クライアントの制御を認識し、再開するための手段を提供します。ウェブベースのクライアントの場合、これは、ブラウザをクライアントにリダイレクトすることを意味します。ネイティブ・クライアントの場合は、ブラウザをカスタム・スキーム・ハンドラにリダイレクトすることを意味します。クライアントはまた、チャレンジ・リソースをポーリングすることでSSOプロセスが完了したことを認識することができる。redirect_uriコールバックを介して明示的な通知を受け取ったクライアントであっても、チャレンジが現在有効であることを検証すべきである（SHOULD）。
サーバーは、クライアントからの応答を受け取った後、チャレンジのステータスを処理中に設定しなければならない（MUST）。クライアントが要求されたSSOインタラクションを完了し、その結果、IDアサーションがクレームされた電子メール識別子を検証する場合、チャレンジのステータスはvalidに設定されます。クライアントがSSOインタラクションを完了できなかった場合、またはインタラクションが主張された識別子の検証に失敗した場合、チャレンジのステータスはinvalidに設定されます。
{
"type": "sso-01",
"url": "https://example.org/acme/chall/prV_B7yEyA4",
"status": "pending",
"sso_url": "https://example.org/acme/start-sso/",
"sso_provider": "https://identity-provider.org/sso"
}
6. シングルサインオンと注文処理
SSO URLは、クライアントがSSOフローを開始するためのものです。このフローは、ユーザーのブラウザで実行することを推奨します。サーバーは、SSO URLに対するGETリクエストを受け付けなければならない。このような要求を受け取った場合、サーバーはクライアントを適切なSSOプロバイダーにリダイレクトし、ユーザーが適切に認証されるようにしなければなりません。SSOプロバイダがユーザの認証に成功すると、SSOフローが開始されたときにCAから提供された場所に、適切な認証を伴って、クライアントをCAにリダイレクトする。その後、サーバーは、SAML [SAML]またはOpen ID [OPENID]仕様で指定されているように、プロバイダーの認証が有効であることを検証しなければならない（MUST）。さらに、サーバは、チャレンジが検証することを意図している電子メールアドレスに対して、IdP の認証が有効であることを検証しなければなりません（MUST）。認証の検証が完了したら、検証の結果に応じて注文状況を更新しなければなりません。詳細については、{Guidance}のセクションを参照してください。
RFC8555]の7.4節で定義されているように、クライアントが認証されると、注文の確定に進むことができます。クライアントは、subjectAltNameにユーザーの電子メール識別子を含めるべきであり、証明書に他の識別子が含まれていない場合は、サーバーに提出されるCSRのcommonNameに含めるべきです。
voluntas7. 電子メールの検証に関するガイダンス
ACMEサーバが証明書を発行するためには、電子メールアドレスがその電子メール識別子の権威あるサービスによって証明されている必要があります。ACMEサーバは、SSOプロバイダからの応答を受信すると、ユーザのプロバイダ証明を検証し、適切なチャレンジステータスを更新しなければなりません。プロバイダー認証の検証に成功した場合、サーバーはチャレンジステータスをvalidに更新し、失敗した場合はステータスをinvalidに更新します。認証サービスおよび認証方法は、選択されたプロトコルおよび/またはサービスに特有のガイダンスを使用して、機密性と完全性を確保する方法を採用する必要があります。
7.1. SAML
SAML が優先されるプロトコルの場合、SAML アサーションを取得および処理する機能を実装する際 の指針として、「SSO Profiles of SAML」を使用することが推奨される。このシナリオでは、ID プロバイダは、サブジェクト（ユーザ）に関する SAML アサーションを生成するアサーティン グ・パーティとして機能する。ACME サーバは、ID プロバイダからアサーションを受け取る依拠当事者として機能する。ACME サーバは relaystate パラメータを使用して、ACME サーバと関連する ID プロバイダ間の注文要求を追跡する必要がある。ACME サーバが ID プロバイダから SAML アサーションを受信すると、ACME サーバは前述の relaystate を使用して、アサーションが返された注文要求を見つける必要がある。次に、アサーションを使用してACMEサーバは、アサートされた電子メール識別子を抽出し、それが注文で指定された電子メール・アドレスと正確に一致することを確認する。電子メール・アドレスは、NameID で定義されるか、または受信した SAML アサーションの NameIdentifier で指定される。これは、ID プロバイダの特定の SAML 構成に依存する。SAML]も参照のこと。ID プロバイダが生成した SAML アサーションで電子メール・アドレスが適切にアサートされるようにするために、 特定の構成が必要になる場合があることに注意されたい。
7.2. OpenID
このシナリオでは、OpenID プロバイダが、対象者（ユーザ）に関する ID トークンを生成するアサーティン グ・パーティとして機能する。ACME サーバーは、OpenID プロバイダーから ID トークンを受け取る依拠当事者として機能します。ACMEサーバーは、ユーザーを識別するClaimを持つIDトークンのみを必要とし、コードやその他のトークンタイプは必要とせず、要求してはいけません。ACMEサーバは、OpenIDプロバイダ間の注文要求を追跡するために、authorizeリクエストのstateパラメータを使用する必要があります。IDトークンを受け取ったACMEサーバーは、ステートパラメーターの値を使って適切な注文情報を見つけます。次に、IDトークン内のクレームを使用して、電子メール識別子が注文時に指定された電子メールアドレスと正確に一致するかどうかを確認します。具体的には、ID トークンの email 属性で定義された電子メールアドレスです。サーバーは、トークンの email_verified 属性が設定されていることも確認しなければなりません（MUST）。注文の状態は、この検証の結果を示す適切な有効または無効の状態で更新されます。
voluntas8. 電子メールアドレス証明書の CAA
DNSドメインの保有者は、CAAリソースレコードをプロビジョニングすることで、当該ドメインおよびそのサブドメインに対して証明書を発行する権限を持つCAを制御することができる[RFC8659]。ここでは、CAA を拡張し、ドメイン内の電子メールアドレスに対する証明書の発行を制御できるようにします。以下の制御が可能である。
- どの CA が電子メール証明書を発行するか
- どのような検証方法を使用するか
- CA が使用できる SSO プロバイダ（ここで定義された新しいメカニズム）。
電子メールアドレスの関連RRSetは、電子メールアドレスの「ドメイン」部分を使用して検索されます。CAAは、ドメイン部分に「dot-atom」プロダクションを使用する電子メールアドレスに対してのみサポートされており、その場合、ドメイン部分はDNSドメイン名である[RFC5322]。関連RRSetは、[RFC8659]で定義されたアルゴリズムに従って、このFQDNに対する関連RRSetである。
証明書を発行する前に、準拠するCAはRelevant RRsetが公開されているかを 確認しなければならない(MUST)。このようなRRセットが存在する場合、認証局は(1)証明書要求が該当する CAA RRセットと一致するか、(2)関連するCPまたはCPSで指定された例外が適用されると 判断しない限り、証明書を発行してはならない(MUST NOT)。メールアドレスの関連RRセットに発行を制限するようなプロパティタグが含まれていない場合(例えば、iodefプロパティタグのみが含まれている場合や、CAが認識できないプロパティタグのみが含まれている場合)、CAAは発行を制限しない。
証明書申請では、複数のメールアドレスを指定してもよい。発行者は、証明書要求に指定されたすべてのメールアドレスに対する認証を検証しなければならない。
8.1. CAA issueemail プロパティ
CAA issueemailプロパティは、issueプロパティと同じ構文であり、同様のセマンティクスを持つ。唯一の違いは、指定されたCAがドメイン名証明書ではなく、電子メール・アドレス証明書を発行する権限を与えられていることです。CAは以下のことを要求される。
- FQDN に対する CAA 発行制限処理を行う。
- FQDNに等しいドメイン部を持つ電子メールアドレスを含む証明書を発行する権限を、発行者ドメイン名の保有者、または発行者ドメイン名の保有者の明示的な権限の下に行動する当事者に付与すること。
example.com. IN CAA 0 issueemail "ca1.example.net"
example.com. IN CAA 0 issueemail "ca2.example.net"
電子メールアドレス証明書を発行する過程でCAAレコードを参照するCAは、 issueemailプロパティタグのみに依存しなければならない（MUST）。特に、issueプロパティタグは無視しなければなりません（MUST）。issueemailプロパティタグが存在しても、FQDNや関連するワイルドカードドメイン名を含む証明書の発行は許可されない。
8.2. CAAのvalidationmethodsパラメータの使い方
メールアドレスの検証は、ドメイン名と同様、validationmethodsパラメータで制御できます。検証方法が電子メール識別子に適用できない場合は、このパラメータに含めるべきではありません。この記事を書いている時点では、電子メール識別子に定義されている検証方法は、smime-01とsso-01のみです（[I-D.ietf-acme-email-smime]およびセクション5を参照）。
例えば、以下のようになります。
example.com. IN CAA 0 issueemail "ca1.example.net; validationmethods=email-reply-00"
example.com. IN CAA 0 issueemail "ca2.example.net; validationmethods=email-reply-00,sso-01"
上記のCAAリソースレコードセットは、準拠するCAがca1.example.netまたはca2.example.netのいずれかを自認しない限り、example.comドメイン上で証明書を発行しないというポリシーを宣言している。さらに、これらの CA が ACME CA である場合、ca1.example.net は smime-01 チャレンジのみを提示し、ca2.example.net は smime-01 と sso-01 の両方のチャレンジを提示することができる。
8.3. CAA ssoprovidersパラメータ
本ドキュメントでは、issueemailプロパティのssoproviders CAAパラメータも定義しています。このパラメータが指定されている場合、その値は、SSOプロバイダーを特定する0個以上のドメイン名をカンマで区切った文字列でなければなりません（MUST）。
これらのドメイン名は、sso-01 チャレンジの sso_provider 属性に対応します。ssoprovidersパラメータは、sso-01が許可されたチャレンジタイプではない場合（例えば、Propertyがsso-01を含まないvalidationmethodsパラメータを持っている場合）、提供されるべきではありません。
このパラメータの存在は，それが添付されているPropertyを制約する。CA は、SSO プロバイダがカンマ区切りのドメイン名で識別される場合にのみ、ssoproviders パラメータを持つ Property を考慮して、sso-01 検証方法による発行検証を認可しなければならない。
ssoprovidersパラメータの値は、以下のABNF[RFC5234]に準拠しなければなりません。
provider-domain-name = issuer-domain-name ; RFC 8659参照
ssoproviders = [provider-domain-name (",") provider-domain-name].
前述の例を拡張して、ca2.example.netが2つの特定のSSOプロバイダーのみを使用するように制約します。
example.com. IN CAA 0 issueemail "ca1.example.net; validationmethods=email-reply-00"
example.com. IN CAA 0 issueemail "ca2.example.net; ˶ˆ꒳ˆ˵ )
validationmethods=smime-01,sso-01 ⋈⋈◍＞◡̈*)
ssoproviders=idp1.example.net,idp2.example.net"
このパラメータの存在は、準拠している CA にとって、sso-01 タイプのチャレンジのために頼ることが許されている プロバイダのセットに対する制限と見なされなければならない（MUST）。しかし、実装では、このプロパティで指定された1つまたはすべてのプロバイダに依存しないことを選択してもよい（MAY）。
このパラメータが存在するが、ゼロ長の値を持つ場合、実装はいかなるSSOプロバイダにも依存してはならない（MUST NOT）。sso-01 チャレンジは SSO プロバイダを必要とするため、validationmethods パラメータが存在していても sso-01 が含まれていない場合と同じ効果になります。
voluntas9. セキュリティへの配慮
本文書は、電子メールの識別子に対する追加の検証方法を提供するためにACMEを拡張したものである。ACMEの証明書発行プロセスに関連する一般的なセキュリティの考慮事項については、[RFC8555]を参照してください。
ACMEの検証方法の常として、SSO検証のセキュリティは、検証プロセスが破壊されるリスクと、検証プロセスとACMEトランザクションの間の結合の強さに帰着します。
検証プロセスとACMEトランザクションの結合は、基礎となるSSOプロトコルに組み込まれたトランザクションの関連付けメカニズムを介して管理されます。例えば、OpenID Connectでは、依拠当事者は認証要求の中で状態値を提供し、SSOプロバイダは認証応答と一緒にこれを返します［OPENID］。
SSOベースの認証自体のセキュリティについては、ユーザーのログインに関連する通常のリスクと軽減策が適用されます。認証がパスワードのみに基づいている場合、ユーザーのパスワードを取得できる攻撃者は、そのユーザーの電子メールアドレスの証明書を取得することができます。多要素認証のような標準的な緩和策は、SSOプロバイダの一般的な機能です。特に、これらの緩和策がフィッシングに対する保護を提供している程度には（例えばWebAuthentication [W3C.REC-webauthn-1-20190304]のように）、CAがクライアントを本当のSSOプロバイダーではなくフィッシングサイトに誘導するリスクからも保護している。
SSOベースの証明書発行では、SSO提供者は、指定されたユーザが指定された電子メールアドレスを所有しているかどうかを表明することを信頼されている。悪意のあるSSOプロバイダは、これらの主張を改ざんして、SSOに依存している認証機関に不正な証明書を発行させる可能性があります。このリスクは、ACMEクライアントが、ある検証に使用するSSOプロバイダを選択することを信頼されていることを考えると、特に深刻です。悪意のあるクライアントは、クライアントが改ざんしたSSOプロバイダを使用するようCAに指示することができます。
認証機関が信頼できるSSOプロバイダーを選択することは、このようなリスクに対する最初の防御策となります。クライアントは、CAが提供するSSOプロバイダの中からしか選択できないため、CAが慎重にSSOプロバイダを選択すれば、誤発行のリスクを低減することができる。ssoproviders CAAパラメータは、第2の防御策を提供します。これにより、メールドメイン運営者は、クライアントの選択を、メールドメイン運営者が認可した特定のSSOプロバイダのセットにさらに制限することができます。