ネットワーク・ワーキンググループ C. Rigney Request for Comments: 2138 Livingston Obsoletes: 2058 A. Rubens カテゴリー: 標準トラック Merit W. Simpson Daydreamer S. Willens Livingston 1997年4月 Remote Authentication Dial In User Service (RADIUS) 遠隔認証ダイアル・イン・ユーザー・サービス(RADIUS) このメモの状態(Status of this Memo) このドキュメントはインターネットを指定します、標準は、インターネットコミュニティーのためのプロトコルを追跡します、また改良のための議論および提案を要求します。 このプロトコルの標準化状態およびステータスに関しては「インターネットの公式プロトコル規格(Official Protocol Standards)」(STD 1)の現在の版を参照してください。 このメモの分配は無制限です。 アブストラクト このドキュメントは、そのリンクを確証することを望むネットワーク・アクセス・サーバー(Network Access Server)と共有された認証サーバーの間の認証、認可および配置情報を運ぶためにプロトコルについて記述します。 実装メモ(Implementation Note) このメモはRADIUSプロトコルの資料です。 このプロトコルのための ポート番号の割り当ての中にある混乱がありました。 The early deployment of RADIUS was done using the erroneously chosen port number 1645, which conflicts with the "datametrics" service. The officially assigned port number for RADIUS is 1812. RADIUSの初期の配備は、誤って選ばれたポート番号1645(それは「datametrics」サービスと矛盾する)を使用して、終わりました。 RADIUSのための公式に割り当てられたポート番号は1812です。 目次(Table of Contents) 1. はじめに....................................... 3 1.1 必要条件の明細............................... 4 1.2 用語........................................ 5 2. オペレーション.............................................. 5 2.1 挑戦/レスポンス............................... 7 2.2 PAPとCHAPのを備えた2.2の相互オペレーション。................ 7 2.3、なぜUDP? ........................................8 3. パケット・フォーマット(Packet Format).........................................10 4. パケット・タイプ(Packet Types)....................................... 13 4.1 アクセスリクエスト(Access-Request)................................... 13 Rigney、et. al. 標準トラック [1ページ] RFC 2138 RADIUS 4月の1997 4.2 アクセス受理(Access-Accept).................................... 14 4.3は...................................をアクセス拒絶します。 15 アクセス挑戦(Access-Challenge)4.4................................. 17 5. 属性.......................................。 ...... 18 ユーザー・ネーム5.1........................................ 21 ユーザパスワード(User-Password)5.2.................................... 22 CHAPパスワード(CHAP-Password)5.3.................................... 23 NASIPアドレス(NAS-IP-Address)5.4................................... 24 NASポート(NAS-Port)5.5........................................ 25 サービスタイプ(Service-Type)5.6..................................... 26 組み立てられたプロトコル(Framed-Protocol)5.7.................................. 28 組み立てられたIPアドレス(Framed-IP-Address)5.8................................ 29 組み立てられたIP-Netmask(Framed-IP-Netmask)5.9................................ 29 組み立てられたルーティング(Framed-Routing)5.10................................... 30 フィルタ-Id(Filter-Id)5.11........................................ 31 組み立てられたMTU(Framed-MTU)5.12....................................... 32 組み立てられた圧縮(Framed-Compression)5.13............................... 33 ログインIPホスト(Login-IP-Host)5.14.................................... 33 ログインサービス(Login-Service)5.15.................................... 34 ログインTCPポート(Login-TCP-Port)5.16................................... 35 5.17(割り当てられていない)..................................... 36 5.18の返答メッセージ(Reply-Message)。 .................................. 36 コールバック数(Callback-Number)5.19.................................. 37 回収-Id(Callback-Id)5.20...................................... 38 5.21(割り当てられていない)..................................... 38 組み立てられたルート(Framed-Route)5.22..................................... 39 組み立てられた-IPXネットワーク(Framed-IPX-Network)5.23............................... 40 5.24は.......................................を述べます.... 40 5.25は.......................................を分類します.... 41 ベンダー特定の5.26.................................. 42 セッションタイムアウト(Session-Timeout)5.27.................................. 44 使用されていないタイムアウト(Idle-Timeout)5.28..................................... 44 終了アクション(Termination-Action)5.29............................... 45 呼ばれたステーション-Id(Called-Station-Id)5.30................................ 46 呼ぶステーション-Id(Calling-Station-Id)5.31............................... 47 NAS確認者(NAS-Identifier)5.32................................... 48 代理州(Proxy-State)5.33...................................... 48 ログイン-LATサービス(Login-LAT-Service)5.34................................ 49 ログイン-LATノード(Login-LAT-Node)5.35................................... 50 ログイン-LATグループ(Login-LAT-Group)5.36.................................. 51 組み立てられたアップル・トークリンク(Framed-AppleTalk-Link)5.37............................ 52 組み立てられたアップル・トークネットワーク(Framed-AppleTalk-Network)5.38......................... 53 組み立てられたアップル・トークゾーン(Framed-AppleTalk-Zone)5.39............................ 54 CHAP挑戦(CHAP-Challenge)5.40................................... 55 NASポートタイプ(NAS-Port-Type)5.41.................................... 55 ポート限界(Port-Limit)5.42....................................... 56 ログイン-LATポート(Login-LAT-Port)5.43................................... 57 属性.............................の5.44のテーブル。 58 Rigney、et。 al。 標準は[2ページ]を追跡します RFC 2138 RADIUS 4月の1997 6. 例.......................................。 ........ 59 指定されたホスト(Specified Host)...................への6.1のユーザテルネット(User Telnet)。 60 CHAP............を備えた組み立てられたユーザ(Framed User)を確証する(6.2の)こと。 60 挑戦レスポンス(Challenge-Response)カード...............を持った6.3人のユーザ。 61 セキュリティ考察(Security Considerations)......................................。 63 参照.......................................。 ............. 64 確認応答.......................................。 ....... 64 椅子アドレス(Chair’s Address).......................................。 ........ 65 著者アドレス(Author’s Addresses)....................................... 65 1. はじめに 多くのユーザのための分散した連続物ラインおよびモデム・プールの管理は、重要な管理上の支援の必要を作成するかもしれません。 モデム・プールが定義によるので、外部の世界へのリンク、それらは、セキュリティ、認可および会計への注意深い注意を要求します。 これは、ユーザの単一の「データ・ベース」(それは、ユーザ(例えばSLIP、PPP、telnet、rlogin)に配達するタイプ・オブ・サービスを詳述する構成情報と同様に認証も(確認するユーザー名およびパスワード)考慮に入れる)の管理により最も達成することができます。 RADIUSの重要な特徴は次のとおりです: クライアント/サーバーモデル ネットワーク・アクセス・サーバー(Network Access Server)(NAS)はRADIUSのクライアントとして作動します。 クライアントは、ユーザ情報を計画的だったRADIUSサーバーへ渡し、次に、返されるレスポンスに作用すること原因です。 ユーザを確証しかつ、次に、クライアントがユーザにサービスを配達するのに必要な構成情報をすべて返して、ユーザ接続リクエストを受け取ること、RADIUSサーバーは原因です。 RADIUSサーバーは、他のRADIUSサーバーあるいは他の種類の認証サーバーへのプロキシークライアントの役割をすることができます。 ネットワーク・セキュリティ クライアントおよびRADIUSサーバーの間のトランザクションは、共有された秘密(それはネットワーク上に送られない)の使用によって確証されます。 さらに、いかなるユーザ・パスワードも、安全でないネットワーク上でスヌープする誰かがユーザのパスワードを決定することができたという可能性を除去するためにクライアントおよびRADIUSサーバーの間で暗号化されて、送られます。 Rigney、et。 al。 標準は[3ページ]を追跡します RFC 2138 RADIUS 4月の1997 柔軟な認証メカニズム RADIUSサーバーは、ユーザを確証する様々な方法を支援することができます。 ユーザによって与えられたユーザー名およびオリジナルのパスワードを供給される場合、それはPPP PAPかCHAP、UNIXログインおよび他の認証メカニズムを支援することができます。 拡張可能なプロトコル トランザクションはすべて、可変長さ属性長さ値(Attribute Length Value)3-tuplesで構成されます。 新しい属性価値はプロトコルの不穏にする既存のインプリメンテーションなしで加えることができます。 1.1. 必要条件の明細 このドキュメントでは、いくつかの言葉が明細の必要条件を示すために使用されます。 これらの単語はしばしば資本化されます。 MUST、この単語あるいは形容詞「要求された。」手段、定義は明細の絶対的な要求です。 MUST NOT、この句手段、定義は明細の絶対的な禁止です。 SHOULD、この単語あるいは形容詞「推薦された。」そこに存在するかもしれない手段、このアイテムを無視する特別の環境中の有効な理由、しかし、十分な含意は異なるコースを選ぶ前に理解され注意深く量られるに違いない。 MAY、この単語あるいは形容詞「オプションの」、手段、このアイテムは代案の許可されたセットのうちの1つです。 このオプションMUSTを含んでいないインプリメンテーション、オプションを含んでいる別のインプリメンテーションと共同で作業するために準備されています。 Rigney、et。 al。 標準は[4ページ]を追跡します RFC 2138 RADIUS 4月の1997 1.2. 用語 このドキュメントは頻繁に次の用語を使用します: NASをサービスする、PPPまたはテルネットのようなダイヤルインユーザにサービスを提供します。 サービスが最初に提供されるポイントとして定義されたセッションの始めおよびセッションの終了と共に、NASによってダイヤルインユーザに提供される各サービスがセッションに任命するセッションは、サービスがどこで終了されるかポイントとして定義しました。 NASがそれを支援する場合、ユーザは平行またはシリーズの中に多数のセッションを行っているかもしれません。 暗黙に廃棄してください。 これは、インプリメンテーションがそれ以上の処理のないパケットを廃棄することを意味します。 インプリメンテーションSHOULD、暗黙に廃棄されたパケットの内容を含むエラー、およびSHOULDを記録する能力を提供する、統計カウンターに出来事を記録します。 2. オペレーション クライアントがRADIUSを使用するために形成される場合、クライアントのいかなるユーザもクライアントに認証情報を提示します。 ユーザが彼らのユーザー名およびパスワードを入力すると予想される場合、これはカスタマイズ可能なログイン・プロンプトであるかもしれません。 二者択一で、ユーザは、2点間プロトコル(PPP)(それはこの情報を伝える認証パケットを持っている)のようなプロトコルを組み立てるリンクを使用するかもしれません。 一度クライアントがそのような情報を得たならば、それは確証することに決めるかもしれません、RADIUSの使用。 そうするために、クライアントは、ユーザの名前、ユーザのパスワード、クライアントのID、およびユーザがアクセスしているポートID(Port ID)のような属性を含んでいる「アクセス・リクエスト(Access Request)」を作成します。 パスワードが存在する場合、それは、RSAメッセージ要約アルゴリズムMD5(RSA Message Digest Algorithm MD5)[1]に基づいた方法を使用して、隠されます。 アクセスリクエスト(Access-Request)はネットワークによってRADIUSサーバーに提出されます。 レスポンスが時間の長さの内に返されない場合、リクエストは多くの回を再度送られます。 クライアントはさらに前にできます、主要なサーバーが下がっているか手が届かない場合、交互のサーバーかサーバーに要求します。 主要なサーバーへの多くの試みが失敗した後、交互のサーバーは使用することができます、あるいはリーグ戦方法中で。 再挑戦と蓄えのアルゴリズムは現在の研究のトピックで、このドキュメントに詳細に指定されません。 Rigney、et。 al。 標準は[5ページ]を追跡します RFC 2138 RADIUS 4月の1997 一度RADIUSサーバーがリクエストを受け取れば、それは送るクライアントを有効にします。 RADIUSサーバーが共有された秘密を持っていないクライアントからのリクエストは、暗黙に廃棄されるべきです。 クライアントが有効な場合、RADIUSサーバーは名前がリクエストと一致するユーザを見つけるためにユーザのデータ・ベースを調べます。 データ・ベース中のユーザ・エントリーは、ユーザのためのアクセスを許可するために満たされるに違いない必要条件のリストを含んでいます。 これは、常にパスワードの立証を含んでいるが、ユーザがアクセスを与えられるクライアント(s)かポート(s)をさらに指定することができます。 リモート・オーセンティケイション・ダイアル・イン・ユーザー・サービスサーバーMAY形はリクエストを満たすために他のサーバーに要求します。それは、クライアントの役割をします。 条件が満たされない場合、RADIUSサーバーは送ります、1つの「アクセス、拒絶する」このユーザ・リクエストが無効であることを示すレスポンス。 もし要求されれば、サーバーMAY、アクセス拒絶する際にテキスト・メッセージを含んでいる、そのMAYはユーザへのクライアントによって表示されます。 他の属性は可能にされません、1つの、アクセス拒絶します。 条件がすべて満たされ、RADIUSサーバーが、ユーザが応答しなければならない挑戦を出したい場合、RADIUSサーバーは「アクセス挑戦(Access-Challenge)」レスポンスを送ります。 それ、MAY、挑戦に対するレスポンスのために促すユーザへのクライアントによって表示される、テキスト・メッセージ、およびMAYを含んでいる、州属性を含んでいます。 クライアントがアクセス挑戦(Access-Challenge)を受け取り、挑戦/レスポンスを支援する場合、それ、MAY、ユーザに、もしあればテキスト・メッセージを表示し、次に、レスポンスのためのユーザを刺激する。 その後、クライアントは、レスポンス(暗号化された)と取り替えられ、アクセス挑戦(Access-Challenge)からの州属性(State Attribute)を含んだ、ユーザパスワード属性(User-Password Attribute)と共に、新しいリクエストIDを備えたそのオリジナルのアクセスリクエスト(Access-Request)をもしあれば再度提出します。 州属性(State Attributes)の0あるいは1つのインスタンスだけがリクエストの中にあるに違いありません。 サーバーはどちらかを備えたこの新しいアクセスリクエスト(Access-Request)に応答することができます、アクセス受理(Access-Accept)(アクセス)拒絶する、あるいは別のアクセス挑戦(Access-Challenge)。 条件がすべて満たされる場合、ユーザに対する構成価値のリスト「アクセス受理(Access-Accept)」レスポンスに入れられます。 これらの値は希望のサービスを伝えるためにタイプ・オブ・サービス(例えば: SLIP、PPP(ログイン・ユーザ(Login User)))、およびすべての必要な値を含んでいます。 シリアルライン・インターネット・プロトコルとPPPについては、これが、IPアドレス、サブネット・マスク、MTU、希望の圧縮および希望のパケットフィルター確認者のような値を含んでいるかもしれません。 文字モード・ユーザのために、これは、希望のプロトコルおよびホストのような値を含んでいるかもしれません。 Rigney、et。 al。 標準は[6ページ]を追跡します RFC 2138 RADIUS 4月の1997 2.1. 挑戦/レスポンス チャレンジ/レスポンス認証では、ユーザが予測不能の数を与えられ、それを暗号化し、かつ結果を戻すように促されます。 認可されたユーザは、容易に正確なレスポンスの計算を促進するスマート・カードあるいはソフトウェアのような特別の装置を装備しています。 適切な装置かソフトウェアを欠き、そのような装置かソフトウェアをエミュレートするのに必要な秘密キーについての知識を欠く無許可のユーザは、レスポンスを単に推測することができます。 アクセス挑戦(Access-Challenge)パケットは、繰り返されるために数値の値のように、ユーザに表示されるという挑戦を含む返答メッセージ(Reply-Message)を典型的にありそうもなく常に含んでいます。 典型的に、これは、どのタイプの証人が認可されたユーザが所有していなければならないか、したがってランダムを選ぶことができるか知っている、外部サーバーから得られるか、あるいは適切な根および長さの擬似乱数的な数を繰り返していません。 その後、ユーザは彼の装置(あるいはソフトウェア)へ挑戦を入力します。また、それはレスポンス(別のアクセスリクエスト(Access-Request)によってRADIUSサーバーへそれを転送するクライアントへユーザはそれを入力する)を計算します。 レスポンスがRADIUSサーバーがアクセス受理(Access-Accept)で返答する、予期されたレスポンスと他の方法で一致する場合、1つの、アクセス拒絶します。 例:NASは、NAS確認者(NAS-Identifier)、NASポート(NAS-Port)、ユーザー名、ユーザパスワード(User-Password)(それはちょうど「挑戦」のような固定ストリングかもしれないか無視されるかもしれない)を備えたRADIUSサーバー(RADIUS Server)へアクセスリクエスト(Access-Request)パケットを送ります。 サーバーは、州とのアクセス挑戦(Access-Challenge)パケット、およびラインに沿った返答メッセージ(Reply-Message)を送り返します、の「挑戦12345678はプロンプトであなたの応答を入力する」どれ、NASディスプレイ。 レスポンスのためのNASプロンプト、またNAS確認者(NAS Identifier)、NASポート(NAS-Port)、ユーザー名、ユーザパスワード(User-Password)(レスポンス、暗号化されて、ユーザによってちょうど入力された)、および同じ州でサーバー(新しいIDを備えた)へNEWアクセスリクエスト(NEW Access-Request)を送る、それに帰着する、アクセス挑戦(Access-Challenge)とともに来ました。 その後、サーバーも送り返します、アクセス受理(Access-Accept)あるいはアクセス拒絶する、レスポンスが一致するかどうかに基づいた、それは何でなければならないかあるいはそれ、別のアクセス挑戦(Access-Challenge)をさらに送ることができます。 2.2. PAPとCHAPを備えた相互オペレーション PAPについては、NASがPAP IDおよびパスワードをとり、ユーザー名およびユーザパスワード(User-Password)としてアクセスリクエスト(Access-Request)パケット中でそれらを送ります。 NAS MAY、属性を含んでいる、RADIUSサーバーに関するヒントとしての組み立てられたサービスタイプ=ユーザ、および組み立てられたプロトコル(Framed-Protocol)=PPP、そのPPPサービス、期待されます。 CHAPについては、NASが任意の挑戦(むしろ16のオクテット)を生成し、ユーザ(この人はCHAP IDおよびCHAPユーザー名に加えてCHAPレスポンスを返す)のもとへそれを送ります。 その後、NASはユーザー名として、CHAPユーザー名を備えたRADIUSサーバーへアクセスリクエスト(Access-Request)パケットを送ります。 Rigney、et。 al。 標準は[7ページ]を追跡します RFC 2138 RADIUS 4月の1997 そしてCHAPパスワード(CHAP-Password)(3に帰着する)としてのCHAP IDおよびCHAPレスポンスで。 任意の挑戦は一方のCHAP挑戦(CHAP-Challenge)属性に含むことができます、あるいはそれが16のオクテットである場合、長い、それはアクセスリクエスト(Access-Request)パケットのリクエスト証人(Request Authenticator)分野に置くことができます。 NAS MAY、属性を含んでいる、RADIUSサーバーに関するヒントとしてのサービスタイプ(Service-Type)=に組み立てられたユーザ(Framed User)、および組み立てられたプロトコル(Framed-Protocol)=PPP、そのPPPサービス、期待されます。 RADIUSサーバーはユーザー名に基づいたパスワードを調べて、CHAP IDオクテット、そのパスワード、およびCHAPの挑戦(CHAP挑戦(CHAP-Challenge)属性からの、場合、現在、リクエスト証人(Request Authenticator)からそうでなければ)上でMD5を使用して、挑戦を暗号化し、CHAPパスワード(CHAP-Password)とその結果を比較します。 それらが一致する場合、サーバーはアクセス受理(Access-Accept)をそうでなければ送り返します、それは送り返します、1つの、アクセス拒絶します。 リモート・オーセンティケイション・ダイアル・イン・ユーザー・サービスサーバーが要求された認証を実行することができない場合、それは返るべきです、1つの、アクセス拒絶します。 例えば、CHAPは、それがCHAPの挑戦を暗号化することができ、CHAPレスポンスとそれを比較することができるように、ユーザのパスワードがサーバーへのクリアテキストにおいて利用可能であることを必要とします。 パスワードがRADIUSサーバーへのクリアテキストにおいて利用可能でない場合、その後サーバーMUST、送る、1つの、アクセス拒絶する、クライアントに。 2.3. なぜUDP? FAQは、なぜRADIUSが輸送プロトコルとしてTCPの代わりにUDPを使用するかです。 UDPは厳密に技術的な理由のために選ばれました。 理解されるに違いない多くの問題があります。 RADIUSはいくつかの面白い特性を持っているトランザクションベースのプロトコルです: 1. 主要な認証サーバーへのリクエストが失敗する場合、第2のサーバーは尋ねられるに違いありません。 この要求を満たすために、リクエストのコピーを交互の送信のために許可するトランスポート層上に維持しなければなりません。 これは、再送信タイマーがなお要求されることを意味します。 2. 特にこのプロトコルのタイミング必要条件は、TCPが提供するのとは著しく異なります。 1つの極端では、RADIUSが、失われたデータの「反応する」検知を要求しません。 ユーザは、喜んで認証が完成するべき数秒待ちます。 一般に積極的なTCP再送信(平均ラウンド・トリップ時間に基づいた)は要求されません。同様に、TCPの認識諸経費がない。 Rigney、et。 al。 標準は[8ページ]を追跡します RFC 2138 RADIUS 4月の1997 反対の極では、ユーザが、喜んで認証のために数分待ちません。 したがって、TCPデータの確実な配達は2分後に有用ではありません。 交互のサーバーのより速い使用は、ユーザが降参する前にアクセスを獲得することを可能にします。 3. このプロトコルの無国籍の性質は、UDPの使用を単純化します。 クライアントとサーバーは移り変わります。 システムはリブートされるか、あるいは力です、独立して循環しました。 一般に、これは問題を引き起こしません、また、失われたTCP接続の創造的なタイムアウトおよび検知で、コードは変則の出来事を扱うために書くことができます。 しかしながら、UDPは、完全にこの特殊扱いのうちの何かを除去します。 各クライアントおよびサーバーはそれらのUDPを開くことができます、輸送する、またちょうど一度それを残す、ネットワークに関するすべてのタイプの失敗出来事によって開きます。 4. UDPはサーバー・インプリメンテーションを単純化します。 リモート・オーセンティケイション・ダイアル・イン・ユーザー・サービスの最も初期のインプリメンテーションでは、糸が通されて、サーバーが単一でした。 これは、単一のリクエストが受け取られ、処理され返されたことを意味します。 これは、バックエンドセキュリティ・メカニズムがリアル・タイム(1秒以上)をとった環境において収拾不可能に感じられました。 サーバー・リクエストキューは充満するでしょう、また、何百もの人々が毎分確証されていた環境では、リクエストターンアラウンド・タイムが増加しました、に、より長い、ユーザは喜んで待ちました(データ・ベース中の、あるいはDNSの上の特定の検査が30秒以上を要した時、これは特に厳しかった)。 明白なソルーションはサーバーを糸がマルチ通されるすることでした。 これの達成はUDPで単純でした。 個別のプロセスは各リクエストに役立つために大量に生成されました。また、これらのプロセスは、クライアントのオリジナルの輸送への単純なUDPパケットを備えたクライアントNASに直接応答することができました。 それはすべて万能薬ではありません。 注意されるように、UDPの使用はTCPに組み込まれる1つのものを要求します:UDPで、それらはTCPによって提供されるタイミングへの同じ注意を要求しませんが、私たちは人為的に同じサーバーへの再送信タイマーを管理しなければなりません。 この1つの罰は、このプロトコル中のUDPの利点に払う、小さな価格です。 TCPなしで、私たちは、ストリングによって接続しているブリキ缶をなお恐らく使用するでしょう。 特にこのプロトコルがなかったならば、UDPはよりよい選択です。 Rigney、et。 al。 標準は[9ページ]を追跡します RFC 2138 RADIUS 4月の1997 3. パケット・フォーマット ちょうど1つのRADIUSパケットはUDPデータ(UDP Data)フィールド[2]にカプセルに入れられます。そこでは、UDP目的地ポート(UDP Destination Port)フィールドは1812(10進)を示します。 返答が生成される場合、出所と目的地のポートが逆にされます。 このメモはRADIUSプロトコルをドキュメント化します。 このプロトコルのためのポート番号の割り当ての中にある混乱がありました。 RADIUSの初期の配備は、誤って選ばれたポート番号1645(それは「datametrics」サービスと矛盾する)を使用して、終わりました。 RADIUSのための公式に割り当てられたポート番号は1812です。 RADIUSデータ・フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |コード|確認者|長さ| ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ || |証人| || || ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |属性... ++++++++、+-+-+-+-+。- コード コード・フィールドは1つのオクテットで、RADIUSパケットのタイプを識別します。 パケットが無効のコード・フィールドで受け取られる場合、それは暗黙に廃棄されます。 RADIUSコード(RADIUS Codes)(10進)は以下のように割り当てられます: 1 アクセスリクエスト 2 アクセス受理 3 アクセス拒絶します 4 説明するリクエスト 5 説明レスポンス 11 アクセス挑戦 12 ステータスサーバー(実験) 13 ステータスクライアント(実験) 255 保存されました Rigney、et。 al。 標準は[10ページ]を追跡します RFC 2138 RADIUS 4月の1997 コード4および5はドキュメント[9]を説明するRADIUSでカバーされ、ここに言及されて、一層ではありません。 コード12および13は可能な使用のために取っておかれるが、ここに言及されて、一層ではありません。 確認者 確認者フィールドは1つのオクテットで、リクエストと返答と一致することを援助します。 長さ 長さフィールドは2つのオクテットです。 それは、コード、確認者、長さ、証人および属性フィールドを含むパケットの長さを示します。 長さフィールドの範囲の外側のオクテットはパディングとして扱われるべきであり、受理で無視されるべきです。 パケットが長さフィールドが示すより短い場合、それは暗黙に廃棄されるべきです。 最小の長さは20です。また、最大の長さは4096です。 証人 証人フィールドは16の(16)オクテットです。 最も重要なオクテットは最初に送信されます。 この値はRADIUSサーバーからの返答を確証するために使用され、アルゴリズムを隠すパスワードの中で使用されます。 リクエスト証人 アクセスリクエストパケット(Access-Request Packets)では、証人価値がリクエスト証人(Request Authenticator)と呼ばれる16のオクテット・ランダム番号です。 値SHOULD、攻撃者が以前に遮られたレスポンスで返答することを同じ秘密と協力するリクエスト価値の反復が可能にするので、秘密(クライアントとRADIUSサーバーの間で共有されたパスワード)の一生の間予測不能でユニークです。 確証するために同じ秘密MAYが使用されることが期待されるので、異種の地理的な地方のサーバーで、グローバルで一時的であるリクエスト証人(Request Authenticator)フィールドSHOULD展覧品、独自性。 アクセスリクエスト(Access-Request)パケットSHOULDの中のリクエスト証人(Request Authenticator)価値、さらに予測不能である、ように、攻撃者、予言された将来のリクエストに応答することへサーバーを騙し、次に、将来のアクセスリクエスト(Access-Request)へのそのサーバーを装うためにレスポンスを使用する。 Rigney、et。 al。 標準は[11ページ]を追跡します RFC 2138 RADIUS 4月の1997 RADIUSのようなプロトコルは活発な盗聴が攻撃するリアル・タイムによって確証されたセッションの窃盗に対して保護することができませんが、ユニークな予測不能のリクエストの生成は認証に対する広範囲の活発な攻撃に対して保護することができます。 NASおよびRADIUSサーバーは秘密を共有します。 リクエスト証人(Request Authenticator)が後続する、その共有された秘密は、アクセスリクエスト(Access-Request)パケット中で、ユーザによって入力されたパスワードでxoredされる16のオクテット要約価値を作成する、一方通行のMD5ハッシュおよびユーザパスワード(User-Password)属性に置かれた、xoredされた結果によって入れられます。 もっと詳細な記述に関しては、属性についてのセクションでユーザパスワード(User-Password)へのエントリーを参照してください。 レスポンス証人 アクセス受理(Access-Accept)中の証人フィールドの値、アクセス、拒絶する、そしてアクセス挑戦(Access-Challenge)パケット、レスポンス証人(Response Authenticator)と呼ばれ、次のものから成るオクテットの流れの上に計算された一方通行のMD5ハッシュを含んでいる、共有された秘密が後続する確認者、長さ、アクセスリクエスト(Access-Request)パケットからのリクエスト証人(Request Authenticator)フィールド、およびレスポンス属性を含む、コード・フィールドで始まるRADIUSパケット。 すなわち+が連結を表示するところで、ResponseAuth=MD5(コード+ID+長さ+RequestAuth+は+密誦に帰着します)。 管理上ノート 秘密(クライアントとRADIUSサーバーの間で共有されたパスワード)SHOULD、よく好きなパスワードと少なくとも同じくらい大きく推測できません。 秘密が少なくとも16のオクテットであることが好まれます。 これは秘密が徹底的な探索攻撃からの保護を提供するために十分に大きな範囲を保証することです。 RADIUSサーバーSHOULD、どれが使用する秘密を共有したか決定するためにRADIUS UDPパケットの出所IPアドレスを使用する、その結果、RADIUSリクエストはproxyedすることができます。 フォワーディングプロキシーを使用する場合、それが各方角へ通り過ぎるとともに、プロキシーはパケットを変更することができるに違いない。プロキシーがリクエストを進める場合、プロキシーはプロキシー州属性(Proxy-State Attribute)を加えることができます。また、プロキシーがレスポンスを進める場合、それはプロキシー州属性(Proxy-State Attribute)を削除します。 アクセス受理(Access-Accept)以来、また返答をアクセス拒絶する、パケット内容全体上で確証される、プロキシーがそれに再署名しなければならないように、プロキシー州(Proxy-State)属性の除去は、パケット中の署名を無効にするでしょう。 RADIUSプロキシーインプリメンテーションの一層の詳細はこのドキュメントの範囲の外部であります。 Rigney、et。 al。 標準は[12ページ]を追跡します RFC 2138 RADIUS 4月の1997 属性 多くの属性はそのような場合の中に、多数のインスタンスを持っているかもしれません、同じ型SHOULD(Type SHOULD)の属性の順序、保存されます。 異なるタイプの属性の順序は保存されるためには要求されません。 セクション中で下に「帰着します」属性がどのパケットを中へ与えられるかをテキストが指すところで、このドキュメントの中で定義されたコード1、2、3および11、ならびに属性を備えたパケットだけが、このドキュメントでカバーされます。 簡略なテーブルは、「属性」セクションの終わりに提供されます。 属性がコードを備えたパケット中でどれを与えられるか決めるために、4と5は、ドキュメント[9]を説明するRADIUSを参照します。 4. パケット・タイプ RADIUSパケット(RADIUS Packet)タイプは、パケットの第1のオクテット中のコード・フィールドによって決定されます。 4.1. アクセスリクエスト 記述 アクセスリクエスト(Access-Request)パケットはRADIUSサーバーへ送られユーザが特定のNASへのアクセスを与えられるかどうか、情報がいつも決めたと伝えます。また、いかなる特別のサービスもそのユーザのために要求しました。 ユーザMUSTを確証したいインプリメンテーション、1(アクセスリクエスト(Access-Request))までコード・フィールド・セットを備えたRADIUSパケットを送信します。 有効なクライアント(適切な返答MUST)からのアクセスリクエスト(Access-Request)の受取で、送信されます。 アクセスリクエストMUST(Access-Request MUST)ユーザー名属性を含んでいます。 それ、SHOULD、NASIPアドレス(NAS-IP-Address)属性あるいはNAS確認者(NAS-Identifier)属性(あるいはそれは推薦されませんが両方)のいずれかを含んでいます。 それ、MUST、ユーザパスワード(User-Password)属性あるいはCHAPパスワード(CHAP-Password)属性のいずれかを含んでいます。 それ、SHOULD、もし要求されているアクセスのタイプがポートを含んでいるか、NASがそのポート中に識別しなければ、NASポート(NAS-Port)あるいはNASポートタイプ(NAS-Port-Type)属性あるいは両方を含んでいます。 アクセスリクエストMAY(Access-Request MAY)サーバーに関するヒントとして追加の属性を含んでいる、しかし、サーバーは、ヒントを尊敬することは要求されません。 ユーザパスワード(User-Password)が存在する場合、それは、RSAメッセージ要約アルゴリズムMD5(RSA Message Digest Algorithm MD5)[1]に基づいた方法を使用して、隠されます。 アクセスリクエスト(Access-Request)パケット・フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 Rigney、et。 al。 標準は[13ページ]を追跡します RFC 2138 RADIUS 4月の1997 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |コード|確認者|長さ| ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ || |リクエスト証人| || || ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |属性... ++++++++、+-+-+-+-+。- コード アクセスリクエスト(Access-Request)用の1. 確認者 確認者フィールドMUST、変更される、常に、属性フィールド変更の内容、また有効な返答が前のリクエストのために受け取られた場合は常に。 再送信のために、確認者MUST(Identifier MUST)変わりません。 リクエスト証人 リクエスト証人(Request Authenticator)値MUST、新しい確認者が使用されたごとに、変更されます。 属性 属性フィールドは長さで可変で、任意の希望のオプションの属性と同様に、タイプ・オブ・サービスのために必要になる属性のリストを含んでいます。 4.2. アクセス受理 記述 アクセス受理(Access-Accept)パケットはRADIUSサーバーによって送られ、ユーザに役立つ配達を始めるのに必要な特定の構成情報を提供します。 すべてが帰着する場合、アクセスリクエスト(Access-Request)中の対価受領は受理可能です、RADIUSインプリメンテーションMUST、2(アクセス受理(Access-Accept))までコード・フィールド・セットを備えたパケットを送信します。 Rigney、et。 al。 標準は[14ページ]を追跡します RFC 2138 RADIUS 4月の1997 アクセス受理(Access-Accept)の受理で、確認者フィールドは未決のアクセスリクエスト(Access-Request)と対抗させられます。 さらに、レスポンス証人(Response Authenticator)フィールドMUST、未決のアクセスリクエスト(Access-Request)のための正確なレスポンスを含んでいます。 無効のパケットは暗黙に廃棄されます。 アクセス受理(Access-Accept)パケット・フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |コード|確認者|長さ| ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ || |レスポンス証人| || || ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |属性... ++++++++、+-+-+-+-+。- コード アクセス受理(Access-Accept)用の2. 確認者 確認者フィールドはこのアクセス受理(Access-Accept)を引き起こしたアクセスリクエスト(Access-Request)の確認者フィールドのコピーです。 レスポンス証人 以前に記述されるように、レスポンス証人(Response Authenticator)価値はアクセス・リクエスト(Access Request)価値から計算されます。 属性 属性フィールドは長さで可変で、0あるいはより多くの属性のリストを含んでいます。 Rigney、et。 al。 標準は[15ページ]を追跡します RFC 2138 RADIUS 4月の1997 4.3. アクセス拒絶します 記述 受信属性のいかなる値も受理可能でない場合、その後RADIUSサーバーMUST、3(アクセス拒絶する)までコード・フィールド・セットを備えたパケットを送信します。 それ、MAY、テキスト・メッセージを備えた1つ以上の返答メッセージ属性(Reply-Message Attributes)を含んでいる、どれ、ユーザへのNAS MAYディスプレイ。 アクセス拒絶するパケット・フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |コード|確認者|長さ| ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ || |レスポンス証人| || || ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |属性... ++++++++、+-+-+-+-+。- コード 3、のために、アクセス拒絶します。 確認者 確認者フィールドはこれを引き起こしたアクセスリクエスト(Access-Request)の確認者フィールドのコピーです、アクセス拒絶します。 レスポンス証人 以前に記述されるように、レスポンス証人(Response Authenticator)価値はアクセス・リクエスト(Access Request)価値から計算されます。 属性 属性フィールドは長さで可変で、0あるいはより多くの属性のリストを含んでいます。 Rigney、et。 al。 標準は[16ページ]を追跡します RFC 2138 RADIUS 4月の1997 4.4. アクセス挑戦 記述 RADIUSサーバーが挑戦にユーザにレスポンスを要求させることを望む場合、その後RADIUSサーバーMUST、11(アクセス挑戦(Access-Challenge))までコード・フィールド・セットを備えたパケットを送信することによりアクセスリクエスト(Access-Request)に応答します。 属性、フィールドMAY、1つ以上の返答メッセージ属性(Reply-Message Attributes)およびMAYを持っている、単一の州属性(State Attribute)あるいは無を持っています。 他の属性はアクセス挑戦(Access-Challenge)中で許されません。 アクセス挑戦(Access-Challenge)の受取で、確認者フィールドは未決のアクセスリクエスト(Access-Request)と対抗させられます。 さらに、レスポンス証人(Response Authenticator)フィールドMUST、未決のアクセスリクエスト(Access-Request)のための正確なレスポンスを含んでいます。 無効のパケットは暗黙に廃棄されます。 NASが挑戦/レスポンスを支援しない場合、それ、MUST、あたかもそれが受け取ったかのように、アクセス挑戦(Access-Challenge)を扱う、1つの、アクセス拒絶する、代わりに。 NASが挑戦/レスポンスを支援する場合、有効なアクセス挑戦(Access-Challenge)の受取は新しいアクセスリクエストSHOULD(Access-Request SHOULD)が送られることを示します。 NAS MAY、ユーザに、もしあればテキスト・メッセージを表示し、次に、レスポンスのためのユーザを刺激する。 その後、それは、新しいリクエストIDを備えたそのオリジナルのアクセスリクエスト(Access-Request)を送信します、またユーザのレスポンス(暗号化された)と取り替えられ、アクセス挑戦(Access-Challenge)からの州属性(State Attribute)を含んだ、ユーザパスワード属性(User-Password Attribute)と共に、もしあれば証人を要求します。 州属性(State Attribute)の0あるいは1つのインスタンスだけがアクセスリクエスト(Access-Request)の中にありえます。 PAP MAYを支援するNASはdialinクライアントへ返答メッセージ(Reply-Message)を転送し、あたかもユーザがレスポンスを入力したかのようにそれが使用することができるPAPレスポンスを受理します。 NASがそうすることができない場合、あたかも受け取ったかのようにそれはアクセス挑戦(Access-Challenge)を扱うべきです、1つの、アクセス拒絶する、代わりに。 Rigney、et。 al。 標準は[17ページ]を追跡します RFC 2138 RADIUS 4月の1997 アクセス挑戦(Access-Challenge)パケット・フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |コード|確認者|長さ| ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ || |レスポンス証人| || || ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |属性... ++++++++、+-+-+-+-+。- コード アクセス挑戦(Access-Challenge)用の11. 確認者 確認者フィールドはこのアクセス挑戦(Access-Challenge)を引き起こしたアクセスリクエスト(Access-Request)の確認者フィールドのコピーです。 レスポンス証人 以前に記述されるように、レスポンス証人(Response Authenticator)価値はアクセス・リクエスト(Access Request)価値から計算されます。 属性 属性フィールドは長さで可変で、0あるいはより多くの属性のリストを含んでいます。 5. 属性 RADIUS属性(RADIUS Attributes)は特定の認証、認可、情報およびリクエストおよび返答のための構成詳細を運びます。 ある属性MAY(Attributes MAY)二度以上含まれています。 この影響は属性です、特定、また各属性記述中で指定されます。 アトリビュートのリストの終了はRADIUSパケットの長さまでに示されます。 Rigney、et。 al。 標準は[18ページ]を追跡します RFC 2138 RADIUS 4月の1997 アトリビュートフォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0 ++++++++、+++++++++-+-+-+-+-+。- |タイプ|長さ|値... ++++++++、+++++++++-+-+-+-+-+。- タイプ 型フィールドは1つのオクテットです。 RADIUS型(RADIUS Type)フィールドの最新の値は非常に最近のものの中で指定されます「割り当てられた数(Assigned Numbers)」RFC[3]. 値192-223は実験の使用のために取っておかれます。値224-240はインプリメンテーション特定の使用のために取っておかれます。また、値241-255は保存され、使用されたべきでない。 この明細は次の値に関係があります: RADIUSサーバーMAY、未知のタイプを備えた属性を無視します。 RADIUSクライアントMAY、未知のタイプを備えた属性を無視します。 1 ユーザー名 2 ユーザパスワード 3 CHAPパスワード 4 NASIPアドレス 5 NASポート 6 サービスタイプ 7 組み立てられたプロトコル 8 組み立てられたIPアドレス 9 組み立てられたIP-Netmask 10 敗走させて、組み立てました 11 フィルタ-Id 12 組み立てられたMTU 13 組み立てられた圧縮 14 ログインIPホスト 15 ログインサービス 16 ログインTCPポート 17 (割り当てられていません) 18 返答メッセージ 19 コールバック数 20 コールバック-Id 21 (割り当てられていません) 22 組み立てられたルート 23 組み立てられたIPXネットワーク 24 州 25 クラス 26 ベンダー特定です Rigney、et。 al。 標準は[19ページ]を追跡します RFC 2138 RADIUS 4月の1997 27 セッションタイムアウト 28 使用されていないタイムアウト 29 終了アクション 30 呼ばれたステーション-Id 31 呼ぶステーション-Id 32 NAS確認者 33 プロキシー州 34 ログインLATサービス 35 ログインLATノード 36 ログインLATグループ 37 組み立てられたアップル・トークリンク 38 組み立てられたアップル・トークネットワーク 39 組み立てられたアップル・トークゾーン 40-59(会計のために取っておかれた) 60 CHAP挑戦 61 NASポートタイプ 62 ポート限界 63 ログインLATポート 長さ 長さフィールドは1つのオクテットで、タイプ、長さおよび値フィールドを含むこの属性の長さを示します。 属性がアクセスリクエスト(Access-Request)中で、だが無効の長さで受け取られる場合、アクセス拒絶するSHOULD、送信されます。 属性がアクセス受理(Access-Accept)中で受け取られる場合、アクセス拒絶する、あるいは無効の長さのアクセス挑戦(Access-Challenge)パケット、パケットMUST、どちらか、扱われる、1つの、アクセス拒絶する、あるいは暗黙に廃棄されました。 値 値フィールドは0あるいはより多くのオクテットで、属性に特有の情報を含んでいます。 値フィールドのフォーマットおよび長さは型と長さのフィールドによって決定されます。 アトリビュートが既に長さフィールドを持つのでRADIUSの中の「ストリング」がASCII NULによって終了を要求しないことに注意してください。 Rigney、et。 al。 標準は[20ページ]を追跡します RFC 2138 RADIUS 4月の1997 値フィールドのフォーマットは4つのデータ・タイプのうちの1つです。 ストリング0-253オクテット アドレス32ビットの価値、最も重要なオクテット、1位。 整数32ビットの価値、最も重要なオクテット、1位。 時間32ビットの価値、最も重要なオクテット、1位--00:00:00 GMT以来の秒、1970年1月1日。 標準の属性はこのデータ・タイプを使用しません。しかし、それは、ベンダー特定の属性内の可能な使用のためにここに示されます。 5.1. ユーザー名 記述 この属性は、確証されるユーザの名前を示します。 それはアクセスリクエスト(Access-Request)パケットの中で単に使用されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ ユーザー名用の1. 長さ >=3 ストリング ストリングのフィールドは1つ以上のオクテットです。 NASは、ユーザー名の最大の長さを制限するかもしれません。しかし、少なくとも63のオクテットを扱う能力が推薦されます。 Rigney、et。 al。 標準は[21ページ]を追跡します RFC 2138 RADIUS 4月の1997 ユーザー名MAYのフォーマット、いくつかの形式のうちの1つである: 単一体、英数字の特徴からのみ成ること この単純な形式はローカルにNASを管理するために使用されるかもしれません。 単純、印刷可能なASCII特徴からのみ成ること 名前@fqdn SMTPアドレス。 全指定ドメイン名(ドットを引きずることを備えた、あるいは引きずることのない)は、主題役が当てはまる領域を示します。 識別された名前 ASN.1の形の名前は公開暗号キー認証システムの中で使用しました。 5.2. ユーザパスワード 記述 この属性は、確証されるユーザのパスワードあるいはアクセス挑戦(Access-Challenge)に続くユーザの入力を示します。 それはアクセスリクエスト(Access-Request)パケットの中で単に使用されます。 トランスミションで、パスワードは隠されます。 パスワードが、多数の16のオクテットへの空で終わりで最初に当てがわれます。 一方通行のMD5ハッシュは、リクエスト証人(Request Authenticator)が後続する、共有された秘密から成るオクテットの流れの上に計算されます。 この値は、パスワードの16の最初のオクテット・セグメントでXORedされ、ユーザ・パスワード属性(User Password Attribute)のストリングのフィールドの16の最初のオクテットに置かれます。 パスワードが16文字より長い場合、別の一方通行のMD5ハッシュは、第1のxorの結果が後続する、共有された秘密から成るオクテットの流れの上に計算されます。 そのハッシュは、パスワードの16の次のオクテット・セグメントでXORedされ、ユーザ・パスワード属性(User Password Attribute)のストリングのフィールドの16の次のオクテットに置かれます。 必要な場合、このオペレーションは次のハッシュを生成するために共有された秘密に加えて使用されている、各xor結果と共に、繰り返されます、高々128文字まで、パスワードの次のセグメントをxorします。 方法は、コーフマン、パールマンおよびSpeciner[4]109-110ページによって本「ネットワーク・セキュリティ(Network Security)」から得られます。 方法のより正確な説明は次のものに続きます: Rigney、et。 al。 標準は[22ページ]を追跡します RFC 2138 RADIUS 4月の1997 共有された秘密S、および偽似乱数の128ビットリクエスト証人(Request Authenticator)をRAと呼んでください。 16-オクテット境界に、空で終わりで当てがわれた、最後のもので、16-オクテット塊p1、p2などへパスワードを知らせてください。 暗号文ブロックc(1)、cなど(2)を呼びます。 私たちは中間の値b1、b2などを必要とするでしょう。 b1=MD5(S+RA)c(1)=p1 xor b1、b2=MD5(S+c(1))c(2)=p2 xor b2。 。 。 。 。 。 bi=MD5(S+c(i-1))c(i)=パイxor bi ストリングはc(1)+c(2)+を含むでしょう...+が連結を表示するところで、+c(i)。 受取で、プロセスはオリジナルのパスワードを産出するために逆にされます。 ユーザパスワード属性(User-Password Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ ユーザパスワード(User-Password)用の2. 長さ 少なくとも18、そして130ほど全く大きくない ストリング ストリングのフィールドは16〜128のオクテットです、長い、包括的。 5.3. CHAPパスワード 記述 この属性は、挑戦に応じてPPP挑戦握手認証プロトコル(PPP Challenge-Handshake Authentication Protocol)(CHAP)ユーザによってレスポンス価値が提供されることを示します。 それはアクセスリクエスト(Access-Request)パケットの中で単に使用されます。 Rigney、et。 al。 標準は[23ページ]を追跡します RFC 2138 RADIUS 4月の1997 パケットの中にある場合、CHAP挑戦価値はCHAP挑戦属性(CHAP-Challenge Attribute)(60)で見つかります、リクエスト証人(Request Authenticator)分野でそうでなければ。 CHAPパスワード属性(CHAP-Password Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 ++++++++、+++++++++++++++++-+-+-+-+-+-+。- |タイプ|長さ|CHAP Ident|ストリング... ++++++++、+++++++++++++++++-+-+-+-+-+-+。- タイプ CHAPパスワード(CHAP-Password)用の3. 長さ 19 CHAP Ident このフィールドは1つのオクテットで、ユーザのCHAPレスポンス(CHAP Response)からのCHAP確認者(CHAP Identifier)を含んでいます。 ストリング ストリングのフィールドは16のオクテットで、ユーザからのCHAPレスポンス(CHAP Response)を含んでいます。 5.4. NASIPアドレス 記述 この属性は、ユーザに認証を要請しているNASの識別するIPアドレスを示します。 それはアクセスリクエスト(Access-Request)パケットの中で単に使用されます。 NASIPアドレス(NAS-IP-Address)あるいはNAS確認者SHOULD(NAS Identifier SHOULD)のいずれか、アクセスリクエスト(Access-Request)パケットの中にあります。 Rigney、et。 al。 標準は[24ページ]を追跡します RFC 2138 RADIUS 4月の1997 NASIPアドレス属性(NAS-IP-Address Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|アドレス ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ アドレス(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ NASIPアドレス(NAS-IP-Address)のための4. 長さ 6 アドレス アドレス・フィールドは4つのオクテットです。 5.5. NASポート 記述 この属性は、ユーザを確証しているNASの物理的なポート番号を示します。 それはアクセスリクエスト(Access-Request)パケットの中で単に使用されます。 TCPまたはUDPのポート番号の感覚中で、NASの上で物理的な接続のその感覚の中でこれが「ポート」を使用していないことに注意してください。 NASポート(NAS-Port)あるいはNASポートタイプ(NAS-Port-Type)(61)のいずれか、あるいは両方とも、SHOULD、NASがそのポート中に分化する場合、アクセスリクエスト(Access-Request)パケットの中にあります。 NASポート属性(NAS-Port Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 Rigney、et。 al。 標準は[25ページ]を追跡します RFC 2138 RADIUS 4月の1997 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ NASポート(NAS-Port)用の5. 長さ 6 値 値フィールドは4つのオクテットです。 フィールドのサイズにもかかわらず、値は0〜65535まで変動します。 5.6. サービスタイプ 記述 この属性は、ユーザが要求したタイプ・オブ・サービスあるいは提供されるタイプ・オブ・サービスを示します。 それ、MAY、アクセスリクエスト(Access-Request)およびアクセス受理(Access-Accept)パケットの両方の中で使用されます。 NASはこれらのサービス・タイプのすべておよびMUSTをインプリメントするためには要求されません、未知かあるいはサポートなしのサービスタイプ(Service-Types)を扱う、あたかもかのように、1つの、アクセス拒絶する、代わりに受け取られました。 サービスタイプ属性(Service-Type Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ サービスタイプ(Service-Type)用の6. Rigney、et。 al。 標準は[26ページ]を追跡します RFC 2138 RADIUS 4月の1997 長さ 6 値 値フィールドは4つのオクテットです。 1 ログインします 2 組み立てられました 3 コールバックログイン 4 組み立てられたコールバック 5 外国行きです 6 管理上です 7 NASプロンプト 8 確証する、だけ 9 コールバックNASプロンプト アクセス受理(Access Accept)の中で使用された時、サービス・タイプは以下のように定義されます。 アクセスリクエスト(Access-Request)の中で使用された時、彼らはNASがユーザが示されたサービスの種類を好むだろうと信じる理由を持っているというRADIUSサーバーに関するヒントであると考えられるべきです。しかし、サーバーは、ヒントを尊敬することは要求されません。 ユーザをログインする、ホストに接続されるべきです。 組み立てられたA(Framed A)に組み立てられたプロトコル(Framed Protocol)は、PPPまたはSLIPのようなユーザのために始められるべきです。 コールバック、ユーザをログインする、分離され呼び戻されるべきであり、次に、ホストに接続されるべきである。 コールバックはユーザを組み立てました、その後分離され呼び戻されるべきである、組み立てられたプロトコル(Framed Protocol)は、PPPまたはSLIPのようなユーザのために始められるべきです。 外国行き、ユーザは、装置より優れることへのアクセスを与えられるべきです。 管理上、ユーザは、NASへの管理上のインターフェースへのアクセスを与えられるべきです、どれから、コマンドに特権を与えた、実行することができます。 NASはユーザを刺激します、特権がなかったコマンドが実行することができるNASの上で迅速なコマンドを供給されるべきです。 Rigney、et。 al。 標準は[27ページ]を追跡します RFC 2138 RADIUS 4月の1997 確証する、認証だけが単に要求されます、また、認可情報をアクセス受理(Access-Accept)(典型的にNASそれ自身ではなくプロキシーサーバーによって使用された)中で返す必要がありません。 コールバックNAS(Callback NAS)はユーザを刺激します、分離され呼び戻されるべきであり、次に、特権がなかったコマンドが実行することができるNASの上で迅速なコマンドを提供した。 5.7. 組み立てられたプロトコル 記述 この属性は組み立てられたアクセスのために使用されるために構成を示します。 それ、MAY、アクセスリクエスト(Access-Request)およびアクセス受理(Access-Accept)パケットの両方の中で使用されます。 組み立てられたプロトコル属性(Framed-Protocol Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ 組み立てられたプロトコル(Framed-Protocol)用の7. 長さ 6 値 値フィールドは4つのオクテットです。 1 PPP 2 スリップします 3 アップルトーク・リモートアクセス・プロトコル(アラップ) 4 ガンダルフの所有者のSingleLink/MultiLinkプロトコル 5つのザイロジックスの所有者のIPX/SLIP Rigney、et。 al。 標準は[28ページ]を追跡します RFC 2138 RADIUS 4月の1997 5.8. 組み立てられたIPアドレス 記述 この属性は、ユーザのために形成されるアドレスを示します。 それ、MAY、アクセス受理(Access-Accept)パケットの中で使用されます。 それ、MAY、サーバーへのNASによってそれがそのアドレスを好むだろうというほのめかしとしてアクセスリクエスト(Access-Request)パケットの中で使用される、しかし、サーバーは、ほのめかしを尊敬することは要求されません。 組み立てられたIPアドレス属性(Framed-IP-Address Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|アドレス ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ アドレス(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ 組み立てられたIPアドレス(Framed-IP-Address)のための8. 長さ 6 アドレス アドレス・フィールドは4つのオクテットです。 値0xFFFFFFFFは、ユーザがアドレス(例えば、交渉した)を選択するのをNASが可能にすることを示します。 値0xFFFFFFFEは、ユーザ(例えば、NASによって維持されたアドレスのプールから割り当てられた)のためにNASがアドレスを選ぶことを示します。 他の有効な値は、NASがユーザのIPアドレスとしてその値を使用することを示します。 5.9. 組み立てられたIP-Netmask 記述 この属性は、ユーザがネットワークへのルーターである場合にユーザのために形成される、IP netmaskを示します。 それ、MAY、アクセス受理(Access-Accept)パケットの中で使用されます。 それ、MAY、サーバーへのNASによってそれがそのnetmaskを好むだろうというほのめかしとしてアクセスリクエスト(Access-Request)パケットの中で使用される、しかし、サーバーは、ほのめかしを尊敬することは要求されません。 Rigney、et。 al。 標準は[29ページ]を追跡します RFC 2138 RADIUS 4月の1997 組み立てられたIP-Netmask属性(Framed-IP-Netmask Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|アドレス ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ アドレス(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ 組み立てられたIP-Netmask(Framed-IP-Netmask)のための9. 長さ 6 アドレス アドレス・フィールドはユーザのIP netmaskを指定する4つのオクテットです。 5.10. 敗走させて、組み立てました 記述 ユーザがネットワークへのルーターである場合、この属性はユーザのためのルーティング方法を示します。 それはアクセス受理(Access-Accept)パケットの中で単に使用されます。 組み立てられた(敗走させて、)属性フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ 組み立てられたルーティング(Framed-Routing)用の10. Rigney、et。 al。 標準は[30ページ]を追跡します RFC 2138 RADIUS 4月の1997 長さ 6 値 値フィールドは4つのオクテットです。 0 無 1 敗走させるパケットを送ります 2 パケットを敗走させることに聞き耳を立てます 3 送り聞きます 5.11. フィルタ-Id 記述 この属性は、このユーザのためのフィルタ・リストの名前を示します。 ゼロあるいはより多くのフィルタ-Id(Filter-Id)はMAYに帰着します、アクセス受理(Access-Accept)パケット中で送られます。 名前によってフィルタ・リストを識別することは、フィルタリストインプリメンテーション詳細に配慮のない異なるNASesの上でフィルタが使用されることを認めます。 フィルタ-Id属性(Filter-Id Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ フィルタ-Id(Filter-Id)のための11. 長さ >=3 Rigney、et。 al。 標準は[31ページ]を追跡します RFC 2138 RADIUS 4月の1997 ストリング ストリングのフィールドは1つ以上のオクテットです、また、その内容はインプリメンテーションです、依存する それは、人間の判読可能なMUST NOTであるように意図されます、プロトコルのオペレーションに影響します。 範囲32から126の10進までメッセージが表示することができるASCII文字を含むことが勧められます。 5.12. 組み立てられたMTU 記述 それが他のある手段(PPPのような)によって協定されない場合、この属性はユーザのために形成される最大伝送単位を示します。 それはアクセス受理(Access-Accept)パケットの中で単に使用されます。 組み立てられたMTU属性(Framed-MTU Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ 組み立てられたMTU(Framed-MTU)のための12. 長さ 6 値 値フィールドは4つのオクテットです。 フィールドのサイズにもかかわらず、値は64〜65535まで変動します。 Rigney、et。 al。 標準は[32ページ]を追跡します RFC 2138 RADIUS 4月の1997 5.13. 組み立てられた圧縮 記述 この属性は、リンクのために使用される圧縮プロトコルを示します。 それ、MAY、アクセス受理(Access-Accept)パケットの中で使用されます。 それ、MAY、その圧縮を使用するためにNASが好むサーバーに関するヒントとしてアクセスリクエスト(Access-Request)パケットの中で使用される、しかし、サーバーは、ヒントを尊敬することは要求されません。 1つを越える圧縮プロトコル属性MAY(Attribute MAY)送られます。 それはリンク交通を充当する適切な圧縮プロトコルを適用するNASの責任です。 組み立てられた圧縮属性(Framed-Compression Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ 組み立てられた圧縮(Framed-Compression)用の13. 長さ 6 値 値フィールドは4つのオクテットです。 0 無 1 VJ TCP/IPヘッダー圧縮[5] 2 IPXヘッダー圧縮 5.14. ログインIPホスト 記述 ログインサービス属性(Login-Service Attribute)が含まれている場合、この属性はユーザを結び付けるシステムを示します。 それ、MAY、アクセス受理(Access-Accept)パケットの中で使用されます。 それ、MAY、アクセスの中で使用される― Rigney、et。 al。 標準は[33ページ]を追跡します RFC 2138 RADIUS 4月の1997 そのホストを使用するためにNASが好むサーバーに関するヒントとしてパケットを要求してください。しかし、サーバーは、ヒントを尊敬することは要求されません。 ログインIPホスト属性(Login-IP-Host Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|アドレス ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ アドレス(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ ログインIPホスト(Login-IP-Host)のための14. 長さ 6 アドレス アドレス・フィールドは4つのオクテットです。 値0xFFFFFFFFは、NAS SHOULDがユーザがアドレスを選択するのを可能にすることを示します。 値0は、ユーザを接続するためにNAS SHOULDがホストを選択することを示します。 他の値はアドレスを示します、NAS SHOULD、ユーザを接続する、に。 5.15. ログインサービス 記述 この属性は、ログイン・ホストにユーザを接続するために利用されるべきサービスを示します。 それはアクセス受理(Access Accept)パケットの中で単に使用されます。 ログインサービス属性(Login-Service Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 Rigney、et。 al。 標準は[34ページ]を追跡します RFC 2138 RADIUS 4月の1997 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ ログインサービス(Login-Service)用の15. 長さ 6 値 値フィールドは4つのオクテットです。 0 テルネット 1 rlogin 2 明瞭なTCP 3 PortMaster(所有者) 4 LAT 5.16. ログインTCPポート 記述 ログインサービス属性(Login-Service Attribute)がさらに存在する場合、この属性はユーザが接続されることになっているTCPポートを示します。 それはアクセス受理(Access-Accept)パケットの中で単に使用されます。 ログインTCPポート属性(Login-TCP-Port Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ ログインTCPポート(Login-TCP-Port)用の16. Rigney、et。 al。 標準は[35ページ]を追跡します RFC 2138 RADIUS 4月の1997 長さ 6 値 値フィールドは4つのオクテットです。 フィールドのサイズにもかかわらず、値は0〜65535まで変動します。 5.17. (割り当てられていません) 記述 ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED。 5.18. 返答メッセージ 記述 この属性はテキストを示します、そのMAYはユーザに表示されます。 アクセス受理(Access-Accept)の中で使用された時、それは成功メッセージです。 使用された時、1つの、アクセス拒絶する、それは失敗メッセージです。 それ、MAY、別のアクセスリクエスト(Access-Request)試みの前にユーザを刺激する、対話メッセージを示します。 アクセス挑戦(Access-Challenge)の中で使用された時、それ、MAY、レスポンスのためのユーザを刺激する、対話メッセージを示します。 複合の返答メッセージ(Multiple Reply-Message)のMAY、含まれている、またいかなるものでも表示される場合、それら、MUST、それらがパケットに現われるのと同じ順に表示されます。 返答メッセージ属性(Reply-Message Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ 返答メッセージ(Reply-Message)用の18. Rigney、et。 al。 標準は[36ページ]を追跡します RFC 2138 RADIUS 4月の1997 長さ >=3 ストリング ストリングのフィールドは1つ以上のオクテットです、また、その内容はインプリメンテーションです、依存する それは、人間になるように意図されます、判読可能、そしてMUST NOT、プロトコルのオペレーションに影響します。 レンジ10、13および32から126の10進までメッセージが表示することができるASCII文字を含むことが勧められます。 他の文字セットに対する拡張用メカニズムはこの明細の範囲外です。 5.19. コールバック数 記述 この属性は、コールバックのために使用されるダイヤルするストリングを示します。 それ、MAY、アクセス受理(Access-Accept)パケットの中で使用されます。 それ、MAY、コールバック・サービスが要求されるというサーバーに関するヒントとしてアクセスリクエスト(Access-Request)パケットの中で使用される、しかし、サーバーは、ヒントを尊敬することは要求されません。 コールバック数属性(Callback-Number Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ コールバック数(Callback-Number)のための19. 長さ >=3 Rigney、et。 al。 標準は[37ページ]を追跡します RFC 2138 RADIUS 4月の1997 ストリング ストリングのフィールドは1つ以上のオクテットです。 情報の実際のフォーマットはサイトまたはアプリケーションです、特定、そして強健なインプリメンテーションSHOULD、平凡なオクテットとしてフィールドを支援します。 このフィールドの許可された使用法の範囲の規則の成文化は、この明細の範囲の外部であります。 5.20. コールバック-Id 記述 この属性は、NASによって解釈されるために呼ばれる場所の名前を示します。 それ、MAY、アクセス受理(Access-Accept)パケットの中で使用されます。 コールバック-Id属性(Callback-Id Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ コールバック-Id(Callback-Id)のための20. 長さ >=3 ストリング ストリングのフィールドは1つ以上のオクテットです。 情報の実際のフォーマットはサイトまたはアプリケーションです、特定、そして強健なインプリメンテーションSHOULD、平凡なオクテットとしてフィールドを支援します。 このフィールドの許可された使用法の範囲の規則の成文化は、この明細の範囲の外部であります。 5.21. (割り当てられていません) 記述 ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED。 Rigney、et。 al。 標準は[38ページ]を追跡します RFC 2138 RADIUS 4月の1997 5.22. 組み立てられたルート 記述 この属性はNASの上のユーザのために形成される情報を敗走させることを提供します。 それはアクセス受理(Access-Accept)パケットの中で使用され、複合回に見えることができます。 組み立てられたルート属性(Framed-Route Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 ++++++++、+++++++++-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+。- タイプ 組み立てられたルート(Framed-Route)用の22. 長さ >=3 ストリング ストリングのフィールドは1つ以上のオクテットです、また、その内容はインプリメンテーションです、依存する それは、人間の判読可能なMUST NOTであるように意図されます、プロトコルのオペレーションに影響します。 範囲32から126の10進までメッセージが表示することができるASCIIキャラクターを含むことが勧められます。 IPルートのために、それ、SHOULD、接頭辞のビットがどれだけの高いオーダーでなければならないか述べるスラッシュおよび10進の長さ明細書作成者が自由に後続する、点のある中庭形式に目的地接頭辞を含んでいる、使用された スペース、点のある中庭形式中のゲートウエイアドレス、スペースおよびスペースによって分離された1つ以上のメトリクスはそれに続きます。 例えば、「192.168.1.1の192.168.1.0/24 1、2-1 3 400”。 長さ明細書作成者は省略されるかもしれません。それは自動的にクラスC接頭辞のためにクラスA接頭辞、クラスB接頭辞用16ビットおよび24ビットのために8ビットになるべきです。 例えば192.168.1.0 192.168.1.1 1””。 ゲートウエイアドレスが「0.0.0.0」として指定される場合は常に、ユーザSHOULDのIPアドレス、ゲートウエイアドレスとして使用されます。 Rigney、et。 al。 標準は[39ページ]を追跡します RFC 2138 RADIUS 4月の1997 5.23. 組み立てられたIPXネットワーク 記述 この属性は、ユーザのために形成されるIPXネットワーク(IPX Network)番号を示します。 それはアクセス受理(Access-Accept)パケットの中で使用されます。 組み立てられた-IPXネットワーク属性(Framed-IPX-Network Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ 組み立てられた-IPXネットワーク(Framed-IPX-Network)用の23. 長さ 6 値 値フィールドは4つのオクテットです。 値0xFFFFFFFEは、ユーザ(例えば、NASによって維持された1つ以上のIPXネットワークのプールから割り当てられた)のためにNASがIPXネットワークを選ぶことを示します。 他の値はユーザへのリンクのためにIPXネットワークとして使用されるべきです。 5.24. 州 記述 この属性はアクセス挑戦(Access-Challenge)およびMUST中のクライアントにサーバーによって送ることができます、送られる、もしあればその挑戦への新しいアクセスリクエスト(Access-Request)返答中のクライアントからサーバーまで未変更。 Rigney、et。 al。 標準は[40ページ]を追跡します RFC 2138 RADIUS 4月の1997 この属性は、RADIUSリクエスト(RADIUS-Request)の値を備えた終了アクション属性(Termination-Action Attribute)をさらに含んでいるアクセス受理(Access-Accept)中のクライアントにサーバーによって送ることができます。 NASが現在のセッションの終了上の新しいアクセスリクエスト(Access-Request)を送信することにより終了アクション(Termination-Action)を実行する場合、それ、MUST、そのアクセスリクエスト(Access-Request)において不変の州属性を含んでいます。 一方の使用法では、クライアントによる解釈がなされてはなりません。 パケットは単に1つの州属性(State Attribute)を持っているかもしれません。 州属性(State Attribute)の使用法はインプリメンテーションです、依存する 州属性(State Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ 州のための24. 長さ >=3 ストリング ストリングのフィールドは1つ以上のオクテットです。 情報の実際のフォーマットはサイトまたはアプリケーションです、特定、そして強健なインプリメンテーションSHOULD、平凡なオクテットとしてフィールドを支援します。 このフィールドの許可された使用法の範囲の規則の成文化は、この明細の範囲の外部であります。 5.25. クラス 記述 この属性はアクセス受理(Access-Accept)中のクライアントにサーバーによって送ることができ送られるべきです、説明する場合説明するリクエスト(Accounting-Request)パケットの一部が支援されるとともに、説明するサーバーへのクライアントによって未変更。 クライアントによる解釈はなされてはなりません。 Rigney、et。 al。 標準は[41ページ]を追跡します RFC 2138 RADIUS 4月の1997 クラス属性(Class Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ クラス用の25. 長さ >=3 ストリング ストリングのフィールドは1つ以上のオクテットです。 情報の実際のフォーマットはサイトまたはアプリケーションです、特定、そして強健なインプリメンテーションSHOULD、平凡なオクテットとしてフィールドを支援します。 このフィールドの許可された使用法の範囲の規則の成文化は、この明細の範囲の外部であります。 5.26. ベンダー特定です 記述 この属性は、ベンダーが一般的な使用法にふさわしくない自分の拡張属性を支援することを可能にすることができます。 それ、MUST、ない、RADIUSプロトコルのオペレーションに影響します。 クライアントMUSTによって送られたベンダー特定の情報を解釈するためには装備をされないサーバーは、それ(それは報告されるかもしれませんが)を無視します。 それらは堕落したモードでそうするかもしれませんが(かつそれらがそのように行っている報告書)、希望のベンダー特定の情報SHOULDを受け取らないクライアントはそれなしで操作することを試みます。 ベンダー特定の属性(Vendor-Specific Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 Rigney、et。 al。 標準は[42ページ]を追跡します RFC 2138 RADIUS 4月の1997 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|ベンダー-Id ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ ベンダー-Id(Vendor-Id)(cont)|ストリング... ++++++++、+++++++++-+-+-+-+-+-+-+-+。- タイプ 26、のために、ベンダー特定。 長さ >=7 ベンダー-Id 割り当てられた数RFC(Assigned Numbers RFC)[3]の中で定義されるように、高いオーダーオクテットは0です。また、低位3つのオクテットはネットワーク・バイトオーダー中のベンダーのSMIネットワーク管理民間企業コード(SMI Network Management Private Enterprise Code)です。 ストリング ストリングのフィールドは1つ以上のオクテットです。 情報の実際のフォーマットはサイトまたはアプリケーションです、特定、そして強健なインプリメンテーションSHOULD、平凡なオクテットとしてフィールドを支援します。 このフィールドの許可された使用法の範囲の規則の成文化は、この明細の範囲の外部であります。 それ、SHOULD、ベンダー型/ベンダー長さ/値フィールドのシーケンスとして以下のようにエンコードされます。 属性特定のフィールドはベンダーのその属性の定義に依存します。 この方法を使用するベンダー特定の属性の例符号づけは、次のものに続きます: 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|ベンダー-Id ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ ベンダー-Id(Vendor-Id)(cont)|ベンダー・タイプ|ベンダー長さ ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |属性特定... ++++++++、+-+-+-+-+-+-+。- Rigney、et。 al。 標準は[43ページ]を追跡します RFC 2138 RADIUS 4月の1997 5.27. セッションタイムアウト 記述 この属性は、セッションかプロンプトの終了の前にユーザに供給されるサービスの秒の最大の数をセットします。 この属性は、アクセス受理(Access-Accept)かアクセス挑戦(Access-Challenge)中のクライアントにサーバーによって送ることができます。 セッションタイムアウト属性(Session-Timeout Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ セッションタイムアウト(Session-Timeout)用の27. 長さ 6 値 フィールドはNASによって接続され続けるためにこのユーザが与えられるべき秒の最大の数を備えた32ビットの符号なしの整数を含んでいる4つのオクテットです。 5.28. 使用されていないタイムアウト 記述 この属性は、セッションかプロンプトの終了の前にユーザに許可された、使用されていない接続の連続する秒の最大の数をセットします。 この属性は、アクセス受理(Access-Accept)かアクセス挑戦(Access-Challenge)中のクライアントにサーバーによって送ることができます。 Rigney、et。 al。 標準は[44ページ]を追跡します RFC 2138 RADIUS 4月の1997 使用されていないタイムアウト属性(Idle-Timeout Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ 使用されていないタイムアウト(Idle-Timeout)用の28. 長さ 6 値 フィールドは4つのオクテットです、空き時間の連続する秒の最大の数を備えた32ビットの符号なしの整数を含んでいること、このユーザはNASによって分離される前に許されるべきです。 5.29. 終了アクション 記述 この属性は、指定されたサービスが完成する場合NASがどの処置を講じなければならないか示します。 それはアクセス受理(Access-Accept)パケットの中で単に使用されます。 終了アクション属性(Termination-Action Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ 終了アクション(Termination-Action)用の29. Rigney、et。 al。 標準は[45ページ]を追跡します RFC 2138 RADIUS 4月の1997 長さ 6 値 値フィールドは4つのオクテットです。 0 デフォルト 1 RADIUSリクエスト 値が指定されたサービスの終了で、RADIUSリクエスト(RADIUS-Request)にセットされる場合、NAS MAY、もしあれば州属性を含むRADIUSサーバーへ新しいアクセスリクエスト(Access-Request)を送ります。 5.30. 呼ばれたステーション-Id 記述 この属性は、NASがアクセスリクエスト(Access-Request)パケット中で送ることを可能にします、ユーザがダイヤルされた数識別(Dialed Number Identification)(DNIS)あるいは類似した技術を使用して、呼んだ電話番号。 呼び出しが中へ入る電話番号とはこれが異なるかもしれないことに注意してください。 それはアクセスリクエスト(Access-Request)パケットの中で単に使用されます。 呼ばれたステーション-Id属性(Called-Station-Id Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ 呼ばれたステーション-Id(Called-Station-Id)のための30. 長さ >=3 ストリング ストリングのフィールドはユーザの呼び出しが中へ入った電話番号を含んでいる1つ以上のオクテットです。 Rigney、et。 al。 標準は[46ページ]を追跡します RFC 2138 RADIUS 4月の1997 情報の実際のフォーマットは特定のサイトあるいはアプリケーションです。 印刷可能なASCII(Printable ASCII)は推薦されます、しかし強健なインプリメンテーションSHOULD、平凡なオクテットとしてフィールドを支援します。 このフィールドの許可された使用法の範囲の規則の成文化は、この明細の範囲の外部であります。 5.31. 呼ぶステーション-Id 記述 この属性は、NASがアクセスリクエスト(Access-Request)パケット中で送ることを可能にします、呼び出しが自動的な数識別(Automatic Number Identification)(ANI)あるいは類似した技術を使用して、来た電話番号。 それはアクセスリクエスト(Access-Request)パケットの中で単に使用されます。 呼ぶステーション-Id属性(Calling-Station-Id Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ 呼ぶステーション-Id(Calling-Station-Id)のための31. 長さ >=3 ストリング ストリングのフィールドはユーザが呼び出しをした電話番号を含んでいる1つ以上のオクテットです。 情報の実際のフォーマットは特定のサイトあるいはアプリケーションです。 印刷可能なASCII(Printable ASCII)は推薦されます、しかし強健なインプリメンテーションSHOULD、平凡なオクテットとしてフィールドを支援します。 このフィールドの許可された使用法の範囲の規則の成文化は、この明細の範囲の外部であります。 Rigney、et。 al。 標準は[47ページ]を追跡します RFC 2138 RADIUS 4月の1997 5.32. NAS確認者 記述 この属性は、アクセスリクエスト(Access-Request)を起こすNASを識別するストリングを含んでいます。 それはアクセスリクエスト(Access-Request)パケットの中で単に使用されます。 NASIPアドレス(NAS-IP-Address)あるいはNAS確認者SHOULD(NAS-Identifier SHOULD)のいずれか、アクセスリクエスト(Access-Request)パケットの中にあります。 NAS確認者属性(NAS-Identifier Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ NAS確認者(NAS-Identifier)用の32. 長さ >=3 ストリング ストリングのフィールドは1つ以上のオクテットで、RADIUSサーバーの範囲内のNASに特有であるべきです。 例えば、完全に資格のあるドメインネームはNAS確認者(NAS-Identifier)として適切でしょう。 情報の実際のフォーマットはサイトまたはアプリケーションです、特定、そして強健なインプリメンテーションSHOULD、平凡なオクテットとしてフィールドを支援します。 このフィールドの許可された使用法の範囲の規則の成文化は、この明細の範囲の外部であります。 5.33. プロキシー州 記述 アクセスリクエスト(Access-Request)およびMUSTを進める場合、この属性は別のサーバーへプロキシーサーバーによって送ることができます、アクセス受理(Access-Accept)において未変更に返される、アクセス拒絶する、あるいはアクセス挑戦(Access-Challenge)。 レスポンスがNASへ転送される前に、この属性はプロキシーサーバーによって削除されるべきです。 Rigney、et。 al。 標準は[48ページ]を追跡します RFC 2138 RADIUS 4月の1997 プロキシー州属性(Proxy-State Attribute)の使用法はインプリメンテーションです、依存する その機能の記述はこの明細の範囲の外部であります。 プロキシー州属性(Proxy-State Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ プロキシー州(Proxy-State)のための33. 長さ >=3 ストリング ストリングのフィールドは1つ以上のオクテットです。 情報の実際のフォーマットはサイトまたはアプリケーションです、特定、そして強健なインプリメンテーションSHOULD、平凡なオクテットとしてフィールドを支援します。 このフィールドの許可された使用法の範囲の規則の成文化は、この明細の範囲の外部であります。 5.34. ログインLATサービス 記述 この属性は、ユーザがLATによって接続されることになっているシステムを示します。 それ、MAY、アクセス受理(Access-Accept)パケットの中で使用される、しかしLATがログインサービス(Login-Service)として指定される場合に限り。 それ、MAY、サーバーに関するヒントとしてアクセスリクエスト(Access-Request)パケットの中で使用される、しかし、サーバーは、ヒントを尊敬することは要求されません。 VAXまたはアルファのクラスタのような房になったシステムに対処する場合、管理者はサービス属性を使用します。 そのような環境では、数人の異なるタイム・シェアリング・ホストが同じ資源(ディスク、プリンタなど)を共有します。また、管理者は共有資源の各々にアクセス(サービス)を提供するために各々をしばしば形成します。 この場合、クラスタ中の各ホストはLAT放送によってそのサービスを広告します。 Rigney、et。 al。 標準は[49ページ]を追跡します RFC 2138 RADIUS 4月の1997 洗練されたユーザは、どのサービス・プロバイダー(機械)がより速いか、LAT接続を始める場合にノード名を使用する傾向があるかしばしば知っています。 交互に、何人かの管理者は、特別のユーザに、ロード・バランシング(LATはそれ自体の平衡を保って、ロードする方法を知っていますが)の原始的な形式としてある機械を使用してほしい。 ログイン-LATサービス属性(Login-LAT-Service Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ ログイン-LATサービス(Login-LAT-Service)用の34. 長さ >=3 ストリング ストリングのフィールドは1つ以上のオクテットで、利用するLATサービスの同一性を含んでいます。 LATアーキテクチャー(LAT Architecture)は、このストリングが$(ドル)を含むことを可能にします、―(ハイフン)、 (期間)、_、数値(下線)、上部、そして小文字alphabetics、またISOラテン語(ISO Latin)-1キャラクターセット[拡張6]. LATストリング比較はすべて無感覚な場合です。 5.35. ログインLATノード 記述 この属性は、ユーザがLATによって自動的に接続されることになっているノードを示します。 それ、MAY、アクセス受理(Access-Accept)パケットの中で使用される、しかしLATがログインサービス(Login-Service)として指定される場合に限り。 それ、MAY、サーバーに関するヒントとしてアクセスリクエスト(Access-Request)パケットの中で使用される、しかし、サーバーは、ヒントを尊敬することは要求されません。 ログイン-LATノード属性(Login-LAT-Node Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 Rigney、et。 al。 標準は[50ページ]を追跡します RFC 2138 RADIUS 4月の1997 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ ログイン-LATノード(Login-LAT-Node)用の35. 長さ >=3 ストリング ストリングのフィールドは1つ以上のオクテットで、ユーザを接続するためにLATノード(LAT Node)の同一性を含んでいます。 LATアーキテクチャー(LAT Architecture)は、このストリングが$(ドル)を含むことを可能にします、―(ハイフン)、 (期間)、_、数値(下線)、上部、そして小文字alphabetics、またISOラテン語(ISO Latin)-1キャラクターセット拡張。 LATストリング比較はすべて無感覚な場合です。 5.36. ログインLATグループ 記述 この属性は、LATグループ・コードを識別するストリングを含んでいます、このそのユーザは使用するために認可されます。 それ、MAY、アクセス受理(Access Accept)パケットの中で使用される、しかしLATがログイン・サービス(Login Service)として指定される場合に限り。 それ、MAY、サーバーに関するヒントとしてアクセスリクエスト(Access-Request)パケットの中で使用される、しかし、サーバーは、ヒントを尊敬することは要求されません。 LATは256本の異なるグループ・コード(アクセス権の形式としてLATはそれらを使用する)を支援します。 LATは256ビットのビットマップとしてグループ・コードをエンコードします。 管理者は、LATサービス・プロバイダーでグループ・コード・ビットの1つ以上を割り当てることができます; それは、ビットマップ中でこれらのグループ・コードをセットするLAT接続を単に受理するでしょう。 管理者は、各ユーザに認可されたグループ・コードのビットマップを譲渡します; LATはオペレーティング・システムからこれらを得て、サービス・プロバイダーへのそのリクエストの中でこれらを使用します。 Rigney、et。 al。 標準は[51ページ]を追跡します RFC 2138 RADIUS 4月の1997 ログイン-LATグループ属性(Login-LAT-Group Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ ログイン-LATグループ(Login-LAT-Group)用の36. 長さ 34 ストリング ストリングのフィールドは32のオクテット・ビットマップです、最も重要なオクテット、1位。 強健なインプリメンテーションSHOULD、平凡なオクテットとしてフィールドを支援します。 このフィールドの許可された使用法の範囲の規則の成文化は、この明細の範囲の外部であります。 5.37. 組み立てられたアップル・トークリンク 記述 この属性は、ユーザ(それは別のアップル・トーク・ルーターである)への連続するリンクのために使用されるべきアップル・トーク・ネットワーク番号を示します。 それはアクセス受理(Access-Accept)パケットの中で単に使用されます。 ユーザが別のルーターでない場合、それは使用されません。 組み立てられたアップル・トークリンク属性(Framed-AppleTalk-Link Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ Rigney、et。 al。 標準は[52ページ]を追跡します RFC 2138 RADIUS 4月の1997 タイプ 組み立てられたアップル・トークリンク(Framed-AppleTalk-Link)用の37. 長さ 6 値 値フィールドは4つのオクテットです。 フィールドのサイズにもかかわらず、値は0〜65535まで変動します。 0の特別の値は、これが無数の連続するリンクであることを示します。 1-65535の値は、NASとユーザの間の連続するラインがアップル・トーク・ネットワーク番号としてその値を割り当てられるべきであることを意味します。 5.38. 組み立てられたアップル・トークネットワーク 記述 この属性は、ユーザにアップル・トーク・ノードを分配するために、NASが調査するべきアップル・トーク・ネットワーク(AppleTalk Network)番号を示します。 それはアクセス受理(Access-Accept)パケットの中で単に使用されます。 ユーザが別のルーターである場合、それは使用されません。 この属性の多数のインスタンスは、NASが指定されたネットワーク番号のうちのいかなるものでも使用して、調査するかもしれないことを示します。 組み立てられたアップル・トークネットワーク属性(Framed-AppleTalk-Network Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ 組み立てられたアップル・トークネットワーク(Framed-AppleTalk-Network)用の38. 長さ 6 Rigney、et。 al。 標準は[53ページ]を追跡します RFC 2138 RADIUS 4月の1997 値 値フィールドは4つのオクテットです。 フィールドのサイズにもかかわらず、値は0〜65535まで変動します。 特別の値0は、NASがそのデフォルトケーブル範囲を使用して、ユーザのためにネットワークを割り当てることを示します。 1と65535(包括的)の間の値は、ユーザにアドレスを捜してやるためにNASが調査するべきアップル・トーク・ネットワーク(AppleTalk Network)を示します。 5.39. 組み立てられたアップル・トークゾーン 記述 この属性は、このユーザのために使用されるアップル・トークデフォルトゾーン(AppleTalk Default Zone)を示します。 それはアクセス受理(Access-Accept)パケットの中で単に使用されます。 同じパケット中のこの属性の多数のインスタンスは許可されません。 組み立てられたアップル・トークゾーン属性(Framed-AppleTalk-Zone Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 ++++++++、+++++++++-+-+-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+-+-+。- タイプ 組み立てられたアップル・トークゾーン(Framed-AppleTalk-Zone)用の39. 長さ >=3 ストリング あるデフォルトアップル・トーク・ゾーン(Default AppleTalk Zone)の名前はこのユーザのために使用しました。 強健なインプリメンテーションSHOULD、平凡なオクテットとしてフィールドを支援します。 このフィールドの許可された使用法の範囲の規則の成文化は、この明細の範囲の外部であります。 Rigney、et。 al。 標準は[54ページ]を追跡します RFC 2138 RADIUS 4月の1997 5.40. CHAP挑戦 記述 この属性は、PPP挑戦握手認証プロトコル(PPP Challenge-Handshake Authentication Protocol)(CHAP)ユーザのもとへNASによって送られたCHAPの挑戦を含んでいます。 それはアクセスリクエスト(Access-Request)パケットの中で単に使用されます。 CHAP挑戦価値が16のオクテットである場合、長い、それ、MAY、この属性を使用する代わりにリクエスト証人(Request Authenticator)分野に置かれます。 CHAP挑戦属性(CHAP-Challenge Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 ++++++++、+++++++++-+-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+-+。- タイプ CHAP挑戦(CHAP-Challenge)用の60. 長さ >=7 ストリング ストリングのフィールドはCHAPの挑戦を含んでいます。 5.41. NASポートタイプ 記述 この属性は、ユーザを確証しているNASの物理的なポートのタイプを示します。 それは、NASポート(NAS-Port)(5)属性の代わりに、あるいはその属性に加えて使用することができます。 それはアクセスリクエスト(Access-Request)パケットの中で単に使用されます。 NASポート(NAS-Port)(5)あるいはNASポートタイプ(NAS-Port-Type)か、両方のSHOULDのいずれか、NASがそのポート中に分化する場合、アクセスリクエスト(Access-Request)パケットの中にあります。 Rigney、et。 al。 標準は[55ページ]を追跡します RFC 2138 RADIUS 4月の1997 NASポートタイプ属性(NAS-Port-Type Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ NASポートタイプ(NAS-Port-Type)用の61. 長さ 6 値 値フィールドは4つのオクテットです。 「仮想の」物理的なポートを通っての代わりに、ある輸送プロトコルによってNASへの接続に言及します。 例えば、ユーザが外国行きのユーザ(Outbound-User)として彼自身を確証するためにNASへtelnettedしたならば、アクセスリクエスト(Access-Request)は、ユーザが物理的なポート上にいなかったというRADIUSサーバーに関するヒントとして仮想のNASポートタイプ(Port-Type)=を含んでいるかもしれません。 0 Async 1 同時録音 2 ISDN同時録音 3 ISDN Async V.120 4 ISDN Async V.110 5 仮想です 5.42. ポート限界 記述 この属性はポートの最大の数にNASによってユーザに供給させます。 この属性MAY(Attribute MAY)アクセス受理(Access-Accept)パケット中のクライアントにサーバーによって送られます。 それは、マルチリンクPPP[7]か類似した用途と協力する使用のために意図されます。 それ、MAY、さらにヒントとしてサーバーへNASによって送られる、多くのポートが要求されるそれ、使用、しかし、サーバーは、ヒントを尊敬することは要求されません。 Rigney、et。 al。 標準は[56ページ]を追跡します RFC 2138 RADIUS 4月の1997 ポート限界属性(Port-Limit Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 3 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ |タイプ|長さ|値 ++++++++、+++++++++++++++++-+-+-+-+-+-+-+-+ 値(cont) ++++++++、+-+-+-+-+-+-+-+-+ タイプ ポート限界(Port-Limit)用の62. 長さ 6 値 フィールドは4つのオクテットです、接続するためにこのユーザが与えられるべきポートの最大の数を備えた32ビットの符号なしの整数を含んでいること、に、NASの上で。 5.43. ログインLATポート 記述 この属性は、ユーザがLATによって接続されることになっているポートを示します。 それ、MAY、アクセス受理(Access-Accept)パケットの中で使用される、しかしLATがログインサービス(Login-Service)として指定される場合に限り。 それ、MAY、サーバーに関するヒントとしてアクセスリクエスト(Access-Request)パケットの中で使用される、しかし、サーバーは、ヒントを尊敬することは要求されません。 ログイン-LATポート属性(Login-LAT-Port Attribute)フォーマットの要約は下に示されます。 フィールドは右への左から送信されます。 0 1 2 0 1 2 3 4 5、6 7 8 9 0、1 2 3 4 5、6 7 8 9 0、1 ++++++++、+++++++++-+-+-+-+-+-+。- |タイプ|長さ|ストリング... ++++++++、+++++++++-+-+-+-+-+-+。- タイプ ログイン-LATポート(Login-LAT-Port)用の63. Rigney、et。 al。 標準は[57ページ]を追跡します RFC 2138 RADIUS 4月の1997 長さ >=3 ストリング ストリングのフィールドは1つ以上のオクテットで、使用するLATポートの同一性を含んでいます。 LATアーキテクチャー(LAT Architecture)は、このストリングが$(ドル)を含むことを可能にします、―(ハイフン)、 (期間)、_、数値(下線)、上部、そして小文字alphabetics、またISOラテン語(ISO Latin)-1キャラクターセット拡張。 LATストリング比較はすべて無感覚な場合です。 5.44. 属性のテーブル 次のテーブルは、どれが帰着するかのガイドを提供します、見つかるかもしれない、どの種類、パケットの、そして何の中で、量。 受理が挑戦#属性を拒絶することを要求します 1 0 0 0 1ユーザー名 0-1 0 0 0 2ユーザパスワード[ノート1] 0-1 0 0 0 3 CHAPパスワード[ノート1] 0-1 0 0 0 4 NASIPアドレス 0-1 0 0 0 5 NASポート 0-1 0-1 0 0 6サービスタイプ 0-1 0-1 組み立てられた0 0 7プロトコル 0-1 0-1 組み立てられた0 0 8 IPアドレス 0-1 0-1 0 0 9組み立てられたIP-Netmask 0 0-1 0 0 10は敗走させて、組み立てました 0 0の+0 0 11フィルタ-Id 0 0-1 組み立てられた0 0 12 MTU 0の+0+0 0、13の組み立てられた圧縮 0の+0+0 0、14人のログインIPホスト 0 0-1 0 0 15ログインサービス 0 0-1 0 0 16ログインTCPポート 0 0の+0+0+、18の返答メッセージ 0-1 0-1 0 0 19コールバック番号 0 0-1 0 0 20コールバック-Id 0 0の組み立てられた+0 0 22ルート 0 0-1 0 0 23組み立てられたIPXネットワーク 0-1 0-1 0 0-1 24州 0 0の+0 0 25クラス 0の+0+0 0+、26、ベンダー特定 0 0-1 0 0-1 27セッションタイムアウト 0 0-1 0 0-1 28使用されていないタイムアウト 0 0-1 0 0 29終了アクション 0-1 0 0 0 30呼ばれたステーション-Id 0-1 0 0 0 31呼ぶステーション-Id Rigney、et。 al。 標準は[58ページ]を追跡します RFC 2138 RADIUS 4月の1997 0-1 0 0 0 32 NAS確認者 0の+0+0+、0の+33プロキシー州 0-1 0-1 0 0 34ログインLATサービス 0-1 0-1 0 0 35ログインLATノード 0-1 0-1 0 0 36ログインLATグループ 0 0-1 0 0 37組み立てられたアップル・トークリンク 0 0の+0 0 38組み立てられたアップル・トークネットワーク 0 0-1 0 0 39組み立てられたアップル・トークゾーン 0-1 0の0の0の60のCHAP挑戦 0-1 0 0 0 61 NASポートタイプ 0-1 0-1 0 0 62ポート限界 0-1 0-1 0 0 63ログインLATポート 受理が挑戦#属性を拒絶することを要求します [1に注意してください] アクセスリクエストMUST(Access-Request MUST)ユーザパスワード(User-Password)あるいはCHAPパスワード(CHAP-Password)のいずれかを含んでいる、そしてMUST NOT、両方を含んでいます。 次のテーブルは、上記のテーブル・エントリーの意味を定義します。 0 この属性MUST NOT、パケットの中にあります。 0の+ゼロあるいはこの属性MAYのより多くのインスタンス、パケットの中にあります。 0-1 この属性MAYのゼロあるいは1つのインスタンス、パケットの中にあります。 1 この属性MUSTのちょうど1つのインスタンス、パケットの中にあります。 6. 例 少数の例は典型的な属性のパケットのフローおよび使用を例証するために示されます。 これらの例は、徹底的になるように意図されません、多くの他のものは可能です。 Rigney、et。 al。 標準は[59ページ]を追跡します RFC 2138 RADIUS 4月の1997 6.1. 指定されたホストへのユーザテルネット 192.168.1.16にNASは、ポート3上でログインするnemoと命名されるユーザのためのRADIUSサーバー(RADIUS Server)へアクセスリクエストUDP(Access-Request UDP)パケットを送ります。 コード=1(アクセスリクエスト) ID=0 長さ=56 任意の数}が帰着するリクエスト証人(Request Authenticator)={16オクテット: ユーザー名=「nemo」ユーザパスワード(User-Password)={、空で終わりで当てがわれたパスワードの16のオクテット、MD5(共有された秘密|リクエスト証人(Request Authenticator))}を備えたXORed NASIPアドレス=192.168.1.16 NASポート=3 RADIUSサーバーはnemoを確証し、telnet nemoに192.168.1.3をホストするようにそれに命じるNASにアクセス受理UDP(Access-Accept UDP)パケットを送ります。 コード=2(アクセス受理) ID=0(アクセスリクエスト(Access-Request)でのような同じ) 長さ=38 コード(2)のレスポンス証人(Response Authenticator)={16-オクテットMD-5のチェックサム、id、長さ(38)(0)、リクエスト証人(Request Authenticator)上から、この返答および共有された秘密}中の属性 属性: サービスタイプ=ログインユーザ ログインサービス=テルネット ログインホスト=192.168.1.3 6.2. CHAPを備えた組み立てられたユーザを確証すること 192.168.1.16にNASはPPPを備えたポート20上でログインするflopsyと命名されるユーザのためのRADIUSサーバー(RADIUS Server)へアクセスリクエストUDP(Access-Request UDP)パケットを送ります、確証、CHAPの使用。 NASはRADIUSサーバーに、NASはそうするためには要求されませんが、このユーザがPPPを捜しているというほのめかしとして、サービスタイプ(Service-Type)および組み立てられたプロトコル(Framed-Protocol)属性に沿って送ります。 Rigney、et。 al。 標準は[60ページ]を追跡します RFC 2138 RADIUS 4月の1997 コード=1(アクセスリクエスト) ID=1 長さ=71 任意の数がCHAP挑戦}属性としてさらに使用したリクエスト証人(Request Authenticator)={16オクテット: ユーザー名=「flopsy」CHAPパスワード(CHAP-Password)={、16のオクテットCHAPレスポンス}が後続する1つのオクテットCHAP ID NASIPアドレス=192.168.1.16 NASポート=20 組み立てられたサービスタイプ=ユーザ 組み立てられたプロトコル=PPP RADIUSサーバーはflopsyを確証し、PPPサービスを始めて、かつその動的なアドレス・プールからユーザのアドレスを決めるようにそれに命じるNASにアクセス受理UDP(Access-Accept UDP)パケットを送ります。 コード=2(アクセス受理) ID=1(アクセスリクエスト(Access-Request)でのような同じ) 長さ=56 コード(2)のレスポンス証人(Response Authenticator)={16-オクテットMD-5のチェックサム、id、長さ(56)(1)、リクエスト証人(Request Authenticator)上から、この返答および共有された秘密}中の属性 属性: 組み立てられたサービスタイプ=ユーザ 組み立てられたプロトコル=PPP 組み立てられたIPアドレス=255.255.255.254 敗走させて、組み立てた=、無 組み立てられた圧縮=1(VJ TCP/IPヘッダー圧縮) 組み立てられたMTU=1500 6.3. 挑戦レスポンスカードを持ったユーザ 192.168.1.16にNASは、ポート7上でログインするmopsyと命名されるユーザのためのRADIUSサーバー(RADIUS Server)へアクセスリクエストUDP(Access-Request UDP)パケットを送ります。 コード=1(アクセスリクエスト) ID=2 長さ=57 任意の数}が帰着するリクエスト証人(Request Authenticator)={16オクテット: ユーザー名=「mopsy」ユーザパスワード(User-Password)={、空で終わりで当てがわれたパスワードの16のオクテット、MD5(共有された秘密|リクエスト証人(Request Authenticator))}を備えたXORed NASIPアドレス=192.168.1.16 NASポート=7 Rigney、et。 al。 標準は[61ページ]を追跡します RFC 2138 RADIUS 4月の1997 RADIUSサーバーは、挑戦ストリングおよびレスポンスを捜すことを送り返して、mopsyに挑戦することを決定します。 RADIUSサーバー、またしたがってNASにアクセス挑戦UDP(Access-Challenge UDP)パケットを送ります。 コード=11(アクセス挑戦}) ID=2(アクセスリクエスト(Access-Request)でのような同じ) 長さ=78 コード(11)のレスポンス証人(Response Authenticator)={16-オクテットMD-5のチェックサム、id、長さ(78)(2)、リクエスト証人(Request Authenticator)上から、この返答および共有された秘密}中の属性 属性: 返答メッセージ(Reply-Message)=「32769430に挑戦してください。 プロンプトでレスポンスを入力してください。」 ユーザのレスポンスに加えて返される州={マジック・クッキー(Magic Cookie);データ}のこの例8オクテット中で ユーザは彼の応答およびNASを入力します、その応答を備えた新しいアクセスリクエスト(Access-Request)を送信する、また州属性(State Attribute)を含んでいます。 コード=1(アクセスリクエスト) ID=3(これが変わることに注目する) 長さ=67 ランダムな数}が帰着する証人={NEW 16オクテットを要求します: ユーザー名=「mopsy」ユーザパスワード(User-Password)={、レスポンスの16のオクテットは詰め物をしました、空を備えた終わりおよび共有された秘密のMD5チェックサムを備えたXORedで、を加えて、リクエスト証人(Request Authenticator)}の上に NASIPアドレス=192.168.1.16 NASポート=7 アクセス挑戦(Access-Challenge)パケット、不変の}からの州={マジック・クッキー(Magic Cookie) レスポンスは正しくありませんでした。したがって、RADIUSサーバーは、ログイン試みを拒絶するようにNASに命じます。 コード=3(アクセス拒絶する) ID=3(アクセスリクエスト(Access-Request)でのような同じ) 長さ=20 コード(3)のレスポンス証人(Response Authenticator)={16-オクテットMD-5のチェックサム、id、長さ(20)(3)、リクエスト証人(Request Authenticator)上から、この返答中の属性、もしあれば、また共有された秘密}属性: (返答メッセージ(Reply-Message)を送信することができるかもしれませんが無) Rigney、et。 al。 標準は[62ページ]を追跡します RFC 2138 RADIUS 4月の1997 セキュリティ考察 セキュリティ問題はこのドキュメントの主要なトピックです。 実際上、の内に、あるいは、各RADIUSサーバーに関係していて、認証情報(「秘密」)に「ユーザ」名を関連させるデータ・ベースがあります。 ユーザと命名される項目が多数の方法によって確証されるだろうことは予想されません。 これはユーザを、セットの中からの最も安全でない方法を協定する攻撃に弱くするでしょう。 代わりに、各指定されたユーザにとって、そのユーザー名を確証するために使用されるちょうど1つの方法の表示があるべきです。 ユーザが異なる環境の下の異なる認証方法の使用、次に別個のユーザー名SHOULDを行なう必要がある場合、使用される、その各々はちょうど1つの認証方法を識別します。 パスワードおよび他の秘密はそれぞれの端に格納されるべきです、可能なものとして制限されたように、それらへのアクセスがそうであるそのようなもの。 理想的には、秘密は、認証を実行するためにアクセスを要求するプロセスに単にアクセス可能に違いありません。 秘密は、秘密を扱う(そしてしたがって利得知識、の)実体の数を制限するメカニズムで分配されるべきです。 理想的には、無許可の人は、常に秘密についての知識を獲得してはなりません。 SNMPセキュリティ・プロトコル(SNMP Security Protocols)[8]でこれを達成することは可能です。しかし、そのようなメカニズムはこの明細の範囲の外部であります。 他の分配方法は現在研究と実験を経験しています。 SNMPセキュリティ(SNMP Security)ドキュメント[8]は、さらにネットワーク・プロトコルに対する脅威の優れた概観を持っています。 Rigney、et。 al。 標準は[63ページ]を追跡します RFC 2138 RADIUS 4月の1997 参照 [1] Rivest(R)、またS.Dusse、「MD5メッセージ・ダイジェスト・アルゴリズム」、RFC、MITコンピューター科学研究所、RSA Data Security、1992年4月インク1321。 [2] ポストL、J。「ユーザ・データグラム・プロトコル。」STD、RFC、USC/情報科学研究所、1980年8月768 6。 [3] レノルズ(J)、またJ.ポストL、「割り当てられた数」、STD、RFC、USC/情報科学研究所、1994年10月1700 2。 [4] コーフマン(C)、パールマン(R)、またSpeciner、M、「ネットワーク・セキュリティ(Network Security): 公世界の個人コミュニケーション。」徒弟ホール、3月 1995、ISBN 0-13-061466-1年。 [5] Jacobson、V。「低い速度連続物リンク用の圧縮するTCP(Compressing TCP)/IPヘッダー。」RFC、ローレンス・バークレーLaboratory、1990年2月1144。 [6] ISO 8859。 国際標準(International Standard)(情報処理) 8ビットのバイトはグラフィックキャラクターセット--部分1--をコード化しました:ラテン語です アルファベット、いいえ。 1、ISO 8859-1:1987. [7] Sklower、キログラム、ロイド、B。マクレガー(G)、またカー、D、「PPP マルチリンク・プロトコル」(MP)。RFC 1717(カリフォルニアの大学) バークレー、ロイドインターネットワーキング、ニューブリッジ・ネットワークス 株式会社、1994年11月。 [8] Galvin(J)、McCloghrie、キログラムおよびDavin、J、「SNMPセキュリティ・プロトコル(SNMP Security Protocols)」、RFC、Trusted情報システム(Trusted Information Systems)、ヒューズインク1352 LANシステムインク、MITコンピューター科学研究所、7月 1992. [9] Rigney、C。「RADIUS、説明すること。」RFC、1997年4月2139。 認識 RADIUSは、ネットワーク・アクセス・サーバー(Network Access Servers)のそれらのPortMasterシリーズのためのリヴィングストンEnterprisesによって元来開発されていました。 Rigney、et。 al。 標準は[64ページ]を追跡します RFC 2138 RADIUS 4月の1997 椅子のアドレス ワーキンググループは現在の椅子によって連絡を受けることができます: カールRigney リヴィングストンEnterprises 4464本の柳道 プレザントン、カリフォルニア94588 電話:510の+1 426、0770 EMail:cdr@livingston.com 著者のアドレス さらにこのメモについての疑問は次のものに向けることができます: カールRigney リヴィングストンEnterprises 4464本の柳道 プレザントン、カリフォルニア94588 電話:510の+1 426、0770 EMail:cdr@livingston.com アランC.ルーベンス 長所ネットワーク(Merit Network)インク。 4251本のプリマス道 アナーバー(ミシガン) 48105-2785 EMail:acr@merit.edu ウィリアム・アラン・シンプソン 夢想家 コンピューター・システム・コンサルティング・サービス 1384 Fontaine マディソンハイツ、ミシガン48071 EMail:wsimpson@greendragon.com スティーヴWillens リヴィングストンEnterprises 4464本の柳道 プレザントン、カリフォルニア94588 EMail:steve@livingston.com Rigney、et。 al。 標準は[65ページ]を追跡します