RADIUS と RadSec におけるトランスポートセキュリティ

拡張認証プロトコル(EAP)を使用したセキュアな認証を展開する際、トランスポートプロトコルの選択(UDP上のRADIUSかTLS上のRADIUS(RadSec)か)は、メタデータやプロトコル要素がネットワーク上でどれだけ安全に送信されるかを決定する上で重要な役割を果たします。

RADIUS と RadSec の双方は、EAP-TLS、PEAP、EAP-TTLS のような一般的な方式で使用されるものを含む EAP メッセージを運ぶことができます。EAP メソッド自体の内部動作は同じままですが、トランスポートプロトコルは可視性、整合性、機密性、および運用上の挙動に影響を与えます。

本書は、暗号化、共有シークレットの使用、属性の露出、ログへの影響、および展開上の考慮点に焦点を当て、RADIUS と RadSec が EAP トランスポートにどのように影響するかを比較します。


トランスポートセキュリティ:主要な違い

EAP-TLS、PEAP、EAP-TTLS などの EAP メソッドは、クライアント(サプリカント)と認証サーバ間の認証メカニズムを提供します。ただし、これらのメソッドは中間ノード間のメタデータのトランスポートを自動的に暗号化するものではありません。この役割はトランスポート層プロトコルが担います:

  • RADIUS(UDP)は EAP メッセージおよび RADIUS 属性を平文で送信します。

  • RadSec(TLS)は RADIUS パケット全体を暗号化し、転送中の全ての属性とプロトコルヘッダを保護します。

以下の表は、外部識別子、NAS IP、Calling-Station-ID などの属性の機密性に影響するこれらの違いを要約しています。EAP メソッドはユーザ認証情報(証明書やパスワードなど)を暗号化する場合がありますが、標準的な RADIUS を使用するとメタデータは露出したままになり、RadSec を使用すると保護されます。

プロトコル
RADIUS
RadSecを使用している場合

トランスポート層プロトコル

UDP(通常)

TCP 上の TLS

暗号化

トランスポートの暗号化なし

トランスポートの完全な暗号化

既定ポート*

UDP 1812

TCP 2083

注記

ステートレス;ファイアウォールでフィルタされる可能性があります。

ステートフル;セキュアなトンネルを確立します。

*これらのポートは認識された標準ですが、一部の導入ではローカルポリシーやインフラの理由でカスタマイズされる場合があります。


両プロトコルにおける RADIUS 共有シークレットの役割

RADIUS 共有シークレットはパケット整合性とレガシーな暗号化動作のために使用されます。これは、トランスポートが標準的な RADIUS であっても RadSec であっても同様に適用されます。

主な使用用途:

  • Message-Authenticator AVP: HMAC-MD5 を使用してパケット整合性を確保します。

  • User-Password AVP(レガシー方式): 共有シークレットを用いて認証情報を暗号化します。

  • RadSec 互換性: RadSec においても、RADIUS のセマンティクスや中間システムとの互換性のために共有シークレットは維持されます。

circle-info

注: 共有シークレットはネットワーク上で送信されることは決してなく、HMAC 操作や AVP 検証のためにローカルで使用されます。


データ要素の可視性:RADIUS と RadSec

この表は、EAP-TLS を RADIUS(UDP)および RadSec(TLS)で使用する際の主要なデータ要素を、転送時の可視性リスクごとに比較したものです。

データ要素
RADIUS(UDP)
RadSec(TLS 上の RADIUS)
例 / 注記

外側の RADIUS パケット

平文(UDP または TCP 上)。

暗号化(TLS 上)。

ヘッダと AVP の両方を含みます。例:Wireshark や tcpdump でパケットが見えること。

ユーザ識別(外側の識別)

平文で送信されます。

暗号化(TLS 上)。

[email protected] レルムルーティングに使用されます。

RADIUS AVP(属性)

一部は平文(例:NAS-IP、User-Name)。

TLS 内で完全に暗号化されます。

NAS-IP-Address,

Calling-Station-Id

RADIUS ヘッダ

平文

TLS 内で暗号化

コード(Access-Request), 識別子、

長さ、

オーセンティケータ

RADIUS 共有シークレット

送信されない(内部的に使用)

送信されない(内部的に使用)

AVP 暗号化および Message-Authenticator の検証に使用されます。

EAP ペイロード

クライアントとサーバ間で暗号化される

TLS 内で暗号化

TLS ハンドシェイク、証明書検証などを含みます。

ユーザ認証情報(証明書/鍵)

EAP トンネル内で暗号化される

EAP トンネル + TLS で暗号化される

証明書ベース(EAP-TLS)およびパスワードベース(PEAP)方式に適用されます。クライアント証明書の subject に含まれるサブジェクト CN=jsmith, OU=IT

パスワード(例:PEAP や MSCHAPv2)

トンネル化された方式(例:PEAP)で暗号化される

EAP トンネル + TLS で暗号化される

パスワードベースの方式に適用されます。


識別プライバシー:外側識別と内側識別

