[要約] RFC 6218は、Ciscoベンダー固有のRADIUS属性を使用して鍵素材を提供するための仕様です。このRFCの目的は、Ciscoデバイス間でのセキュアな通信を確保するための鍵素材の配信方法を定義することです。
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エディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントでは、Ciscoベンダースペースから割り当てられたベンダー固有のRADIUS属性のセットを定義します。これは、よく理解されたセキュリティプロパティを備えた標準の技術を使用して暗号化キーイン素材を安全に転送するために使用できます。さらに、メッセージ-Authentication-Code属性を使用して、会計や動的な承認に使用されるものを含む、あらゆる半径メッセージに強力な認証を提供することができます。
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-センドキーおよび[RFC2548]のMSMPPE-RECV-KEY属性と[RFC3579]のメッセージ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]認証の副産物として生成され、認証プロセスが成功した後にアクセス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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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]の半径属性で送信されるサブアトリビュートについて説明しています。ベンダー固有の属性のベンダーIDフィールドは、10進数（シスコ）に設定する必要があります。属性の一般的な形式は次のとおりです。
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のCiscoベンダー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
o Mac-Randomizer
o Message-Authentication-Code
o Message-authentication-code
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、Key-Encrypting-Key（KEK）ID、Lifetime、初期化ベクトル（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.
キーイングマテリアル属性を含むパケットには、メッセージ-Authentication-Code属性も含める必要があります。
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-Keys [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のCiscoベンダー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
string-id
The ASCII characters "radius:app-key=" without quotes or null termination
ASCII文字 "Radius：app-key =" quotesまたはnull exeminationなし
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タイプフィールドは、データフィールドの内容を暗号化するために使用される方法を示します。このドキュメントは、このフィールドの1つの値（小数）のみを定義します。
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としてのみ使用するキー（通常の半径の共有秘密と暗号化的に分離）を提供する手段を提供する必要があります。
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オクテットで、キー資料を使用するアプリケーションのタイプを識別します。これにより、同じメッセージに異なる目的のための複数のキーが存在する可能性があります。このドキュメントは、アプリIDの2つの値を定義します。
0 Reserved
0予約
1 EAP MSK
1 EAP MSK
KEK ID
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タイプフィールドで指定されたアルゴリズムで使用するのに適したタイプと長さの暗号化キーを参照する必要があります（上記参照）。このキーは、データフィールドの内容を保護するために使用されます（以下）。KEK IDは、帯域外のメカニズムを介して構成されている定数です。同じ値は、RADIUSクライアントとサーバーの両方で構成されています。KEK IDが構成されていない場合、フィールドは0に設定されています。特定のRADIUSクライアントとサーバー間で使用するために単一のKEKのみが構成されている場合、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が使用されていない場合、0に設定されています。EAPマスターセッションキー（MSK）アプリケーションのKM IDは0に設定されています。KMIDフィールドを使用する別のアプリケーションは、将来定義できます。
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タイプフィールドの値に依存しますが、その任意の値に対して固定されています。ENCタイプフィールドの値が0（小数）の場合、IVフィールドの長さは8オクテット（上記のように）でなければならず、IVフィールドの値は[RFC3394]で指定されている必要があります。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-Randomizer属性は、メッセージ-Authentication-Code属性のインスタンスを含む任意のメッセージに存在する必要があります。ランダムフィールドには、[RFC4086]の要件を満たす必要がある32-OCTET乱数を含める必要があります。
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-Randomizer属性は、可能であれば、RADIUSメッセージの先頭に配置する必要があります。
A summary of the MAC-Randomizer Attribute format is shown below. The fields are transmitted from left to right.
Mac-Randomizer属性形式の概要を以下に示します。フィールドは左から右に送信されます。
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のCiscoベンダー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
string-id
The ASCII characters "radius:random-nonce=" without quotes or null termination
ASCII文字 "Radius：random-nonce =" quotesまたはnull exeminationなし
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.
メッセージ-Authentication-Code属性は、キーイングマテリアル属性を含む任意のメッセージに含める必要があります。
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.
メッセージauthentication-codeとmessage-authenticator属性の両方をメッセージに含める場合（例えば、古いクライアントと新しいクライアントの両方を含むネットワークの後方互換性の場合）、メッセージauthentication-code属性の値を計算する必要があります初め。
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.
メッセージ-Authentication-Code属性のインスタンスを含むメッセージが受信された場合、受信者は、メッセージ-Authentication-Codeの正しい値を計算し、計算された値が受信された値と一致しない場合、パケットを静かに破棄する必要があります。
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-Randomizer属性のインスタンス（セクション3.2）が含まれている場合、受信したMac-Randomizer属性は、以下に説明するように、応答で送信されたメッセージ-Wauthentication-Code属性の計算に含める必要があります。
A summary of the Message-Authentication-Code Attribute format is shown below. The fields are transmitted from left to right.
Message-authentication-Code属性形式の概要を以下に示します。フィールドは左から右に送信されます。
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のCiscoベンダー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
string-id
The ASCII characters "radius:message-authenticator-code=" without quotes or null termination
ASCII文字 "Radius：message-authenticator-code =" quotesまたはnull exeminationなし
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タイプフィールドは、MACフィールドに値を作成するために使用されるアルゴリズムを指定します。このドキュメントでは、MACタイプフィールドの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 Type 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タイプフィールドで指定されたアルゴリズムで使用するのに適したタイプと長さのキーを参照する必要があります（上記参照）。
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に設定されています。特定のRADIUSクライアントとサーバー間で使用するために単一のMACキーIDのみが構成されている場合、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タイプフィールドの値によって指定されたアルゴリズムに依存します。指定されたアルゴリズムが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が要求メッセージまたは応答に対して計算されているかどうかに応じて、違いがあります。これらの違いを以下に詳しく説明します。実際のアルゴリズムを表す自由可変ハッシュアルグを使用しています。
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-Request [RFC5176]、Accounting-Request [RFC2866]など）の場合、MACフィールドの値は、RADIUSパケットのヘッダーのリクエスト認証器を除いて、パケット全体のハッシュです。次のように、鍵として秘密を共有します。
MAC = MAC-ALG(Key, Type + Identifier + Length + Attributes)
where '+' represents concatenation
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-Randomizer属性（セクション3.2）は、メッセージAuthentication-Code属性が使用される任意の要求に含める必要があります。MACランダマイザー属性のランダムフィールドは、MACフィールドの値が計算される前に記入する必要があります。
If the Message-Authenticator-Code Attribute is included in a client request, the server SHOULD ignore the contents of the Request Authenticator.
Message-authenticator-Code属性がクライアントリクエストに含まれている場合、サーバーはリクエスト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.
ハッシュが計算されると、メッセージ-Authenticator-Code属性のMACフィールドと、メッセージ-Authenticator属性の文字列フィールド（存在する場合）の両方がゼロ充填と見なされる必要があります。
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.
実装は、メッセージ - 承認コードの生成でのみ使用するキー（通常の半径の共有秘密と暗号化的に分離）を提供する手段を提供する必要があります。
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-CACK [RFC5176]、会計応答[RFC2866]など）の場合、MACフィールドの値は、共有パケットのヘッダーの応答認証器の応答認証者を除き、パケット全体のハッシュです。次のように、鍵として秘密。
MAC = HASH-ALG(Key, Type + Identifier + Length + Attributes)
where '+' represents concatenation
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-Randomizer属性のインスタンスが含まれており、Responderが対応する応答にメッセージAuthentication-Code属性のインスタンスを含めることを希望する場合、リクエストからのMac-Randomizer属性を応答に含める必要があります。
If the Message-Authenticator-Code Attribute is included in a server response, the client SHOULD ignore the contents of the Response Authenticator.
Message-authenticator-Code属性がサーバーの応答に含まれている場合、クライアントは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.
ハッシュが計算されると、メッセージ-Authenticator-Code属性のMACフィールドと、メッセージ-Authenticator属性の文字列フィールド（存在する場合）の両方がゼロ充填と見なされる必要があります。
The Message-Authentication-Code Attribute MUST be created and inserted in the packet before the Response Authenticator is calculated.
Response Authenticatorが計算される前に、Message-authentication-Code属性をパケットに作成して挿入する必要があります。
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.
実装は、メッセージ - 承認コードの生成でのみ使用するキー（通常の半径の共有秘密と暗号化的に分離）を提供する手段を提供する必要があります。
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.
このメモでは、キー暗号化キーとメッセージ認証キーである2つの新しいキーが、RADIUSクライアントとサーバーによって共有されることをお勧めします。実装されている場合、これらの2つのキーは互いに異なる必要があり、パスワードに基づいてはなりません。これらの2つのキーは、応答認証因子[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キーを2^（n/2）以上のメッセージで使用しないでください。ここで、「n」はオクテットのMAC値の長さです。
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.
キーイングマテリアル属性のインスタンスを含むパケットに、同一のキーキー材料をカプセル化する別の弱いキートランスポート属性（例：MSMPPE-recv-key [rfc2548]）のインスタンスも含まれている場合、より弱い属性を破壊する可能性があります。Kekに対する既知のプレーンテキスト攻撃。
Hao Zhou, Nancy Cam-Winget, Alex Lam, Paul Funk, and John Fossaceca all contributed to this document.
Hao Zhou、Nancy Cam-Winget、Alex Lam、Paul Funk、およびJohn 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.
Keith McCloghrie、Kaushik Narayan、Murtaza Chiba、Bill Burr、Russ Housley、David McGrew、Pat Calhoun、Joel Halpern、Jim Schaad、Greg Weber、Bernard Abobaに有用なフィードバックをありがとう。
[FIPS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-3, October 2008.
[FIPS]国立標準技術研究所、「Secure Hash Standard（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] Dworkin、M。、「操作のブロックモードの推奨：認証用のCMACモード」、NIST SP800-38B、2005年5月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C。、「Radius Accounting」、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] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「トンネルプロトコルサポートのRadius属性」、RFC 2868、2000年6月。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394] Schaad、J。およびR. Housley、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、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. Calhoun、「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] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、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.
[RFC5176] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、およびB. Aboba、「Remote Authentication Dial in User Service（RADIUS）への動的認証拡張」、RFC 5176、2008年1月。
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999.
[RFC2548] Zorn、G。、「Microsoft Vendor固有の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.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「Extensible認証プロトコル（EAP）」、RFC 3748、2004年6月。
Authors' Addresses
著者のアドレス
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na、Bangkok 10260 Thail
Phone: +66 (0) 87 040 4617
EMail: gwz@net-zen.net
Tiebing Zhang Advista Technologies 5252 Orange Ave., Suite 106 Cypress, CA 90630 US
タイビングチャンアドバイスタテクノロジー5252オレンジアベニュー、スイート106サイプレス、CA 90630 US
Phone: +1 (949) 242 0391
EMail: tzhang@advistatech.com
Jesse Walker Intel Corporation JF2-55 2111 N.E. 25th Ave. Hillsboro, OR 97214-5961 US
Jesse Walker Intel Corporation JF2-55 2111 N.E.25th Ave. Hillsboro、または97214-5961 US
Phone: +1 (503) 712-1849
EMail: jesse.walker@intel.com
Joseph Salowey Cisco Systems 2901 Third Avenue SEA1/6/ Seattle, WA 98121 US
Joseph Salowey Cisco Systems 2901 Third Avenue Sea1/ 6/ Seattle、WA 98121 US
Phone: +1 (206) 256-3380
EMail: jsalowey@cisco.com