要約

  • RFC 5349はPKINITでECC certificate、ECC signature、ECDHを使う方法を定めるInformational RFCで、RFC 4556 messageのsyntaxやsemanticsは変えない。P-256とP-384のsupportをinteroperability requirementとする。
  • Curve parameterが選択されても、peer public keyが正しいcurve上のvalid pointであることは別に確認する必要がある。Long-term ECDH keyに対するinvalid-point interactionは累積し、private keyの露出に至り得る。
  • Parameter拒否時にKDCが返すTD-DH-PARAMETERSも完全には信頼できない。Kerberos errorはintegrity protectedではないため、local policyがretryの上限を決める。Curve、point、certificate、secret、ticket、service accessは独立したreceiptである。

Identifierは期待値を示し、inputの正しさを保証しない

ECC implementationはcurve identifierを見てfield、base point、orderなどのparameter setを選ぶ。これは相互運用に必要な共通語である。しかし、sessionで受信したpublic pointがそのgroupに属するかどうかはidentifierから自動では決まらない。

RFC 5349はIEEE P1363のcheckを行うべきだとし、long-term ECDH private keyの場合を強く警告する。Attackerが用意したpointを誤って処理すると、同じ秘密に対する複数の応答から情報が漏れ、反復によって完全な露出へ進み得る。

したがってlogにcurve=P-256だけを残しても不十分である。Encoded pointのdigest、validation routineの結果、失敗理由、使用したprivate-key instance、ephemeralかreusedか、nonceを結び付ける必要がある。

Key lifetimeが一回のfailureをincidentへ変える

同じinvalid pointでも、毎回新しいephemeral secretを使う場合と、長期間同じprivate keyを使う場合では意味が違う。後者ではsessionをまたぐ観測が同じ秘密へ集約される。

RFC 5349はRFC 4556のnonce logicによるECDH key reuseにも触れる。Reuseが許されることと、安全に実装されたことは別である。Operatorはpolicy上のreuse許可、実際のkey instance、validation failure countを区別しなければならない。

Incident responseで必要なのは「何件失敗したか」だけではない。どのkeyが、何回、どの種類のpointを処理し、その後どのticketを保護したかである。これがなければrotation範囲を過小にも過大にも見積もる。

Parameter negotiationにも別のtrust boundaryがある

Clientがcurveを提案し、KDCが拒否すると、error 65とTD-DH-PARAMETERS listを返せる。ListはKDC preference順で、clientは共通項を選んでretryできる。

しかしKerberos errorにはintegrity protectionがない。Listを弱いsetへ変えたり、両者の本来のpreferenceでない順序にしたりできる。RFC 5349がclientとKDC双方にlocal policyを求めるのはこのためである。

Local allow-listはwireから学習してはいけない。Listはpeer support discoveryの証拠であり、administrative approvalではない。Retryはlocal policy versionとmatched ruleを引用して初めて説明可能になる。

Certificateにparameterがあっても判断は残る

RFC 5349はECC certificate内のdomain parametersを利用すれば、別のpreconfigurationを省けると述べる。Configuration surfaceを減らす点で有用である。

Certificate path、key usage、validity、revocation、principal bindingはそれぞれ必要であり、curve自体のlocal acceptabilityも消えない。Session public point validationも別である。

「certificateから得た」はprovenanceを示す。「このserviceとassurance tierで許可された」を示すものではない。Automationはこの二つを一つのbooleanへ潰してはならない。

Shared secretは中間結果である

Accepted parameterのもとで、KDCはPA-PK-AS-REPにpublic valueを返す。両者はshared EC pointを計算し、x-coordinateをoctet stringへ変換してDHSharedSecretとする。

同じ値を導出できても、certificate identity、freshness、intended realm、KDC reply、ticket issuance、service authorization、user sessionはまだ別の処理である。Cryptographic computationが成功したことを「login成功」と表示すれば、failure layerを誤る。

望ましいreceipt chainは、parameter offer、local policy、certificate、point validation、secret derivation、KDF、authenticated reply、initial ticket、service ticket、application resultである。

Common curveは相互運用と共通障害を同時に作る

RFC 5349はP-256とP-384を必須supportとし、named curveとcustom curve、conservative structureとefficiency、広い共通利用とcatastrophic failureの集中を論じる。実際にcurve breakが起きたとは述べない。

Common baselineはtest matrixとinteroperability failureを減らす。一方、同じimplementation defectやpolicy mistakeのblast radiusを大きくする。Diversityは共通障害を抑える可能性があるが、parserとvalidation pathを増やす。

必要なのはasset inventoryとretirement planである。NIST SP 800-56A Rev. 3、SP 800-186、FIPS 186-5は現在のcaptured referenceで、2008年のtableだけを2026 policyにしてはならない。NISTはSP 800-56A更新を発表したが、現行版のwithdrawalではない。

RFC 8636ではKDF agilityにも同じ境界が現れる。Field欠落はold KDCかdowngradeかもしれず、continuationはlocal policyが決める。2026年のPKINIT post-quantum draftもhintとretryを扱うが、まだwork in progressである。

Deployment factを文書から作らない

RFC 5349はInformationalであり、IANA registryはcode assignmentを示すだけでimplementation populationを数えない。本稿はcurrent vendor support、attack prevalence、named breachを主張しない。

Lu HengのMinimum Initial Specificationは後年のanalogyとして、common grammarとlocal future decisionを分ける。Reality Layersはcurve symbol、document preference、validation result、operational accessを別層に置く。どちらもRFCの歴史的sourceではない。