[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[upki-fed:00395] Re: Back-Channelの設定で8443にする理由

京都産業大学 秋山様
NII 西村様

お世話になっております、OSSTech 相本です。

本件、色々と議論頂いているようでありがとうございます。
別のメールでやりとりされている内容の全容が見えませんので
どのような話になっているのかわかりませんが、
弊社環境でSPとIdPを構築して検証してみましたので
その結果を展開させて頂きます。
（まと外れな内容でしたら申し訳ありません）

検証の結果から申し上げますと、バックチャネル通信ではクライアント証明書が
必須ではありませんでした。
(検証したバージョンは Idp：2.3.3、SP：2.4.3-2.2です。)

【検証：バックチャネルの通信について】
・SPがSAMLリクエストに署名していれば、IdPでは
　SSLネゴシエーション時にクライアント証明書の提示がなくても
　エラーとせず、SPは属性取得可能。
・SPがSAMLリクエストに署名していなければ、IdPは
　SSLネゴシエーション時にクライアント証明書の提示がないとエラーとし、
　SPではSAMLエラーを出力。SPは属性取得できませんでした。
　→IdPでのエラーは以下の通りメッセージの送信者を特定できない
　　旨を示しました。
　 Inbound message issuer was not authenticated.

よって、最初に西村様はクライアント証明書が必須とおっしゃておりますが
「クライアント証明書」または「署名」のどちらかが必須だと思います。
# 試したIdPのバージョンは最新のみですので、昔は必須だったのかもしれません。
# しかし、よく見ますと学認技術ガイドのバックチャネルtomcatの設定も
# clientAuth="want"なのでクライアント証明書提示は任意ですね。
# 必須であれば"true"にすべきかと思います。

SPが提示するクライアント証明書は、秋山様がメールで書かれておりますとおり
shibboleth2.xmlのCredentialResolverで設定した証明書でした。
となりますと、SPはメタデータに書かれている証明書を提示することになりそう
です。

今回の検証の結果から学認フェデレーション内の1.3で通信してくる全てのSPが
バックチャネルの通信時に署名してくるのであれば
クライアント証明書の設定を入れる必要はないということになります。
(もちろん今後新しく1.3通信時に署名しないSPが増えない、という前提にはなり
ますが)
当方では運用フェデレーションのSPがバックチャネル通信時に署名しているか確
認できないので
もしどなたか情報お持ちであれば(このSPは署名する/しない)、ご展開頂けると
幸いです。

最後に、秋山様のメールにもありますが現在運用されている皆様の環境では
クライアント証明書を信頼するための認証局の証明書を登録しているのでしょうか？
tomcatであればkeystoreに、ApacheであればSSLCACertificateFile(またはPath)
に設定を行う必要があります。
例えば運用フェデレーションの海外SPの一つであるElsevierではCOMODOの証明書
使っていますので
COMODOの認証局のルート証明書から登録する必要があると思うのですが、
わざわざ設定を行っているのでしょうか？

以上、よろしくお願い致します。



(2011年10月24日 12:18), Toyokazu Akiyama wrote:
> NII 西村先生
> OSSTech 相本様
> 
> 京都産業大学の秋山です．
> 
> # 学認TFのMLで議論がされておりましたが，それも含めて，
> # このMLにて議論した方がよいとのことですので，つながりが
> # 悪いかもしれませんが，再度投稿させていただきます．
> 
>> 学認の運用フェデレーションには実際に443ポートのみで運用されてい
>> る方もいらっしゃるかと思います。
> 
> 例えば本学は 443 ポートで運用しているのですが，実は単純に
> Shib 1.3 対応を検討できていないためでした．本学では図書館
> 関係のサービス連携は実施できていないため，現状では Shib 1.3
> SP に連携する要望が出ておりません．また，私自身 Shib 1.3
> についてはよくわかっておりません．そのため，残念ながら
> 本学からは有用な情報はご提供できそうにありません．
> 申し訳ありません．
> # 443 に変更したのは，特に大きな理由はないと伺って
> # います．必要があれば修正していただけると思います．
> 
> 本学でも今後 Shib 1.3 に対応するという話があがる可能性
> もあるため，以下確認させてください．失礼ながら文中
> にて記載させていただきます．
> # 以下学認 ML での議論を含みます．
> 
>>> のだとすると、SP のサーバ証明書はClient Authのフラグも
>>> 立っていて欲しいような気がしますが、これは別に Server
>>
>> 確かに、バックチャンネルの通信のみ切り出せば、まさにClient Auth
>> の用途になります。ただ、Shibbolethを始めSAML製品（のうちバック
>> チャンネルでクライアント証明書認証を許容しているもの）が、たまたま
>> extendedKeyUsage(eKU)をチェックしないためClient Authが立って
>> いなくても連携できているという状況です。
>>
>> Relying Partyの立場では、一般的なパブリック証明書を許容するような
>> 状況で、少しでもリスクを減らしたいというのがeKUの役割かなと思っています。
>> すでに「学認メタデータに掲載される」という狭き関門を通過した証明書に
>> ついて、eKUを確認したところでリスクが減る訳ではない（ちゃんと考えた
>> 訳ではありませんが直感的に）。
>>
>> とすると、本当の意味で証明書を精査しなければならない人物、つまり
>> 学認事務局がeKUをチェックし、Client Authの無いものは拒否するか？
>> ということになりますが…
>>
>> 別の観点で、IdPの証明書はアサーションに署名することがメインの目的で
>> あり、TLSクライアント証明書認証に使うのは暗号化と署名を効率的に行な
>> うためのショートカットに過ぎないという見方もできます。Shibboleth IdP
>> のデフォルト設定では、バックチャンネルでクライアント認証されている場合
>> にはアサーション自体には署名も暗号化もされません。
>> # 実のところ、Shibboleth以外の実装でこの辺の設定がどうなっているか
>> # 把握していないのですが。
> 
> 元の質問では，どういう証明書がSPから提示されるのか，とかかれていた
> ように思いますが，Shibboleth SP のコードをざっと見た感じ，CredentialResolver
> （m_credResolver）でクライアント証明書を取得しているように見えるので，
> shibboleth2.xml に設定した証明書を提示してきているものと認識しています．
> 
> 一方，この署名用証明書として，プライベート証明書を設定していた場合，
> 以下のページにかかれている設定だけでは駄目で，対象証明書を検証
> できるような設定を，keystore や Apache のSSLCARevocationPath,
> SSLCARevocationFile あたりに設定する必要があると思ったのですが，
> 図書館系のサービスではこのあたり対応されているのでしょうか？
> メタデータから自動的にインポートされたりしているのでしょうか？
> 
> https://www.gakunin.jp/docs/fed/technical/idp/customize/certpj-metadata
> 
>>> さらに、バックチャネルで送られてくるアサーションも
>>> サーバ証明書で署名されて送られてくるのなら、その検証も
>>> やっているはずで、そうであれば、SSL に脆弱性があったと
>>> しても大丈夫、という話にはならないのでしょうか？
>>
>> ということで、Shibboleth IdPデフォルト設定ではバックチャネル
>> のアサーションは署名/暗号化されません。
>> 先日のBEASTのようにSSL/TLSに脆弱性が発見された場合アサーションに
>> 署名および暗号化するように切り替えることもできますが、
>> - そのようなアサーションをSP側が受け取れるか？の実装上の問題は置いておいても、
>> - SAML1ではアサーション暗号化が定義されていないので解読攻撃には無力
>> - 改竄攻撃に対して、SP側がアサーションに対する署名の検証を怠っていないか、
>>  (TLSサーバ認証と署名と2つの検証があるが、実装上片方の検証を
>>   パスしたらもう片方は検証しないという実装はありそう（SAMLで
>>   ちゃんと規定されていたらすみません）)
>> のような問題がありそうです。
>>
>> 以下に、TLS相互認証と署名・暗号化の比較がありました。（私には理解できません）
>> https://wiki.shibboleth.net/confluence/display/~xxxxxxxx@xxxxxxx/Message+Level+Security
> 
> 相本様が指摘されているとおり，443 に統合すると，いちいちブラウザに
> 証明書選択ダイアログが表示されるのはかなわないので，特定URLのみに
> 証明書要求を設定するのが好ましいと思いますが，Shib 1.3 側の対応は
> よくわかりませんね．
> 
> そういう意味では，別ポートで対応して，クライアント認証を利用する
> 方がよいのかもしれません．
> 
>>
>>
>> On 2011/10/20, at 17:39, NAKAMURA Motonori wrote:
>>
>>> 中村です。
>>>
>>> わかんなくなってきたので、確認させてください。
>>> 、
>>> SSL の通信ではクライアント側/サーバ側、という区別と、
>>> 証明書のextendedKeyUsageにClient Authentication/
>>> Server Authenticationのフラグが立っているという区別が
>>> ありますよね。
>>>
>>> で、例えば、NII IdP だと、サーバ証明書のフラグは
>>> Client/Server Authのものになっていますが、京産大の
>>> IdP をみると、Server Authのみのものになっています。
>>> また、mAP でバックチャネルを使っている meatwiki の
>>> サーバ証明書も、Server Auth だけのものです。
>>>
>>> SSL 通信でクライアント認証（バックチャネルは SP から
>>> initiate するから、SP 側がクライアントになる）している
>>> のだとすると、SP のサーバ証明書はClient Authのフラグも
>>> 立っていて欲しいような気がしますが、これは別に Server
>>> Authのみで構わない（それでもクライアント側の認証は
>>> 可能）、ということでしょうか。
>>> 証明書の検証はメタデータに登録されているものとの
>>> 照合で行われているのですよね。
>>>
>>> さらに、バックチャネルで送られてくるアサーションも
>>> サーバ証明書で署名されて送られてくるのなら、その検証も
>>> やっているはずで、そうであれば、SSL に脆弱性があったと
>>> しても大丈夫、という話にはならないのでしょうか？
>>>
>>> 昔、いろいろ議論した気がするのですが、忘れちゃいました。
>>>
>>> (2011/10/20 13:05), Takeshi NISHIMURA wrote:
>>>> 西村です。
>>>> # 宛先をgakunin-tfに変えています
>>>>
>>>> 学認運用フェデレーションでバックチャンネルに443ポートを使っている
>>>> ところは、
>>>> - 京都産業大学
>>>> - 筑波大学
>>>> - 東邦大学
>>>> の3つですが、Shibboleth IdPで443を使う上でのノウハウや利点・欠点等
>>>> ありませんでしょうか？>  秋山さん、尾崎さん
>>>>
>>>> -------- Original Message --------
>>>> Subject: [upki-fed:00383] Re: Back-Channelの設定で8443にする理由
>>>> Date: Tue, 18 Oct 2011 17:49:28 +0900
>>>> From: AIMOTO NORIHITO<xxxxxx@xxxxxxxxxxxxx>
>>>> Reply-To: xxxxxxxx@xxxxxxxxx
>>>> To: xxxxxxx@xxxxxxxxx, xxxxxxxx@xxxxxxxxx, xxxx@xxxxxxxxxxxxx
>>>>
>>>> NII 西村さま
>>>>
>>>> お世話になります。OSSTech 相本です。
>>>>
>>>> 早々のご回答ありがとうございます。
>>>> ご質問の(1),(2)に関してはメタデータをお送りすることで
>>>> 変更できるとのこと、了解致しました。
>>>>
>>>> また(3)についてもご回答ありがとうございます。
>>>> 不勉強なため、SSLクライアント証明書が必須とは知りませんでした。
>>>> # SOAP内のデータは、IdPが署名によりSPからの要求であると判断すると
>>>> # 考えていました。
>>>>
>>>> しかし、クライアント証明書必須となると別の疑問が浮かびます。
>>>> バックチャネル使用時はtomcat(443利用時はApache)に
>>>> クライアント証明書を要求する定義が必須となりますが、
>>>> SPはどこが発行した認証局の証明書を提示してくるのでしょうか？
>>>> IdPでは、どこから発行されたクライアント証明書を許容すれば良いのでしょうか？
>>>> IdP側でクライアント証明書を許容する認証局の証明書を
>>>> 設定する必要があるかと思います。
>>>> # 技術ガイドを見るとUPKIの証明書を登録しているようです。
>>>> # 学認フェデレーションでのSP-IdP間のクライアント証明書は
>>>> # 「全てUPKI」かとも思いましたが、海外のSPもあるわけですので
>>>> # これはないのでは？と思っております。
>>>>
>>>> 重ねての質問でお手数ではありますが、ご教示頂ければ幸いです。
>>>>
>>>>
>>>>> もしよろしければ利害得失等ありましたらお教えいただければと思
>>>>> います。
>>>> 443の同一ポートで行う場合、SSL再ネゴシエーションの脆弱性(CVE-2009-3555)
>>>> が問題になるなと思いました。
>>>> 特定URLのみクライアント証明書提示を求める設定を行うと、SSL再ネゴシエー
>>>> ションが発生しますが
>>>> 上記脆弱性があるため(セキュリティを考えるなら)Secure Renegotiationにすべ
>>>> きです。
>>>> しかし、未だShibboleth1.3を使う古い環境であると考えると、SPがSecure
>>>> Renegotiationに
>>>> 対応していない可能性があり、接続エラー等問題になるなという懸念が思いつき
>>>> ました。
>>>>
>>>> 以上、よろしくお願い致します。
>>>>
>>>>
>>>>
>>>> (2011年10月18日 15:29), Takeshi NISHIMURA wrote:
>>>>> 相本様
>>>>> NIIの西村と申します。よろしくお願いします。
>>>>>
>>>>> (1)(2)につきましては、こちらで提供している構築ガイドに従った
>>>>> 標準的なメタデータをテンプレートとして生成するようになってお
>>>>> ります。これは利用者の利便性を考えてのものであり、テンプレート
>>>>> に沿わないメタデータを登録できないということではありません。
>>>>>
>>>>> そのような（テンプレート外の）メタデータをお持ちの方は、従来
>>>>> の方法で学認事務局
>>>>> https://www.gakunin.jp/docs/fed/contact
>>>>> までメールにて提出いただければと思います。
>>>>>
>>>>> (3)につきましては、バックチャネルではSSLクライアント証明書認証
>>>>> が必須、というように通常の443とは接続条件が異なり、構成を単純化
>>>>> するためにこのような設定を推奨しているとご理解ください。
>>>>>
>>>>> 学認の運用フェデレーションには実際に443ポートのみで運用されてい
>>>>> る方もいらっしゃるかと思います。
>>>>> もしよろしければ利害得失等ありましたらお教えいただければと思
>>>>> います。
>>>>>
>>>>> 参考情報: IdPのメタデータテンプレート
>>>>> https://www.gakunin.jp/docs/fed/technical/idp/metadata
>>>>>
>>>>> 蛇足:
>>>>> SWITCHでは、上記クライアント証明書認証を不要にする方法を模索して
>>>>> いたようです。結局どうしたかは不明ですが…
>>>>> https://groups.google.com/group/shibboleth-users/browse_thread/thread/d7378c7bb58e94e9/2834ab6ec65d0228
>>>>>
>>>>>
>>>>> (2011/10/18 12:37), AIMOTO NORIHITO wrote:
>>>>>> お世話になります。
>>>>>> オープンソース・ソリューション・テクノロジ 相本と申します。
>>>>>>
>>>>>> Shibboleteh-IdPを導入する案件を担当しておりまして、
>>>>>> IdP構築にあたって疑問点が発生しました。
>>>>>> もしご存知の方がいらっしゃいましたご教示頂ければ幸いです。
>>>>>>
>>>>>> 【Shibboleth1.3との通信】
>>>>>> IdPを構築し、Shibboleth1.3のSPに属性情報を送るためには
>>>>>> Back-Channelの設定が必要かと思います。
>>>>>> SPがIdPにSOAP通信する際のURLはメタデータに書かれていますが、
>>>>>> 学認テストフェデレーションに参加したところ、メタデータ内のURL記載ポート
>>>>>> 番号が
>>>>>> 強制的に8443となります。
>>>>>>
>>>>>> (1) テストフェデレーションのメタデータは自動的に8443で作成されてしまいま
>>>>>> したが、
>>>>>> 　　 443に変更することはできないのでしょうか？
>>>>>> (2) 運用フェデレーションでも(1)は可能でしょうか？
>>>>>> (3) 技術ガイドの構築手順やメタデータでは8443となっておりますが、SOAP通信
>>>>>> のURLを
>>>>>> 　　 Apacheが受ける443と同じにしない（あえてtomcatで受ける）理由が何かあ
>>>>>> るのでしょうか？
>>>>>>
>>>>>> 外部からアクセス可能なポート番号は443だけにしたいと考えております。
>>>>>> どなたかご教示頂ければ幸いです。
>>>>>>
>>>>>> 以上、よろしくお願い致します。
>>
>> --
>> 西村健
>> 国立情報学研究所 TEL:03-4212-2720
> 
> 
> 
> 2011年10月18日17:49 AIMOTO NORIHITO <xxxxxx@xxxxxxxxxxxxx>:
>> NII 西村さま
>>
>> お世話になります。OSSTech 相本です。
>>
>> 早々のご回答ありがとうございます。
>> ご質問の(1),(2)に関してはメタデータをお送りすることで
>> 変更できるとのこと、了解致しました。
>>
>> また(3)についてもご回答ありがとうございます。
>> 不勉強なため、SSLクライアント証明書が必須とは知りませんでした。
>> # SOAP内のデータは、IdPが署名によりSPからの要求であると判断すると
>> # 考えていました。
>>
>> しかし、クライアント証明書必須となると別の疑問が浮かびます。
>> バックチャネル使用時はtomcat(443利用時はApache)に
>> クライアント証明書を要求する定義が必須となりますが、
>> SPはどこが発行した認証局の証明書を提示してくるのでしょうか？
>> IdPでは、どこから発行されたクライアント証明書を許容すれば良いのでしょうか？
>> IdP側でクライアント証明書を許容する認証局の証明書を
>> 設定する必要があるかと思います。
>> # 技術ガイドを見るとUPKIの証明書を登録しているようです。
>> # 学認フェデレーションでのSP-IdP間のクライアント証明書は
>> # 「全てUPKI」かとも思いましたが、海外のSPもあるわけですので
>> # これはないのでは？と思っております。
>>
>> 重ねての質問でお手数ではありますが、ご教示頂ければ幸いです。
>>
>>
>>> もしよろしければ利害得失等ありましたらお教えいただければと思
>>> います。
>> 443の同一ポートで行う場合、SSL再ネゴシエーションの脆弱性(CVE-2009-3555)
>> が問題になるなと思いました。
>> 特定URLのみクライアント証明書提示を求める設定を行うと、SSL再ネゴシエー
>> ションが発生しますが
>> 上記脆弱性があるため(セキュリティを考えるなら)Secure Renegotiationにすべ
>> きです。
>> しかし、未だShibboleth1.3を使う古い環境であると考えると、SPがSecure
>> Renegotiationに
>> 対応していない可能性があり、接続エラー等問題になるなという懸念が思いつき
>> ました。
>>
>> 以上、よろしくお願い致します。
>>
>>
>>
>> (2011年10月18日 15:29), Takeshi NISHIMURA wrote:
>>> 相本様
>>> NIIの西村と申します。よろしくお願いします。
>>>
>>> (1)(2)につきましては、こちらで提供している構築ガイドに従った
>>> 標準的なメタデータをテンプレートとして生成するようになってお
>>> ります。これは利用者の利便性を考えてのものであり、テンプレート
>>> に沿わないメタデータを登録できないということではありません。
>>>
>>> そのような（テンプレート外の）メタデータをお持ちの方は、従来
>>> の方法で学認事務局
>>> https://www.gakunin.jp/docs/fed/contact
>>> までメールにて提出いただければと思います。
>>>
>>> (3)につきましては、バックチャネルではSSLクライアント証明書認証
>>> が必須、というように通常の443とは接続条件が異なり、構成を単純化
>>> するためにこのような設定を推奨しているとご理解ください。
>>>
>>> 学認の運用フェデレーションには実際に443ポートのみで運用されてい
>>> る方もいらっしゃるかと思います。
>>> もしよろしければ利害得失等ありましたらお教えいただければと思
>>> います。
>>>
>>> 参考情報: IdPのメタデータテンプレート
>>> https://www.gakunin.jp/docs/fed/technical/idp/metadata
>>>
>>> 蛇足:
>>> SWITCHでは、上記クライアント証明書認証を不要にする方法を模索して
>>> いたようです。結局どうしたかは不明ですが…
>>> https://groups.google.com/group/shibboleth-users/browse_thread/thread/d7378c7bb58e94e9/2834ab6ec65d0228
>>>
>>>
>>> (2011/10/18 12:37), AIMOTO NORIHITO wrote:
>>>> お世話になります。
>>>> オープンソース・ソリューション・テクノロジ 相本と申します。
>>>>
>>>> Shibboleteh-IdPを導入する案件を担当しておりまして、
>>>> IdP構築にあたって疑問点が発生しました。
>>>> もしご存知の方がいらっしゃいましたご教示頂ければ幸いです。
>>>>
>>>> 【Shibboleth1.3との通信】
>>>> IdPを構築し、Shibboleth1.3のSPに属性情報を送るためには
>>>> Back-Channelの設定が必要かと思います。
>>>> SPがIdPにSOAP通信する際のURLはメタデータに書かれていますが、
>>>> 学認テストフェデレーションに参加したところ、メタデータ内のURL記載ポート
>>>> 番号が
>>>> 強制的に8443となります。
>>>>
>>>> (1) テストフェデレーションのメタデータは自動的に8443で作成されてしまいま
>>>> したが、
>>>> 　　 443に変更することはできないのでしょうか？
>>>> (2) 運用フェデレーションでも(1)は可能でしょうか？
>>>> (3) 技術ガイドの構築手順やメタデータでは8443となっておりますが、SOAP通信
>>>> のURLを
>>>> 　　 Apacheが受ける443と同じにしない（あえてtomcatで受ける）理由が何かあ
>>>> るのでしょうか？
>>>>
>>>> 外部からアクセス可能なポート番号は443だけにしたいと考えております。
>>>> どなたかご教示頂ければ幸いです。
>>>>
>>>> 以上、よろしくお願い致します。
>>>
>>
>>
> 
> 
>