# RADIUS と RadSec におけるトランスポート セキュリティ Extensible Authentication Protocol (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 パケット全体を暗号化し、転送中のすべての属性とプロトコルヘッダーを保護します。 以下の表は、これらの違いを要約したもので、外部 ID、NAS IP、呼び出し元ステーション ID などの属性の機密性に影響します。EAP 方式がユーザー資格情報（例: 証明書やパスワード）を暗号化する場合でも、RadSec を使用しない標準 RADIUS ではメタデータは露出したままです。 | プロトコル | RADIUS | RadSec | | ------------- | ---------------------------------- | --------------------- | | トランスポート層プロトコル | UDP（通常） | TCP 上の TLS | | 暗号化 | トランスポート暗号化なし | 完全なトランスポート暗号化 | | 既定ポート\* | UDP 1812 | TCP 2083 | | 注記 | ステートレス。ファイアウォールでフィルタリングされる場合があります。 | ステートフル。安全なトンネルを確立します。 | \*これらのポートは標準として認識されていますが、ローカルポリシーやインフラ上の理由により、導入環境によってはカスタマイズされることがあります。 *** ### 両方のプロトコルにおける RADIUS 共有シークレットの役割 RADIUS 共有シークレットは、パケットの整合性とレガシーな暗号化動作のために使用されます。これは、トランスポートが標準 RADIUS であるか RadSec であるかに関係なく適用されます。 **主な用途:** * **Message-Authenticator AVP**: HMAC-MD5 を使用してパケットの整合性を確保します。 * **User-Password AVP（レガシー方式）**: 共有シークレットを使用して資格情報を暗号化します。 * **RadSec の互換性**: RadSec でも、RADIUS の意味論や中間システムとの互換性のために共有シークレットは維持されます。 {% hint style="info" %} **注:** 共有シークレットがネットワーク上で送信されることはありません。HMAC 操作と AVP の検証のためにローカルで使用されます。 {% endhint %} *** ### データ要素の可視性: RADIUS と RadSec この表では、RADIUS (UDP) 上の EAP-TLS と RadSec (TLS) を使用する場合の主要なデータ要素を、転送中の可視性リスクごとに分類して比較します。
データ要素RADIUS (UDP)RadSec (TLS 上の RADIUS)例 / 注記
外側の RADIUS パケット平文（UDP または TCP 上）。暗号化済み（TLS 上）。ヘッダーと AVP の両方を含みます。例: Wireshark や tcpdump でパケットが表示されます。
ユーザー ID（外部 ID）平文で送信されます。暗号化済み（TLS 上）。anonymous@organisation.com レルームルーティングに使用されます。
RADIUS AVP（属性）一部は平文（例: NAS-IP、User-Name）。TLS により完全に暗号化されます。

NAS-IP-Address,

Calling-Station-Id

RADIUS ヘッダー平文TLS で暗号化

Code (Access-Request), Identifier,

Length,

Authenticator

RADIUS 共有シークレット送信されません（内部で使用）送信されません（内部で使用）AVP の暗号化と Message-Authenticator の検証に使用されます。
EAP ペイロード クライアントとサーバー間で暗号化TLS で暗号化TLS ハンドシェイク、証明書検証などを含みます。
ユーザー資格情報（証明書/キー）EAP トンネル内で暗号化EAP トンネル + TLS で暗号化証明書ベース（EAP-TLS）およびパスワードベース（PEAP）の方式に適用されます。subject CN=jsmith, OU=IT
パスワード（例: PEAP または MSCHAPv2）トンネル方式で暗号化（例: PEAP）EAP トンネル + TLS で暗号化パスワードベースの方式に適用されます。
*** ### ID のプライバシー: 外部 ID と内部 ID トンネリングまたは証明書を使用する EAP 方式（例: PEAP、EAP-TTLS、EAP-TLS）は、外部 ID と内部 ID をサポートします: * **外部 ID**: レルームルーティングを容易にするため、User-Name AVP に平文で送信されます。多くの場合、匿名化されます（例: `anonymous@domain.com`). * **内部 ID**: 暗号化された EAP トンネル内で安全に運ばれます（例: ユーザー名/パスワード、証明書 CN）。 #### トランスポート間の挙動: * では、 **RADIUS**外部 ID は平文で送信され、通信上で可視です。 * では、 **RadSec**では、外部 ID を含むパケット全体が暗号化されます。 RADIUS で外部 ID が平文送信されることに関するプライバシー上の懸念は、ID プライバシーを構成するか、共通名属性に PII データを含まないデバイス証明書を活用することで軽減できます {% hint style="info" %} **注**: Windows のネイティブ EAP クライアントのような一部のプラットフォームでは、EAP-TLS などの方式で既定では ID プライバシーをサポートしない場合があり、外側レイヤーで実際の ID が露出する可能性があります。 {% endhint %} #### 外部 ID 以下の表は、各 OS プラットフォームが外部 ID に通常どのような値を設定するかの概要を示します。 | 資格情報の種類 | 外部 ID | 対象 OS | | ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | ユーザー名/パスワード |



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

