要約

  • RFC 5113は、接続点発見、NAIとcredentialの選択、AAA routing、payload routing、service capabilityを別の問題面として整理した。
  • 選択は通常、認証より前に行われる。したがって認証で導出される鍵は、最初の広告やidentity selectionをさかのぼって保護できない。
  • 後のchannel bindingは一部を確認できるが、確認不能な広告も残る。広告はmandateではなくhintとして扱い、事前のsecurity policyで拒否できなければならない。

端末はSSIDや接続点を見つけ、利用するrealmとNAIを選び、EAPを開始する。認証の途中で、より弱い方式しか使えないことや、目的のサービスが存在しないことを知る。その時点では選択がすでに接続状態になっている。

再選択には、切断、別の接続点、別のidentity、再認証が必要になる。発見情報は早いほど有用だが、早いほどまだ信頼基盤がない。RFC 5113はその非対称性を問題の中心に置いた。

未来の鍵で過去を検証できない

認証後に生成されるdynamic keyは、認証前のnetwork advertisementを保護できない。順序を変えれば、選択前に認証するために、何を選んで認証すべきかという元の問題が戻る。

事前共有鍵や署名検証のtrust anchorを配れば、広告を早い段階で保護できる。しかし、それは鍵配布、更新、失効、対象ネットワークとの対応付けという別のcontrol surfaceを作る。保護は無料ではない。

したがって証拠は二段になる。最初のhintで候補を選ぶ。認証後に確認可能なパラメータを照合する。照合対象に含まれないservice、price、routeは未確認のまま残す。

発見、identity、routeは一つではない

接続点の可視性は、radioまたはlink layerの機会を示す。上位のroaming relationship、Internet restriction、quality、service、chargingまでは保証しない。

NAIとcredentialの選択は、誰として認証するかを決める。同時にrealmがAAA requestのrouteを左右する。

AAA routingはhome serverへの認証対話を運ぶ。複数のmediating networkが同じrealmに到達できる場合、どれを選ぶかというpolicyは別問題である。

payload routingは認証対話と異なるtunnelを使いうる。AAA成功からdata pathを推定できない。

network capabilityは最終的に利用したいservice、security、price、qualityを扱う。これらを一つの“connected”にまとめると、どの境界が失敗したか分からなくなる。

Credential selectionはAAA routingだった

RFC 5113は、credential selectionとAAA routingを同じidentity selection問題の側面と結論づけた。複数のrealmを持つ利用者は、identityを変えることで到達可能なaccess networkやrouteも変える。

同じidentityが複数のroaming pathで成功することもある。認証結果は同じでも、direct relationshipとconsortium経由ではserviceやpriceが違いうる。

認証が成功したというログは狭い。どのNAIを選び、どのproxyを経て、どのcommercial pathがpayloadを決めたかを残さなければ、成功の意味を監査できない。

Realm hintは失敗から始まる

RFC 4284のrealm hintは、最初のrouteが失敗した後にalternate identityを選ぶ材料を返せる。RFC 5113は、そのlistを完全と見なすことを否定した。packet sizeとconfidentialityのために省略されうるし、dynamic routing protocolではない。

NASが手動表からhintを出すと、core AAAの状態とずれる。到達不能になったrealmを広告し続け、新しいrouteを掲載しないことがある。

実際に次のrequestをrouteするcore proxyがhintも生成すれば、claimとactionが同じfailure domainに置かれる。これはfate sharingであり、完全性の保証ではないが、責任の分裂を減らす。

後から確認できるもの、できないもの

Channel bindingは、secure methodの外で見た情報と内部で保証された情報を比較できる。secure associationも一部を確定できる。しかし全てのadvertised parameterが必ず確認できるわけではない。

確認不能な弱い能力を攻撃者が先に提示し、端末がそれを前提にmethodを選べば、bidding downが成立する。端末は発見より前にminimum security policyを持ち、広告がそれを下げようとしたら無視しなければならない。

Hintとして扱うとは、広告を無価値にすることではない。候補を絞り、失敗を減らす。ただし最後の拒否権を端末とpolicyに残す。

Privacyは効率と衝突する

端末が保持する全realmを認証前に公開すれば、network側は適切なidentityを選びやすい。盗聴者も、利用者がどの組織のcredentialを持つか推測しやすくなる。

最小開示はprivacyを守るが、最初の試行が失敗する可能性を上げる。安全な設計は一括公開を避け、失敗時に段階的に追加情報を出し、回数を制限し、何を開示したかを記録する。

Probeをrouting protocolにしない

NASがEAP identity packetを周期的に送り、hintを集めてrouting tableを作る案は負荷を生む。AAA serverが過負荷でpacketをdropしている時、retransmissionは状況を悪化させる。しかも得られる表は不完全である。

大規模なrealm tableは機密性と管理の問題も持つ。各NASへの手動配布はstale stateを作る。回復mechanismには、原因、hint source、age、retry budget、alternate identity、outcomeが必要である。

証拠の順序

  • 接続点の発見はnetwork identityを証明しない。
  • network名の広告はserviceを証明しない。
  • realm hintは現在のrouteを証明しない。
  • AAA到達はcredential受理を証明しない。
  • 認証成功はpayload pathを証明しない。
  • channel bindingは含まれないpriceを証明しない。
  • session成立は最良の候補を選んだことを証明しない。

RFC 5113の教訓は、trustが遅れて到着することを前提に、早い情報の権限を限定することにある。

情報源