トンネリングや証明書を使用する EAP メソッド(例:PEAP、EAP-TTLS、EAP-TLS)は外側識別と内側識別をサポートします:

  • 外側識別: レルムルーティングを容易にするために User-Name AVP に平文で送信されます。しばしば匿名化されます(例: [email protected]).

  • 内側識別: 暗号化された EAP トンネル内で安全に運ばれます(例:ユーザ名/パスワード、証明書の CN)。

トランスポート間の振る舞い:

  • RADIUS(UDP)では、外側識別は平文で送信され、ワイヤ上で可視化されます。 RADIUS(訳注:原文の断片に合わせて独立して翻訳しています)

  • RADIUS(UDP)では、外側識別は平文で送信され、ワイヤ上で可視化されます。 RadSecを使用している場合RadSec(TLS)では、外側識別を含むパケット全体が暗号化されます。

RADIUS で外側識別が平文で送信されることに関するプライバシー上の懸念は、識別プライバシーの設定やコモンネーム属性に個人識別情報を含まないデバイス証明書の活用によって軽減できます。

circle-info

: Windows のネイティブ EAP クライアントのような一部プラットフォームは、EAP-TLS のようなメソッドで識別プライバシーをデフォルトでサポートしていない場合があり、外側レイヤで実際の識別が露出する可能性があります。

外側識別

以下の表は、各種 OS プラットフォームが外側識別に通常何を設定するかの概要を示します。

認証情報の種類
外側識別
該当する OS

ユーザ名/パスワード

通常: - UPN - メールアドレス

  • Windows (匿名化可能)

  • iOS、iPadOS、macOS (匿名化可能)

  • Android (匿名化可能)

デバイス証明書

クライアント証明書の subject 名の Common Name(CN)プロパティ。 通常: - DeviceName - Intune デバイス ID (GUID) - AAD デバイス ID (GUID)

  • Windows (匿名化できない) *

  • iOS、iPadOS、macOS (匿名化可能)

  • Android (匿名化可能)

ユーザ証明書

クライアント証明書の subject 名の Common Name(CN)プロパティ。 通常: - UPN - メールアドレス

  • Windows (匿名化できない)*

  • iOS、iPadOS、macOS (匿名化可能)

  • Android (匿名化可能)

*Windows で使用される EAP クライアントは EAP-TLS に対する識別プライバシーをサポートしていません。


ログ記録と展開上の考慮点

RadSec(TLS)

RadSec は RADIUS パケット全体を暗号化するため、受動的な盗聴を防ぎます。これにより、ログ記録と診断はネットワークのパケット検査から TLS セッションを終端するアプリケーションまたは RADIUS サーバ側へとシフトします。RadSec に移行する組織は、暗号化されたトラフィックに対応するための監視ワークフローを評価する必要があります。

RADIUS(UDP)

属性(User-Name、NAS-IP-Address など)の平文送信はトラブルシューティングやライブ診断を簡素化し、最小限のツールでパケットキャプチャが可能になります。しかし、これは転送中にセンシティブなメタデータが露出するリスクを高めます。

ネットワークのサポート

RadSec のサポートはすべてのネットワーク機器やインフラで普遍的ではありません。多くのネットワークスイッチ、無線アクセスポイント、およびファイアウォールは従来の RADIUS のみをサポートします。混在環境では、最新コンポーネントとレガシーコンポーネントを橋渡しするために RadSec と RADIUS のプロキシが必要になる場合があります。本番環境で RadSec を展開する前にインフラの評価を推奨します。


結論と主要なポイント

RADIUS でも RadSec でも EAP メソッドはユーザ認証情報に対して同等に強力なエンドツーエンド保護を提供しますが、転送中にメタデータやプロトコル要素がどのように露出するかは大きく異なります。

  • EAP のエンドツーエンド保護: EAP は RADIUS と RadSec の両方でユーザ認証情報に対して強力な保護を提供します。

  • 主な違い: RADIUS は UDP を使用し RADIUS パケット自体を暗号化しませんが、RadSec はパケット全体を TLS で包み、ワイヤ上からすべての属性とヘッダを隠します。

  • メタデータの機密性: RadSec はすべてのメタデータ(ヘッダ、属性、および外側識別)を暗号化し、ネットワークレベルでの露出を防ぎます。

  • 不一致の: 共有シークレットは決して送信されません。それはメッセージ整合性チェックを計算し、真正性を検証するためにローカルでのみ使用されます。

  • トレードオフ: RadSec は機密性を強化しますが、暗号化により診断が複雑になり、すべてのネットワーク機器でのサポートが普遍的ではないという欠点があります。


標準と RFC 参照

プロトコルと仕様の詳細については:

  • EAP(Extensible Authentication Protocol):RFC 3748

  • EAP-TLS:RFC 5216

  • RADIUS(Remote Authentication Dial-In User Service):RFC 2865

  • RadSec(RADIUS over TLS):RFC 6614

最終更新

役に立ちましたか?