| | | デバイス証明書 |

クライアント証明書の subject 名にある共通名（CN）プロパティ。

通常:
- DeviceName
- Intune Device ID （GUID）
- AAD Device ID （GUID）

|

| | ユーザー証明書 |

クライアント証明書の subject 名にある共通名（CN）プロパティ。

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

|

| \*Windows で使用される EAP クライアントは、EAP-TLS の ID プライバシーをサポートしていません。 *** ### ログと導入の考慮事項 #### RadSec (TLS) RadSec は RADIUS パケット全体を暗号化するため、受動的な盗聴を防ぎます。TLS セッションを終了するのはこれらのエンドポイントであるため、ログと診断はネットワーク検査からアプリケーションまたは RADIUS サーバーレベルへ移行します。RadSec に移行する組織は、暗号化されたトラフィックに対応できるよう監視ワークフローを評価する必要があります。 #### RADIUS (UDP) 属性（User-Name、NAS-IP-Address など）が平文で送信されると、トラブルシューティングやライブ診断が容易になり、最小限のツールでパケットキャプチャが可能です。ただし、転送中に機密メタデータが露出するリスクは高まります。 #### ネットワークサポート RadSec のサポートは、すべてのネットワークデバイスやインフラで普遍的ではありません。多くのネットワークスイッチ、無線アクセスポイント、ファイアウォールは従来の RADIUS のみをサポートします。混在環境では、最新コンポーネントとレガシーコンポーネントをつなぐために RadSec-to-RADIUS プロキシが必要になる場合があります。本番環境で RadSec を導入する前に、インフラの評価を推奨します。 *** ### 結論と重要なポイント EAP 方式を RADIUS または RadSec のいずれかで転送しても、ユーザー資格情報に対する同じ強力なエンドツーエンド保護が得られますが、転送中のメタデータとプロトコル要素の露出の仕方は大きく異なります。 * **EAP のエンドツーエンド保護**: EAP は、RADIUS と RadSec の両方でユーザー資格情報を強力に保護します。 * **主な違い**: RADIUS は UDP を使用し、RADIUS パケット自体を暗号化しません。一方、RadSec はパケット全体を TLS で包み込み、すべての属性とヘッダーを通信経路上から隠します。 * **メタデータの機密性**: RadSec はすべてのメタデータ（ヘッダー、属性、外部 ID）を暗号化し、ネットワークレベルでの露出を防ぎます。 * **共有シークレット**: 共有シークレットが送信されることはありません。メッセージ整合性チェックの計算と真正性の検証のためにのみローカルで使用されます。 * **トレードオフ**: RadSec は機密性を向上させますが、暗号化のため診断が複雑になり、またすべてのネットワーク機器でサポートされているわけではありません。 *** ### 標準と RFC 参照 プロトコルと仕様の詳細については: * EAP (Extensible Authentication Protocol): RFC 3748 * EAP-TLS: RFC 5216 * RADIUS (Remote Authentication Dial-In User Service): RFC 2865 * RadSec (TLS 上の RADIUS): RFC 6614