リモートからサーバへアクセスする場合に、アクセスする権利があるかどうかのユーザー認証に使用するプロトコル。
なりすましや不正接続を防止する。

【 SMTP-AUTH 】
メール送信の際にサーバとユーザとの間で認証を行い、 認証された場合のみメール送信を許可する仕組み。
SMTPはもともと認証を持たない単純な仕様であったため、スパムメールの横行を許してしまっていた。その対策として考えられた。

【 OAuth 】
OAuthは，一旦ユーザー認証されたら、別のサービスを利用する場合でも、再度ユーザー認証のための処理が必要なく、ユーザー認証情報を受け渡すことができる仕組み。
「認可情報の委譲」のための仕様です。
あらかじめ信頼関係を構築したサービス間でユーザの同意のもとにセキュアにユーザの権限を受け渡しする仕組み。
サービス間で認可情報を受け渡せると、あるサービスがユーザの認可のもとで別のサービスの管理する情報の取得／追加／更新／削除などを行えるようになります。OAuthに対応したサービスでは、ユーザが外部サービスにパスワードを教えることなく、認可情報の委譲が可能です。また認可情報の適用範囲を指定したり、有効期限を設定することができるため、ユーザが外部サービスにすべての権限を渡すこと無く、自分が利用したいサービスに最低限必要な権限のみを委譲することができます。そのためBasic認証と比べて柔軟かつセキュアな運用が可能です。
OAuthには、大きく分けて3つのサービスが必要です。
1つ目はOAuth Server(OAuth Service Provider)と呼ばれる、ユーザの認可情報を第三者に渡すサービス。OAuthをサポートしたAPIを提供します。
2つ目はOAuth Client(OAuth Consumer)と呼ばれる、OAuth Serverから認可情報を受け取り、ユーザに代っていろいろな情報にアクセスしたり変更／追加を行ったりするサービス。APIを利用する側のサービス。
3つ目が、Resource Owner(User)です。Resource OwnerはOAuth ServerがOAuth Clientに認可情報を渡すことを許可したり、すでに受け渡した認可情報を無効にするといったことができます。実際に利用する本人のこと。

【 RADIUS 】(Remote Authentication Dial In User Service)
サーバーで「認証」・「認可」・「アカウンティング」(AAA)の一元管理を目的とする認証プロトコル。

• 認証(Authentication)
  利用者が誰であるかを識別すること
• 認可(Authorization)
  認証済みの利用者に対してサービスを提供するか否かを判断すること
• アカウンティング(Accounting)
  ログインしたユーザーが使用したコマンド、接続時間、システムイベントなどにタイムスタンプを付加してログとして記録します。

RADIUSサーバーを利用することで、認証機能と提供するサービスとを分離し、複数のサービスでのユーザー認証を一元化できる。

• 通信ではUDPを使う。
• 共通鍵によるサーバー認証機構と改ざん検知機能を持つ。共通鍵なので鍵の漏洩に注意。
• パケット全体の暗号化はされないが、パスワードだけは暗号化されるらしい。
• RFC 2865 - 2869で規定されている。

1. クライアントがサービスを提供するサーバーにリクエストを送信。
2. サービス提供サーバーがRADIUSサーバに「RADIUS要求パケット」を送信。
3. RADIUSサーバーが認証を行い、結果をサービス提供サーバーに返す。

【 TACACS/TACACS+ 】(Terminal Access Controller Access Control System)
機能はRADIUSと同じですが、TACACS+は、AAAの認証、認可、およびアカウンティングのそれぞれを独立したサービスとして個別に利用できるセキュリティープロトコルです。TACACS+プロトコルに対応したTACACS+サーバーには、AAAの認証、認可、およびアカウンティングのそれぞれの情報が、個別のデータベースに記録されています。これにより、認証だけを利用したり、認可だけを利用したりできます。
RADIUSプロトコルでは、AAAモデルが確立される前に開発されたプロトコルであり「認証と認可」が組み合わされており1つのサービスとして統合されて、「アカウンティング」のみ分離されています。
一方、TACACS+プロトコルについては「認証」「認可」「アカウンティング」の3つのサービスが分離しています。

