Independent Submission G. Zorn
Request for Comments: 6218 Network Zen
Category: Informational T. Zhang
ISSN: 2070-1721 Advista Technologies
J. Walker
Intel Corporation
J. Salowey
Cisco Systems
April 2011
Cisco Vendor-Specific RADIUS Attributes for
the Delivery of Keying Material
Abstract
抽象
This document defines a set of vendor-specific RADIUS Attributes designed to allow both the secure transmission of cryptographic keying material and strong authentication of any RADIUS message. These attributes have been allocated from the Cisco vendor-specific space and have been implemented by multiple vendors.
この文書は、暗号化キーイングマテリアルの安全な送信と任意RADIUSメッセージの強力な認証の両方を可能にするように設計されたベンダー固有のRADIUS属性のセットを定義します。これらの属性は、シスコのベンダー固有の空間から割り当てられていると、複数のベンダーによって実装されています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6218.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6218で取得することができます。
IESG Note
IESG注意
The IESG has concluded that this work is related to IETF work done in the RADEXT WG, but this relationship does not prevent publishing. The IESG recommends that the RADEXT WG proceed with the work for an interoperable modern key wrap solution using attributes from the standard space as part of its charter.
IESGは、この作業はRADEXT WGで行わIETF仕事に関連していると結論しているが、この関係は公開を防ぐことはできません。 IESGはRADEXT WGはその憲章の一部として標準空間からの属性を使用して、相互運用可能な最新のキーラップ・ソリューションのための作業を進めることをお勧めします。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction ....................................................2
2. Specification of Requirements ...................................3
3. Attributes ......................................................3
3.1. Keying-Material ............................................4
3.2. MAC-Randomizer .............................................9
3.3. Message-Authentication-Code ...............................11
4. Security Considerations ........................................16
5. Contributors ...................................................16
6. Acknowledgements ...............................................16
7. References .....................................................16
7.1. Normative References ......................................16
7.2. Informative References ....................................17
This document defines a set of vendor-specific RADIUS Attributes, allocated from the Cisco vendor space, that can be used to securely transfer cryptographic keying material using standard techniques with well-understood security properties. In addition, the Message-Authentication-Code Attribute may be used to provide strong authentication for any RADIUS message, including those used for accounting and dynamic authorization.
この文書では、確実に十分に理解セキュリティ特性を有する標準的な技術を使用して暗号化キーイングマテリアルを転送するために使用することができるシスコのベンダー空間から割り当てられたベンダー固有のRADIUS属性のセットを定義します。加えて、メッセージ認証コード属性は、会計および動的認可のために使用されるものを含む、任意のRADIUSメッセージのための強力な認証を提供するために使用されてもよいです。
These attributes were designed to provide stronger protection and more flexibility than the currently defined Vendor-Specific MS-MPPE-Send-Key and MS-MPPE-Recv-Key Attributes in [RFC2548] and the Message-Authenticator Attribute in [RFC3579].
これらの属性は、現在定義されているベンダー固有のMS-MPPE-SENDキーおよびMS-MPPE-Recv関数 - キー[RFC2548]と[RFC3579]でMessage-Authenticatorアトリビュートの属性よりも強力な保護とより多くの柔軟性を提供するように設計されました。
Many remote access deployments (for example, deployments utilizing wireless LAN technology) require the secure transmission of cryptographic keying material from a RADIUS [RFC2865] server to a network access point. This material is usually produced as a by-product of an Extensible Authentication Protocol (EAP) [RFC3748] authentication and returned in the Access-Accept message following a successful authentication process. The keying material is of a form that may be used in virtually any cryptographic algorithm after appropriate processing. These attributes may also be used in other cases where an Authentication, Authorization, and Accounting (AAA) server needs to deliver keying material to a network access point.
多くのリモートアクセスの展開は、（例えば、無線LAN技術を利用して展開）は、ネットワークアクセスポイントにRADIUS [RFC2865]サーバから暗号化キーイングマテリアルの安全な送信を必要とします。この材料は、通常、成功した認証プロセスの次の拡張認証プロトコル（EAP）[RFC3748]認証とAccess-Acceptメッセージで返されるの副産物として生成されます。鍵材料は、適切な処理の後、実質的に任意の暗号アルゴリズムで使用することができる形式のものです。これらの属性は、認証は、許可、アカウンティング（AAA）サーバは、ネットワークアクセスポイントにキーイングマテリアルを送達するために必要以外の場合に使用することができます。
Discussion of this document may be directed to the authors.
本書の議論は執筆者に向けることができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following subsections describe sub-attributes that are transmitted in RADIUS Attributes of type Vendor-Specific [RFC2865]. The Vendor ID field of the Vendor-Specific Attribute(s) MUST be set to decimal 9 (Cisco). The general format of the attributes is:
以下のサブセクションでは、タイプベンダー固有[RFC2865]のRADIUS属性で送信されるサブ属性を記述する。ベンダー固有の属性（複数可）のベンダーIDフィールドは、9（Cisco）を進数に設定されなければなりません。属性の一般的な形式は次のとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
26 for Vendor-Specific
ベンダー固有26
Length
長さ
Length of entire attribute including type and length fields
タイプと長さフィールドを含む全体の属性の長さ
Vendor ID
ベンダーID
4 octets encoding the Cisco Vendor ID of 9
9のシスコのベンダーIDをコードする4つのオクテット
Sub-type
サブタイプ
Attribute sub-type of 1
1のサブタイプの属性
Sub-length
サブ長
Length of the sub-attribute including the sub-type and sub-length fields
サブタイプおよびサブ長さフィールドを含むサブ属性の長さ
Value
値
Value of the sub-attribute
サブ属性の値
This specification concerns the following sub-attributes:
この仕様は、次のサブ属性に関係します：
o Keying-Material
Oキーイング物質 -
o MAC-Randomizer
MAC-ランダマイザO
o Message-Authentication-Code
Oメッセージ認証コード -
Description
説明
This Attribute MAY be used to transfer cryptographic keying material from a RADIUS server to a client.
この属性は、クライアントにRADIUSサーバから暗号鍵素材を転送するために使用されるかもしれません。
It MAY be sent in request messages (e.g., Access-Request, etc.), as well; if the Keying-Material (KM) Attribute is present in a request, it SHOULD be taken as a hint by the server that the client prefers this method of key delivery over others. The server is not obligated to honor the hint, however. When the Keying-Material Attribute is included in a request message, the KM ID, key-encrypting-key (KEK) ID, Lifetime, Initialization Vector (IV), and Key Material Data fields MAY be omitted.
それだけでなく、要求メッセージ（例えば、アクセス要求、等）で送られてもよいです。キーイング・マテリアル（KM）属性がリクエストに存在する場合、それは、クライアントが他のものより鍵配送のこの方法を好むサーバによってヒントとして取られるべきです。サーバーは、しかし、ヒントを尊重する義務を負いません。キーイング・マテリアル属性は、要求メッセージに含まれている場合、KM ID、キー暗号化キー（KEK）ID、生涯、初期化ベクトル（IV）、およびキーマテリアルデータフィールドは省略されるかもしれません。
In environments where the Keying-Material Attribute is known to be supported or in cases where the client wants to avoid roll-back attacks, the client MAY be configured to require the use of the Keying-Material Attribute. If the client requires the use of the Keying-Material Attribute for keying material delivery and it is not present in the Access-Accept or Access-Challenge message, the client MAY ignore the message in question and end the user session.
キーイング・マテリアルの属性がサポートまたはクライアントがロールバック攻撃を避けたい場合にすることが知られている環境では、クライアントは、キーイング・マテリアル属性の使用を必要とするように構成されるかもしれません。クライアントは、素材の配信をキーイングのためのキーイング・マテリアル属性を使用する必要があり、それがアクセス-受け入れるか、またはアクセスチャレンジメッセージに存在しない場合、クライアントは、問題のメッセージを無視し、ユーザーセッションを終了してもよいです。
Any packet that contains a Keying-Material Attribute MUST also include the Message-Authentication-Code Attribute.
キーイング・マテリアル属性を含むすべてのパケットはまた、メッセージ認証コード属性を含める必要があります。
Any packet that contains an instance of the Keying-Material Attribute MUST NOT contain an instance of any other attribute (e.g., MS-CHAP-MPPE-Keys [RFC2548], Tunnel-Password [RFC2868], etc.) encapsulating identical keying material.
キーイング・マテリアル属性のインスタンスを含む任意のパケットは、同一の鍵材料をカプセル化する任意の他の属性（例えば、MS-CHAP-MPPE-キー[RFC2548]、トンネルパスワード[RFC2868]など）のインスタンスを含んではなりません。
The Keying-Material Attribute MUST NOT be used to transfer long-lived keys (i.e., passwords) between RADIUS servers and clients.
キーイング・マテリアル属性は、RADIUSサーバとクライアントの間で長寿命のキー（すなわち、パスワード）を転送するために使用してはいけません。
A summary of the Keying-Material Attribute format is shown below. The fields are transmitted from left to right.
キーイング・マテリアル属性のフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:app-key=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) | Enc Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| App ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KEK ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KEK ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| KM ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
KM ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IV
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IV (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Keying Material Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
26 for Vendor-Specific
ベンダー固有26
Length
長さ
Length of entire attribute including type and length fields
タイプと長さフィールドを含む全体の属性の長さ
Vendor ID
ベンダーID
4 octets encoding the Cisco Vendor ID of 9
9のシスコのベンダーIDをコードする4つのオクテット
Sub-type
サブタイプ
Attribute sub-type of 1
1のサブタイプの属性
Sub-length
サブ長
Length of the sub-attribute including the sub-type and sub-length fields
サブタイプおよびサブ長さフィールドを含むサブ属性の長さ
String-ID
文字列-ID
The ASCII characters "radius:app-key=" without quotes or null termination
ASCII文字：引用符やヌル終了せずに、「半径アプリキー=」
Enc Type
ENCタイプ
The Enc Type field indicates the method used to encrypt the contents of the Data field. This document defines only one value (decimal) for this field:
なお、Enc Typeフィールドは、データフィールドの内容を暗号化するために使用される方法を示しています。この文書では、このフィールドに一つだけの値（10進数）定義されています。
0 AES Key Wrap with 128-bit KEK [RFC3394]
128ビットのKEK [RFC3394]と0 AESキーラップ
Implementations MUST support Enc Type 0 (AES Key Wrap with 128-bit KEK).
実装は、なお、Encタイプ0（128ビットKEKとAESキーラップ）をサポートしなければなりません。
Implementation Note
実装上の注意
A shared secret is used as the key-encrypting-key (KEK) for the AES key wrap algorithm. Implementations SHOULD provide a means to provision a key (cryptographically separate from the normal RADIUS shared secret) to be used exclusively as a KEK.
共有秘密は、AESキーラップアルゴリズムのキー暗号化キー（KEK）として使用されています。実装は、KEKとして排他的に使用される（暗号通常RADIUSの共有秘密とは別に）プロビジョニングするキー手段を提供すべきです。
App ID
アプリケーションID
The App ID field is 4 octets in length and identifies the type of application for which the key material is to be used. This allows for multiple keys for different purposes to be present in the same message. This document defines two values for the App ID:
アプリIDフィールドは長さが4つのオクテットであり、鍵材料が使用されるためのアプリケーションの種類を識別する。これは、同じメッセージの中に存在することが、異なる目的のために複数のキーを可能にします。このドキュメントは、App IDのための2つの値を定義します。
0 Reserved
0予約
1 EAP MSK
1 EAP MSK
KEK ID
ケーキイード
The KEK ID field is 16 octets in length. The combination of the KEK ID and the client and server IP addresses together uniquely identify a key shared between the RADIUS client and server. As a result, the KEK ID need not be globally unique. The KEK ID MUST refer to an encryption key of a type and length appropriate for use with the algorithm specified by the Enc Type field (see above). This key is used to protect the contents of the Data field (below). The KEK ID is a constant that is configured through an out-of-band mechanism. The same value is configured on both the RADIUS client and server. If no KEK ID is configured, then the field is set to 0. If only a single KEK is configured for use between a given RADIUS client and server, then 0 can be used as the default value.
KEK IDフィールドは、長さが16オクテットです。 KEK IDおよびクライアントとサーバーのIPアドレスの組み合わせは、一緒に一意のRADIUSクライアントとサーバとの間で共有されるキーを識別する。その結果、KEK IDは、グローバルに一意である必要はありません。 KEK IDは、なお、Enc Typeフィールドによって指定されたアルゴリズムで使用するための適切な種類と長さ（上記参照）の暗号化キーを参照しなければなりません。このキーは、データフィールド（下）の内容を保護するために使用されます。 KEK IDは、アウトオブバンド機構を介して構成されている定数です。同じ値は、RADIUSクライアントとサーバの両方で設定されています。何KEKのIDが設定されていない場合、そのフィールドは0に設定されている単一のKEKが与えRADIUSクライアントとサーバとの間の使用のために構成されている場合、0がデフォルト値として使用することができます。
KM ID
KM ID
The KM ID field is 16 octets in length and contains an identifier for the contents of the Data field. The KM ID MAY be used by communicating parties to identify the material being transmitted. The combination of App ID and KM ID MUST uniquely identify the keying material between the parties utilizing it. The KM ID is assumed to be known to the parties that derived the keying material. If the KM ID is not used, it is set to 0. The KM ID for the EAP Master Session Key (MSK) application is set to 0. Another application that uses the KM ID field can be defined in the future.
KM IDフィールドの長さは16個のオクテットであり、データフィールドの内容のための識別子を含みます。 KM IDは、材料が送信される識別するために、通信者によって使用されてもよいです。アプリID及びKM IDの組み合わせが一意に利用する当事者間の鍵材料を識別しなければなりません。 KM IDは、キーイング材料由来当事者に知られているものとします。 KM IDを使用しない場合は、KM ID 0に設定されているEAPマスターセッションキー（MSK）アプリケーションは0に設定されているためKM IDフィールドを使用して別のアプリケーションは、将来的に定義することができます。
Lifetime
一生
The Lifetime field is an integer [RFC2865] representing the period of time (in seconds) for which the keying material is valid.
ライフタイムフィールドは、キーイング材料が有効である時間（秒）の周期を表す整数[RFC2865]です。
Note: Applications using this value SHOULD consider the beginning of the lifetime to be the point in time when the keying material is first used.
注意：この値を使用するアプリケーションは、キーイング材料が最初に使用された時点であることを生涯の始まりを検討すべきです。
IV
IV
The length of the IV field depends upon the value of the Enc Type field, but is fixed for any given value thereof. When the value of the Enc Type field is 0 (decimal), the IV field MUST be 8 octets in length (as illustrated above), and the value of the IV field MUST be as specified in [RFC3394]. If the IV for Enc Type 0 does not match [RFC3394], then the receiver MUST NOT use the key material from this attribute.
IVフィールドの長さのENC Typeフィールドの値に依存するが、これらの任意の所与の値に対して固定されています。なお、Enc Typeフィールドの値が0（10進数）である場合、IVフィールドは（上記示されているように）長さが8つのオクテットでなければなりません、そして、[RFC3394]で指定されるようIVフィールドの値でなければなりません。なお、Encタイプ0のためのIVは、[RFC3394]を一致しない場合、受信側は、この属性からキーマテリアルを使用してはなりません。
Keying Material Data
キーイング材料データ
The Keying Material Data field is of variable length and contains the actual encrypted keying material.
鍵材料データフィールドは可変長であり、実際の暗号化キーイングマテリアルが含まれています。
Description
説明
The MAC-Randomizer Attribute MUST be present in any message that includes an instance of the Message-Authentication-Code Attribute. The Random field MUST contain a 32-octet random number that SHOULD satisfy the requirements of [RFC4086].
MAC-ランダマイザ属性は、メッセージ認証コード属性のインスタンスを含む任意のメッセージ中に存在しなければなりません。ランダムフィールドは、[RFC4086]の要件を満たさなければならない32オクテット乱数を含まなければなりません。
Implementation Note
実装上の注意
The Random field MUST be filled in before the Message Authentication Code (MAC) is computed. The MAC-Randomizer Attribute SHOULD be placed at the beginning of the RADIUS message if possible.
メッセージ認証コード（MAC）が計算される前に、ランダムフィールドが記入されなければなりません。可能であればMAC-ランダマイザ属性は、RADIUSメッセージの先頭に配置する必要があります。
A summary of the MAC-Randomizer Attribute format is shown below. The fields are transmitted from left to right.
MAC-ランダマイザ属性形式の概要は以下に示されています。フィールドは左から右に送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:random-nonce=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Random...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
26 for Vendor-Specific
ベンダー固有26
Length
長さ
Length of entire attribute including type and length fields
タイプと長さフィールドを含む全体の属性の長さ
Vendor ID
ベンダーID
4 octets encoding the Cisco Vendor ID of 9
9のシスコのベンダーIDをコードする4つのオクテット
Sub-type
サブタイプ
Attribute sub-type of 1
1のサブタイプの属性
Sub-length
サブ長
Length of the sub-attribute including the sub-type and sub-length fields
サブタイプおよびサブ長さフィールドを含むサブ属性の長さ
String-ID
文字列-ID
The ASCII characters "radius:random-nonce=" without quotes or null termination
引用符またはヌル終了：ASCII文字「ランダム・ナンス=半径」
Random
ランダム
This field MUST contain a 32 octet random number that SHOULD satisfy the requirements of [RFC4086].
このフィールドは、[RFC4086]の要件を満たさなければならない32オクテット乱数を含まなければなりません。
Description
説明
This Attribute MAY be used to "sign" messages to prevent spoofing. If it is present in a request, the receiver should take this as a hint that the sender prefers the use of this Attribute for message authentication; the receiver is not obligated to do so, however.
この属性は、なりすましを防ぐために、「記号」のメッセージに使用されるかもしれません。それは要求に存在する場合、受信側は送信者がメッセージ認証のために、この属性を使用することを好むのヒントとしてこれを取る必要があります。受信機は、しかし、そうする義務を負いません。
The Message-Authentication-Code Attribute MUST be included in any message that contains a Keying-Material Attribute.
メッセージ認証コード属性は、キーイング・マテリアル属性を含む任意のメッセージに含まれなければなりません。
If both the Message-Authentication-Code and Message-Authenticator Attributes are to be included in a message (e.g., for backward compatibility in a network containing both old and new clients), the value of the Message-Authentication-Code Attribute MUST be computed first.
メッセージ認証・コードおよびメッセージ認証属性の両方がメッセージに含まれている場合（例えば、新旧両方のクライアントを含むネットワークでの後方互換性のために）、メッセージ認証コード属性の値を計算しなければなりません最初。
If any message is received containing an instance of the Message-Authentication-Code Attribute, the receiver MUST calculate the correct value of the Message-Authentication-Code and silently discard the packet if the computed value does not match the value received.
すべてのメッセージは、メッセージ認証コード属性のインスタンスを含む受信された場合、受信機は、メッセージ認証-コードの正しい値を計算しなければならないと計算された値が受信された値と一致しない場合静かにパケットを捨てます。
If a received message contains an instance of the MAC-Randomizer Attribute (Section 3.2), the received MAC-Randomizer Attribute SHOULD be included in the computation of the Message-Authentication-Code Attribute sent in the response, as described below.
受信したメッセージがMAC-ランダマイザ属性（セクション3.2）のインスタンスを含む場合、以下に記載されるように、受信したMAC-ランダマイザ属性は、応答で送信されたメッセージ認証コード属性の計算に含まれるべきです。
A summary of the Message-Authentication-Code Attribute format is shown below. The fields are transmitted from left to right.
メッセージ認証コード属性のフォーマットの概要は以下に示されています。フィールドは左から右に送信されます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (26) | Length | Vendor ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor ID (cont'd) | Sub-type (1)| Sub-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| String ID ("radius:message-authenticator-code=")
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
String ID (cont'd) | MAC Type | MAC Key ID
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MAC Key ID (cont'd) | MAC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC (cont'd) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
26 for Vendor-Specific
ベンダー固有26
Length
長さ
Length of entire attribute including type and length fields
タイプと長さフィールドを含む全体の属性の長さ
Vendor ID
ベンダーID
4 octets encoding the Cisco Vendor ID of 9
9のシスコのベンダーIDをコードする4つのオクテット
Sub-type
サブタイプ
Attribute sub-type of 1
1のサブタイプの属性
Sub-length
サブ長
Length of the sub-attribute including the sub-type and sub-length fields
サブタイプおよびサブ長さフィールドを含むサブ属性の長さ
String-ID
文字列-ID
The ASCII characters "radius:message-authenticator-code=" without quotes or null termination
ASCII文字「半径：メッセージオーセンティケータコード=」引用符またはヌル終端なし
MAC Type
MACタイプ
The MAC Type field specifies the algorithm used to create the value in the MAC field. This document defines six values for the MAC Type field:
MAC Typeフィールドは、MACフィールドの値を作成するために使用するアルゴリズムを指定します。この文書では、MAC Typeフィールドのための6つの値を定義します。
0 HMAC-SHA-1 [FIPS] [RFC2104]
0 HMAC-SHA-1 [FIPS] [RFC2104]
1 HMAC-SHA-256 [FIPS] [RFC4231]
1 HMAC-SHA-256 [FIPS] [RFC4231]
2 HMAC-SHA-512 [FIPS] [RFC4231]
2 HMAC-SHA-512 [FIPS] [RFC4231]
3 CMAC-AES-128 [NIST]
3 CMAC-AES-128 [NIST]
4 CMAC-AES-192 [NIST]
4 CMAC-AES-192 [NIST]
5 CMAC-AES-256 [NIST]
5 CMAC-AES-256 [NIST]
Implementations MUST support MAC Type 0 (HMAC-SHA-1).
実装は、MACタイプ0（HMAC-SHA-1）をサポートしなければなりません。
MAC Key ID
MACキーID
The MAC Key ID field is 16 octets in length and contains an identifier for the key. The combination of the MAC Key ID and the client and server IP addresses together uniquely identify a key shared between the RADIUS client and server. As a result, the MAC Key ID need not be globally unique. The MAC Key ID MUST refer to a key of a type and length appropriate for use with the algorithm specified by the MAC Type field (see above).
MACキーIDフィールドは、長さが16個のオクテットで、キーの識別子が含まれています。 MACキーIDと、クライアントとサーバーのIPアドレスの組み合わせが一緒に一意のRADIUSクライアントとサーバとの間で共有されるキーを識別する。その結果、MACキーIDは、グローバルに一意である必要はありません。 MAC鍵IDはMAC Typeフィールドによって指定されたアルゴリズムで使用するための適切な種類と長さ（上記参照）のキーを参照しなければなりません。
The MAC Key ID is a constant that is configured through an out-of-band mechanism. The same value is configured on both the RADIUS client and server. If no MAC Key ID is configured, then the field is set to 0. If only a single MAC Key ID is configured for use between a given RADIUS client and server, then 0 can be used as the default value.
MAC鍵IDは、アウトオブバンド機構を介して構成されている定数です。同じ値は、RADIUSクライアントとサーバの両方で設定されています。何のMACキーIDが設定されていない場合、そのフィールドは0に設定されているだけで、単一のMACキーIDが与えられたRADIUSクライアントとサーバの間で使用するように構成されている場合は、0がデフォルト値として使用することができます。
MAC
マック
Both the length and value of the MAC field depend upon the algorithm specified by the value of the MAC Type field. If the algorithm specified is HMAC-SHA-1, HMAC-SHA-256, or HMAC-SHA-512, the MAC field MUST be 20, 32, or 64 octets in length, respectively. If the algorithm specified is CMAC-AES-128, CMAC-AES-192, or CMAC-AES-256, the MAC field SHOULD be 64 octets in length. The derivation of the MAC field value for all the algorithms specified in this document is identical, except for the algorithm used. There are differences, however, depending upon whether the MAC is being computed for a request message or a response. These differences are detailed below, with the free variable HASH-ALG representing the actual algorithm used.
MACフィールドの長さと値の両方がMAC Typeフィールドの値によって指定されたアルゴリズムに依存します。指定されたアルゴリズムはHMAC-SHA-1、HMAC-SHA-256、またはHMAC-SHA-512である場合、MACフィールドは、それぞれ、長さが20、32、または64オクテットでなければなりません。指定されたアルゴリズムは、CMAC-AES-128、CMAC-AES-192、またはCMAC-AES-256である場合、MACフィールドの長さは64オクテットであるべきです。この文書で指定されたすべてのアルゴリズムのMACフィールド値の導出は、使用されるアルゴリズムを除いて、同一です。違いはMAC要求メッセージまたは応答に対して計算されているかどうかに応じて、しかし、そこです。これらの違いは、自由変数HASH-ALGが使用される実際のアルゴリズムを表現すると、以下に詳述します。
Request Messages
リクエスト・メッセージ
For requests (e.g., CoA-Request [RFC5176], Accounting-Request [RFC2866], etc.), the value of the MAC field is a hash of the entire packet except the Request Authenticator in the header of the RADIUS packet, using a shared secret as the key, as follows.
要求（例えば、CoAをリクエスト[RFC5176]、アカウンティング要求[RFC2866]など）のために、MACフィールドの値を使用して、RADIUSパケットのヘッダのリクエスト認証を除く全パケットのハッシュであります以下のように、キーと秘密を共有しました。
MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes) where '+' represents concatenation
'+' は連結を表し、MAC = MAC-ALG（キー、タイプ識別子+ +長+属性）
The MAC-Randomizer Attribute (Section 3.2) MUST be included in any request in which the Message-Authentication-Code Attribute is used. The Random field of the MAC-Randomizer Attribute MUST be filled in before the value of the MAC field is computed.
MAC-ランダマイザ属性（セクション3.2）メッセージ認証コード属性が使用される任意の要求に含まれなければなりません。 MAC-ランダマイザ属性のランダムフィールドは、MACフィールドの値が計算される前に記入しなければなりません。
If the Message-Authenticator-Code Attribute is included in a client request, the server SHOULD ignore the contents of the Request Authenticator.
メッセージ認証コード属性は、クライアントの要求に含まれている場合、サーバは要求認証の内容を無視すべきです。
Implementation Notes
実装の注意事項
When the hash is calculated, both the MAC field of the Message-Authenticator-Code Attribute and the String field of the Message-Authenticator Attribute (if any) MUST be considered to be zero-filled.
ハッシュが算出されると、メッセージ認証コード属性のMACフィールドおよびメッセージ認証属性の文字列フィールド（もしあれば）の両方がゼロで満たされたと見なされなければなりません。
Implementations SHOULD provide a means to provision a key (cryptographically separate from the normal RADIUS shared secret) to be used exclusively in the generation of the Message-Authentication-Code.
実装では、メッセージ認証、コードの生成にのみ使用される（暗号通常RADIUSの共有秘密とは別に）プロビジョニングするキー手段を提供すべきです。
Response Messages
応答メッセージ
For responses (e.g., CoA-ACK [RFC5176], Accounting-Response [RFC2866], etc.), the value of the MAC field is a hash of the entire packet except the Response Authenticator in the header of the RADIUS packet using a shared secret as the key, as follows.
応答のために（例えば、アシルCoA-ACK [RFC5176]、アカウンティングレスポンス[RFC2866]など）は、MACフィールドの値は、共有使用RADIUSパケットのヘッダに応答認証以外パケット全体のハッシュであります以下のように、キーとして秘密。
MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes) where '+' represents concatenation
'+' は連結を表し、MAC = HASH-ALG（キー、タイプ識別子+ +長+属性）
If the request contained an instance of the MAC-Randomizer Attribute and the responder wishes to include an instance of the Message-Authentication-Code Attribute in the corresponding response, then the MAC-Randomizer Attribute from the request MUST be included in the response.
要求は、MAC-ランダマイザ属性のインスタンスと応答が含まれている場合、対応する応答メッセージ認証コード属性のインスタンスを含めることを望む、その要求からMAC-ランダマイザ属性は、応答に含まれなければなりません。
If the Message-Authenticator-Code Attribute is included in a server response, the client SHOULD ignore the contents of the Response Authenticator.
メッセージ認証コード属性は、サーバーの応答に含まれている場合、クライアントはレスポンス認証の内容を無視すべきです。
Implementation Notes
実装の注意事項
When the hash is calculated, both the MAC field of the Message-Authenticator-Code Attribute and the String field of the Message-Authenticator Attribute (if any) MUST be considered to be zero-filled.
ハッシュが算出されると、メッセージ認証コード属性のMACフィールドおよびメッセージ認証属性の文字列フィールド（もしあれば）の両方がゼロで満たされたと見なされなければなりません。
The Message-Authentication-Code Attribute MUST be created and inserted in the packet before the Response Authenticator is calculated.
メッセージ認証コード属性が作成され、レスポンス認証が計算される前に、パケットに挿入する必要があります。
Implementations SHOULD provide a means to provision a key (cryptographically separate from the normal RADIUS shared secret) to be used exclusively in the generation of the Message-Authentication-Code.
実装では、メッセージ認証、コードの生成にのみ使用される（暗号通常RADIUSの共有秘密とは別に）プロビジョニングするキー手段を提供すべきです。
It is RECOMMENDED in this memo that two new keys, a key encrypting key and a message authentication key, be shared by the RADIUS client and server. If implemented, these two keys MUST be different from each other and SHOULD NOT be based on a password. These two keys MUST be cryptographically independent of the RADIUS shared secret used in calculating the Response Authenticator [RFC2865], Request Authenticator [RFC2866] [RFC5176], and Message-Authenticator Attribute [RFC3579]; otherwise, if the shared secret is broken, all is lost.
これは、二つの新しいキー、キー暗号化キーとメッセージ認証鍵は、RADIUSクライアントとサーバで共有することは、このメモで推奨されています。実装されている場合、これら2つのキーが互いに異なっていなければならないとパスワードに基づいてされるべきではありません。これら二つの鍵は、認証[RFC2866]、[RFC5176]、およびメッセージ認証属性[RFC3579]を要求、応答認証[RFC2865]を計算する際に使用されるRADIUSの共有秘密の暗号独立していなければなりません。それ以外の場合は、共有秘密が壊れている場合、すべてが失われます。
To avoid the possibility of collisions, the same MAC key SHOULD NOT be used with more than 2^(n/2) messages, where 'n' is the length of the MAC value in octets.
衝突の可能性を回避するために、同じMACキーは「N」オクテットでMAC値の長さ以上2 ^（N / 2）メッセージと一緒に使用しないでください。
If a packet that contains an instance of the Keying-Material Attribute also contains an instance of another, weaker key transport attribute (e.g., MS-MPPE-Recv-Key [RFC2548]) encapsulating identical keying material, then breaking the weaker attribute might facilitate a known-plaintext attack against the KEK.
キーイング・マテリアル属性のインスタンスを含むパケットは、別のインスタンス、弱いキートランスポート属性が含まれている場合（例えば、MS-MPPE-Recv関数 - キー[RFC2548]）は、同一の鍵材料カプセル化し、容易かもしれない弱い属性を壊しますKEKに対するクリブ。
Hao Zhou, Nancy Cam-Winget, Alex Lam, Paul Funk, and John Fossaceca all contributed to this document.
ハオ周、ナンシー・カム・ウィンゲット、アレックス・ラム、ポール・ファンク、そしてジョンFossacecaすべては、この文書に貢献しました。
Thanks (in no particular order) to Keith McCloghrie, Kaushik Narayan, Murtaza Chiba, Bill Burr, Russ Housley, David McGrew, Pat Calhoun, Joel Halpern, Jim Schaad, Greg Weber, and Bernard Aboba for useful feedback.
有用なフィードバックのためのキースMcCloghrie、Kaushikによるナラヤン、Murtaza千葉、ビル・バー、ラスHousley、デビッドマグリュー、パットカルフーン、ジョエル・ハルパーン、ジムSchaad、グレッグ・ウェーバー、およびバーナードAbobaに（順不同）感謝します。
[FIPS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[FIPS]米国国立標準技術研究所、 "セキュアハッシュ規格（SHS）"、FIPS PUB 180-3の、2008年10月。
[NIST] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication", NIST SP800- 38B, May 2005.
、NIST SP800- 38B、2005年5月：[NIST] Dworkin、M.、 "認証のためのCMACモード動作のブロック暗号モードのための勧告"。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、ベラー、M.、およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、2000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M., and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868]ゾルン、G.、Leifer、D.、ルーベンス、A.、シュライバー、J.、ホールドレッジ、M.、およびI. Goyret、RFC 2868、2000年6月 "RADIUSトンネルプロトコルサポートのための属性"。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394] Schaad、J.とR. Housley氏、 "高度暗号化標準（AES）キーラップアルゴリズム"、RFC 3394、2002年9月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B.およびP.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086]イーストレーク3、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、BCP 106、RFC 4086、2005年6月。
[RFC4231] Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC 4231, December 2005.
[RFC4231] Nystrom、M.、 "識別子とHMAC-SHA-224、HMAC-SHA-256、HMAC-SHA-384、およびHMAC-SHA-512のテストベクター"、RFC 4231、2005年12月。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
、RFC 5176、2008年1月[RFC5176]千葉、M.、Dommety、G.、エクランド、M.、ミトン、D.、およびB. Aboba、 "ユーザーサービス（RADIUS）でリモート認証ダイヤルへのダイナミックな承認拡張機能"。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548]ソーン、G.、 "マイクロソフトのベンダー固有のRADIUSアトリビュート"、RFC 2548、1999年3月。
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.
[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。
Authors' Addresses
著者のアドレス
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
グレンツォルンネットワーク禅358分の227タノンSanphawutバンナー、バンコク10260タイ
Phone: +66 (0) 87 040 4617 EMail: gwz@net-zen.net
電話：+66（0）87 040 4617 Eメール：gwz@net-zen.net
Tiebing Zhang Advista Technologies 5252 Orange Ave., Suite 106 Cypress, CA 90630 US
ネクタイと張ADビスタ技術5252オレンジのAVああ。、スイート106本のヒノキ、CA 90630米国
Phone: +1 (949) 242 0391 EMail: tzhang@advistatech.com
電話：+1（949）242 0391 Eメール：tzhang@advistatech.com
Jesse Walker Intel Corporation JF2-55 2111 N.E. 25th Ave. Hillsboro, OR 97214-5961 US
ジェシーウォーカーインテルコーポレーションJF2-55 2111 N.E.第25回アベニューヒルズボロ、OR 97214-5961米国
Phone: +1 (503) 712-1849 EMail: jesse.walker@intel.com
電話：+1（503）712-1849 Eメール：jesse.walker@intel.com
Joseph Salowey Cisco Systems 2901 Third Avenue SEA1/6/ Seattle, WA 98121 US
ジョセフSaloweyシスコシステムズ2901 Third AvenueのSEA1 / 6 /シアトル、WA 98121米国
Phone: +1 (206) 256-3380 EMail: jsalowey@cisco.com
電話：+1（206）256-3380 Eメール：jsalowey@cisco.com