【 Kerberos 】
認証プロトコルやプログラムを含む認証システムの総称。RADIUSやTACACSでは認証,認可を同じフェーズで行うがKerberosでは2フェーズで行う。(サービスを行うプログラムも別。しかし、一般的には同じサーバーで運用する場合が多い。)
ネットワーク認証方式の1つでありサーバとクライアント間の身元確認のために使用するプロトコルです。Kerberosはクライアントとサーバとを相互認証できるだけでなくデータ保全のためにクライアントとサーバ間の通信を暗号化します。
現在ではKerberosバージョン 5 が主に使用されています。　そのため、Kerberosは「 KRB5 」とも呼ばれています。
複数のユーザーそれぞれが，複数のネットワーク・リソース（サーバー）を利用するようなケースにおいて，個々のユーザーは一度だけ認証を受ければ複数のサービスを利用できるようにする仕組み(シングルサインオン)です。
・KDC (Key Distribution Center)
サーバとユーザに関する信頼関係の情報を一括管理する中央データベース

・AS（Authentication Server）
認証を行うサーバー。ユーザからの認証を受け付けるサーバ

・TGS（Ticket Granting Server）
認可を行うサーバー(チケット発行サーバ)。各サーバ・サービスを利用するためのチケットを発行するサーバ

・プリンシパル （principal)
KDCが認証を行うユーザやサーバのこと

・レルム (realm)
同じKDCの配下にあるシステムをグループとして定義する論理ネットワーク

・クレデンシャル (Credential)
資格証明書のこと。セション鍵とTGTを含む

1. クライアントがASにTGT(Ticket Getting Ticket)を要求(ユーザー名、パスワードもこのとき渡す。)
2. ASは認証を行い、認証できた場合、TGTを発行。
   TGTとは、チケット発行のもとになるチケットのこと。
   返されるTGTは以下の情報を含む
   
   • TGST 信用証明書。クレデンシャルと呼ばれる。
   • TGSキー クライアントがTGSとやり取りする際に使用する暗号化鍵
   • ASキー クライアントがASとやり取りする際に使用する暗号化鍵。
   このやり取りは共通鍵で暗号化される。(クライアント/ASサーバーで同じ鍵を事前に登録しておく。)
   
3. クライアントはTGTを使って、クレデンシャルと利用したいサービスの情報をTGSに送付して、利用したいサービスのチケットを要求
4. TGSは認可を行い、問題がなければ以下を返す
   
   • ST(Service Ticket) サービスの利用許可証明(TGSとサービスサーバーで使う鍵で暗号化されている。クライアントは複合できない)
   • Sキー クライアントがサービスサーバーとやり取りする際に使用する暗号化鍵。
   このやり取りは、2で返されたTGSキーを用いて暗号化される。
5. クライアントはSTとユーザー名、IPアドレスなどをサービスを提供しているサーバーに送付し、利用を開始する。

【 シングルサインオン 】(SSO：Single Sign-On)
シングルサインオンとは、1つのIDとパスワードで一度認証を行うことで、複数のWebサービスやクラウドサービスにアクセスできるようにする仕組みのこと。
サービスを切り替えるごとにユーザー認証を行う必要がないので、ユーザーの利便性が上がります。

【 IDaaS 】(Identity as a Service)
IDaaSは、クラウド上で提供される認証サービスです。
IDやパスワードなどの認証情報の管理をクラウド上で管理するサービスです。
機能として、以下のようなものがあります。

• 認証・シングルサインオン
  ・ユーザーの認証
  ・ワンタイムパスワードのような多要素認証
  ・複数のクラウドサービスへのシングルサインオン
  
• ID管理
  ・IDaaSそれ自体のID管理
  ・クラウドサービスのID管理
  
• ID連携
  ・IDaaSと対象のクラウドとのID連携
  ・オンプレミスのID基盤とIDaaSとのID連携
  
• 認可
  ・クラウドサービスへの適切なアクセス権の付与
  ・条件によるクラウドサービスへのアクセスコントロール
  
• 監査

【 IDプロバイダ(IdP) 】(Identity Provider)
各種クラウドサービスがそれぞれ行う認証（例: ユーザーがID・パスワードを入力してログイン）を、クラウドサービスに代わって行い、許可された認証情報をクラウドサービス側に提供することでクラウドサービスを利用できます。
IdPをLDAPやActiveDirectoryなどの認証サーバと連携することで、企業内で利用しているIDとパスワードを、クラウドサービスでも使えるようになります。
「d」を小文字で表記するのが普通です

【 SAML 】(Security Assertion Markup Language)
SAMLとは、OASIS(Organization for the Advancement of Structured Information Standards)によって策定された、異なるインターネットサービス間でユーザー認証を行うための認証情報の規格です。つまり、ユーザーの認証情報をやり取りするルール・プロトコルのことです。
XML ベースの標準規格となっています。SAMLを使うことで、異なるインターネットサービス間であっても、ユーザーの属性情報や権限などの認証に必要な情報をやりとりすることができます。
SAMLの認証では、以下のようなフローで行われます。

1. ユーザがサービスにアクセスします。
2. サービスプロバイダ(SP)(Webサービスを提供する側)は、認証済みかどうかを調べ、認証していなければIdPのURLを調べます。
3. サービスプロバイダ(SP)は、IdPのURLを返送します。
4. ユーザのブラウザは、IdPのURLに自動的にリダイレクトされます。
5. ユーザは、IdPに認証を依頼します。
6. IdPは、ユーザの認証状況を調べ、まだ認証済みでなければ認証処理を行います。
   (IDとパスワードを入力するための認証画面を表示、入力されたIDとパスワードが正しいか判断します)
7. IdPは、認証情報が正しければ、秘密鍵で電子署名した 認証応答(認証トークン)をユーザに返送します。
8. ユーザのブラウザは、サービスプロバイダ(SP)に自動的にリダイレクトされます。
9. ユーザからサービスプロバイダ(SP)に、IdPが発行した認証応答(認証トークン)が送られます。
10. サービスプロバイダ(SP)は、Idpの公開鍵で認証応答(認証トークン)を検証します。
11. 検証した結果、認証応答(認証トークン)が正しければ、ユーザはサービスを利用できるようになります。

このフローからも分るように、IdPが実施するのは認証の処理のみです。
SAML認証ではSPとIdPの間で、信頼関係をつくっておく必要があります。 信頼関係とは、具体的には事前に公開鍵を交換し合うということです。

【 フェデレーション(認証連携) 】
フェデレーションとはクラウドサービス間のID連携の仕組みのことです。
フェデレーションで利用される認証プロトコルのひとつがSAMLです。
フェデレーションのためのプロトコルとしてもうひとつOpenID Connectもあります。

【 DNSSEC 】(domain name system Security Extensions)
DNSサーバーから送られてくるIPアドレスとホスト名の対応情報の信頼性を証明するセキュリティ拡張機能である。DNSキャッシュ・ポイズニングのようなDNS応答のなりすまし攻撃を防ぐためのものだ。
DNSSECでは、応答を送信するDNSサーバーが秘密鍵を使って応答に署名し、受信する側が公開鍵で検証する。秘密鍵を持っていないと正しく署名を付けられないので、署名の検証によって偽の応答を検知できる。

【 EAP 】(（PPP拡張認証プロトコル:PPP Extensible Authentication Protocol)
PPP（Point to Point Protocol）を拡張し認証機能を備えたプロトコルのこと。
EAP-MD5・EAP-TLS・EAP-TTLS・EAP-PEAP・EAP-Ciscoなどの方式がある。

【 EAP-TLS 】（Transport Layer Security）
EAP-TLSは、情報を暗号化して安全に送受信するプロトコルの1つで、電子証明書を利用してクライアントと認証サーバの相互認証を行うもの。電子証明書を使うためセキュリティは高いのだが、クライアントと認証サーバの双方で電子証明書の管理が必要になる。Windows 2000／XPが標準で対応している。

【 EAP-TTLS 】（Tunneled TLS）
MD5とTLS両方の利点を併せ持った方式。トンネルを張り認証を行うことでセキュリティを確保。TTLSの場合、クライアント側では、ユーザーIDとパスワードによる認証を行うことで、導入・管理・運用がTLSと比較して楽だといわれている。その一方で、認証サーバ側では電子証明書が利用されるため、高いセキュリティ性の確保が可能となる。WEPキーの自動生成も可能だ。ただし、クライアントライセンス費用（サプリカント導入）や、米Funk社が提案する方式のため指定の認証サーバを必要とする。

【 EAP-PEAP 】（Protected EAP）
TTLSと同様に、クライアント側ではユーザーIDとパスワードによる認証、認証サーバ側では電子証明書による認証が行われる方式。

1. 平成31年度秋期　問44　　SMTP-AUTH
2. 平成29年度春期　問44　　メールサーバ