RFC5209 日本語訳
5209 Network Endpoint Assessment (NEA): Overview and Requirements. P.Sangster, H. Khosravi, M. Mani, K. Narayan, J. Tardo. June 2008. (Format: TXT=132227 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Sangster
Request for Comments: 5209 Symantec
Category: Informational H. Khosravi
Intel
M. Mani
Avaya
K. Narayan
Cisco Systems
J. Tardo
Nevis Networks
June 2008
コメントを求めるワーキンググループP.サングスタの要求をネットワークでつないでください: 5209年のSymantecカテゴリ: 情報のH.のM.マニAvaya K.ナーラーヤンKhosraviインテルシスコシステムズJ.緩やかなネヴィスは2008年6月をネットワークでつなぎます。
Network Endpoint Assessment (NEA): Overview and Requirements
終点査定(NEA)をネットワークでつないでください: 概要と要件
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document defines the problem statement, scope, and protocol requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g., an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance-oriented decisions. The posture information is frequently useful for detecting systems that are lacking or have out-of-date security protection mechanisms such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced.
このドキュメントはNEA(ネットワークEndpoint Assessment)規範モデルの部品の間の問題声明、範囲、およびプロトコル要件を定義します。 NEAは、システムの姿勢を評価するためにネットワーク(例えば、遠隔アクセスを提供する企業)の所有者にメカニズムを提供します。 これは要求の間、ネットワークアクセス次にいつでもで行われるかもしれませんネットワークに関する間。 そして、さまざまな承諾指向の決定に学術的姿勢情報を適用できます。 姿勢情報は頻繁に欠けであるか以下などの時代遅れな機密保持メカニズムを持っているシステムを検出することの役に立ちます。 アンチウイルスとホストベースのファイアウォールソフトウェア。 文脈を要件に提供するために、規範モデルと用語は紹介されます。
Sangster, et al. Informational [Page 1] RFC 5209 NEA Requirements June 2008
サングスタ、他 [1ページ]情報のRFC5209NEA要件2008年6月
Table of Contents
目次
1. Introduction ....................................................3
1.1. Requirements Language ......................................4
2. Terminology .....................................................5
3. Applicability ...................................................7
3.1. Scope ......................................................7
3.2. Applicability of Environments ..............................8
4. Problem Statement ...............................................9
5. Reference Model ................................................10
5.1. NEA Client and Server .....................................12
5.1.1. NEA Client .........................................12
5.1.1.1. Posture Collector .........................12
5.1.1.2. Posture Broker Client .....................14
5.1.1.3. Posture Transport Client ..................15
5.1.2. NEA Server .........................................15
5.1.2.1. Posture Validator .........................15
5.1.2.2. Posture Broker Server .....................17
5.1.2.3. Posture Transport Server ..................18
5.2. Protocols .................................................18
5.2.1. Posture Attribute Protocol (PA) ....................18
5.2.2. Posture Broker Protocol (PB) .......................19
5.2.3. Posture Transport Protocol (PT) ....................19
5.3. Attributes ................................................20
5.3.1. Attributes Normally Sent by NEA Client: ............21
5.3.2. Attributes Normally Sent by NEA Server: ............21
6. Use Cases ......................................................22
6.1. Initial Assessment ........................................22
6.1.1. Triggered by Network Connection or Service
Request ............................................22
6.1.1.1. Example ...................................23
6.1.1.2. Possible Flows and Protocol Usage .........23
6.1.1.3. Impact on Requirements ....................25
6.1.2. Triggered by Endpoint ..............................25
6.1.2.1. Example ...................................25
6.1.2.2. Possible Flows and Protocol Usage .........26
6.1.2.3. Impact on Requirements ....................28
6.2. Posture Reassessment ......................................28
6.2.1. Triggered by NEA Client ............................28
6.2.1.1. Example ...................................28
6.2.1.2. Possible Flows & Protocol Usage ...........29
6.2.1.3. Impact on Requirements ....................30
6.2.2. Triggered by NEA Server ............................30
6.2.2.1. Example ...................................30
6.2.2.2. Possible Flows and Protocol Usage .........31
6.2.2.3. Impact on Requirements ....................33
1. 序論…3 1.1. 要件言語…4 2. 用語…5 3. 適用性…7 3.1. 範囲…7 3.2. 環境の適用性…8 4. 問題声明…9 5. 参照モデル…10 5.1. NEAクライアントとサーバ…12 5.1.1. NEAクライアント…12 5.1.1.1. 姿勢コレクタ…12 5.1.1.2. 姿勢ブローカーのクライアント…14 5.1.1.3. 姿勢輸送クライアント…15 5.1.2. NEAサーバ…15 5.1.2.1. 姿勢Validator…15 5.1.2.2. 姿勢ブローカーサーバ…17 5.1.2.3. 姿勢輸送サーバ…18 5.2. プロトコル…18 5.2.1. 姿勢属性プロトコル(PA)…18 5.2.2. 姿勢ブローカープロトコル(Pb)…19 5.2.3. 姿勢トランスポート・プロトコル(太平洋標準時の)…19 5.3. 属性…20 5.3.1. 通常、属性はNEAクライアントで送りました: ............21 5.3.2. 通常、属性はNEAサーバで送りました: ............21 6. ケースを使用してください…22 6.1. 査定に頭文字をつけてください…22 6.1.1. ネットワーク接続かサービスのリクエストで、引き起こされます…22 6.1.1.1. 例…23 6.1.1.2. 可能な流れとプロトコル用法…23 6.1.1.3. 要件で影響を与えてください…25 6.1.2. 終点で、引き起こされます…25 6.1.2.1. 例…25 6.1.2.2. 可能な流れとプロトコル用法…26 6.1.2.3. 要件で影響を与えてください…28 6.2. 姿勢Reassessment…28 6.2.1. NEAクライアントによって引き起こされます…28 6.2.1.1. 例…28 6.2.1.2. 可能な流れとプロトコル用法…29 6.2.1.3. 要件で影響を与えてください…30 6.2.2. NEAサーバで、引き起こされます…30 6.2.2.1. 例…30 6.2.2.2. 可能な流れとプロトコル用法…31 6.2.2.3. 要件で影響を与えてください…33
Sangster, et al. Informational [Page 2] RFC 5209 NEA Requirements June 2008
サングスタ、他 [2ページ]情報のRFC5209NEA要件2008年6月
7. Requirements ...................................................34
7.1. Common Protocol Requirements ..............................34
7.2. Posture Attribute (PA) Protocol Requirements ..............35
7.3. Posture Broker (PB) Protocol Requirements .................36
7.4. Posture Transport (PT) Protocol Requirements ..............38
8. Security Considerations ........................................38
8.1. Trust .....................................................39
8.1.1. Endpoint ...........................................40
8.1.2. Network Communications .............................41
8.1.3. NEA Server .........................................42
8.2. Protection Mechanisms at Multiple Layers ..................43
8.3. Relevant Classes of Attack ................................43
8.3.1. Man-in-the-Middle (MITM) ...........................44
8.3.2. Message Modification ...............................45
8.3.3. Message Replay or Attribute Theft ..................45
8.3.4. Other Types of Attack ..............................46
9. Privacy Considerations .........................................46
9.1. Implementer Considerations ................................47
9.2. Minimizing Attribute Disclosure ...........................49
10. References ....................................................50
10.1. Normative References .....................................50
10.2. Informative References ...................................50
11. Acknowledgments ...............................................51
7. 要件…34 7.1. 一般的なプロトコル要件…34 7.2. 姿勢属性(PA)プロトコル要件…35 7.3. 姿勢ブローカー(Pb)プロトコル要件…36 7.4. 姿勢輸送(太平洋標準時の)プロトコル要件…38 8. セキュリティ問題…38 8.1. 信じます。39 8.1.1. 終点…40 8.1.2. コミュニケーションをネットワークでつないでください…41 8.1.3. NEAサーバ…42 8.2. 複数の層の保護メカニズム…43 8.3. 関連クラスの攻撃…43 8.3.1. 中央の男性(MITM)…44 8.3.2. メッセージ変更…45 8.3.3. メッセージ再生か属性窃盗…45 8.3.4. 他のタイプの攻撃…46 9. プライバシー問題…46 9.1. Implementer問題…47 9.2. 属性公開を最小にします…49 10. 参照…50 10.1. 標準の参照…50 10.2. 有益な参照…50 11. 承認…51
1. Introduction
1. 序論
Endpoints connected to a network may be exposed to a wide variety of threats. Some protection against these threats can be provided by ensuring that endpoints conform to security policies. Therefore, the intent of NEA is to assess these endpoints to determine their compliance with security policies so that corrective measures can be provided before they are exposed to those threats. For example, if a system is determined to be out of compliance because it is lacking proper defensive mechanisms such as host-based firewalls, anti-virus software, or the absence of critical security patches, the NEA protocols provide a mechanism to detect this fact and indicate appropriate remediation actions to be taken. Note that an endpoint that is deemed compliant may still be vulnerable to threats that may exist on the network.
ネットワークにつなげられた終点はさまざまな脅威に暴露されるかもしれません。 終点が安全保障政策に従うのを確実にすることによって、これらの脅威に対する何らかの保護を提供できます。 したがって、NEAの意図はそれらの脅威にそれらを暴露する前に是正措置を提供できるように安全保障政策への彼らのコンプライアンスを決定するためにこれらの終点を評価することです。 例えば、それが重要なセキュリティー・パッチのホストベースのファイアウォール、ウイルス除去ソフト、または欠如などの欠いている適切な防衛的なメカニズムであるのでシステムが承諾から脱していることを決定しているなら、NEAプロトコルは、この事実を検出して、取るために適切な治療教育動きを示すためにメカニズムを提供します。 言いなりになると考えられる終点がまだネットワークに存在するかもしれない脅威に被害を受け易いかもしれないことに注意してください。
NEA typically involves the use of special client software running on the requesting endpoint that observes and reports on the configuration of the system to the network infrastructure. The infrastructure has corresponding validation software that is capable of comparing the endpoint's configuration information with network compliance policies and providing the result to appropriate authorization entities that make decisions about network and application access. Some endpoints may be incapable of running the
NEAはシステムの構成に関する見る要求終点で動く特別なクライアントソフトウェアとレポートの使用にネットワークインフラに通常かかわります。 インフラストラクチャには、ネットワーク承諾方針と終点の設定情報を比べて、ネットワークとアプリケーションに関する決定をアクセサリーにする承認実体を当てるために結果を提供できる対応する合法化ソフトウェアが、あります。 いくつかの終点は稼働できないかもしれません。
Sangster, et al. Informational [Page 3] RFC 5209 NEA Requirements June 2008
サングスタ、他 [3ページ]情報のRFC5209NEA要件2008年6月
NEA Client software (e.g., printer) or be unwilling to share information about their configuration. This situation is outside the scope of NEA and is subject to local policies.
または、NEA Clientソフトウェア(例えば、プリンタ)、それらの構成の情報を共有するには、不本意であってください。 この状況は、NEAの範囲の外にあって、ローカルの方針を受けることがあります。
The result of an endpoint assessment may influence an access decision that is provisioned to the enforcement mechanisms on the network and/or endpoint requesting access. While the NEA Working Group recognizes there may be a link between an assessment and the enforcement of a resulting access decision, the mechanisms and protocols for enforcement are not in scope for this specification.
終点査定の結果はアクセサリーを要求しながらネットワーク、そして/または、終点で実施メカニズムに食糧を供給されるアクセス決定に影響を及ぼすかもしれません。 NEA作業部会は、結果として起こるアクセス決定の査定と実施とのリンクがあるかもしれないと認めますが、実施のためのメカニズムとプロトコルがこの仕様のための範囲にありません。
Architectures, similar to NEA, have existed in the industry for some time and are present in shipping products, but do not offer adequate interoperability. Some examples of such architectures include: Trusted Computing Group's Trusted Network Connect [TNC], Microsoft's Network Access Protection [NAP], and Cisco's Cisco Network Admission Control [CNAC]. These technologies assess the software and/or hardware configuration of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy.
NEAと同様のアーキテクチャは、しばらく、産業で存在していて、製品を出荷する際に存在していますが、適切な相互運用性を提供しないでください。 そのようなアーキテクチャに関するいくつかの例は: グループの信じられたネットワークを計算しながら信じられて、マイクロソフトのネットワークの[TNC]、アクセス保護[仮眠]、およびシスコのコクチマスネットワーク入場コントロール[CNAC]を接続してください。 これらの技術は組織の方針にコンプライアンスをモニターするか、または実施する目的のために終点デバイスのソフトウェア、そして/または、ハードウェア・コンフィギュレーションを評価します。
The NEA Working Group is developing standard protocols that can be used to communicate compliance information between a NEA Client and a NEA Server. This document provides the context for NEA including: terminology, applicability, problem statement, reference model, and use cases. It then identifies requirements for the protocols used to communicate between a NEA Client and NEA server. Finally, this document discusses some potential security and privacy considerations with the use of NEA. The majority of this specification provides informative text describing the context of NEA.
NEA作業部会はNEA ClientとNEA Serverの間の承諾情報を伝えるのに使用できる標準プロトコルを開発しています。このドキュメントはNEA包含のための文脈を提供します: 用語、適用性、問題声明、参照をモデル化します、そして、ケースを使用してください。 次に、それはNEA ClientとNEAサーバの間で交信するのに使用されるプロトコルのための要件を特定します。最終的に、このドキュメントはいくつかの潜在的セキュリティとプライバシー問題についてNEAの使用と議論します。 この仕様の大部分がNEAの文脈について説明する有益なテキストを提供します。
1.1. Requirements Language
1.1. 要件言語
Use of each capitalized word within a sentence or phrase carries the following meaning during the NEA WG's protocol selection process:
文か句の中のそれぞれの大文字で書かれた単語の使用はNEA WGのプロトコル選択プロセスの間、以下の意味を運びます:
MUST - indicates an absolute requirement
--、絶対条件を示さなければなりません。
MUST NOT - indicates something absolutely prohibited
NOT--、絶対に何か禁止されたものを示さなければなりません。
SHOULD - indicates a strong recommendation of a desired result
SHOULD--、必要な結果の強い推薦を示します。
SHOULD NOT - indicates a strong recommendation against a result
SHOULD NOT--、結果に対して強い推薦を示します。
MAY - indicates a willingness to allow an optional outcome
5月--、任意の結果を許容する意欲を示します。
Lower case use of "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" carry their normal meaning and are not subject to these definitions.
“MUST"のケース使用、「必須NOT」を下ろしてください、“SHOULD"、「」 「5月」は、それらの正常な意味を運んで、これらの定義を受けることがあるべきではありません。
Sangster, et al. Informational [Page 4] RFC 5209 NEA Requirements June 2008
サングスタ、他 [4ページ]情報のRFC5209NEA要件2008年6月
2. Terminology
2. 用語
This section defines a set of terms used throughout this document. In some cases these terms have been used in other contexts with different meanings so this section attempts to describe each term's meaning with respect to the NEA WG activities.
このセクションはこのドキュメント中で使用される用語一式を定義します。 いくつかの場合、これらの用語が他の文脈で異なった意味で使用されたので、このセクションは、NEA WG活動に関してそれぞれタームの意味について説明するのを試みます。
Assessment - The process of collecting posture for a set of
capabilities on the endpoint (e.g., host-based firewall) such that
the appropriate validators may evaluate the posture against
compliance policy.
査定--適切なvalidatorsが承諾方針に対して姿勢を評価するかもしれなくて、収集のプロセスは1セットの能力のために終点(例えば、ホストベースのファイアウォール)でポーズをとります。
Assertion Attributes - Attributes that include reusable information
about the success of a prior assessment of the endpoint. This
could be used to optimize subsequent assessments by avoiding a
full posture reassessment. For example, this classification of
attribute might be issued specifically to a particular endpoint,
dated and signed by the NEA Server allowing that endpoint to reuse
it for a time period to assert compliance to a set of policies.
The NEA Server might accept this in lieu of obtaining posture
information.
主張Attributes--終点の先の査定の成功の再利用できる情報を含んでいる属性。 完全な姿勢再査定を避けることによってその後の査定を最適化するのにこれを使用できました。 例えば、属性のこの分類は、1セットの方針にコンプライアンスについて断言するために期間、その終点にそれを再利用させるNEA Serverによって特に特定の終点に発行されて、日付を入れられて、署名されるかもしれません。 姿勢情報を得ることの代わりにNEA Serverはこれを受け入れるかもしれません。
Attribute - Data element including any requisite meta-data describing
an observed, expected, or the operational status of an endpoint
feature (e.g., anti-virus software is currently in use).
Attributes are exchanged as part of the NEA protocols (see section
5.2). NEA recognizes a variety of usage scenarios where the use
of an attribute in a particular type of message could indicate:
データの要素の含んでいるいずれも必要なメタデータが説明して、結果と考える、予想されて、観測される、または、終点の特徴(例えば、ウイルス除去ソフトは現在、使用中である)の操作上の状態。 NEAプロトコルの一部として属性を交換します(セクション5.2を見てください)。 NEAは特定のタイプに関するメッセージにおける属性の使用が以下を示すことができたさまざまな用法シナリオを認識します。
o previously assessed status (Assertion Attributes),
o 以前に評価された状態(主張Attributes)
o observed configuration or property (Posture Attributes),
o 構成か特性(姿勢Attributes)を観測しました。
o request for configuration or property information (Request
Attributes),
o 構成か特性には、情報を要求してください(Attributesを要求してください)。
o assessment decision (Result Attributes), or
o または査定決定(結果Attributes)。
o repair instructions (Remediation Attributes).
o 指示(治療教育Attributes)を修理してください。
The NEA WG will standardize a subset of the attribute namespace
known as standard attributes. Those attributes not standardized
are referred to in this specification as vendor-specific.
NEA WGは標準の属性として知られている属性名前空間の部分集合を標準化するでしょう。 標準化されなかったそれらの属性はこの仕様にベンダー特有であると呼ばれます。
Dialog - Sequence of request/response messages exchanged.
対話--交換された要求/応答メッセージの系列。
Sangster, et al. Informational [Page 5] RFC 5209 NEA Requirements June 2008
サングスタ、他 [5ページ]情報のRFC5209NEA要件2008年6月
Endpoint - Any computing device that can be connected to a network.
Such devices normally are associated with a particular link layer
address before joining the network and potentially an IP address
once on the network. This includes: laptops, desktops, servers,
cell phones, or any device that may have an IP address.
終点--ネットワークに接続できるどんなコンピュータ・デバイス。 通常、そのようなデバイスはネットワークで一度ネットワークと潜在的にIPアドレスに加わる前の特定のリンクレイヤアドレスに関連しています。 これは: ラップトップ、デスクトップ、サーバ、携帯電話、またはIPアドレスがあるかもしれないどんなデバイス。
Message - Self contained unit of communication between the NEA Client
and Server. For example, a posture attribute message might carry
a set of attributes describing the configuration of the anti-virus
software on an endpoint.
SelfはNEA ClientとServerとのコミュニケーションのユニットを含みました。メッセージ--例えば、姿勢属性メッセージは終点でウイルス除去ソフトの構成について説明する1セットの属性を運ぶかもしれません。
Owner - the role of an entity who is the legal, rightful possessor of
an asset (e.g., endpoint). The owner is entitled to maintain
control over the policies enforced on the device even if the asset
is not within the owner's possession. The owner may permit user
override or augmentation of control policies or may choose to not
assert any policies limiting use of asset.
所有者--資産(例えば、終点)の法的で、正しい所有者である実体の役割。 所有者は所有者の所有物の中に資産がなくてもデバイスで励行される方針のコントロールを維持する権利を与えられます。 所有者は、コントロール方針のユーザオーバーライドか増大を許可するか、またはどんな方針も資産の制限使用であると断言しないのを選ぶかもしれません。
Posture - Configuration and/or status of hardware or software on an
endpoint as it pertains to an organization's security policy.
姿勢--それとしての終点のハードウェアかソフトウェアの構成、そして/または、状態は組織の安全保障政策に関係します。
Posture Attributes - Attributes describing the configuration or
status (posture) of a feature of the endpoint. For example, a
Posture Attribute might describe the version of the operating
system installed on the system.
姿勢Attributes--終点の特徴の構成か状態(姿勢)について説明する属性。 例えば、Posture Attributeはシステムにインストールされたオペレーティングシステムのバージョンについて説明するかもしれません。
Request Attributes - Attributes sent by a NEA Server identifying the
posture information requested from the NEA Client. For example, a
Request Attribute might be an attribute included in a request
message from the NEA Server that is asking for the version
information for the operating system on the endpoint.
Attributesを要求してください--NEA Clientから要求された姿勢情報を特定するNEA Serverによって送られた属性。 例えば、Request Attributeは終点のオペレーティングシステムのためのバージョン情報を求めているNEA Serverからの要求メッセージに含まれていた属性であるかもしれません。
Remediation Attributes - Attributes containing the remediation
instructions for how to bring an endpoint into compliance with one
or more policies. The NEA WG will not define standard remediation
attributes, but this specification does describe where they are
used within the reference model and protocols.
治療教育Attributes--どう1つ以上の方針への承諾に終点を運び込むかためには治療教育指示を含む属性。 NEA WGは標準の治療教育属性を定義しないでしょうが、この仕様は、それらが規範モデルとプロトコルの中でどこで使用されるかを説明します。
Result Attributes - Attributes describing whether the endpoint is in
compliance with NEA policy. The Result Attribute is created by
the NEA Server normally at the conclusion of the assessment to
indicate whether or not the endpoint was considered compliant.
More than one of these attributes may be used allowing for more
granular feature level decisions to be communicated in addition to
an overall, global assessment decision.
結果Attributes--終点がNEA方針に従ってあるかを説明する属性。 通常、Result Attributeは、査定の結論のときに終点が言いなりになると考えられたかどうかを示すためにNEA Serverによって作成されます。 これらの属性の1つ以上は、より粒状の特徴のために、総合的で、グローバルな査定決定に加えてコミュニケートするという平らな決定を許しながら、使用されるかもしれません。
Sangster, et al. Informational [Page 6] RFC 5209 NEA Requirements June 2008
サングスタ、他 [6ページ]情報のRFC5209NEA要件2008年6月
Session - Stateful connection capable of carrying multiple message
exchanges associated with (an) assessment(s) of a particular
endpoint. This document defines the term session at a conceptual
level and does not describe the properties of the session or
specify requirements for the NEA protocols to manage these
sessions.
セッション--複数の交換処理を運ぶことができるStateful接続が特定の終点の(an)査定と交際しました。 このドキュメントは、概念的なレベルでセッションという用語を定義して、セッションの特性について説明するか、またはNEAプロトコルがこれらのセッションを管理するという要件を指定しません。
User - Role of a person that is making use of the services of an
endpoint. The user may not own the endpoint so he or she might
need to operate within the acceptable use constraints defined by
the endpoint's owner. For example, an enterprise employee might
be a user of a computer provided by the enterprise (owner) for
business purposes.
ユーザ--終点のサービスを利用している人の役割。 ユーザが終点を所有しないかもしれないので、その人は、規制が終点の所有者で定義した許容できる使用の中で作動する必要があるかもしれません。 例えば、企業の従業員は企業(所有者)によってビジネス目的に提供されたコンピュータのユーザであるかもしれません。
3. Applicability
3. 適用性
This section discusses the scope of the technologies being standardized and the network environments where it is envisioned that the NEA technologies might be applicable.
このセクションは適切な状態でNEA技術があるかもしれない標準化される技術とそれが思い描かれるネットワーク環境の範囲について論じます。
3.1. Scope
3.1. 範囲
The priority of the NEA Working Group is to develop standard protocols at the higher layers in the reference model (see section 5): the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). PA and PB will be designed to be carried over a variety of lower layer transport (PT) protocols. The NEA WG will identify standard PT protocol(s) that are mandatory to implement. PT protocols may be defined in other WGs because the requirements may not be specific to NEA. When used with a standard PT protocol (e.g., Extensible Authentication Protocol (EAP), Transport Layer Security (TLS) [TLS]), the PA and PB protocols will allow interoperability between a NEA Client from one vendor and a NEA Server from another. This specification will not focus on the other interfaces between the functional components of the NEA reference model nor requirements on their internals. Any discussion of these aspects is included to provide context for understanding the model and resulting requirements.
NEA作業部会の優先権は規範モデルで、より高い層で標準プロトコルを開発する(セクション5を見てください)ことです: Posture Attributeプロトコル(PA)とPosture Brokerは(PB)について議定書の中で述べます。 PAとPBは、さまざまな下層輸送(太平洋標準時の)プロトコルの上まで運ばれるように設計されるでしょう。 NEA WGは実装するために義務的な標準のPTプロトコルを特定するでしょう。 要件がNEAに特定でないかもしれないので、PTプロトコルは他のWGsで定義されるかもしれません。 太平洋標準時の規格と共に使用されると、プロトコル(例えば、拡張認証プロトコル(EAP)、Transport Layer Security(TLS)[TLS])、PA、およびPBプロトコルは別のものから1つのベンダーからのNEA ClientとNEA Serverの間の相互運用性を許容するでしょう。 この仕様はどんなNEA規範モデルの機能部品の間の他のインタフェースの焦点もそれらのインターナルに関する要件もそうしないでしょう。 これらの局面のどんな議論も、モデルと結果として起こる要件を理解しているのに文脈を提供するために含まれています。
Some tangent areas not shown in the reference model that are also out of scope for the NEA working group, and thus this specification, include:
NEAワーキンググループのための範囲のも外にそれがいるのが規範モデルで示されなかった、いくつかの接した領域、およびその結果、この仕様は:
o Standardizing the protocols and mechanisms for enforcing
restricted network access,
o 実施のためにプロトコルとメカニズムを標準化すると、ネットワークアクセスは制限されました。
o Developing standard protocols for remediation of non-compliant
endpoints,
o 不従順な終点の治療教育のために標準プロトコルを開発します。
Sangster, et al. Informational [Page 7] RFC 5209 NEA Requirements June 2008
サングスタ、他 [7ページ]情報のRFC5209NEA要件2008年6月
o Specifying protocols used to communicate with remote portions of
the NEA Client or Server (e.g., remote collectors or validators
of posture),
o プロトコルを指定するのは以前はよくNEA ClientかServer(例えば、姿勢のリモートコレクタかvalidators)のリモート部分で交信する予定でした。
o Supporting a NEA Client providing posture for other endpoints
(e.g., a NEA Client on an Intrusion Detection System (IDS)
providing posture for an endpoint without a NEA Client),
o 他の終点(例えば、NEA Clientなしで姿勢を終点に提供するIntrusion Detection System(IDS)の上のNEA Client)に姿勢を提供するNEA Clientをサポートします。
o Defining the set of events or situations that might trigger a
NEA Client or NEA Server to request an assessment,
o 査定を要求するためにNEA ClientかNEA Serverの引き金となるかもしれないイベントか状況のセットを定義します。
o Detecting or handling lying endpoints (see section 8.1.1 for
more information).
o 横たわっている終点(詳しい情報に関してセクション8.1.1を見る)を検出するか、または扱います。
3.2. Applicability of Environments
3.2. 環境の適用性
Because the NEA model is based on NEA-oriented software being present on the endpoint and in the network infrastructure, and due to the nature of the information being exposed, the use of NEA technologies may not apply in a variety of situations possible on the Internet. Therefore, this section discusses some of the scenarios where NEA is most likely to be applicable and some where it may not be. Ultimately, the use of NEA within a deployment is not restricted to just these scenarios. The decision of whether to use NEA technologies lies in the hands of the deployer (e.g., network provider) based upon the expected relationship they have with the owners and users of potential endpoints.
NEAモデルが終点に存在しているNEA指向のソフトウェアに基づいているためと、ネットワークインフラと、暴露される情報の本質のため、NEA技術の使用はインターネットで可能なさまざまな状況で適用されないかもしれません。 したがって、それが論じないところでこのセクションはNEAが適切である最も傾向があるシナリオといくつかのいくつかについて論じます。 結局、展開の中のNEAの使用はまさしくこれらのシナリオに制限されません。 NEA技術を使用するかどうかに関する決定が彼らが潜在的終点の所有者とユーザと共に持っている予想された関係に基づくデプロイヤ(例えば、ネットワーク内の提供者)の手にあります。
NEA technologies are largely focused on scenarios where the owner of the endpoint is the same as the owner of the network. This is a very common model for enterprises that provide equipment to employees to perform their duties. These employees are likely bound under an employment contract that outlines what level of visibility the employer expects to have into the employee's use of company assets and possibly activities during work hours. This contract may establish the expectation that the endpoint needs to conform to policies set forth by the enterprise.
NEA技術は主に終点の所有者がネットワークの所有者と同じであるシナリオに焦点を合わせられます。 これは義務を果たすために設備を従業員に提供する企業の非常に一般的なモデルです。 これらの従業員は労働時間雇い主が、従業員の会社の資産の使用にどんなレベルの目に見えることを持っていると予想するか、そして、ことによると活動について概説する雇用契約においておそらく義務があります。 この契約は終点が企業によって詳しく説明された方針に従う必要がある期待を確立するかもしれません。
Some other environments may be in a similar situation and thus find NEA technologies to be beneficial. For example, environments where the endpoint is owned by a party (possibly even the user) that has explicitly expressed a desire to conform to the policies established by a network or service provider in exchange for being able to access its resources. An example of this might be an independent contractor with a personal laptop, working for a company imposing NEA assessment policies on its employees, who may wish a similar level of access and is willing to conform to the company's policies. NEA technologies may be applicable to this situation.
ある他の環境によって、同様の状況にいて、その結果、NEA技術が有益であることがわかるかもしれません。 例えば、終点がそれが明らかに開くパーティー(ことによるとユーザさえ)によって所有されている環境はリソースにアクセスできることと引き換えにネットワークかサービスプロバイダーによって確立された方針に従う願望を述べました。 この例はパーソナルラップトップをもっている請負人であるかもしれません、NEA査定方針を従業員に課す会社(同様のアクセスのレベルを願うかもしれなくて、会社の方針に従っても構わないと思っている)で働いていて。 NEA技術はこの状況に適切であるかもしれません。
Sangster, et al. Informational [Page 8] RFC 5209 NEA Requirements June 2008
サングスタ、他 [8ページ]情報のRFC5209NEA要件2008年6月
Conversely, some environments where NEA is not expected to be applicable would be environments where the endpoint is owned by a user that has not agreed to conform to a network provider's policies. An example might include when the above contractor visits any public area like the local coffee shop that offers Internet access. This coffee shop would not be expected to be able to use NEA technologies to assess the posture of the contractor's laptop. Because of the potentially invasive nature of NEA technology, such an assessment could amount to an invasion of privacy of the contractor.
逆に、NEAが適切でないと予想されるいくつかの環境が終点がネットワーク内の提供者の方針に従うのに同意していないユーザによって所有されている環境でしょう。 例は、上の契約者がいつ何かインターネット・アクセスを提供する地方の喫茶店のような公共区域を訪問するかを含むかもしれません。 この喫茶店が契約者のラップトップの姿勢を評価するNEA技術を使用できないと予想されるでしょう。 NEA技術の潜在的に侵略的な本質のために、そのような査定は契約者のプライバシー侵害に達するかもしれません。
It is more difficult to determine whether NEA is applicable in other environments, so the NEA WG will consider them to be out of scope for consideration and specification. In order for an environment to be considered applicable for NEA, the owner or user of an endpoint must have established a clear expectation that it will comply with the policies of the owner and operator of the network. Such an expectation likely includes a willingness to disclose appropriate information necessary for the network to perform compliance checks.
NEA WGが、考慮と仕様のための範囲の外にそれらがあると考えるように、NEAが他の環境で適切であるかどうか決定するのは、より難しいです。 環境がNEAに適切であると考えられるために、終点の所有者かユーザがそれが望んでいる確立したa明確な期待をネットワークの所有者とオペレータの方針に従わせなければなりません。 そのような期待はおそらくネットワークが服薬チェックを実行するように適切な必要情報を明らかにする意欲を含んでいます。
4. Problem Statement
4. 問題声明
NEA technology may be used for a variety of purposes. This section highlights some of the major situations where NEA technologies may be beneficial.
NEA技術はさまざまな目的に使用されるかもしれません。 このセクションはNEA技術が有益であるかもしれない主要な状況のいくつかを目立たせます。
One use is to facilitate endpoint compliance checking against an organization's security policy when an endpoint connects to the network. Organizations often require endpoints to run an IT-specified Operating System (OS) configuration and have certain security applications enabled, e.g., anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An endpoint that is not compliant with IT policy may be vulnerable to a number of known threats that might exist on the network.
1つの使用は組織の安全保障政策に対して終点がいつネットワークに接続するかをチェックする終点コンプライアンスを容易にすることです。 組織は、しばしば終点がITに指定されたOperating System(OS)構成を実行して、アプリケーションが可能にしたあるセキュリティ、例えば、ウイルス除去ソフト、ホスト侵入検出/防止システム、パーソナルファイアウォール、およびパッチ管理ソフトウェアを持っているのを必要とします。 IT政策で言いなりになっていない終点はネットワークに存在するかもしれない多くの知られている脅威に被害を受け易いかもしれません。
Without NEA technology, ensuring compliance of endpoints to corporate policy is a time-consuming and difficult task. Not all endpoints are managed by a corporation's IT organization, e.g., lab assets and contractor machines. Even for assets that are managed, they may not receive updates in a timely fashion because they are not permanently attached to the corporate network, e.g., laptops. With NEA technology, the network is able to assess an endpoint as soon as it requests access to the network or at any time after joining the network. This provides the corporation an opportunity to check compliance of all NEA-capable endpoints in a timely fashion and facilitate endpoint remediation potentially while quarantined when needed.
NEA技術がなければ、終点のコンプライアンスを会社の方針に確実にするのは、手間がかかって難しいタスクです。 すべての終点が会社のIT組織、例えば、研究室資産と契約者マシンによって管理されるというわけではありません。 管理される資産ではさえ、それらは、直ちに永久に企業ネットワーク(例えば、ラップトップ)に付けられないので、アップデートを受けないかもしれません。 NEA技術で、ネットワークに加わった後にネットワークかいつでもでアクセスを要求するとすぐに、ネットワークは終点を評価できます。 これは直ちにすべてのNEAできる終点のコンプライアンスをチェックして、必要であると検疫されている間に潜在的に終点治療教育を容易にする機会を会社に提供します。
Sangster, et al. Informational [Page 9] RFC 5209 NEA Requirements June 2008
サングスタ、他 [9ページ]情報のRFC5209NEA要件2008年6月
NEA technology can be used to provide posture assessment for a range of ways of connecting to the network including (but not limited to) wired and wireless LAN access such as using 802.1X [802.1X], remote access via IPsec [IPSEC], or Secure Socket Layer (SSL) VPN, or gateway access.
ネットワークに接続するのが802.1X[802.1X]を使用などなどのワイヤードでワイヤレスのLANアクセスを含む(他)さまざまな方法のための姿勢査定を提供するのにNEA技術を使用できます、IPsec[IPSEC]、Secure Socket Layer(SSL)VPN、またはゲートウェイアクセサリーを通して、遠隔アクセスです。
Endpoints that are not NEA-capable or choose not to share sufficient posture to evaluate compliance may be subject to different access policies. The decision of how to handle non-compliant or non-participating endpoints can be made by the network administrator possibly based on information from other security mechanisms on the network (e.g., authentication). For example, remediation instructions or warnings may be sent to a non-compliant endpoint with a properly authorized user while allowing limited access to the network. Also, network access technologies can use the NEA results to restrict or deny access to an endpoint, while allowing vulnerabilities to be addressed before an endpoint is exposed to attack. The communication and representation of NEA assessment results to network access technologies on the network is out of scope for this document.
NEAできないか、またはコンプライアンスを評価できるくらいの姿勢を共有しないのを選ぶ終点は異なったアクセス方針を受けることがあるかもしれません。 ことによると情報に基づくネットワーク管理者はネットワーク(例えば、認証)で他のセキュリティー対策からどう不従順であるか非参加している終点を扱うかに関する決定をすることができます。 例えば、ネットワークへの限られたアクセスを許している間、適切に認可されたユーザがいる不従順な終点に治療教育指示か警告を送るかもしれません。 また、終点が攻撃するために暴露される前に脆弱性が扱われるのを許容している間、ネットワークアクセス技術は、終点へのアクセスを制限するか、または拒絶するのにNEA結果を使用できます。 このドキュメントのための範囲の外にネットワークのネットワークアクセス技術へのNEA査定結果のコミュニケーションと表現があります。
Reassessment is a second important use of NEA technology as it allows for additional assessments of previously considered compliant endpoints to be performed. This might become necessary because network compliance policies and/or endpoint posture can change over time. A system initially assessed as being compliant when it joined the network may no longer be in compliance after changes occur. For example, reassessment might be necessary if a user disables a security protection (e.g., host-based firewall) required by policy or when the firewall becomes non-compliant after a firewall patch is issued and network policy is changed to require the patch.
言いなりになっている終点であると考えられた以前にの追徴金のために実行されるのを許容するようにReassessmentはNEA技術の2番目の重要な使用です。 ネットワーク承諾方針、そして/または、終点姿勢が時間がたつにつれて変化できるので、これは必要になるかもしれません。 変化が起こった後に初めはネットワークに加わったとき言いなりになるとして評価されたシステムはコンプライアンスもう中でないかもしれません。 ユーザが、セキュリティが方針によって必要とされた保護(例えば、ホストベースのファイアウォール)であることを無効にするか、またはファイアウォールパッチを支給して、パッチを必要とするようにネットワーク方針を変えた後にファイアウォールが不従順になるとき、例えば、再査定が必要であるかもしれません。
A third use of NEA technology may be to verify or supplement organization asset information stored in inventory databases.
NEA技術の3番目の使用は、目録データベースに保存された組織資産情報を確かめるか、または補うことであるかもしれません。
NEA technology can also be used to check and report compliance for endpoints when they try to access certain mission critical applications within an enterprise, employing service (application) triggered assessment.
また、企業の中で、ある不可欠なアプリケーションにアクセスしようとするとき、終点のためのコンプライアンスをチェックして、報告するのにNEA技術を使用できて、サービス(アプリケーション)を使うのは査定の引き金となりました。
5. Reference Model
5. 規範モデル
This section describes the reference model for Network Endpoint Assessment. This model is provided to establish a context for the discussion of requirements and may not directly map to any particular product or deployment architecture. The model identifies the major
このセクションはNetwork Endpoint Assessmentのために規範モデルについて説明します。 このモデルは、要件の議論のための文脈を証明するために提供されて、直接どんな特定の製品や展開にもアーキテクチャを写像しないかもしれません。 モデルは少佐を特定します。
Sangster, et al. Informational [Page 10] RFC 5209 NEA Requirements June 2008
サングスタ、他 [10ページ]情報のRFC5209NEA要件2008年6月
functionality of the NEA Client and Server and their relationships, as well as the protocols they use to communicate at various levels (e.g., PA is carried by the PB protocol).
NEA ClientとServerの機能性とそれらが様々なレベルで交信するのに使用するプロトコルと同様にそれらの関係(例えばPAはPBプロトコルによって運ばれます)。
While the diagram shows 3 layered protocols, it is envisioned that PA is likely a thin message wrapper around a set of attributes and that it is batched and encapsulated in PB. PB is primarily a lightweight message batching protocol, so the protocol stack is mostly the transport (PT). The vertical lines in the model represent APIs and/or protocols between components within the NEA Client or Server. These interfaces are out of scope for standardization in the NEA WG.
ダイヤグラムのショー3はプロトコルを層にしましたが、それがPBで思い描かれて、そのPAが属性のセットの周りのありそうなa薄いメッセージラッパーであり、batchedされて、カプセル化されるということです。 PBが主として軽量のメッセージバッチングプロトコルであるので、プロトコル・スタックはほとんど輸送(太平洋標準時の)です。 モデルの縦線はNEA ClientかServerの中のコンポーネントの間のAPI、そして/または、プロトコルを表します。NEA WGでの標準化のための範囲の外にこれらのインタフェースがあります。
+-------------+ +--------------+
| Posture | <--------PA--------> | Posture |
| Collectors | | Validators |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
| |
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Broker | <--------PB--------> | Broker |
| Client | | Server |
+-------------+ +--------------+
| |
| |
+-------------+ +--------------+
| Posture | | Posture |
| Transport | <--------PT--------> | Transport |
| Client | | Server |
| (1 .. N) | | (1 .. N) |
+-------------+ +--------------+
+-------------+ +--------------+ | 姿勢| <、-、-、-、-、-、-、--PA-------->| 姿勢| | コレクタ| | Validators| | (1N) | | (1N) | +-------------+ +--------------+ | | | | | | +-------------+ +--------------+ | 姿勢| | 姿勢| | ブローカー| <、-、-、-、-、-、-、--Pb-------->| ブローカー| | クライアント| | サーバ| +-------------+ +--------------+ | | | | +-------------+ +--------------+ | 姿勢| | 姿勢| | 輸送| <、-、-、-、-、-、-、--太平洋標準時-------->| 輸送| | クライアント| | サーバ| | (1N) | | (1N) | +-------------+ +--------------+
NEA CLIENT NEA SERVER
シビルの部屋クライアントシビルの部屋サーバ
Figure 1: NEA Reference Model
図1: NEA規範モデル
The NEA reference model does not include mechanisms for discovery of NEA Clients and NEA Servers. It is expected that NEA Clients and NEA Servers are configured with information that allows them to reach each other. The specific methods of referencing the configuration and establishing the communication channel are out of scope for the NEA reference model and should be covered in the specifications of candidate protocols such as the Posture Transport (PT) protocol.
NEA規範モデルはNEA ClientsとNEA Serversの発見のためのメカニズムを入れません。 NEA ClientsとNEA Serversが彼らが互いに届くことができる情報によって構成されると予想されます。 構成に参照をつけて、通信チャネルを確立する特定のメソッドは、NEA規範モデルのための範囲の外にあって、Posture Transport(太平洋標準時の)プロトコルなどの候補プロトコルの仕様でカバーされているべきです。
Sangster, et al. Informational [Page 11] RFC 5209 NEA Requirements June 2008
サングスタ、他 [11ページ]情報のRFC5209NEA要件2008年6月
5.1. NEA Client and Server
5.1. NEAクライアントとサーバ
5.1.1. NEA Client
5.1.1. NEAクライアント
The NEA Client is resident on an endpoint device and comprised of the following functionality:
NEA Clientは終点デバイスで居住して以下の機能性から成ります:
o Posture Collector(s)
o 姿勢コレクタ(s)
o Posture Broker Client
o 姿勢ブローカーのクライアント
o Posture Transport Client(s)
o 姿勢輸送クライアント(s)
The NEA Client is responsible for responding to requests for attributes describing the configuration of the local operating domain of the client and handling the assessment results including potential remediation instructions for how to conform to policy. A NEA Client is not responsible for reporting on the posture of entities that might exist on the endpoint or over the network that are outside the domain of execution (e.g., in other virtual machine domains) of the NEA Client.
NEA Clientはクライアントの地方の操作ドメインの構成について説明して、どう方針に従うかためには潜在的治療教育指示を含む査定結果を扱う属性を求める要求に応じるのに責任があります。 NEA ClientはNEA Clientの実行(例えば、他の仮想計算機ドメインの)のドメインの外で終点に存在するかもしれない実体の姿勢の上、または、ネットワークの上で報告するのに責任がありません。
For example, a network address translation (NAT) device might route communications for many systems behind it, but when the NAT device joins the network, its NEA Client would only report its own (local) posture. Similarly, endpoints with virtualization capabilities might have multiple independent domains of execution (e.g., OS instances). Each NEA Client is only responsible for reporting posture for its domain of execution, but this information might be aggregated by other local mechanisms to represent the posture for multiple domains on the endpoint. Such posture aggregation mechanisms are outside the focus of this specification.
例えば、ネットワークアドレス変換(NAT)デバイスはそれの後ろの多くのシステムのためのコミュニケーションを発送するかもしれませんが、NATデバイスがネットワークに加わるときだけ、NEA Clientはそれ自身の(地方)の姿勢を報告するでしょう。 同様に、仮想化能力がある終点には、実行(例えば、OSインスタンス)の複数の独立しているドメインがあるかもしれません。 それぞれのNEA Clientは単に実行のドメインに姿勢を報告するのに責任がありますが、この情報は他の局所機構によって集められて、終点の複数のドメインに姿勢を表すかもしれません。 この仕様の焦点の外にそのような姿勢凝集機構があります。
Endpoints lacking NEA Client software (which is out of NEA scope) or choosing not to provide the attributes required by the NEA Server could be considered non-compliant. The NEA model includes capabilities to enable the endpoint to update its contents in order to become compliant.
不従順であるとNEA Clientソフトウェア(NEA範囲の外にある)を欠いているか、またはNEA Serverによって必要とされた属性を提供しないのを選ぶ終点を考えることができました。 NEAモデルは言いなりになるようになるように終点がコンテンツをアップデートするのを可能にする能力を入れます。
5.1.1.1. Posture Collector
5.1.1.1. 姿勢コレクタ
The Posture Collector is responsible for responding to requests for posture information in Request Attributes from the NEA Server. The Posture Collector is also responsible for handling assessment decisions in Result Attributes and remediation instructions in Remediation Attributes. A single NEA Client can have several Posture Collectors capable of collecting standard and/or vendor-specific Posture Attributes for particular features of the endpoint. Typical
Posture CollectorはNEA ServerからRequest Attributesの姿勢情報に関する要求に応じるのに責任があります。また、Posture CollectorもResult Attributesでの取り扱い査定決定とRemediation Attributesでの治療教育指示に責任があります。 独身のNEA Clientは数個のPosture Collectorsを終点の特定の特徴において標準の、そして/または、ベンダー特有のPosture Attributesを集めることができるようにすることができます。 典型的
Sangster, et al. Informational [Page 12] RFC 5209 NEA Requirements June 2008
サングスタ、他 [12ページ]情報のRFC5209NEA要件2008年6月
examples include Posture Collectors that provide information about Operating System (OS) version and patch levels, anti-virus software, and security mechanisms on the endpoint such as host-based Intrusion Detection System (IDS) or firewall.
例は終点のホストベースのIntrusion Detection System(IDS)かファイアウォールなどのOperating System(OS)バージョンの情報、パッチレベル、ウイルス除去ソフト、およびセキュリティー対策を提供するPosture Collectorsを含んでいます。
Each Posture Collector will be associated with one or more identifiers that enable it to be specified as the destination in a PA message. The Posture Broker Client uses these identifiers to route messages to this Collector. An identifier might be dynamic (e.g., generated by the Posture Broker Client at run-time during registration) or more static (e.g., pre-assigned to the Posture Collector at install-time and passed to the Posture Broker Client during registration) or a function of the attribute messages the Collector desires to receive (e.g., message type for subscription).
それぞれのPosture CollectorはそれがPAメッセージの目的地として指定されるのを可能にする1つ以上の識別子に関連するでしょう。 Posture Broker Clientは、このCollectorにメッセージを発送するのにこれらの識別子を使用します。 識別子は、動力(例えば、登録の間のランタイムのときにPosture Broker Clientが生成される)、より多くの静電気(例えば、時間をインストールするところのPosture Collectorにあらかじめ割り当てられて、登録の間、Posture Broker Clientに通過される)またはCollectorが受け取ることを望んでいる属性メッセージの機能であるかもしれません(例えば、購読のためのメッセージタイプ)。
The NEA model allocates the following responsibilities to the Posture Collector:
NEAモデルは以下の責任をPosture Collectorに割り当てます:
o Consulting with local privacy and security policies that may
restrict what information is allowed to be disclosed to a given
NEA Server.
o 情報が与えられたNEA Serverに明らかにすることができることを制限するかもしれない地方のプライバシーと安全保障政策と相談します。
o Receiving Request Attributes from a Posture Validator and
performing the local processing required to respond
appropriately. This may include:
o Posture ValidatorからRequest Attributesを受けて、ローカル処理を実行するのが適切に応じるのが必要です。 これは以下を含むかもしれません。
- Collecting associated posture information for particular
features of the endpoint and returning this information in
Posture Attributes.
- 収集はPosture Attributesの終点とこの情報を返す特定の特徴のための姿勢情報を関連づけました。
- Caching and recognizing the applicability of recently issued
attributes containing reusable assertions that might serve to
prove compliance and returning this attribute instead of
posture information.
- 最近の適用性をキャッシュして、認識すると、コンプライアンスと帰りが姿勢情報の代わりにこの属性であると立証するのに役立つかもしれない再利用できる主張を含む属性が発行されました。
o Receiving attributes containing remediation instructions on how
to update functionality on the endpoint. This could require the
Collector to interact with the user, owner, and/or a remediation
server.
o どう終点に関する機能性をアップデートするかに関する治療教育指示を含む属性を受けます。 これは、Collectorがユーザ、所有者、そして/または、治療教育サーバと対話するのを必要とするかもしれません。
o Monitoring the posture of (a) particular features(s) on the
endpoint for posture changes that require notification to the
Posture Broker Client.
o (a)の姿勢をモニターして、姿勢がそれを変えるので、終点に関する特定の特徴はPosture Broker Clientに通知を必要とします。
o Providing cryptographic verification of the attributes received
from the Validator and offering cryptographic protection to the
attributes returned.
o Validatorから受けられて、暗号の保護を属性に提供しながら属性の暗号の検証を提供するのは戻りました。
Sangster, et al. Informational [Page 13] RFC 5209 NEA Requirements June 2008
サングスタ、他 [13ページ]情報のRFC5209NEA要件2008年6月
The above list describes the model's view of the possible responsibilities of the Posture Collector. Note that this is not a set of requirements for what each Posture Collector implementation must support, nor is it an exhaustive list of all the things a Posture Collector may do.
上記のリストはモデルのPosture Collectorの可能な責任の視点について説明します。 これがそれぞれのPosture Collector実装がサポートしなければならないことのための1セットの要件でないことに注意してください、そして、それはPosture Collectorがするかもしれないすべてのことに関する完全なりストではありません。
5.1.1.2. Posture Broker Client
5.1.1.2. 姿勢ブローカーのクライアント
The Posture Broker Client is both a PA message multiplexer and a de-multiplexer. The Posture Broker Client is responsible for de-multiplexing the PB message received from the NEA Server and distributing each encapsulated PA message to the corresponding Posture Collector(s). The model also allows for the posture information request to be pre-provisioned on the NEA Client to improve performance by allowing the NEA Client to report posture without receiving a request for particular attributes from the NEA Server.
Posture Broker ClientはPAメッセージ回線多重化装置とデマルチプレクサの両方です。 Posture Broker Clientは反-NEA Serverから受け取られたPBメッセージを多重送信して、それぞれのカプセル化されたPAメッセージを対応するPosture Collector(s)に分配するのに責任があります。 また、モデルはNEA ClientがNEA Serverから特定の属性を求める要求を受け取らないで姿勢を報告するのを許容するのによる性能を向上させるためにNEA Clientであらかじめ食糧を供給されるという姿勢情報要求を考慮します。
The Posture Broker Client also multiplexes the responses from the Posture Collector(s) and returns them to the NEA Server. The Posture Broker Client constructs one or more PB messages using the PA message(s) it obtains from the Posture Collector(s) involved in the assessment. The quantity and ordering of Posture Collector responses (PA message(s)) multiplexed into the PB response message(s) can be determined by the Posture Broker Client based on many factors including policy or characteristics of the underlying network transport (e.g., MTU). A particular NEA Client will have one Posture Broker Client.
Posture Broker Clientはまた、Posture Collector(s)から応答を多重送信して、それらをNEA Serverに返します。Posture Broker Clientは、それが査定にかかわるPosture Collector(s)から得るPAメッセージを使用することで1つ以上のPBメッセージを構成します。 Posture Collector応答の量と注文、(基本的なネットワーク輸送(例えば、MTU)の方針か特性を含む多くの要素に基づくPosture Broker ClientはPB応答メッセージに多重送信されたPAメッセージ(s))を決定できます。 特定のNEA Clientには、1Posture Broker Clientがあるでしょう。
The Posture Broker Client also handles the global assessment decision from the Posture Broker Server and may interact with the user to communicate the global assessment decision and aid in any necessary remediation steps.
Posture Broker Clientも、Posture Broker Serverからグローバルな査定決定を扱って、どんな必要な治療教育ステップでもグローバルな査定決定と援助を伝えるためにユーザと対話するかもしれません。
The NEA model allocates the following responsibilities to the Posture Broker Client:
NEAモデルは以下の責任をPosture Broker Clientに割り当てます:
o Maintaining a registry of known Posture Collectors and allowing
for Posture Collectors to dynamically register and deregister.
o 知られているPosture Collectorsの登録を維持して、ダイナミックに登録するPosture Collectorsと「反-レジスタ」を考慮します。
o Multiplexing and de-multiplexing attribute messages between the
NEA Server and the relevant Posture Collectors.
o NEA Serverと関連Posture Collectorsの間に属性メッセージを多重送信して、反-多重送信します。
o Handling posture change notifications from Posture Collectors
and triggering reassessment.
o Posture Collectorsからの姿勢変更届出書を扱って、再査定の引き金となります。
o Providing user notification about the global assessment decision
and other user messages sent by the NEA Server.
o グローバルな査定決定に関するユーザ通知とメッセージがNEA Serverで送った他のユーザを提供します。
Sangster, et al. Informational [Page 14] RFC 5209 NEA Requirements June 2008
サングスタ、他 [14ページ]情報のRFC5209NEA要件2008年6月
5.1.1.3. Posture Transport Client
5.1.1.3. 姿勢輸送クライアント
The Posture Transport Client is responsible for establishing a reliable communication channel with the NEA Server for the message dialog between the NEA Client and NEA Server. There might be more than one Posture Transport Client on a particular NEA Client supporting different transport protocols (e.g., 802.1X, VPN). Certain Posture Transport Clients may be configured with the address of the appropriate Posture Transport Server to use for a particular network.
Posture Transport ClientはNEA ClientとNEA Serverの間のメッセージ対話のためにNEA Serverと共に信頼できる通信チャネルを確立するのに責任があります。1Posture Transport Clientが異なったトランスポート・プロトコルが(例えば、802.1X、VPN)であるとサポートする特定のNEA Clientにあるかもしれません。 あるPosture Transport Clientsは特定のネットワークに使用する適切なPosture Transport Serverのアドレスによって構成されるかもしれません。
The NEA model allocates the following responsibilities to the Posture Transport Client:
NEAモデルは以下の責任をPosture Transport Clientに割り当てます:
o Initiating and maintaining the communication channel to the NEA
Server. The Posture Transport Client hides the details of the
underlying carrier that could be a Layer 2 or Layer 3 protocol.
o . NEA Serverへの通信チャネルがPosture Transport Clientであることを開始して、支持するのがLayer2かLayer3プロトコルであるかもしれない基本的なキャリヤーの細部を隠します。
o Providing cryptographic protection for the message dialog
between the NEA Client and NEA Server.
o NEA ClientとNEA Serverの間のメッセージ対話のための暗号の保護を提供します。
5.1.2. NEA Server
5.1.2. NEAサーバ
The NEA Server is typically comprised of the following NEA functionality:
NEA Serverは以下のNEAの機能性から通常成ります:
o Posture Validator(s)
o 姿勢Validator(s)
o Posture Broker Server
o 姿勢ブローカーサーバ
o Posture Transport Server(s)
o 姿勢輸送サーバ(s)
The Posture Validators might be located on a separate server from the Posture Broker Server, requiring the Posture Broker Server to deal with both local and remote Posture Validators.
Posture ValidatorsはPosture Broker Serverからの別々のサーバに位置するかもしれません、Posture Broker Serverが地方のものと同様にリモートなPosture Validatorsに対処するのが必要であることで。
5.1.2.1. Posture Validator
5.1.2.1. 姿勢Validator
A Posture Validator is responsible for handling Posture Attributes from corresponding Posture Collector(s). A Posture Validator can handle Posture Attributes from one or more Posture Collectors and vice-versa. The Posture Validator performs the posture assessment for one or more features of the endpoint (e.g., anti-virus software) and creates the result and, if necessary, the remediation instructions, or it may choose to request additional attributes from one or more Collectors.
Posture Validatorは対応するPosture Collector(s)からの取り扱いPosture Attributesに責任があります。 Posture Validatorは1Posture CollectorsからPosture Attributesを扱うことができます、そして、逆もまた同様です。 Posture Validatorが終点(例えば、ウイルス除去ソフト)の1つ以上の特徴のための姿勢査定を実行して、結果と必要なら治療教育指示を作成するか、またはそれは、1Collectorsから追加属性を要求するのを選ぶかもしれません。
Sangster, et al. Informational [Page 15] RFC 5209 NEA Requirements June 2008
サングスタ、他 [15ページ]情報のRFC5209NEA要件2008年6月
Each Posture Validator will be associated with one or more identifiers that enable it to be specified as the destination in a PA message. The Posture Broker Server uses this identifier to route messages to this Validator. This identifier might be dynamic (e.g., generated by the Posture Broker Server at run-time during registration) or more static (e.g., pre-assigned to a Posture Validator at install-time and passed to the Posture Broker Server during registration) or a function of the attribute messages the Validator desires to receive (e.g., message type for subscription).
それぞれのPosture ValidatorはそれがPAメッセージの目的地として指定されるのを可能にする1つ以上の識別子に関連するでしょう。 Posture Broker Serverは、このValidatorにメッセージを発送するのにこの識別子を使用します。 この識別子は、動力(例えば、登録の間のランタイムのときにPosture Broker Serverが生成される)、より多くの静電気(例えば、時間をインストールするところのPosture Validatorにあらかじめ割り当てられて、登録の間、Posture Broker Serverに通過される)またはValidatorが受け取ることを望んでいる属性メッセージの機能であるかもしれません(例えば、購読のためのメッセージタイプ)。
Posture Validators can be co-located on the NEA Server or can be hosted on separate servers. A particular NEA Server is likely to need to handle multiple Posture Validators.
姿勢ValidatorsをNEA Serverに共同位置できるか、または別々のサーバで接待できます。 特定のNEA Serverが複数のPosture Validatorsを扱うのが必要でありそうです。
The NEA model allocates the following responsibilities to the Posture Validator:
NEAモデルは以下の責任をPosture Validatorに割り当てます:
o Requesting attributes from a Posture Collector. The request may
include:
o Posture Collectorから属性を要求します。 要求は以下を含むかもしれません。
- Request Attributes that indicate to the Posture Collector to
fetch and provide Posture Attributes for particular
functionality on the endpoint.
- 終点に関する特定の機能性にPosture Attributesをとって来て、提供するようそれがPosture Collectorに示すAttributesに要求してください。
o Receiving attributes from the Posture Collector. The response
from the Posture Collector may include:
o Posture Collectorから属性を受けます。 Posture Collectorからの応答は以下を含むかもしれません。
- Posture Attributes collected for the requested functionality.
- 姿勢Attributesは要求された機能性の寄付を募りました。
- Assertion Attributes that indicate the compliance result from
a prior assessment.
- コンプライアンスを示す主張Attributesが先の査定から生じます。
o Assessing the posture of endpoint features based on the
attributes received from the Collector.
o 属性に基づく終点の特徴の姿勢を評価するのはCollectorから受信されました。
o Communicating the posture assessment result to the Posture
Broker Server.
o 姿勢査定結果をPosture Broker Serverに伝えます。
o Communicating the posture assessment results to the Posture
Collector; this attribute message may include:
o 姿勢査定結果をPosture Collectorに伝えます。 この属性メッセージは以下を含むかもしれません。
- Result Attributes that communicate the posture assessment
result.
- Remediation Attributes that communicate the remediation
instructions to the Posture Collector.
- 姿勢査定結果を伝える結果Attributes。 - 治療教育指示をPosture Collectorに伝える治療教育Attributes。
o Monitoring out-of-band updates that trigger reassessment and
require notifications to be sent to the Posture Broker Server.
o バンドの外では、再査定の引き金となって、通知がPosture Broker Serverに送られるのを必要とするアップデートをモニターします。
Sangster, et al. Informational [Page 16] RFC 5209 NEA Requirements June 2008
サングスタ、他 [16ページ]情報のRFC5209NEA要件2008年6月
o Providing cryptographic protection for attributes sent to the
Posture Collector and offering cryptographic verification of the
attributes received from the Posture Collector.
o Posture Collectorに送られて、属性の暗号の検証を提供しながら属性のための暗号の保護を提供するのはPosture Collectorから受信されました。
The above list describes the model's view of the possible responsibilities of the Posture Validator. Note that this is not a set of requirements for what each Posture Validator implementation must support, nor is it an exhaustive list of all the things a Posture Validator may do.
上記のリストはモデルのPosture Validatorの可能な責任の視点について説明します。 これがそれぞれのPosture Validator実装がサポートしなければならないことのための1セットの要件でないことに注意してください、そして、それはPosture Validatorがするかもしれないすべてのことに関する完全なりストではありません。
5.1.2.2. Posture Broker Server
5.1.2.2. 姿勢ブローカーサーバ
The Posture Broker Server acts as a multiplexer and a de-multiplexer for attribute messages. The Posture Broker Server parses the PB messages received from the NEA Client and de-multiplexes them into PA messages that it passes to the associated Posture Validators. The Posture Broker Server multiplexes the PA messages (e.g., messages containing (a) Request Attribute(s) from the relevant Posture Validator(s)) into one or more PB messages and sends them to the NEA Client via the Posture Transport protocol. The quantity and ordering of Posture Validator responses (PA messages) and global assessment decision multiplexed into the PB response message(s) can be determined by the Posture Broker Server based on many factors including policy or characteristics of the underlying network transport (e.g., MTU).
Posture Broker Serverは属性メッセージのために回線多重化装置とデマルチプレクサとして機能します。 Posture Broker ServerはNEA Clientから受け取られたPBメッセージを分析して、反-関連Posture Validatorsに通るというPAメッセージにそれらを多重送信します。 Posture Broker ServerはPAメッセージを多重送信します。((a)を含んでいると、Posture Transportを通して関連Posture Validator(s))から1つ以上のPBメッセージにAttribute(s)を要求して、それらをNEA Clientに送るという例えばメッセージは議定書を作ります。 基本的なネットワーク輸送(例えば、MTU)の方針か特性を含む多くの要素に基づくPosture Broker ServerはPosture Validator応答(PAメッセージ)とPB応答メッセージに多重送信されたグローバルな査定決定の量と注文を測定できます。
The Posture Broker Server is also responsible for computing the global assessment decision based on individual posture assessment results from the various Posture Validators. This global assessment decision is sent back to the NEA Client in Result Attributes within a PB message. A particular NEA Server will have one Posture Broker Server, and this Posture Broker Server will handle all the local and remote Posture Validators.
また、Posture Broker Serverも様々なPosture Validatorsから個々の姿勢査定結果に基づくグローバルな査定決定を計算するのに責任があります。 PBメッセージの中のResult AttributesのNEA Clientはこのグローバルな査定決定に送り返されます。 特定のNEA Serverには1Posture Broker Serverがあるでしょう、そして、このPosture Broker Serverはすべての地方の、そして、リモートなPosture Validatorsを扱うでしょう。
The NEA model allocates the following responsibilities to the Posture Broker Server:
NEAモデルは以下の責任をPosture Broker Serverに割り当てます:
o Maintaining a registry of Posture Validators and allowing for
Posture Validators to register and deregister.
o Posture Validatorsの登録を維持して、登録するPosture Validatorsと「反-レジスタ」を考慮します。
o Multiplexing and de-multiplexing posture messages from and to
the relevant Posture Validators.
o Posture Validatorsと、そして、関連Posture Validatorsに姿勢メッセージを多重送信して、反-多重送信します。
o Computing the global assessment decision based on posture
assessment results from the various Posture Validators and
compliance policy. This assessment decision is sent to the
Posture Broker Client in a PB message.
o グローバルな査定決定を計算すると、査定結果は様々なPosture Validatorsと承諾方針から姿勢に基づきました。 この査定決定をPBメッセージのPosture Broker Clientに送ります。
Sangster, et al. Informational [Page 17] RFC 5209 NEA Requirements June 2008
サングスタ、他 [17ページ]情報のRFC5209NEA要件2008年6月
5.1.2.3. Posture Transport Server
5.1.2.3. 姿勢輸送サーバ
The Posture Transport Server is responsible for establishing a reliable communication channel with the NEA Client for the message dialog between the NEA Client and NEA Server. There might be more than one Posture Transport Server on a particular NEA Server to support different transport protocols. A particular Posture Transport Server will typically handle requests from several Posture Transport Clients and may require local configuration describing how to reach the NEA Clients.
Posture Transport ServerはNEA ClientとNEA Serverの間のメッセージ対話のためにNEA Clientと共に信頼できる通信チャネルを確立するのに責任があります。1Posture Transport Serverが異なった輸送がプロトコルであるとサポートする特定のNEA Serverにあるかもしれません。 特定のPosture Transport Serverは数個のPosture Transport Clientsからの要求を通常扱って、NEA Clientsに達する方法を説明する地方の構成を必要とするかもしれません。
The NEA model allocates the following responsibilities to the Posture Transport Server:
NEAモデルは以下の責任をPosture Transport Serverに割り当てます:
o Initiating and maintaining a communication channel with,
potentially, several NEA Clients.
o 潜在的に数個のNEA Clientsがある通信チャネルに着手して、維持します。
o Providing cryptographic protection for the message dialog
between the NEA Client and NEA Server.
o NEA ClientとNEA Serverの間のメッセージ対話のための暗号の保護を提供します。
5.2. Protocols
5.2. プロトコル
The NEA reference model includes three layered protocols (PA, PB, and PT) that allow for the exchange of attributes across the network. While these protocols are intended to be used together to fulfill a particular role in the model, they may offer overlapping functionality. For example, each protocol should be capable of protecting its information from attack (see section 8.2 for more information).
NEA規範モデルインクルードthreeはネットワークの向こう側に属性の交換を考慮するプロトコル(PA、PB、およびPT)を層にしました。 モデルにおける特定の役割を実現させるのにこれらのプロトコルによって一緒に使用されることを意図している間、それらは重なっている機能性を提供するかもしれません。 例えば、それぞれのプロトコルは攻撃から情報を保護できるべきです(詳しい情報に関してセクション8.2を見てください)。
5.2.1. Posture Attribute Protocol (PA)
5.2.1. 姿勢属性プロトコル(PA)
PA is a protocol that carries one or more attributes between Posture Collectors and their associated Posture Validator. The PA protocol is a message-oriented lightweight wrapper around a set of attributes being exchanged. This wrapper may indicate the purpose of attributes within the message. Some of the types of messages expected include: requests for posture information (Request Attributes), posture information about the endpoint (Posture Attributes), results of an assessment (Result Attributes), reusable compliance assertions (Assertion Attributes), and instructions to remediate non-compliant portions of the endpoint (Remediation Attributes). The PA protocol also provides the requisite encoding and cryptographic protection for the Posture Attributes.
PAはPosture Collectorsと彼らの関連Posture Validatorの間の1つ以上の属性を運ぶプロトコルです。 PAプロトコルは交換される属性のセットの周りのメッセージ指向の軽量のラッパーです。 このラッパーはメッセージの中に属性の目的を示すかもしれません。 予想されたメッセージの何人かのタイプは: 姿勢情報(Attributesを要求する)、終点の姿勢情報(姿勢Attributes)、査定の結果(結果Attributes)、再利用できる承諾主張(主張Attributes)、および終点のremediateの不従順な部分への指示(治療教育Attributes)を求める要求。 また、PAプロトコルは必要なコード化していて暗号の保護をPosture Attributesに供給します。
Sangster, et al. Informational [Page 18] RFC 5209 NEA Requirements June 2008
サングスタ、他 [18ページ]情報のRFC5209NEA要件2008年6月
5.2.2. Posture Broker Protocol (PB)
5.2.2. 姿勢ブローカープロトコル(Pb)
PB is a protocol that carries aggregate attribute messages between the Posture Collectors on the NEA Client and the corresponding Posture Validators on the NEA Server involved in a particular assessment. The PB protocol provides a session allowing for message dialogs for every assessment. This PB session is then used to bind multiple Posture Attribute requests and responses from the different Posture Collectors and Posture Validators involved in a particular assessment. The PB protocol may also carry the global assessment decision in the Result Attribute from the Posture Broker Server to the Posture Broker Client. PB may be used to carry additional types of messages for use by the Posture Broker Client and Server (e.g., information about user preferred interface settings such as language).
PBは特定の査定にかかわるNEA Serverの上のNEA Clientの上のPosture Collectorsと対応するPosture Validatorsに集合属性メッセージを伝えるプロトコルです。 PBプロトコルはメッセージ対話のためのセッション許容をあらゆる査定に提供します。 そして、このPBセッションは、特定の査定にかかわる異なったPosture CollectorsとPosture Validatorsから複数のPosture Attribute要求と応答を縛るのに使用されます。 また、PBプロトコルはPosture Broker ServerからPosture Broker ClientまでResult Attributeでのグローバルな査定決定を運ぶかもしれません。 PBは、Posture Broker ClientとServer(例えば、言語などのユーザ都合のよいインタフェース設定の情報)による使用への追加タイプに関するメッセージを伝えるのに使用されるかもしれません。
5.2.3. Posture Transport Protocol (PT)
5.2.3. 姿勢トランスポート・プロトコル(太平洋標準時)です。
PT is a transport protocol between the NEA Client and the NEA Server responsible for carrying the messages generated by the PB protocol. The PT protocol(s) transport(s) PB messages during the network connection request or after network connectivity has been established.
太平洋標準時は、PBプロトコルによって生成されたメッセージを伝えるのに責任があるNEA ClientとNEA Serverの間のトランスポート・プロトコルです。 ネットワーク接続要求かネットワークの接続性が確立された後に太平洋標準時は(s) 輸送PBメッセージについて議定書の中で述べます。
In scenarios where an initial assessment needs to occur during the network connection, the PT protocol (e.g., EAP within 802.1X) may have constrained use of the network, so deployments may choose to limit the amount and/or size of the attributes exchanged. The NEA Client and NEA Server should be able to detect when a potentially constrained situation exists prior to the assessment based upon properties of the underlying network protocol. Using this information, NEA policy could dictate what aspects of the endpoint to include in the initial assessment and potentially limit the PA message attributes exchanged. This could be followed up by a full reassessment after the endpoint is placed on the network. Alternatively, deployments can choose not to limit their assessment by configuring their network access technology to temporarily grant restricted IP connectivity prior to the assessment and use an unconstrained, high bandwidth IP-based transport during the assessment. Some of the constraints that may exist for protocols involved in the network connection phase include:
初期評価がネットワーク接続の間、起こる必要があるシナリオでは、太平洋標準時のプロトコル(例えば、802.1Xの中のEAP)がネットワークの使用を抑制したかもしれないので、展開は属性の量、そして/または、サイズが交換した限界に選ばれるかもしれません。 NEA ClientとNEA Serverは、潜在的に強制的な状況が基本的なネットワーク・プロトコルの特性に基づく査定の前にいつ存在するかを検出するはずであることができます。 この情報を使用して、NEA方針は、初期評価と潜在的にPAメッセージ属性が交換した限界に終点のどんな局面を含んだらよいかを決めるかもしれません。 終点がネットワークに置かれた後に完全な再査定はこれを追求できました。 あるいはまた、展開が、査定と使用の前に一時制限されたIPの接続性を与えるそれらのネットワークアクセス技術を構成することによって彼らの査定を制限しないのを選ぶことができる、自由である、査定の間の高帯域のIPベースの輸送。 ネットワーク接続フェーズにかかわるプロトコルのために存在するかもしれない規制のいくつかは:
o Limited maximum transmission unit (MTU) size and ability to
negotiate larger MTUs,
o 株式会社マキシマム・トランスミッション・ユニット(MTU)サイズと、より大きいMTUsを交渉する能力
o Inability to perform multiple roundtrips,
o 複数の往復旅行を実行できないこと
o Lack of support for piggybacking attributes for other protocols,
o 他のプロトコルのために属性を背負うサポートの不足
Sangster, et al. Informational [Page 19] RFC 5209 NEA Requirements June 2008
サングスタ、他 [19ページ]情報のRFC5209NEA要件2008年6月
o Low bandwidth or high latency limitations precluding exchanges
of large amounts of data,
o 多量のデータの交換を排除する低い帯域幅か高い潜在制限
o Inability of servers to initiate messages except during the
network connection phase.
o ネットワーク接続フェーズ以外に、サーバがメッセージを開始できないこと。
The PT protocol selection process needs to consider the impact of selecting a particular PT and set of underlying protocols on the deployment needs of PA and PB. PA and PB will be selected prior to PT so the needs of PA and PB will be known. Certain underlying protocol stacks may be too constrained to support adequate NEA assessments during network connection.
PTプロトコル選択プロセスは、PAとPBの展開の必要性で特定のPTと1セットの基本的なプロトコルを選択する影響を考える必要があります。 PAとPBが太平洋標準時以前選択されるので、PAとPBの必要性は知られているでしょう。 ある基本的なプロトコル・スタックはネットワーク接続の間、適切なNEA査定をサポートすることができないくらい強制的であるかもしれません。
The PT protocol provides reliable message delivery, mutual authentication, and cryptographic protection for the PB messages as specified by local policy.
PTプロトコルは指定されるとしてのローカルの方針によるPBメッセージのための信頼できるメッセージ配送、互いの認証、および暗号の保護を提供します。
5.3. Attributes
5.3. 属性
The PA protocol is responsible for the exchange of attributes between a Posture Collector and Posture Validator. The PB protocol may also carry the global assessment decision attributes from the Posture Broker Server. Attributes are effectively the reserved word 'nouns' of the posture assessment. The NEA Server is only able to ask for information that has a corresponding attribute, thus bounding what type of posture can be obtained. The NEA WG will define a common (standard) set of attributes that are expected to be widely applicable to Posture Collectors and thus used for maximum interoperability, but Posture Collectors may support additional vendor-specific attributes when necessary.
PAプロトコルはPosture CollectorとPosture Validatorの間の属性の交換に原因となります。 また、PBプロトコルはPosture Broker Serverからグローバルな査定決定属性を運ぶかもしれません。事実上、属性は姿勢査定のリザーブドワード'名詞'です。 NEA Serverは、対応する属性を持っている、その結果、バウンドしている情報のためにどんなタイプの姿勢を得ることができるかを尋ねることができるだけです。 NEA WGはPosture Collectorsに広く適切であると予想されて、最大限のインターオペラビリティにこのようにして使用される一般的な(標準の)セットの属性を定義するでしょうが、必要であるときに、Posture Collectorsは追加ベンダー特有の属性をサポートするかもしれません。
Depending on the deployment scenario, the purpose of the attributes exchanged may be different (e.g., posture information vs. asserted compliance). This section discusses the originator and expected situation resulting in the use of each classification of attributes in a PA message. These classifications are not intended to dictate how the NEA WG will specify the attributes when defining the attribute namespace or schema.
展開シナリオによって、交換された属性の目的は異なっているかもしれません(例えば、姿勢情報対断言された承諾)。 このセクションはPAメッセージにおける、属性の各分類の使用をもたらす創始者と予想された状況について論じます。 これらの分類が属性名前空間か図式を定義するとき、NEA WGがどう属性を指定するかを書き取ることを意図しません。
Sangster, et al. Informational [Page 20] RFC 5209 NEA Requirements June 2008
サングスタ、他 [20ページ]情報のRFC5209NEA要件2008年6月
5.3.1. Attributes Normally Sent by NEA Client:
5.3.1. 通常、属性はNEAクライアントで送りました:
o Posture Attributes - Attributes and values sent to report
information about a particular aspect (based on semantic of the
attribute) of the system. These attributes are typically sent
in response to Request Attributes from the NEA Server. For
example, a set of Posture Attributes might describe the status
of the host-based firewall (e.g., if running, vendor, version).
The NEA Server would base its decision on comparing this type of
attribute against policy.
o 姿勢Attributes--属性と値は、システムの特定の局面(属性における意味に基づいた)の情報を報告するために発信しました。 NEA ServerからのRequest Attributesに対応してこれらの属性を通常送ります。例えば、Posture Attributesの1セットは、ホストベースのファイアウォールの状態について説明するかもしれません(例えば、稼働、ベンダー、バージョンであるなら)。 NEA Serverは決定を方針に対してこのタイプの属性をたとえるのに基礎づけるでしょう。
o Assertion Attributes - Attributes stating recent prior
compliance to policy in hopes of avoiding the need to recollect
the posture and send it to the NEA Server. Examples of
assertions include (a) NEA Server provided attributes (state)
describing a prior evaluation (e.g., opaque to endpoint, signed,
time stamped items stating specific results) or (b) NEA Client
identity information used by the NEA Server to locate state
about prior decisions (e.g., system-bound cookie). These might
be returned in lieu of, or in addition to, Posture Attributes.
o 最近の先のコンプライアンスを方針に述べる属性が、必要がないという望みで姿勢を思い出して、それをNEA Serverに送ります。主張Attributes--主張に関する例は(a) 事前評価について説明する属性(状態)に提供されたNEA Server(例えば、時間の押し込まれた項目が特定の結果を述べて、署名される終点への不透明なもの)か(b) 先の決定に関して状態の場所を見つけるのにNEA Serverによって使用されたNEA Clientアイデンティティ情報(例えば、システム行きのクッキー)を含んでいます。 Posture AttributesかPosture Attributesでこれらを返すかもしれません。
5.3.2. Attributes Normally Sent by NEA Server:
5.3.2. 通常、属性はNEAサーバで送りました:
o Request Attributes - Attributes that define the specific posture
information desired by the NEA Server. These attributes might
effectively form a template that the Posture Collector fills in
(subject to local policy restrictions) with the specific value
corresponding to each attribute. The resulting attributes are
typically Posture or Assertion Attributes from the NEA Client.
o Attributesを要求してください--NEA Serverによって望まれていた特定の姿勢情報を定義する属性。事実上、これらの属性は各属性に対応する特定の値でPosture Collectorが記入するテンプレート(ローカルの方針制限を条件とした)を形成するかもしれません。 結果として起こる属性は、NEA Clientからの通常PostureかAssertion Attributesです。
o Result Attributes - Attributes that contain the decisions of the
Posture Validators and/or Posture Broker Server. The level of
detail provided may vary from which individual attributes were
compliant or not through just the global assessment decision.
o 結果Attributes--Posture Broker Server Posture Validatorsの決定、そして/または、明らかにされる詳細のレベルを含む属性はどの個々の属性が対応であったか、そして、グローバルなまさしく査定決定で異なるかもしれません。
o Remediation Attributes - Attributes that explain to the NEA
Client and its user how to update the endpoint to become
compliant with the NEA Server policies. These attributes are
sent when the global assessment decision was that the endpoint
is not currently compliant. Remediation and Result Attributes
may both exist within a NEA Server attribute message.
o 治療教育Attributes--NEA Server方針で言いなりになるようになるように終点をアップデートする方法がNEA Clientとそのユーザにわかる属性。 グローバルな査定決定が終点が現在言いなりにならないということであったときに、これらの属性を送ります。 治療教育とResult AttributesはNEA Server属性メッセージの中にともに存在するかもしれません。
o Assertion Attributes - Attributes containing NEA Server
assertions of compliance to a policy for future use by the NEA
Client. See section 5.3.1 for more information.
o 主張Attributes--NEA Clientによる今後の使用のために方針に承諾のNEA Server主張を含む属性。 詳しい情報に関してセクション5.3.1を見てください。
Sangster, et al. Informational [Page 21] RFC 5209 NEA Requirements June 2008
サングスタ、他 [21ページ]情報のRFC5209NEA要件2008年6月
6. Use Cases
6. ケースを使用してください。
This section discusses several of the NEA use cases with intent to describe and collectively bound the NEA problem space under consideration. The use cases provide a context and general rationale for the defined requirements. In order to ease understanding of each use case and how it maps to the reference model, each use case will be accompanied by a simple example and a discussion of how this example relates to the NEA protocols. It should be emphasized that the provided examples are not intended to indicate the only approach to addressing the use case but rather are included to ease understanding of how the flows might occur and impact the NEA protocols.
このセクションは、使用が説明する意図をもってケースに入れるNEAの数個について論じて、考慮の下のNEA問題スペースをまとめて縛りました。 ケースが定義された要件のための文脈と一般的な原理を提供する使用。 それぞれの使用の理解を緩和するために、この例がどうNEAプロトコルに関連するかに関する簡単な例と議論で際とそれがどう規範モデル、各使用にケースを写像するかは伴われるでしょう。 提供された例が使用がケースであると扱うことへの唯一のアプローチを示すことを意図しませんが、流れがどう起こるかもしれないかに関する理解を緩和して、NEAプロトコルに影響を与えるためにむしろ含まれていると強調されるべきです。
We broadly classify the use cases into two categories, each with its own set of trigger events:
私たちは2つのカテゴリにケースを使用して、それ自身のものでそれぞれ引き金のイベントをセットしているのを露骨に分類します:
o Initial assessment - evaluation of the posture of an endpoint
that has not recently been assessed and thus is not in
possession of any valid proof that it should be considered
compliant. This evaluation might be triggered by a request to
join a network, a request to use a service, or a desire to
understand the posture of a system.
o 査定に頭文字をつけてください--最近、評価されていなくて、またその結果それが言いなりになると考えられるべきであるというどんな有効な証拠の所有物にもない終点の姿勢の評価。 ネットワークに加わるという要求でこの評価は引き起こされるかもしれません、サービス、またはシステムの姿勢を理解する願望を利用するという要求。
o Reassessment - evaluation of the posture of an endpoint that has
previously been assessed. This evaluation could occur for a
variety of reasons including the NEA Client or Server
recognizing an occurrence affecting the endpoint that might
raise the endpoint's risk level. This could be as simple as it
having been a long time since the endpoint's prior reassessment.
o Reassessment--以前に評価された終点の姿勢の評価。 この評価は終点の危険水準を上げるかもしれない終点に影響する発生を認識するNEA ClientかServerを含むさまざまな理由で起こることができました。 これは長い間、終点の先の再査定以来あるのにおいてそれと同じくらい簡単であるかもしれません。
6.1. Initial Assessment
6.1. 初期評価
An initial assessment occurs when a NEA Client or Server event occurs that causes the evaluation of the posture of the endpoint for the first time. Endpoints do not qualify for this category of use case if they have been recently assessed and the NEA Client or Server has maintained state (or proof) that the endpoint is compliant and therefore does not need to have its posture evaluated again.
初めて終点の姿勢の評価を引き起こすNEA ClientかServerイベントが現れると、初期評価は起こります。 それらが最近、評価されて、NEA ClientかServerが、終点で言いなりになって、したがって、再び姿勢を評価する必要はないと述べる(または、証拠)ように主張したなら、終点は使用のこのカテゴリのケースに資格を与えません。
6.1.1. Triggered by Network Connection or Service Request
6.1.1. ネットワーク接続かサービスのリクエストで、引き起こされます。
This use case focuses on assessments performed at the time an endpoint attempts to join a network or request use of a service that requires a posture evaluation. This use case is particularly interesting because it allows the NEA Server to evaluate the posture of an endpoint before allowing it access to the network or service.
これは、終点が、ネットワークに加わるのを試みるとき実行された査定のときにケース焦点を使用するか、または姿勢評価を必要とするサービスの使用を要求します。 ネットワークかサービスへのアクセスをそれに許す前に、NEA Serverを許容するのでケースが特におもしろいこの使用は終点の姿勢を評価します。
Sangster, et al. Informational [Page 22] RFC 5209 NEA Requirements June 2008
サングスタ、他 [22ページ]情報のRFC5209NEA要件2008年6月
This approach could be used to help detect endpoints with known vulnerabilities and facilitate their repair before they are admitted to the network and potentially exposed to threats on the network.
それらがネットワークに認められて、ネットワークで潜在的に脅威に暴露される前に、知られている脆弱性がある終点を検出するのを助けて、彼らの修理を容易にするのにこのアプローチを使用できました。
A variety of types of endpoint actions could result in this class of assessment. For example, an assessment could be triggered by the endpoint trying to access a highly protected network service (e.g., financial or HR application server) where heightened security checking is required. A better known example could include requesting entrance to a network that requires systems to meet compliance policy. This example is discussed in more detail in the following section.
さまざまなタイプの終点動作はこのクラスの査定をもたらすかもしれません。 例えば、高められたセキュリティー検査が必要である非常に保護されたネットワーク・サービス(例えば、財政的であるかHRアプリケーション・サーバー)にアクセスしようとする終点は査定を引き起こすことができました。 よりよく知られている例は、承諾方針を満たすためにシステムを必要とするネットワークに入り口を要求するのを含むかもしれません。 さらに詳細に以下のセクションでこの例について議論します。
6.1.1.1. Example
6.1.1.1. 例
An IT employee returning from vacation boots his office desktop computer that generates a request to join the wired enterprise network. The network's security policy requires the system to provide posture information in order to determine whether the desktop's security features are enabled and up to date. The desktop sends its patch, firewall, and anti-virus posture information. The NEA Server determines that the system is lacking a recent security patch designed to fix a serious vulnerability and the system is placed on a restricted access network. The desktop follows the provided remediation instructions to download and install the necessary patch. Later, the desktop requests again to join the network and this time is provided full access to the enterprise network after a full assessment.
休暇から戻るIT従業員はワイヤードな企業網に加わるという要求を生成する彼のオフィスデスクトップコンピュータをブートします。 ネットワークの安全保障政策は、デスクトップのセキュリティ機能が可能にされて最新であるかどうか決定するために姿勢情報を提供するためにシステムを必要とします。 デスクトップはパッチ、ファイアウォール、およびアンチウイルスに姿勢情報を送ります。 NEA Serverは、システムが重大な脆弱性を修理するように設計された最近のセキュリティー・パッチを欠いていることを決定します、そして、システムは制限されたアクセスネットワークに関して課されます。 デスクトップは、必要なパッチをダウンロードして、インストールするために提供された治療教育指示に従います。 その後、デスクトップは、再び企業網への完全なアクセスが完全な査定の後にネットワークとこの時間に加わるのに提供されるよう要求します。
6.1.1.2. Possible Flows and Protocol Usage
6.1.1.2. 可能な流れとプロトコル用法
The following describes typical message flows through the NEA reference model for this example use case:
以下はこの例の使用のためのNEA規範モデルを通した流れがケースに入れる典型的なメッセージについて説明します:
1. The IT employee's desktop computer connects to the network
through an access gateway in the wired enterprise network.
1. IT従業員のデスクトップコンピュータはワイヤードな企業網におけるアクセスゲートウェイを通してネットワークに接続します。
2. The Posture Broker Server on the NEA Server is instructed to
assess the endpoint joining the wired network.
2. NEA Serverの上のPosture Broker Serverが有線ネットワークに加わる終点を評価するよう命令されます。
3. Based upon compliance policy, the Posture Broker Server
contacts the operating system patch, host-based firewall, and
anti-virus Posture Validators to request the necessary posture.
Each Posture Validator creates a PA message containing the
desired attributes to be requested for assessment from the
desktop system.
3. 承諾方針に基づいて、Posture Broker Serverは、必要な姿勢を要求するためにオペレーティングシステムパッチ、ホストベースのファイアウォール、およびアンチウイルスPosture Validatorsに連絡します。 各Posture Validatorは、査定のためにデスクトップ型から要求されるために必要な属性を含むPAメッセージを作成します。
Sangster, et al. Informational [Page 23] RFC 5209 NEA Requirements June 2008
サングスタ、他 [23ページ]情報のRFC5209NEA要件2008年6月
4. The Posture Broker Server aggregates the PA messages from the
Posture Validators into a PB message. The Posture Broker
Server passes the PB message to the Posture Transport Server
that uses the PT protocol to send the PB message to the NEA
Client on the desktop computer.
4. Posture Broker ServerはPBメッセージへのPosture ValidatorsからのPAメッセージに集めます。 Posture Broker Serverは、デスクトップコンピュータの上のNEA ClientにPBメッセージを送るために、それが使用するPosture Transport Serverに、太平洋標準時が議定書を作るというPBメッセージを通過します。
5. The Posture Transport Client receives the message from the NEA
Server and passes it to the Posture Broker Client for message
delivery.
5. Posture Transport ClientはNEA Serverからメッセージを受け取って、メッセージ配送のためにPosture Broker Clientにそれを移ります。
6. The Posture Broker Client de-multiplexes the PB message and
delivers the PA messages with the requests for attributes to
the firewall, operating system patch, and anti-virus Posture
Collectors.
6. Posture Broker Clientはファイアウォール、オペレーティングシステムパッチ、およびアンチウイルスPosture Collectorsに反-PBメッセージを多重送信して、属性を求める要求でPAメッセージを提供します。
7. Each Posture Collector involved consults local privacy policy
to determine what information is allowed to be disclosed and
then returns the requested attributes that are authorized in a
PA message to the Posture Broker Client.
7. Posture Collectorがかかわったそれぞれが、どんな情報が明らかにすることができるかを決定するために地方のプライバシーに関する方針に相談して、次に、PAメッセージでPosture Broker Clientに認可される要求された属性を返します。
8. The Posture Broker Client aggregates these PA messages into a
single PB message and sends it to the Posture Broker Server
using the Posture Transport Client to Server session.
8. Posture Broker Clientは、ただ一つのPBメッセージへのこれらのPAメッセージに集めて、ServerセッションまでPosture Transport Clientを使用することでそれをPosture Broker Serverに送ります。
9. The Posture Transport Server provides the PB message to the
Posture Broker Server that de-multiplexes the message and sends
the appropriate attributes to the corresponding Posture
Validator.
9. Posture Transport Serverは反-メッセージを多重送信するPosture Broker ServerにPBメッセージを供給して、適切な属性を対応するPosture Validatorに送ります。
10. Each Posture Validator compares the values of the attributes it
receives with the expected values defined in its policy.
10. 各Posture Validatorは期待値が方針で定義されている状態でそれが受ける属性の値を比較します。
11. The anti-virus and firewall Posture Validators return
attributes to the Posture Broker Server stating the desktop
computer is compliant, but the operating system patch Posture
Validator returns non-compliant. The operating system patch
Posture Validator creates a PA message that contains attributes
with remediation instructions in addition to the attribute
indicating non-compliance result.
11. アンチウイルスとファイアウォールPosture Validatorsはデスクトップコンピュータが言いなりになると述べるPosture Broker Serverに属性を返しますが、オペレーティングシステムパッチPosture Validatorは不従順な状態で戻ります。 オペレーティングシステムパッチPosture Validatorは属性に加えた治療教育指示が不承諾結果を示している属性を含むPAメッセージを作成します。
12. The Posture Broker Server aggregates the PA messages and sends
them in a PB message to the Posture Broker Client via the
Posture Transport Server and Posture Transport Client.
12. Posture Broker ServerはPosture Transport ServerとPosture Transport Clientを通してPosture Broker ClientにPAメッセージに集めて、PBメッセージでそれらを送ります。
Sangster, et al. Informational [Page 24] RFC 5209 NEA Requirements June 2008
サングスタ、他 [24ページ]情報のRFC5209NEA要件2008年6月
13. The Posture Broker Client delivers the PA messages with the
results from the various Posture Validators to the Posture
Collectors including the PA message containing attributes with
remediation instructions to the operating system patch Posture
Collector. This Posture Collector then interacts with the user
to download and install the needed patches, potentially while
the endpoint remains quarantined.
13. Posture Broker Clientは治療教育指示で様々なPosture ValidatorsからPosture Collectorsまでの結果が属性を含むPAメッセージを含んでいるPAメッセージをオペレーティングシステムパッチPosture Collectorに提供します。 次に、このPosture Collectorは必要なパッチをダウンロードして、インストールするためにユーザと対話して、潜在的に、残りは終点である間、検疫しました。
14. Upon completion of the remediation, the above steps 1-10 are
repeated (triggered by the NEA Client repeating its request to
join the network).
14. 治療教育の完成のときに、上のステップ1-10は繰り返されます(ネットワークに加わるという要求を繰り返して言うNEA Clientによって引き起こされます)。
15. This time each involved Posture Validator (including the
operating system patch Posture Validator) returns a compliant
status and the Posture Broker Server returns a compliant result
indicating a global success.
15. 今回、それぞれのかかわったPosture Validator(オペレーティングシステムパッチPosture Validatorを含んでいる)は対応する状態を返します、そして、Posture Broker Serverはグローバルな成功を示す対応する結果を返します。
16. The Posture Broker Client receives the compliant result and the
IT employee's desktop is now on the network.
16. Posture Broker Clientは対応する結果を受けます、そして、IT従業員のデスクトップが現在、ネットワークにあります。
6.1.1.3. Impact on Requirements
6.1.1.3. 要件で影響を与えてください。
The following are several different aspects of the use case example that potentially need to be factored into the requirements.
以下による使用のいくつかの異なった局面が潜在的に要件が要因として考慮される必要がある例をケースに入れるということです。
o Posture assessment before endpoint allowed on network
o ネットワークに許容された終点の前の姿勢査定
o Endpoint sends attributes containing posture information
o 終点は姿勢情報を含む属性を送ります。
o NEA Server sends remediation instructions
o NEA Serverは治療教育指示を送ります。
o NEA Client causes a reassessment after remediation
o NEA Clientは治療教育の後に再査定を引き起こします。
6.1.2. Triggered by Endpoint
6.1.2. 終点で、引き起こされます。
This use case highlights that an endpoint (possibly at the request of a user) may wish to trigger an assessment of its posture to determine whether its security protective mechanisms are running and up to date.
これは終点(ことによるとユーザの依頼で)がセキュリティの保護的なメカニズムが実行していて最新であるかどうか決定するために姿勢の査定の引き金となりたがっているかもしれないケースハイライトを使用します。
6.1.2.1. Example
6.1.2.1. 例
A student goes to the terminal room to work on a project. The terminal room contains shared systems owned by the school that are on the network. These systems have been previously used by other students so their security posture is unknown. The student wishes to check whether a system is currently in compliance with the school's security policies prior to doing work, so she requests a posture
学生はプロジェクトに取り組む端末の部屋に行きます。 端末の部屋はネットワークにある学校によって所有されていた共有システムを含んでいます。 これらのシステムが以前に他の学生によって使用されたので、彼らの警戒姿勢は未知です。 現在、システムがする前の学校の安全保障政策に従ってあるかをチェックするという学生願望が働いているので、彼女は姿勢を要求します。
Sangster, et al. Informational [Page 25] RFC 5209 NEA Requirements June 2008
サングスタ、他 [25ページ]情報のRFC5209NEA要件2008年6月
assessment. The NEA Server performs an initial assessment of the system and determines it is compliant but the anti-virus protection is not in use. The student receives an advisory response indicating the system's anti-virus software is turned off but that otherwise it complies with the school's policy. The student turns on the anti-virus software, initiates a scan, and upon completion decides to trust the system with her work.
査定。 NEA Serverは、システムの初期評価を実行して、それが言いなりになることを決定しますが、アンチウイルス保護は使用中ではありません。 学生はシステムのウイルス除去ソフトがオフにされるのを示す顧問応答にもかかわらず、それを受けます。そうでなければ、それは学校の方針に従います。 学生は、ウイルス除去ソフトをつけて、スキャンを開始して、完成のときに彼女の仕事をシステムに委託すると決めます。
6.1.2.2. Possible Flows and Protocol Usage
6.1.2.2. 可能な流れとプロトコル用法
The following describes the message flows through the NEA reference model for the student using a terminal room shared system example:
以下は学生のために端末の余地の共有システムの例を使用することでNEA規範モデルを通したメッセージ流れについて説明します:
1. Student triggers the Posture Broker Client on the computer
system in the terminal room to initiate a posture assessment.
1. 学生は姿勢査定を開始する端末の部屋のコンピュータ・システムの上でPosture Broker Clientの引き金となります。
2. The Posture Broker Client establishes a session with the
Posture Broker Server that causes an assessment to be
triggered.
2. Posture Broker Clientは査定を引き起こさせるPosture Broker Serverとのセッションを確立します。
3. The Posture Broker Server detects the new session and consults
policy to determine that Posture Validators to involve in the
assessment. The Posture Broker Server decides to employ
several Posture Validators including the anti-virus Posture
Validator.
3. Posture Broker Serverは新しいセッションを検出して、そのPosture Validatorsが査定にかかわることを決定する方針に相談します。 Posture Broker Serverは、アンチウイルスPosture Validatorを含む数個のPosture Validatorsを使うと決めます。
4. The Posture Validators involved create PA messages containing
requests for particular attributes containing information about
the desired terminal room computer based on the school's
security policy.
4. かかわったPosture Validatorsは学校の安全保障政策に基づく必要な端末の余地のコンピュータの情報を含む特定の属性を求める要求を含むPAメッセージを作成します。
5. The Posture Broker Server assembles a PB message including each
of the PA messages from the Posture Validators.
5. Posture Broker ServerはPosture Validatorsからのそれぞれに関するPAメッセージを含むPBメッセージを組み立てます。
6. The Posture Transport Server sends the PB message to the
Posture Transport Client where it is passed on to the Posture
Broker Client.
6. Posture Transport ServerはそれがPosture Broker Clientに通過されるPosture Transport ClientにPBメッセージを送ります。
7. The Posture Broker Client on the student's computer
de-multiplexes the PA messages and delivers them to the
corresponding Posture Collectors.
7. 学生のコンピュータの上のPosture Broker Clientは反-PAメッセージを多重送信して、対応するPosture Collectorsにそれらを提供します。
8. The Posture Collectors consult privacy policy to decide what
information to share with the Server. If allowable, the
Collectors each return a PA message containing the requested
posture to the Posture Broker Client.
8. Posture Collectorsは、どんな情報をServerと共有したらよいかを決めるためにプライバシーに関する方針に相談します。許容できるなら、Collectorsはそれぞれ要求された姿勢をPosture Broker Clientに含むPAメッセージを返します。
Sangster, et al. Informational [Page 26] RFC 5209 NEA Requirements June 2008
サングスタ、他 [26ページ]情報のRFC5209NEA要件2008年6月
9. The Posture Broker Client aggregates the returned PA messages
into a PB message and hands it to the Posture Transport Client
for transmission to the Posture Transport Server.
9. Posture Broker ClientはPBメッセージへの返されたPAメッセージに集めて、Posture Transport Serverへの伝送のためPosture Transport Clientを尊敬します。
10. The Posture Broker Server separates and distributes the Posture
Collector PA messages to the associated Posture Validators.
10. Posture Broker ServerはPosture Collector PAメッセージを関連Posture Validatorsに切り離して、分配します。
11. The Posture Validators determine whether the attributes
containing the posture included in the PA message are compliant
with their policies and returns a posture assessment decision
to the Posture Broker Server. In this case, the anti-virus
Posture Validator returns a PA message indicating a
non-compliant result because the anti-virus software is not
running and includes attributes describing how to activate the
software.
11. Posture ValidatorsはPAメッセージに含まれていた姿勢を含む属性がそれらの方針で対応であるかどうか決定して、姿勢査定決定をPosture Broker Serverに返します。この場合、アンチウイルスPosture Validatorはウイルス除去ソフトが稼働していないので不従順な結果を示すPAメッセージを返して、ソフトウェアを動かす方法を説明する属性を含めます。
12. The Posture Broker Server determines the overall compliance
decision based on all of the Validators' assessment results and
sends a PB message containing an attribute expressing the
global assessment decision and the anti-virus Validator's PA
message. In this case, the global assessment decision
indicates the system is compliant (despite the anti-virus
Validator's result) because the Posture Broker Server policy
allowed for the anti-virus to not be running as long as the
system was properly patched and running a firewall (which was
the case according to the other Posture Validators).
12. Posture Broker ServerはValidatorsの査定結果のすべてに基づく総合的な応諾決定を決定して、属性を含むPBメッセージにグローバルな査定決定とアンチウイルスValidatorのPAメッセージを言い表させます。 この場合、グローバルな査定決定は、システムが適切に、ファイアウォール(他のPosture Validatorsによると、ケースであった)にパッチされて、動かしていた限り、Posture Broker Server方針が、アンチウイルスが稼働していないのを許容したのでシステムが対応であることを(アンチウイルスValidatorの結果にもかかわらず)示します。
13. The Posture Transport Server sends the PB message to the
Posture Transport Client that provides the message to the
Posture Broker Client.
13. Posture Transport ServerはメッセージをPosture Broker Clientに供給するPosture Transport ClientにPBメッセージを送ります。
14. The Posture Broker Client on the terminal room computer
examines the PB message's global assessment decision attribute
and reports to the student that the system was deemed to be
compliant, but that an advisory was included.
14. 端末の余地のコンピュータの上のPosture Broker ClientはPBメッセージのグローバルな査定決定属性とシステムが言いなりになると考えられましたが、状況報告が含まれていたという学生へのレポートを調べます。
15. The Posture Broker Client provides the PA message with the
remediation attributes to the anti-virus Posture Collector that
interacts with the user to explain how to turn on anti-virus to
improve the local protections.
15. Posture Broker Clientは地方の保護を改良するためにアンチウイルスをつける方法を説明するためにユーザと対話するアンチウイルスPosture Collectorへの治療教育属性をPAメッセージに提供します。
16. The student turns on the anti-virus software and on completion
steps 1-10 are repeated.
16. ウイルス除去ソフトの上と、そして、完成ステップ1-10における学生回転は繰り返されます。
17. This time the anti-virus Posture Validator returns a success
status and the Posture Broker Server returns a successful
global assessment decision in the PB message.
17. 今回、アンチウイルスPosture Validatorは成功状態を返します、そして、Posture Broker ServerはPBメッセージにおけるうまくいっているグローバルな査定決定を返します。
Sangster, et al. Informational [Page 27] RFC 5209 NEA Requirements June 2008
サングスタ、他 [27ページ]情報のRFC5209NEA要件2008年6月
18. The Posture Broker Client receives the successful global
assessment decision in the PB message and the student now uses
the computer for her assignment.
18. Posture Broker ClientはPBメッセージにおけるうまくいっているグローバルな査定決定を受けます、そして、学生は現在、彼女の課題にコンピュータを使用します。
6.1.2.3. Impact on Requirements
6.1.2.3. 要件で影響を与えてください。
The following are several different aspects of the use case example that potentially need to be factored into the requirements.
以下による使用のいくつかの異なった局面が潜在的に要件が要因として考慮される必要がある例をケースに入れるということです。
o Voluntary endpoint requested initial assessment,
o 自発的の終点は初期評価を要求しました。
o Successful (compliant) global assessment decision included in PB
message with a PA message containing an advisory set of
attributes for remediation.
o PAメッセージが治療教育のための顧問セットの属性を含んでいるPBメッセージにうまくいっている(言いなりになっている)グローバルな査定決定を含んでいます。
6.2. Posture Reassessment
6.2. 姿勢Reassessment
Reassessment(s) of endpoints can happen anytime after being admitted to the network after a successful initial NEA assessment. These reassessments may be event-based, such as driven by posture changes detected by the NEA Client, or changes detected by network infrastructure such as detection of suspicious behavior or network policy updates on the NEA Server. They may also be periodic (timer- driven) to reassess the health of the endpoint.
終点のReassessment(s)はうまくいっている初期のNEA査定の後にネットワークに認められた後に、いつでも起こることができます。 これらの再査定はイベントベースであるかもしれません、NEA ServerでNEA Clientによって検出された姿勢変化、不審な挙動の検出などのネットワークインフラによって検出された変化またはネットワーク方針アップデートで駆動であることのように。また、それらも、終点の健康を再評価するために周期的であるかもしれません(動かされたタイマ)。
6.2.1. Triggered by NEA Client
6.2.1. NEAクライアントによって引き起こされます。
This use case allows for software on the endpoint or a user to determine that a reassessment of the system is required. There are a variety of reasons why such a reassessment might be beneficial including: changes in its previously reported posture, detection of potentially suspicious behavior, or even to enable the system to periodically poll the NEA Server to assess its condition relative to the latest policies.
ケースがそれを決定する終点かユーザの上のソフトウェアのためにシステムの再査定を許すこの使用が必要です。 そのような再査定が有益であるかもしれないである:さまざまな理由があります。 以前に報告された姿勢、潜在的に疑わしげな振舞い、システムが最新の方針に比例して状態を評価するために定期的にNEA Serverに投票するのを可能にするために同等の検出における変化。
6.2.1.1. Example
6.2.1.1. 例
The desktops within a company's HR department have a history of poor security practices and eventual compromise. The HR department administrator decides to deploy software on each desktop to monitor the use of security protective mechanisms to assure their use. One day, an HR person accidentally turns off the desktop firewall. The monitoring process detects the lack of a firewall and contacts the NEA Server to request a reassessment of the firewall compliance. The NEA Server returns a decision that the firewall must be reactivated to stay on the network. The NEA Client explains the decision to the user and how to reactivate the firewall. The HR person restarts the firewall and initiates a request to rejoin the network.
会社のHR部の中のデスクトップには、貧しいセキュリティ実践と最後の感染の歴史があります。 HR部の管理者は、彼らの使用を保証するためにセキュリティの保護的なメカニズムの使用をモニターするために各デスクトップのソフトウェアを配布すると決めます。 ある日、HR人は偶然デスクトップファイアウォールをオフにします。 モニターしているプロセスは、ファイアウォールの不足を検出して、ファイアウォールコンプライアンスの再査定を要求するためにNEA Serverに連絡します。 NEA Serverはネットワークに滞在するためにファイアウォールを再起動しなければならないという決定を返します。 NEA Clientはユーザとどうファイアウォールを再起動するかに決定について説明します。 HR人は、ファイアウォールを再開して、ネットワークに再び加わるという要求を開始します。
Sangster, et al. Informational [Page 28] RFC 5209 NEA Requirements June 2008
サングスタ、他 [28ページ]情報のRFC5209NEA要件2008年6月
6.2.1.2. Possible Flows & Protocol Usage
6.2.1.2. 可能な流れとプロトコル用法
The following describes the message flows through the NEA reference model for the HR department example:
以下はHR部の例のためにNEA規範モデルを通したメッセージ流れについて説明します:
1. The desktop monitoring software that typically might act as a
Posture Collector triggers the Posture Broker Client to
initiate a posture reassessment. The Posture Broker Client
creates a PB message that contains a PA message indicating the
desktop firewall has been disabled.
1. Posture Collectorが姿勢再査定を開始するPosture Broker Clientの引き金となるとき、ソフトウェアをそんなに通常モニターするデスクトップは作動するかもしれません。 Posture Broker Clientはデスクトップファイアウォールが無効にされたのを示すPAメッセージを含むPBメッセージを作成します。
2. The Posture Broker Client sends the PB message to the Posture
Broker Server.
2. Posture Broker ClientはPBメッセージをPosture Broker Serverに送ります。
3. The Posture Transport Client sends the PB message to the
Posture Transport Server over the PT protocol.
3. Posture Transport Clientは太平洋標準時の上のPosture Transport Serverへのメッセージが議定書の中で述べるPBを送ります。
4. The Posture Broker Server receives the PB message and forwards
the PA message to the firewall Posture Validator for
evaluation.
4. Posture Broker Serverは評価のためにPBメッセージを受け取って、PAメッセージをファイアウォールPosture Validatorに転送します。
5. The firewall Posture Validator determines that the endpoint is
no longer compliant because its firewall has been disabled.
5. ファイアウォールPosture Validatorは、ファイアウォールが無効にされたので終点がもう言いなりにならないことを決定します。
6. The Posture Validator generates a PA message that contains
attributes indicating a non-compliant posture assessment result
and remediation instructions for how to reactivate the
firewall.
6. Posture Validatorは不従順な姿勢を示す属性を含むPAメッセージにどうファイアウォールを再起動するかためには査定結果と治療教育指示を生成します。
7. The Posture Validator communicates the PA message with the
posture assessment result to the Posture Broker Server to
respond back to the NEA Client.
7. Posture Validatorは、NEA Clientに応じて戻るためにPAメッセージをPosture Broker Serverに姿勢査定結果と伝えます。
8. The Posture Broker Server generates a PB message including a
global assessment decision of non-compliant and the PA message
from the firewall Posture Validator.
8. Posture Broker Serverは不従順のグローバルな査定決定とファイアウォールPosture ValidatorからのPAメッセージを含むPBメッセージを生成します。
9. The Posture Transport Server transports the PB message to the
Posture Transport Client where it is passed to the Posture
Broker Client.
9. Posture Transport ServerはそれがPosture Broker Clientに通過されるPosture Transport ClientにPBメッセージを輸送します。
10. The Posture Broker Client processes the attribute containing
the global assessment decision received from the NEA Server and
displays the non-compliance messages to the user.
10. Posture Broker ClientはNEA Serverから受けられたグローバルな査定決定を含む属性を処理して、不承諾メッセージをユーザに表示します。
Sangster, et al. Informational [Page 29] RFC 5209 NEA Requirements June 2008
サングスタ、他 [29ページ]情報のRFC5209NEA要件2008年6月
11. The Posture Broker Client forwards the PA message to the
firewall Posture Collector; the Posture Collector displays the
remediation instructions for how to enable the desktop
firewall.
11. Posture Broker ClientはPAメッセージをファイアウォールPosture Collectorに転送します。 Posture Collectorはどうデスクトップファイアウォールを可能にするかためには治療教育指示を表示します。
12. The user is prompted to initiate a reassessment after
completing the remediation.
12. 治療教育を完成した後にユーザが再査定を開始するようにうながされます。
13. Upon completion of the remediation, the NEA Client reinitiates
a request for reassessment and steps 1-4 are repeated. This
time the firewall Posture Validator determines the endpoint is
compliant and returns a successful posture assessment decision.
13. 治療教育の完成のときに、再査定を求めるNEA Client reinitiates a要求とステップ1-4は繰り返されます。 今回、ファイアウォールPosture Validatorは終点が言いなりになることを決定して、うまくいっている姿勢査定決定を返します。
14. The Posture Broker Server generates a PB message with a global
assessment decision of compliant and returns this to the NEA
Client.
14. Posture Broker Serverは言いなりになることのグローバルな査定決定でPBメッセージを生成して、これをNEA Clientに返します。
6.2.1.3. Impact on Requirements
6.2.1.3. 要件で影響を与えてください。
The following are several different aspects of the use case example that potentially need to be factored into the requirements.
以下による使用のいくつかの異なった局面が潜在的に要件が要因として考慮される必要がある例をケースに入れるということです。
o Voluntary, endpoint (software) initiated posture reassessment
request
o 自発的であることで、終点(ソフトウェア)は姿勢再査定要求を開始しました。
o NEA Server requests specific firewall-oriented Posture
Attributes
o NEA Server要求の特定のファイアウォール指向のPosture Attributes
o NEA Client (firewall Posture Collector) interacts with user to
remediate problem
o NEA Client(ファイアウォールPosture Collector)はremediate問題へのユーザと対話します。
6.2.2. Triggered by NEA Server
6.2.2. NEAサーバで、引き起こされます。
In many cases, especially for reassessment, the NEA Server may initiate specific or complete reassessment of one or more endpoints triggered by:
多くの場合、特に再査定に関して、NEA Serverは以下によって引き起こされた1つ以上の終点の特定の、または、完全な再査定を開始するかもしれません。
o Time (periodic)
o Event occurrence
o Policy updates
o (周期的)の時間のo Event発生o Policyアップデート
6.2.2.1. Example
6.2.2.1. 例
An enterprise requires employees on the network to always stay up to date with security critical operating system patches. A marketing employee joins the network and performs an initial assessment. The assessment determines the employee's laptop is compliant. Several
企業は、ネットワークの従業員がいつもセキュリティの重要なオペレーティングシステムパッチで最新のままであることを必要とします。 マーケティング従業員は、ネットワークに加わって、初期評価を実行します。 査定は、従業員のラップトップが言いなりになることを決定します。 数個
Sangster, et al. Informational [Page 30] RFC 5209 NEA Requirements June 2008
サングスタ、他 [30ページ]情報のRFC5209NEA要件2008年6月
hours later, a major operating system vendor releases a set of patches preventing a serious vulnerability that is being exploited on the Internet.
何時間も後に、主要なオペレーティングシステムベンダーは、インターネットで利用されている重大な脆弱性を防ぎながら、1セットのパッチをリリースします。
The enterprise administrators make available the patches and change the network policy to require them to be installed by 5 PM. This policy change causes the NEA Server to request a reassessment to determine which endpoints are impacted and lacking the patches. The marketing employee's laptop is reassessed and determined to need the patches. A remediation advisory is sent and presented to the employee explaining how to obtain the patches and that they must be installed by 5 PM. The marketing employee immediately downloads and installs the patches and obtains an assertion that all patches are now installed.
企業の管理者はパッチと変更を利用可能にします。午後5時までにインストールされて、それらは必要であるネットワーク方針。 この政策変更で、NEA Serverは、どの終点が影響を与えられて、パッチを欠いているか決定するよう再査定に要求します。 マーケティング従業員のラップトップは、再評価されて、パッチを必要とすることを決定します。 治療教育状況報告は、どうパッチを入手するか、そして、午後5時までにそれらをインストールしなければならないと説明する従業員に、送られて、提示されます。 マーケティング従業員は、すぐに、ダウンロードして、パッチをインストールして、すべてのパッチが現在インストールされるという主張を得ます。
At 5 PM, the enterprise performs another reassessment of all impacted endpoints to determine if they are now in compliance. The marketing employee's laptop is reassessed and presents the assertion that it has the patches installed and thus is determined to be compliant.
午後5時に、企業は、それらが現在、コンプライアンス中であるかを決定するためにすべての影響を与えられた終点の別の再査定を実行します。 マーケティング従業員のラップトップは、再評価されて、それがパッチをインストールさせて、その結果、言いなりになると決心しているという主張を提示します。
6.2.2.2. Possible Flows and Protocol Usage
6.2.2.2. 可能な流れとプロトコル用法
The following describes the message flows through the NEA reference model for the above example:
以下は上記の例のためにNEA規範モデルを通したメッセージ流れについて説明します:
1. Marketing employee joins network and completes an initial
assessment resulting in a compliant decision.
1. マーケティング従業員は、ネットワークに加わって、対応する決定をもたらす初期評価を終了します。
2. The Enterprise Administrator configures an operating system
patch policy indicating that recent patches are required on all
endpoints by 5 PM to prevent serious vulnerabilities.
2. エンタープライズAdministratorは、最近のパッチがそうであることを示すオペレーティングシステムパッチ方針が午後5時までにすべての終点で重大な脆弱性を防ぐのが必要であることを構成します。
3. The NEA Server's operating system patch Posture Validator
becomes aware of this policy change and creates a PA message
requesting attributes describing OS patches in use and triggers
the Posture Broker Server to initiate a posture reassessment of
all endpoints connected to the network.
3. NEA ServerのオペレーティングシステムパッチPosture Validatorはこの政策変更を意識するようになって、OSパッチについて使用中に説明する属性を要求するPAメッセージを作成して、ネットワークにつなげられたすべての終点の姿勢再査定を開始するPosture Broker Serverの引き金となります。
4. The Posture Broker creates a PB message that includes the PA
message from the operating system patch Posture Validator.
4. Posture BrokerはオペレーティングシステムパッチPosture ValidatorからPAメッセージを含んでいるPBメッセージを作成します。
5. The Posture Broker Server gradually establishes a session with
each available NEA Client.
5. Posture Broker Serverは徐々にそれぞれの利用可能なNEA Clientとのセッションを確立します。
6. The Posture Broker Server sends the PB message to the Posture
Broker Client.
6. Posture Broker ServerはPBメッセージをPosture Broker Clientに送ります。
Sangster, et al. Informational [Page 31] RFC 5209 NEA Requirements June 2008
サングスタ、他 [31ページ]情報のRFC5209NEA要件2008年6月
7. The Posture Transport Server carries the PB message to the
Posture Transport Client over the PT protocol.
7. Posture Transport Serverは太平洋標準時の上のPosture Transport Clientへのメッセージが議定書の中で述べるPBを運びます。
8. The Posture Broker Client receives the PB message and forwards
the PA message to the operating system patch Posture Collector.
8. Posture Broker ClientはオペレーティングシステムパッチPosture CollectorにPBメッセージを受け取って、PAメッセージを転送します。
9. The operating system patch Posture Collector determines the OS
patches present on the endpoint and if authorized by its
disclosure policy creates a PA message containing the patch
information attributes.
9. オペレーティングシステムパッチPosture Collectorは終点の現在のOSパッチを決定します、そして、認可されているなら、公開方針はパッチ情報属性を含むPAメッセージを作成します。
10. The Posture Broker Client sends a PB message that includes the
operating system patch PA message.
10. Posture Broker ClientはオペレーティングシステムパッチPAメッセージを含んでいるPBメッセージを送ります。
11. The Posture Transport Client transports the PB message to the
Posture Transport Server where it is passed to the Posture
Broker Server.
11. Posture Transport ClientはそれがPosture Broker Serverに通過されるPosture Transport ServerにPBメッセージを輸送します。
12. The Posture Broker Server receives the PB message and delivers
the PA message to the operating system patch Posture Validator.
12. Posture Broker ServerはオペレーティングシステムパッチPosture ValidatorにPBメッセージを受け取って、PAメッセージを提供します。
13. The operating system patch Posture Validator extracts the
attributes describing the current OS patches from the PA
message and uses the values to determine whether the endpoint
is compliant with the new policy. The Posture Validator
determines that the endpoint is not compliant since it does not
have the new OS patches installed.
13. オペレーティングシステムパッチPosture Validatorは、PAメッセージから現在のOSパッチについて説明する属性を抽出して、終点が新しい政策で言いなりになるかどうか決定するのに値を使用します。 Posture Validatorは、終点がそれで新しいOSパッチをインストールしないので言いなりにならないことを決定します。
14. The Posture Validator generates a PA message that includes
attributes stating the posture assessment decision is
non-compliant and attributes containing the remediation
instructions to enable the endpoint to download the required OS
patches.
14. Posture Validatorは終点が必要なOSパッチをダウンロードするのを可能にするために姿勢査定決定が不従順であると述べる属性と治療教育指示を含む属性を含んでいるPAメッセージを生成します。
15. The Posture Validator communicates the posture assessment
result to the Posture Broker Server along with its PA message.
15. Posture Validatorは姿勢査定結果をPAメッセージに伴うPosture Broker Serverに伝えます。
16. The Posture Broker Server generates a global assessment
decision and sends a PB message with the decision and the
operating system patch Posture Validator's PA message.
16. Posture Broker Serverはグローバルな査定決定を生成して、決定があるPBメッセージとオペレーティングシステムパッチPosture ValidatorのPAメッセージを送ります。
17. The Posture Transport Server transports the PB message to the
Posture Transport Client where it is passed to the Posture
Broker Client.
17. Posture Transport ServerはそれがPosture Broker Clientに通過されるPosture Transport ClientにPBメッセージを輸送します。
18. The Posture Broker Client processes the Result Attribute
received from the NEA Server and displays the non-compliance
decision to the user.
18. Posture Broker ClientはNEA Serverから受け取られたResult Attributeを処理して、不承諾決定をユーザに表示します。
Sangster, et al. Informational [Page 32] RFC 5209 NEA Requirements June 2008
サングスタ、他 [32ページ]情報のRFC5209NEA要件2008年6月
19. The Posture Broker Client forwards the PA message containing
the remediation instructions to the operating system patch
Posture Collector; the Posture Collector guides the user with
instructions on how to become compliant that include
downloading the appropriate OS patches to prevent the
vulnerability.
19. Posture Broker ClientはオペレーティングシステムパッチPosture Collectorに治療教育指示を含むPAメッセージを転送します。 Posture Collectorは脆弱性を防ぐために適切なOSパッチをダウンロードするのを含んでいるどう言いなりになるようになるかに関する指示でユーザを誘導します。
20. The marketing employee installs the required patches and now is
in compliance.
20. マーケティング従業員は、必要なパッチをインストールして、現在、コンプライアンス中です。
21. The NEA Client triggers a reassessment of the operating system
patches that causes a repeat of many of the steps above. This
time, in step 13 the operating system patch Posture Validator
determines the marketing employee's laptop is compliant. It
returns a reusable (e.g., signed and dated) set of attributes
that assert OS patch compliance to the latest policy. These OS
patch compliance assertions can be used in a future PA message
from the operating system patch Collector instead of
determining and providing the specific patch set posture as
before.
21. NEA Clientは上のステップの多くの反復を引き起こすオペレーティングシステムパッチの再査定の引き金となります。 今回、ステップ13では、オペレーティングシステムパッチPosture Validatorは、マーケティング従業員のラップトップが言いなりになることを決定します。 それはOSがパッチ承諾であると最新の方針に断言する再利用できる(例えば、署名されて、日付を入れられる)セットの属性を返します。 従来と同様特定のパッチセット姿勢を決定して、提供することの代わりに将来のPAメッセージでオペレーティングシステムパッチCollectorからこれらのOSパッチ承諾主張を使用できます。
22. This time when the operating system patch Posture Collector
receives the PA message that contains reusable attributes
asserting compliance, it caches those attributes for future
use.
22. オペレーティングシステムパッチPosture Collectorが今回コンプライアンスについて断言する再利用できる属性を含むPAメッセージを受け取るとき、それは今後の使用のためにそれらの属性をキャッシュします。
23. Later at 5 PM, the NEA Server triggers a gradual reassessment
to determine compliance to the patch advisory. When the
operating system patch Posture Collector receives the request
for posture information (like in step 9 above) it returns the
cached set of assertions (instead of specific OS patch
information) to indicate that the patches have been installed
instead of determining all the patches that have been installed
on the system.
23. 午後5時より遅く、NEA Serverはパッチ状況報告にコンプライアンスを決定するゆるやかな再査定の引き金となります。 オペレーティングシステムパッチPosture Collectorが姿勢情報(上のステップ9では、好きである)に関する要求を受け取るとき、それは、システムの上にインストールされたすべてのパッチを決定することの代わりにパッチがインストールされたのを示すために、キャッシュされたセットの主張(特定のOSパッチ情報の代わりに)を返します。
24. When the operating system patch Posture Validator receives the
PA message containing the assertions, it is able to determine
that they are authentic and acceptable assertions instead of
specific posture. It returns a posture assessment decision of
compliant thus allowing the laptop to remain on the network.
24. オペレーティングシステムパッチPosture Validatorが主張を含むPAメッセージを受け取るとき、それは、それらが特定の姿勢の代わりに正統の、そして、許容できる主張であることを決定できます。 その結果、ラップトップがネットワークに残っているのを許容しながら、それは言いなりになることの姿勢査定決定を返します。
6.2.2.3. Impact on Requirements
6.2.2.3. 要件で影響を与えてください。
The following are several different aspects of the use case example that potentially need to be factored into the requirements.
以下による使用のいくつかの異なった局面が潜在的に要件が要因として考慮される必要がある例をケースに入れるということです。
o Server-initiated reassessment required due to urgent patch
availability
o サーバで開始している再査定が緊急のパッチの有用性のため必要です。
Sangster, et al. Informational [Page 33] RFC 5209 NEA Requirements June 2008
サングスタ、他 [33ページ]情報のRFC5209NEA要件2008年6月
o NEA Client submits reusable assertion attributes instead of
posture that patch is installed
o NEA Clientはインストールされていた状態で姿勢の代わりにパッチがそうである再利用できる主張属性を提出します。
o NEA Server capable of recognizing previously issued assertion
attributes are sufficient instead of posture
o 以前に発行された主張属性が姿勢の代わりに十分であると認めることができるNEA Server
7. Requirements
7. 要件
This section describes the requirements that will be used by the NEA WG to assess and compare candidate protocols for PA, PB, and PT. These requirements frequently express features that a candidate protocol must be capable of offering so that a deployer can decide whether to make use of that feature. This section does not state requirements about what features of each protocol must be used during a deployment.
このセクションはPA、PBのために候補プロトコルを評価して、比較するのにNEA WGによって使用されて、太平洋標準時になる要件について説明します。 これらの要件は、デプロイヤが、その特徴を利用するかどうか決めることができるように、頻繁に候補プロトコルが提供できなければならない特徴を言い表します。 このセクションは展開の間それぞれのプロトコルのどんな特徴を使用しなければならないかに関する要件を述べません。
For example, a requirement (MUST, SHOULD, or MAY) might exist for cryptographic security protections to be available from each protocol but this does not require that a deployer make use of all or even any of them should they deem their environment to offer other protections that are sufficient.
例えば、要件、(SHOULD、5月) 力は暗号の機密保持が各プロトコルから利用可能であるように存在していますが、彼らの環境が他の十分な保護を提供すると考えるなら、これはすべてのそのaデプロイヤ造の使用かそれらのいずれさえも必要としてはいけません。
7.1. Common Protocol Requirements
7.1. 一般的なプロトコル要件
The following are the common requirements that apply to the PA, PB, and PT protocols in the NEA reference model:
↓これはNEA規範モデルのPA、PB、およびPTプロトコルに適用される一般的な要件です:
C-1 NEA protocols MUST support multiple round trips between the NEA
Client and NEA Server in a single assessment.
C-1NEAプロトコルはただ一つの査定でNEA ClientとNEA Serverの間の複数の周遊旅行をサポートしなければなりません。
C-2 NEA protocols SHOULD provide a way for both the NEA Client and
the NEA Server to initiate a posture assessment or reassessment
as needed.
C-2NEAプロトコルSHOULDはNEA ClientとNEA Serverの両方が必要に応じて姿勢査定か再査定を開始する方法を提供します。
C-3 NEA protocols including security capabilities MUST be capable of
protecting against active and passive attacks by intermediaries
and endpoints including prevention from replay based attacks.
セキュリティ能力を含むC-3つのNEAプロトコルが仲介者によるアクティブで受け身の攻撃から守ることができなければなりません、そして、再生からの防止を含む終点が攻撃を基礎づけました。
C-4 The PA and PB protocols MUST be capable of operating over any PT
protocol. For example, the PB protocol must provide a transport
independent interface allowing the PA protocol to operate
without change across a variety of network protocol environments
(e.g., EAP/802.1X, TLS, and Internet Key Exchange Protocol
version 2 (IKEv2)).
PAとPBプロトコルが太平洋標準時のいずれも上で操作できなければならないC-4は議定書を作ります。 例えば、PBプロトコルは、さまざまなネットワーク・プロトコル環境(例えば、EAP/802.1X、TLS、およびインターネット・キー・エクスチェンジプロトコルバージョン2(IKEv2))の向こう側に変化なしで作動するために輸送インディペンデント・インタフェース許容にPAプロトコルを提供しなければなりません。
Sangster, et al. Informational [Page 34] RFC 5209 NEA Requirements June 2008
サングスタ、他 [34ページ]情報のRFC5209NEA要件2008年6月
C-5 The selection process for NEA protocols MUST evaluate and prefer
the reuse of existing open standards that meet the requirements
before defining new ones. The goal of NEA is not to create
additional alternative protocols where acceptable solutions
already exist.
新しいものを定義する前に条件を満たすNEAプロトコルのための選択プロセスが再利用を評価して、好まなければならないC-5の既存のオープンスタンダード。 NEAの目標は許容できるソリューションが既に存在する追加代替のプロトコルを作成しないことです。
C-6 NEA protocols MUST be highly scalable; the protocols MUST
support many Posture Collectors on a large number of NEA Clients
to be assessed by numerous Posture Validators residing on
multiple NEA Servers.
C-6つのNEAプロトコルが非常にスケーラブルでなければなりません。 複数のNEA Serversに住んでいて、多数のPosture Validatorsによって評価されるように、プロトコルは多くのNEA Clientsで多くのPosture Collectorsをサポートしなければなりません。
C-7 The protocols MUST support efficient transport of a large number
of attribute messages between the NEA Client and the NEA Server.
プロトコルが多くの効率的な輸送をサポートしなければならないC-7はNEA ClientとNEA Serverの間のメッセージを結果と考えます。
C-8 NEA protocols MUST operate efficiently over low bandwidth or
high latency links.
C-8つのNEAプロトコルが低い帯域幅か高い潜在リンクの上に効率的に作動しなければなりません。
C-9 For any strings intended for display to a user, the protocols
MUST support adapting these strings to the user's language
preferences.
ディスプレイのためにユーザに意図するどんなストリングのためのC-9、プロトコルは適合がこれらのストリングであるとユーザの言語好みにサポートしなければなりません。
C-10 NEA protocols MUST support encoding of strings in UTF-8 format
[UTF8].
C-10のNEAプロトコルがUTF-8形式[UTF8]における、ストリングのコード化をサポートしなければなりません。
C-11 Due to the potentially different transport characteristics
provided by the underlying candidate PT protocols, the NEA
Client and NEA Server MUST be capable of becoming aware of and
adapting to the limitations of the available PT protocol. For
example, some PT protocol characteristics that might impact the
operation of PA and PB include restrictions on: which end can
initiate a NEA connection, maximum data size in a message or
full assessment, upper bound on number of roundtrips, and
ordering (duplex) of messages exchanged. The selection process
for the PT protocols MUST consider the limitations the candidate
PT protocol would impose upon the PA and PB protocols.
太平洋標準時の基本的な候補によって提供された潜在的に異なった輸送の特性によるC-11プロトコル、NEA Client、およびNEA Serverは意識していて太平洋標準時の利用可能の制限に適合しているプロトコルになることができなければなりません。 例えば、PAとPBの操作に影響を与えるかもしれないいくつかのPTプロトコルの特性が以下に制限を含んでいます。 どの終わりがNEA接続、メッセージか完全な査定における最大のデータサイズ、往復旅行の数に関する上限、およびメッセージの(デュプレックス)が交換した注文を開始できますか? PTプロトコルが、制限が候補PTプロトコルであると考えなければならないので、選択プロセスはPAとPBプロトコルにでしゃばるでしょう。
7.2. Posture Attribute (PA) Protocol Requirements
7.2. 姿勢属性(PA)プロトコル要件
The Posture Attribute (PA) protocol defines the transport and data model to carry posture and validation information between a particular Posture Collector associated with the NEA Client and a Posture Validator associated with a NEA Server. The PA protocol carries collections of standard attributes and vendor-specific attributes. The PA protocol itself is carried inside the PB protocol.
Posture Attribute(PA)プロトコルは、NEA Clientに関連している特定のPosture CollectorとNEA Serverに関連しているPosture Validatorの間まで姿勢と合法化情報を運ぶために輸送とデータモデルを定義します。PAプロトコルは標準の属性とベンダー特有の属性の収集を運びます。 PAプロトコル自体はPBプロトコルで運ばれます。
Sangster, et al. Informational [Page 35] RFC 5209 NEA Requirements June 2008
サングスタ、他 [35ページ]情報のRFC5209NEA要件2008年6月
The following requirements define the desired properties that form the basis for comparison and evaluation of candidate PA protocols. These requirements do not mandate the use of these properties, but merely that the candidate protocols are capable of offering the property if it should be needed.
以下の要件は候補PAプロトコルの比較と評価の基礎を形成する必要な特性を定義します。 それが必要であるなら候補プロトコルが資産を提供できるというこれらの要件はこれらの特性について使用を強制するのではなく、単に強制します。
PA-1 The PA protocol MUST support communication of an extensible set
of NEA standards defined attributes. These attributes will be
distinguishable from non-standard attributes.
PAプロトコルが広げることができるセットのNEA規格に関するコミュニケーションをサポートしなければならないPA-1は属性を定義しました。 これらの属性は標準的でない属性から区別可能になるでしょう。
PA-2 The PA protocol MUST support communication of an extensible set
of vendor-specific attributes. These attributes will be
segmented into uniquely identified vendor-specific namespaces.
PAプロトコルが広げることができるセットのベンダー特有の属性に関するコミュニケーションをサポートしなければならないPA-2。 これらの属性は唯一特定されたベンダー特有の名前空間に区分されるでしょう。
PA-3 The PA protocol MUST enable a Posture Validator to make one or
more requests for attributes from a Posture Collector within a
single assessment. This enables the Posture Validator to
reassess the posture of a particular endpoint feature or to
request additional posture including from other parts of the
endpoint.
PAが議定書の中で述べるPA-3は、Posture Validatorがただ一つの査定の中でPosture Collectorから属性を求める1つ以上の要求をするのを可能にしなければなりません。 これは、Posture Validatorが特定の終点の特徴の姿勢を再評価するか、または終点の他の地域からの追加姿勢包含を要求するのを可能にします。
PA-4 The PA protocol MUST be capable of returning attributes from a
Posture Validator to a Posture Collector. For example, this
might enable the Posture Collector to learn the specific reason
for a failed assessment and to aid in remediation and
notification of the system owner.
PAプロトコルがPosture ValidatorからPosture Collectorまで属性を返すことができなければならないPA-4。 例えば、これは、Posture Collectorが失敗した査定の特定の理由を学んで、システム所有者の治療教育と通知で支援するのを可能にするかもしれません。
PA-5 The PA protocol SHOULD provide authentication, integrity, and
confidentiality protection for attributes communicated between a
Posture Collector and Posture Validator. This enables
end-to-end security across a NEA deployment that might involve
traversal of several systems or trust boundaries.
PAプロトコルSHOULDが属性のための認証、保全、および秘密性保護を提供するPA-5はPosture CollectorとPosture Validatorの間で交信しました。 これは数個のシステムの縦断にかかわるか、または境界を信じるかもしれないNEA展開の向こう側に終わりから終わりへのセキュリティを可能にします。
PA-6 The PA protocol MUST be capable of carrying attributes that
contain non-binary and binary data including encrypted content.
非バイナリーとバイナリ・データ包含を含むPAプロトコルが運ぶことができなければならないPA-6属性が内容を暗号化しました。
7.3. Posture Broker (PB) Protocol Requirements
7.3. 姿勢ブローカー(Pb)プロトコル要件
The PB protocol supports multiplexing of Posture Attribute messages (based on PA protocol) between the Posture Collectors on the NEA Client to and from the Posture Validators on the NEA Server (in either direction).
PBプロトコルはNEA Clientの上のPosture Collectorsの間でPosture ValidatorsとNEA Server(どちらかの方向への)の上のPosture ValidatorsからPosture Attributeメッセージのマルチプレクシングをサポートします(PAプロトコルに基づいています)。
The PB protocol carries the global assessment decision made by the Posture Broker Server, taking into account the results of the Posture Validators involved in the assessment, to the Posture Broker Client.
PBプロトコルはPosture Broker Serverによってされたグローバルな査定決定を運びます、査定にかかわるPosture Validatorsの結果を考慮に入れて、Posture Broker Clientに。
Sangster, et al. Informational [Page 36] RFC 5209 NEA Requirements June 2008
サングスタ、他 [36ページ]情報のRFC5209NEA要件2008年6月
The PB protocol also aggregates and transports advisories and notifications such as remediation instructions (e.g., patch references) from one or more Posture Validators.
また、PBプロトコルは、1Posture Validatorsからの治療教育指示(例えば、パッチ参照)などの状況報告と通知を集めて、輸送します。
The requirements for the PB protocol are:
PBプロトコルのための要件は以下の通りです。
PB-1 The PB protocol MUST be capable of carrying attributes from the
Posture Broker Server to the Posture Broker Client. This
enables the Posture Broker Client to learn the posture
assessment decision and if appropriate to aid in remediation and
notification of the endpoint owner.
PBが議定書の中で述べるPB-1はPosture Broker ServerからPosture Broker Clientまで属性を運ぶことができなければなりません。 これは、Posture Broker Clientが姿勢査定決定を学ぶのを可能にします、そして、適切であるなら、終点所有者の治療教育と通知では、支援してください。
PB-2 The PB protocol MUST NOT interpret the contents of PA messages
being carried, i.e., the data it is carrying must be opaque to
it.
PBが議定書の中で述べるPB-2は伝えられるPAメッセージのコンテンツを解釈してはいけません、すなわち、それが運ぶデータがそれに不明瞭であるに違いありません。
PB-3 The PB protocol MUST carry unique identifiers that are used by
the Posture Brokers to route (deliver) PA messages between
Posture Collectors and Posture Validators. Such message routing
should facilitate dynamic registration or deregistration of
Posture Collectors and Validators. For example, a dynamically
registered anti-virus Posture Validator should be able to
subscribe to receive messages from its respective anti-virus
Posture Collector on NEA Clients.
PBが議定書の中で述べるPB-3はPosture CollectorsとPosture Validatorsの間にPAメッセージを発送すること(配送する)にPosture Brokersによって使用されるユニークな識別子を運ばなければなりません。 そのようなメッセージルーティングはPosture CollectorsとValidatorsのダイナミックな登録か反登録を容易にするべきです。 例えば、ダイナミックに登録されたアンチウイルスPosture Validatorは、NEA ClientsにそれぞれのアンチウイルスPosture Collectorからメッセージを受け取るために申し込むはずであることができます。
PB-4 The PB protocol MUST be capable of supporting a half-duplex PT
protocol. However this does not preclude PB from operating
full-duplex when running over a full-duplex PT.
PBプロトコルが太平洋標準時の半二重をサポートすることができなければならないPB-4は議定書を作ります。 しかしながら、太平洋標準時の全二重をひくとき、これは操作全二重からPBを排除しません。
PB-5 The PB protocol MAY support authentication, integrity and
confidentiality protection for the attribute messages it carries
between a Posture Broker Client and Posture Broker Server. This
provides security protection for a message dialog of the
groupings of attribute messages exchanged between the Posture
Broker Client and Posture Broker Server. Such protection is
orthogonal to PA protections (which are end to end) and allows
for simpler Posture Collector and Validators to be implemented,
and for consolidation of cryptographic operations possibly
improving scalability and manageability.
PBが議定書の中で述べるPB-5はそれがPosture Broker ClientとPosture Broker Serverで伝える属性メッセージのための認証、保全、および秘密性保護をサポートするかもしれません。これはPosture Broker ClientとPosture Broker Serverの間で交換された属性メッセージの組分けのメッセージ対話のための機密保持を提供します; そのような保護は、より簡単なPosture CollectorとValidatorsが実装されて、暗号の操作の強化のためにことによるとスケーラビリティと管理可能性を改良しているのをPA保護(終わらせる終わりである)と直交していて、許容します。
PB-6 The PB protocol MUST support grouping of attribute messages
optimize transport of messages and minimize round trips.
PBプロトコルが属性メッセージの組分けをサポートしなければならないPB-6はメッセージの輸送を最適化して、周遊旅行を最小にします。
Sangster, et al. Informational [Page 37] RFC 5209 NEA Requirements June 2008
サングスタ、他 [37ページ]情報のRFC5209NEA要件2008年6月
7.4. Posture Transport (PT) Protocol Requirements
7.4. 姿勢輸送(太平洋標準時の)プロトコル要件
The Posture Transport (PT) protocol carries PB protocol messages between the Posture Transport Client and the Posture Transport Server. PT is responsible for providing a protected transport for the PB protocol. The PT protocol may itself be transported by one or more concatenated sessions using lower layer protocols, such as 802.1X, RADIUS [RADIUS], TLS, or IKE.
Posture Transport(太平洋標準時の)プロトコルはPBプロトコルメッセージをPosture Transport ClientとPosture Transport Serverに伝えます。PTはPBプロトコルのための保護された輸送を提供するのに原因となります。 PTプロトコルは802.1X、RADIUS[RADIUS]、TLS、またはIKEなどの下位層プロトコルを使用するそれ自体で1時までに輸送されたか、またはさらに連結されたセッションがそうするかもしれません。
This section defines the requirements that candidate PT protocols must be capable of supporting.
このセクションは候補PTプロトコルがサポートすることができなければならない要件を定義します。
PT-1 The PT protocol MUST NOT interpret the contents of PB messages
being transported, i.e., the data it is carrying must be opaque
to it.
太平洋標準時が議定書の中で述べる太平洋標準時の1は輸送されるPBメッセージのコンテンツを解釈してはいけません、すなわち、それが運ぶデータがそれに不明瞭であるに違いありません。
PT-2 The PT protocol MUST be capable of supporting mutual
authentication, integrity, confidentiality, and replay
protection of the PB messages between the Posture Transport
Client and the Posture Transport Server.
太平洋標準時が議定書の中で述べる太平洋標準時の2はPosture Transport ClientとPosture Transport Serverの間のPBメッセージの互いの認証、保全、秘密性、および反復操作による保護をサポートすることができなければなりません。
PT-3 The PT protocol MUST provide reliable delivery for the PB
protocol. This includes the ability to perform fragmentation
and reassembly, detect duplicates, and reorder to provide
in-sequence delivery, as required.
太平洋標準時が議定書の中で述べる太平洋標準時の3はPBプロトコルのための信頼できる配信を提供しなければなりません。 必要に応じてこれは断片化を実行する能力を含んで、再アセンブリに、写し、および追加注文を検出して、連続して配送を提供してください。
PT-4 The PT protocol SHOULD be able to run over existing network
access protocols such as 802.1X and IKEv2.
PT-4PTはSHOULDについて議定書の中で述べます。存在する上で802.1XやIKEv2などのネットワークアクセス・プロトコルを実行できてください。
PT-5 The PT protocol SHOULD be able to run between a NEA Client and
NEA Server over TCP or UDP (similar to Lightweight Directory
Access Protocol (LDAP)).
PT-5PTはSHOULDについて議定書の中で述べます。TCPかUDP(ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)と同様の)の上でNEA ClientとNEA Serverの間で稼働できてください。
8. Security Considerations
8. セキュリティ問題
This document defines the functional requirements for the PA, PB, and PT protocols used for Network Endpoint Assessment. As such, it does not define a specific protocol stack or set of technologies, so this section will highlight security issues that may apply to NEA in general or to particular aspects of the NEA reference model.
このドキュメントはNetwork Endpoint Assessmentに使用されるPA、PB、およびPTプロトコルのための機能条件書を定義します。 そういうものとして、特定のプロトコル・スタックか1セットの技術を定義しないので、このセクションは一般に、NEA、または、NEA規範モデルの特定の局面に適用されるかもしれない安全保障問題を強調するでしょう。
Note that while a number of topics are outside the scope of the NEA WG and thus this specification (see section 3.1), it is important that those mechanisms are protected from attack. For example, the methods of triggering an assessment or reassessment are out of scope but should be appropriately protected from attack (e.g., an attacker hiding the event indicating a NEA Server policy change has occurred).
NEA WGとその結果、この仕様の範囲の外に多くの話題がありますが(セクション3.1を見てください)、それらのメカニズムが攻撃から保護されるのが、重要であることに注意してください。 例えば、査定か再査定の引き金となるメソッドは、範囲の外にありますが、攻撃から適切に保護されるべきです(例えば、NEA Server政策変更を示すイベントを隠す攻撃者は起こりました)。
Sangster, et al. Informational [Page 38] RFC 5209 NEA Requirements June 2008
サングスタ、他 [38ページ]情報のRFC5209NEA要件2008年6月
NEA intends to facilitate detection and corrective actions for cooperating endpoints to become compliant with network compliance policies. For example, it is envisioned that these policies will allow deployers to detect out-of-date, inactive, or absent security mechanisms on the endpoint that might leave it more vulnerable to known attacks. If an endpoint is more vulnerable to compromise, then it is riskier to have this endpoint present on the network with other valuable assets. By proactively assessing cooperating endpoints before their entrance to the network, deployers can improve their resilience to attack prior to network access. Similarly, reassessments of cooperating endpoints on the network may be helpful in assuring that security mechanisms remain in use and are up to date with the latest policies.
NEAは、協力終点がネットワーク承諾方針で言いなりになるようになるように検出と修正措置を容易にするつもりです。 例えば、それは思い描かれます。これらの方針は、それを知られている攻撃により被害を受け易い状態でおくかもしれない終点に時代遅れであるか、不活発であるか、欠けているセキュリティー対策を検出するためにデプロイヤを許容するでしょう。 終点が妥協するために、より被害を受け易いなら、ネットワークの他の価値ある資産の現在のこの終点を持っているのは、より危険です。 予測することで、それらの入り口の前に協力終点をネットワークに評価するデプロイヤは、ネットワークアクセサリーの前で攻撃するためにそれらの弾力を改良できます。 同様に、ネットワークの協力終点の再査定は、セキュリティー対策が使用中であり残っていることを保証する際に役立つかもしれなくて、最新の方針で最新です。
NEA fully recognizes that not all endpoints will be cooperating by providing their valid posture (or any posture at all). This might occur if malware is influencing the NEA Client or policies, and thus a trustworthy assessment isn't possible. Such a situation could result in the admission of an endpoint that introduces threats to the network and other endpoints despite passing the NEA compliance assessment.
NEAは、すべての終点がそれらの有効な姿勢(または、全くどんな姿勢も)を提供することによって協力するというわけではないと完全に認めます。 マルウェアがNEA Clientか方針に影響を及ぼしているなら、これは起こるかもしれません、そして、その結果、信頼できる査定は可能ではありません。 NEAコンプライアンス評価を通過しますが、そのような状況はネットワークに脅威を紹介する終点と他の終点の入場をもたらすかもしれません。
8.1. Trust
8.1. 信頼
Network Endpoint Assessment involves assessing the posture of endpoints entering or already on the network against compliance policies to assure they are adequately protected. Therefore, there must be an implied distrusting of endpoints until there is reason to believe (based on posture information) that they are protected from threats addressed by compliance policy and can be trusted to not propagate those threats to other endpoints. On the network provider side, the NEA Client normally is expected to trust the network infrastructure systems to not misuse any disclosed posture information (see section 9) and any remediation instructions provided to the endpoint. The NEA Client normally also needs to trust that the NEA Server will only request information required to determine whether the endpoint is safe to access the network assets.
ネットワークEndpoint Assessmentが、終点の入ることの姿勢を評価することを伴うか、または既に保証する承諾方針に対するネットワークでは、それらは適切に保護されます。 したがって、それらを承諾方針で扱われた脅威から保護して、他の終点へのそれらの脅威を伝播しないと信じることができると信じる(姿勢情報に基づいています)理由があるまで、終点の暗示している不信用があるに違いありません。 ネットワーク内の提供者側では、通常、NEA Clientが少しの明らかにされた姿勢情報も誤用しないようにネットワークインフラシステムを信じると予想されて(セクション9を見てください)、どんな治療教育指示も終点に前提とされました。 また、通常、NEA Clientは、NEA Serverが、ネットワーク資産にアクセスするよう終点が安全であるかどうか決定するのに必要である情報に要求するだけであると信じる必要があります。
Between the NEA Client and Server there exists a network that is not assumed to be trustworthy. Therefore, little about the network is implicitly trusted beyond its willingness and ability to transport the exchanged messages in a timely manner. The amount of trust given to each component of the NEA reference model is deployment specific. The NEA WG intends to provide security mechanisms to reduce the amount of trust that must be assumed by a deployer. The following sections will discuss each area in more detail.
NEA ClientとServerの間では、信頼できるのは思われないネットワークが存在しています。 したがって、意欲と直ちに交換されたメッセージを輸送する能力を超えて少ししかネットワークに関してそれとなく信じられません。 NEA規範モデルの各部品に与えられた信頼の量は展開特有です。 NEA WGは、デプロイヤが想定しなければならない信頼の量を減少させるためにセキュリティー対策を提供するつもりです。 以下のセクションはさらに詳細に各領域について論ずるでしょう。
Sangster, et al. Informational [Page 39] RFC 5209 NEA Requirements June 2008
サングスタ、他 [39ページ]情報のRFC5209NEA要件2008年6月
8.1.1. Endpoint
8.1.1. 終点
For NEA to properly operate, the endpoint needs to be trusted to accurately represent the requested security posture of the endpoint to the NEA Server. By NEA WG charter, the NEA reference model does not explicitly specify how to detect or prevent lying endpoints that intentionally misrepresent their posture. Similarly, the detection of malware (e.g., root kits) that are able to trick the Posture Collectors into returning incorrect information is the subject for research and standardization outside the IETF (e.g., Trusted Computing Group [TCG]) and is not specifically addressed by the model. However, if such mechanisms are used in a deployment, the NEA reference model should be able to accommodate these technologies by allowing them to communicate over PA to Posture Validators or work orthogonally to protect the NEA Client from attack and assure the ability of Posture Collectors to view the actual posture.
NEAが適切に作動するのに、終点は、正確に終点の要求された警戒姿勢をNEA Serverに表すと信じられる必要があります。NEA WG特許で、NEA規範モデルは明らかに故意にそれらの姿勢を誤り伝える横たわっている終点を検出するか、または防ぐ方法を指定しません。 同様に、Posture Collectorsが不正確な情報を返すようにだますことができるマルウェア(例えば、root kit)の検出は、研究とIETF(例えば、Trusted Computing Group[TCG])の外での標準化のための対象であり、モデルによって明確に扱われません。 しかしながら、そのようなメカニズムが展開に使用されるなら、NEA規範モデルは、PAの上で交信するのを許容することによってこれらの技術にPosture Validatorsに対応するべきであるか、または攻撃からNEA Clientを保護して、実際の姿勢を見るために能力にPosture Collectorsを保証するために直交して働くことができるべきです。
Besides having to trust the integrity of the NEA Client and its ability to accurately collect and report Posture Attributes about the endpoint, we try to limit other assumed trust. Most of the usage models for NEA expect the posture information to be sent to the NEA Server for evaluation and decision making. When PA and/or PT level security protections are used, the endpoint needs to trust the integrity and potentially confidentiality of the trust anchor information (e.g., public key certificates) used by the Posture Collector and/or Posture Transport Client. However, NEA implementations may choose to send or pre-provision some policies to the endpoint for evaluation that would assume more trust in the endpoint. In this case, the NEA Server must trust the endpoint's policy storage, evaluation, and reporting mechanisms to not falsify the results of the posture evaluation.
終点でNEA Client、正確に集まる性能、およびレポートPosture Attributesの保全を信じなければならないこと以外に、私たちは他の想定された信頼を制限しようとします。 NEAの用法モデルの大部分は、姿勢情報が評価と意志決定のためにNEA Serverに送られると予想します。 PA、そして/または、PTの平らな機密保持が使用されているとき、終点は、保全を信じる必要があります、そして、潜在的に、信頼アンカー情報(例えば、公開鍵証明書)の秘密性はPosture Collector、そして/または、Posture Transport Clientを使用しました。 しかしながら、NEA実装が、発信するのを選ぶかもしれませんか、またはプレ支給は終点で、より多くの信頼を仮定する評価のための終点へのいくつかの方針を選びます。 この場合、NEA Serverは、姿勢評価の結果を改竄しないように終点の方針ストレージ、評価、および報告メカニズムを信じなければなりません。
Generally the endpoint should not trust network communications (e.g., inbound connection requests) unless this trust has been specifically authorized by the user or owner defined policy or action. The NEA reference model assumes the entire NEA Client is local to the endpoint. Unsolicited communications originating from the network should be inspected by normal host-based security protective mechanisms (e.g., firewalls, security protocols, Intrusion Detection/Prevention System (IDS/IPS), etc.). Communications associated with a NEA assessment or reassessment requires some level of trust particularly when initiated by the NEA Server (reassessment). The degree of trust can be limited by use of strong security protections on the messages as dictated by the network deployer and the endpoint user/owner policy.
この信頼がユーザ、所有者の定義された方針または動作で明確に認可されていない場合、一般に終点はネットワークコミュニケーション(例えば、本国行きの接続要求)を信じるべきではありません。 NEA規範モデルは、全体のNEA Clientが終点に地方であると仮定します。 正常なホストベースのセキュリティ保護的なメカニズム(例えば、ファイアウォール、セキュリティプロトコル、Intrusion Detection/防止System(IDS/IPS)など)によってネットワークから発する求められていないコミュニケーションは点検されるべきです。 特にNEA Server(再査定)によって開始されると、NEA査定か再査定に関連しているコミュニケーションは何らかのレベルの信頼を必要とします。 ネットワークデプロイヤと終点ユーザ/所有者方針で書き取られるようにメッセージにおける強い機密保持の使用で信頼の度合いを制限できます。
Sangster, et al. Informational [Page 40] RFC 5209 NEA Requirements June 2008
サングスタ、他 [40ページ]情報のRFC5209NEA要件2008年6月
8.1.2. Network Communications
8.1.2. ネットワークコミュニケーション
Between the NEA Client and Server, there may exist a variety of types of devices to facilitate the communication path. Some of the devices may serve as intermediaries (e.g., simple L2 switches) so they may have the opportunity to observe and change the message dialogs.
NEA ClientとServerの間では、通信路を容易にするさまざまなタイプのデバイスは存在するかもしれません。 いくつかのデバイスが仲介者として機能するかもしれないので(例えば、簡単なL2は切り替わります)、彼らには、メッセージ対話を観測して、変える機会があるかもしれません。
The intermediary devices may fall into a few major categories that impact our degree of trust in their operation. First, some intermediary devices may act as message forwarders or carriers for PT (e.g., L2 switches, L3 routers). For these devices we trust them not to drop the messages or actively attempt to disrupt (e.g., denial of service (DoS)) the NEA deployment.
媒介装置は彼らの操作における、私たちの信頼の度合いに影響を与えるいくつかの大範疇になるかもしれません。 まず最初に、いくつかの媒介装置がPT(例えば、L2スイッチ、L3ルータ)のためにメッセージ混載業者かキャリヤーとして作動するかもしれません。 これらのデバイスに関しては、私たちは、それらが、メッセージを下げないか、またはNEA展開を中断するのを(例えば、サービス(DoS)の否定)活発に試みないと信じます。
Second, some intermediary devices may be part of the access control layer of the network and as such, we trust them to enforce policies including remediation, isolation, and access controls given to them as a result on a NEA assessment. These devices may also fill other types of roles described in this section.
2番目に、いくつかの媒介装置がネットワークのアクセス制御層の一部であるかもしれません、そして、そういうものとして、私たちはそれらがNEA査定のときにその結果それらに与えられた治療教育、分離、およびアクセス制御を含む方針を実施すると信じます。 また、これらのデバイスはこのセクションで説明された他のタイプの役割をいっぱいにするかもしれません。
Third, some devices may act as a termination point or proxy for the PT carrier protocol. Frequently, it is expected that the carrier protocol for PT will terminate on the NEA Client and Server so will be co-resident with the PT endpoints. If this expectation is not present in a deployment, we must trust the termination device to accurately proxy the PT messages without alteration into the next carrier protocol (e.g., if inner EAP method messages are transitioned from an EAP [EAP] tunnel to a RADIUS session).
3番目に、いくつかのデバイスが太平洋標準時の間、終了ポイントかプロキシとしてキャリヤープロトコルを務めるかもしれません。 頻繁に、PTのためのキャリヤープロトコルがNEA Clientで終わるのでServerがコレジデントであるためにPT終点で望んでいると予想されます。 私たちは、どんなプレゼントもこの期待であるなら展開でないと正確に終了デバイスを信じなければなりません。次のキャリヤーへの変更のないPTメッセージが議定書の中で述べる(例えば、RADIUSセッションまで内側のEAPメソッドメッセージがEAPから移行した[EAP]トンネルであるなら)プロキシ。
Fourth, many networks include infrastructure such as IDS/IPS devices that monitor and take corrective action when suspicious behavior is observed on the network. These devices may have a relationship with the NEA Server that is not within scope for this specification. Devices trusted by the NEA Server to provide security information that might affect the NEA Server's decisions are trusted to operate properly and not cause the NEA Server to make incorrect decisions.
4番目に、多くのネットワークがネットワークで観測されていた状態で不審な挙動であるときに、修正措置をモニターして、取るIDS/IPSデバイスのようなインフラストラクチャを含んでいます。 これらのデバイスには、この仕様のための範囲の中にないNEA Serverとの関係があるかもしれません。 適切に作動して、NEA Serverの決定に影響するかもしれないセキュリティ情報を提供するとNEA Serverによって信じられたデバイスが、NEA Serverが不正確な決定をすることを引き起こさないと信じられます。
Finally, other types of intermediary devices may exist on the network between the NEA Client and Server that are present to service other network functions beside NEA. These devices might be capable of passively eavesdropping on the network, archiving information for future purposes (e.g., replay or privacy invasion), or more actively attacking the NEA protocols. Because these devices do not play a role in facilitating NEA, it is essential that NEA deployers not be forced to trust them for NEA to reliably operate. Therefore, it is required that NEA protocols offer security protections to assure these devices can't steal, alter, spoof or otherwise damage the reliability of the message dialogs.
最終的に、他のタイプの媒介装置はNEAの横で他のネットワーク機能を修理するために存在しているNEA ClientとServerの間にネットワークに存在するかもしれません。 これらのデバイスはネットワークを受け身に立ち聞きできるかもしれません、将来の目的(例えば、再生かプライバシー侵入)のための情報を格納するか、または、より活発にNEAプロトコルを攻撃して。 これらのデバイスがNEAを容易にすることにおける役割を果たさないので、NEAが確かに作動するようにNEAデプロイヤがやむを得ずそれらを信じないのは、不可欠です。 したがって、保証するプロトコルが機密保持をこれらのデバイスを申し出であるNEAがメッセージ対話の信頼性を横取りしない場合がありますし、変更しない場合がありますし、偽造しない場合がありますし、またそうでなければ、破損しない場合があるのが必要です。
Sangster, et al. Informational [Page 41] RFC 5209 NEA Requirements June 2008
サングスタ、他 [41ページ]情報のRFC5209NEA要件2008年6月
8.1.3. NEA Server
8.1.3. NEAサーバ
The NEA Server (including potentially remote systems providing posture validation services) is generally trusted to apply the specified assessment policies and must be protected from compromise. It is essential that NEA Server deployments properly safeguard these systems from a variety of attacks from the network and endpoints to assure their proper operation.
NEA Server(姿勢合法化サービスを提供する潜在的にリモートなシステムを含んでいる)を一般に、指定された査定方針を適用すると信じられて、感染から保護しなければなりません。 NEA Server展開が彼らの適切な操作を保証するためにさまざまな攻撃からネットワークと終点からこれらのシステムを適切に保護しているのは、不可欠です。
While there is a need to trust the NEA Server operation to some degree, rigorous security architecture, analysis, monitoring, and review should assure its network footprint and internal workings are protected from attack. The network footprint would include communications over the network that might be subject to attack such as policy provisioning from the policy authoring systems and general security and system management protocols. Some examples of internal workings include protections from malware attacking the intra-NEA Server communications, NEA Server internal logic, or policy stores (particularly those that would change the resulting decisions or enforcements). The NEA Server needs to trust the underlying NEA and lower layer network protocols to properly behave and safeguard the exchanged messages with the endpoint. The NEA reference model does not attempt to address integrity protection of the operating system or other software supporting the NEA Server.
NEA Server操作をある程度信じる必要がある間、厳密なセキュリティー体系、分析、モニター、およびレビューはネットワーク足跡を保証するべきです、そして、内部の作業は攻撃から保護されます。 ネットワーク足跡は、方針からオーサリングシステム、総合証券、およびシステム管理プロトコルに食糧を供給しながら、方針などのように攻撃するためになることがあるかもしれないネットワークの上にコミュニケーションを含んでいるでしょう。 内部の作業に関するいくつかの例がイントラ-NEA Serverコミュニケーションを攻撃するマルウェアからの保護、NEA Serverの内部の論理、または方針店(特に結果として起こる決定か実施を変えるもの)を含んでいます。 NEA Serverは、終点で適切に交換されたメッセージを振る舞って、保護するために基本的なNEAと下層ネットワーク・プロトコルを信じる必要があります。 NEA規範モデルは、保全がNEA Serverをサポートするオペレーティングシステムか他のソフトウェアの保護であると扱うのを試みません。
One interesting example is where some components of the NEA Server physically reside in different systems. This might occur when a Posture Validator (or a remote backend server used by a local Posture Validator) exists on another system from the Posture Broker Server. Similarly, the Posture Broker Server might exist on a separate system from the Posture Transport Server. When there is a physical separation, the communications between the remote components of the NEA Server must ensure that the PB session and PA message dialogs are resistant to active and passive attacks, in particular, guarded against eavesdropping, forgery and replay. Similarly, the Posture Validators may also wish to minimize their trust in the Posture Broker Server beyond its ability to properly send and deliver PA messages. The Posture Validators could employ end-to-end PA security to verify the authenticity and protect the integrity and/or confidentiality of the PA messages exchanged.
1つのおもしろい例がNEA Serverのいくつかの部品が異系統に物理的にあるところです。Posture Validator(または、地方のPosture Validatorによって使用されたリモートバックエンドサーバ)がPosture Broker Serverからの別のシステムの上に存在していると、これは起こるかもしれません。同様に、Posture Broker ServerはPosture Transport Serverからの別々のシステムの上に存在するかもしれません; 物理的分離があるとき、NEA Serverのリモート部品のコミュニケーションは、PBセッションとPAメッセージ対話は盗聴、偽造に対して特に警備されたアクティブで受け身の攻撃に抵抗力があるのを確実にして、再演されなければなりません。 また、同様に、Posture ValidatorsはPosture Broker Serverで彼らの信頼を適切にPAメッセージを送って、提供する性能を超えたところまで最小にしたがっているかもしれません。 Posture Validatorsは、信憑性について確かめて、メッセージが交換したPAの保全、そして/または、秘密性を保護するのに終わりから終わりへのPAセキュリティを使うかもしれません。
When PA security is used, each Posture Validator must be able to trust the integrity and potentially confidentiality of its trust anchor policies.
いつPAセキュリティは使用されていて、それぞれのPosture Validatorが保全を信じることができなければならないということですか、そして、潜在的に信頼アンカー方針の秘密性。
Sangster, et al. Informational [Page 42] RFC 5209 NEA Requirements June 2008
サングスタ、他 [42ページ]情報のRFC5209NEA要件2008年6月
8.2. Protection Mechanisms at Multiple Layers
8.2. 複数の層の保護メカニズム
Inherent in the requirements is a desire for NEA candidate protocols throughout the reference model to be capable of providing strong security mechanisms as dictated by the particular deployment. In some cases, these mechanisms may appear to provide overlapping or redundant protections. These apparent overlaps may be used in combination to offer a defense in depth approach to security. However, because of the layering of the protocols, each set of protections offers slightly different benefits and levels of granularity.
要件に固有であるのは、規範モデル中のNEA候補プロトコルが特定の展開で書き取られるように強いセキュリティー対策を提供できる願望です。 いくつかの場合、これらのメカニズムは重なるか余分な保護を提供するように見えるかもしれません。 これらの見かけのオーバラップは、セキュリティへの縦深防御アプローチを提供するのに組み合わせに使用されるかもしれません。 しかしながら、プロトコルのレイヤリングのために、それぞれのセットの保護は異なった利益とレベルの粒状をわずかに提供します。
For example, a deployer may wish to encrypt traffic at the PT layer to protect against some forms of traffic analysis or interception by an eavesdropper. Additionally, the deployer may also selectively encrypt messages containing the posture of an endpoint to achieve end-to-end confidentiality to its corresponding Posture Validator. In particular, this might be desired when the Posture Validator is not co-located with the NEA Server so the information will traverse additional network segments after the PT protections have been enforced or so that the Posture Validator can authenticate the corresponding Posture Collector (or vice versa).
例えば、デプロイヤは、立ち聞きする者によるいくつかの形式のトラヒック分析か妨害から守るためにPT層にトラフィックを暗号化したがっているかもしれません。 また、さらに、デプロイヤは、終わりから終わりへの秘密性を対応するPosture Validatorに達成するために選択的に終点の姿勢を含むメッセージを暗号化するかもしれません。 PT保護が励行された後に情報が追加ネットワークセグメントを横断するか、またはPosture Validatorが対応するPosture Collector(逆もまた同様である)を認証できるようにPosture ValidatorがNEA Serverと共に共同見つけられていないとき、特に、これは望まれるかもしれません。
Different use cases and environments for the NEA technologies will likely influence the selection of the strength and security mechanisms employed during an assessment. The goal of the NEA requirements is to encourage the selection of technologies and protocols that are capable of providing the necessary protections for a wide variety of types of assessment.
NEA技術のためのケースと環境がおそらくそうする異なった使用は査定の間に使われた強さとセキュリティー対策の品揃えに影響を及ぼします。 NEA要件の目標はさまざまなタイプの評価のための必要な保護を提供できる技術とプロトコルの品揃えを奨励することです。
8.3. Relevant Classes of Attack
8.3. 関連クラスの攻撃
A variety of attacks are possible against the NEA protocols and assessment technologies. This section does not include a full security analysis, but wishes to highlight a few attacks that influenced the requirement definition and should be considered by deployers selecting use of protective mechanisms within the NEA reference model.
さまざまな攻撃がNEAプロトコルと査定技術に対して可能です。 このセクションは完全な証券分析を含んでいません、要件定義に影響を及ぼしたいくつかの攻撃を強調することを願って、NEA規範モデルの中で保護的なメカニズムの使用を選択するデプロイヤによって考えられるべきであるのを除いて。
As discussed, there are a variety of protective mechanisms included in the requirements for candidate NEA protocols. Different use cases and environments may cause deployers to decide not to use some of these mechanisms; however, this should be done with an understanding that the deployment may become vulnerable to some classes of attack. As always, a balance of risk vs. performance, usability, manageability, and other factors should be taken into account.
議論するように、候補NEAプロトコルのための要件に含まれていたさまざまな保護的なメカニズムがあります。 デプロイヤがこれらのいくつかのメカニズムを使用しないようにケースと環境で決めるかもしれない異なった使用。 しかしながら、展開が数人のクラスの攻撃に被害を受け易くなるかもしれないという条件でこれをするべきです。 いつものように、性能、ユーザビリティ、管理可能性、およびリスク対他の要素のバランスは考慮に入れられるべきです。
Sangster, et al. Informational [Page 43] RFC 5209 NEA Requirements June 2008
サングスタ、他 [43ページ]情報のRFC5209NEA要件2008年6月
The following types of attacks are applicable to network protocols defined in the reference model and thus should be considered by deployers.
以下のタイプの攻撃は、規範モデルで定義されたネットワーク・プロトコルに適切であり、その結果、デプロイヤによって考えられるべきです。
8.3.1. Man-in-the-Middle (MITM)
8.3.1. 中央の男性(MITM)
MITM attacks against a network protocol exist when a third party can insert itself between two communicating entities without detection and gain benefit from involvement in their message dialog. For example, a malware infested system might wish to join the network replaying posture observed from a clean endpoint entering the network. This might occur by the system inserting itself into and actively proxying an assessment message dialog. The impact of the damage caused by the MITM can be limited or prevented by selection of appropriate protocol protective mechanisms.
第三者が検出なしで2つの交信実体の間にそれ自体を挿入して、それらのメッセージ対話におけるかかわり合いから利益を獲得できるとき、ネットワーク・プロトコルに対するMITM攻撃は存在しています。 例えば、マルウェアの出没されたシステムはネットワークに入る清潔な終点から観測された姿勢を再演するネットワークに加わりたがっているかもしれません。 これ自体がシステム挿入で起こるかもしれなくて、活発に査定をproxyingするのが通信する、対話。 適切なプロトコル保護的なメカニズムの品揃えでMITMによってもたらされた損害の影響を制限するか、または防ぐことができます。
For example, the requirement for PT to be capable of supporting mutual authentication prior to any endpoint assessment message dialogs prevents the attacker from inserting itself as an active participant (proxy) within the communications without detection (assuming the attacker lacks credentials convincing either party it is legitimate). Reusable credentials should not be exposed on the network to assure the MITM doesn't have a way to impersonate either party. The PT requirement for confidentiality-protected (encrypted) communications linked to the above authentication prevents a passive MITM from eavesdropping by observing the message dialog and keeping a record of the conformant posture values for future use. The PT requirement for replay prevention stops a passive MITM from later establishing a new session (or hijacking an existing session) and replaying previously observed message dialogs.
例えば、PTがどんな終点査定メッセージ対話の前にも互いの認証をサポートすることができるという要件によって、攻撃者は積極的な参加者(プロキシ)としてコミュニケーションの中で検出(攻撃者がそれが正統であると何れの当事者に納得させる資格証明書を欠いていると仮定する)なしでそれ自体を挿入できません。 再利用できる資格証明書は保証するためにネットワークで暴露されて、MITMには何れの当事者をまねる方法がないということであるべきではありません。 上の認証にリンクされた秘密性で保護された(暗号化された)コミュニケーションのためのPT要件は、受け身のMITMが今後の使用のためにメッセージ対話を観測して、conformant姿勢値に関する記録をつけることによって盗み聞くのを防ぎます。 再生防止のためのPT要件は、受け身のMITMが後で新しいセッションを確立するのを止めます、そして、(既存のセッションをハイジャックして)以前に再演するのはメッセージ対話を観測しました。
If a non-compliant, active MITM is able to trick a clean endpoint to give up its posture information, and the MITM has legitimate credentials, it might be able to appear to a NEA Server as having compliant posture when it does not. For example, a non-compliant MITM could connect and authenticate to a NEA Server and as the NEA Server requests posture information, the MITM could request the same posture from the clean endpoint. If the clean endpoint trusts the MITM to perform a reassessment and is willing to share the requested posture, the MITM could obtain the needed posture from the clean endpoint and send it to the NEA Server. In order to address this form of MITM attack, the NEA protocols would need to offer a strong (cryptographic) binding between the posture information and the authenticated session to the NEA Server so the NEA Server knows the posture originated from the endpoint that authenticated. Such a strong binding between the posture's origin and the authenticating endpoint may be feasible so should be preferred by the NEA WG.
現れることができないとき、不従順で、アクティブなMITMが姿勢情報をあきらめるために清潔な終点をだますことができて、MITMに正統の資格証明書があるなら、対応する姿勢を持っているとしてNEA Serverにおいて現れることができるかもしれません。 例えば、不従順なMITMはNEA ServerとNEA Server要求姿勢として情報を接続して、認証できて、MITMは清潔な終点から同じ姿勢を要求できました。 清潔な終点が、MITMが再査定を実行すると信じて、要求された姿勢を共有しても構わないと思っているなら、MITMは清潔な終点から必要な姿勢を得て、それをNEA Serverに送るかもしれません。NEAプロトコルは、この形式のMITM攻撃を扱うのに強い(暗号の)結合を姿勢情報とNEA Serverへの認証されたセッションの間に提供する必要があるでしょう、したがって、NEA Serverは姿勢がそれが認証した終点から発したのを知っています。 姿勢の発生源と認証終点の間のそのような強い結合が可能であるかもしれないので、NEA WGによって好まれるはずです。
Sangster, et al. Informational [Page 44] RFC 5209 NEA Requirements June 2008
サングスタ、他 [44ページ]情報のRFC5209NEA要件2008年6月
8.3.2. Message Modification
8.3.2. メッセージ変更
Without message integrity protection, an attacker capable of intercepting a message might be capable of modifying its contents and causing an incorrect decision to be made. For example, the attacker might change the Posture Attributes to always reflect incorrect values and thus prevent a compliant system from joining the network. Unless the NEA Server could detect this change, the attacker could prevent admission to large numbers of clean systems. Conversely, the attacker could allow a malware infested machine to be admitted by changing the sent Posture Attributes to reflect compliant values, thus hiding the malware from the Posture Validator. The attacker could also infect compliant endpoints by sending malicious remediation instructions that, when performed, would introduce malware on the endpoint or deactivate security mechanisms.
メッセージの保全保護がなければ、通信を傍受できる攻撃者は、コンテンツを変更して、作られているという不正確な決定を引き起こすことができるかもしれません。 例えば、攻撃者は、いつも不正確な値を反映して、その結果、対応するシステムがネットワークに加わるのを防ぐためにPosture Attributesを変えるかもしれません。 NEA Serverがこの変化を検出できないなら、攻撃者は多くの清潔なシステムに入場を防ぐことができるでしょうに。逆に、攻撃者は対応する値を反映するために送られたPosture Attributesを変えることによって、マルウェアの出没されたマシンを認めさせることができるでしょう、その結果、Posture Validatorからマルウェアを隠します。 攻撃者は、また、実行されると悪意がある治療教育指示にそれを送ることによって言いなりになっている終点を感染させることができるだろうか、終点でマルウェアを紹介するか、またはセキュリティー対策を非活性化するでしょう。
In order to protect against such attacks, the PT includes a requirement for strong integrity protection (e.g., including a protected hash like a Hashed Message Authentication Code (HMAC) [HMAC] of the message) so any change to a message would be detected. PA includes a similar requirement to enable end-to-end integrity protection of the attributes, extending the protection all the way to the Posture Validator even if it is located on another system behind the NEA Server.
太平洋標準時がそのような攻撃から守るために強い保全保護(例えば、メッセージに関するHashedメッセージ立証コード(HMAC)[HMAC]のような保護されたハッシュを含んでいる)のための要件を含んでいるので、メッセージへのどんな変化も検出されるでしょう。 PAは終わりから終わりへの属性の保全保護を可能にするという同様の要件を含んでいます、それがNEA Serverの後ろに別のシステムに位置していても保護をPosture Validatorまでのいっぱいに広げていて。
It is important that integrity protection schemes leverage fresh secret information (not known by the attacker) that is bound to the authenticated session such as an HMAC using a derived fresh secret associated with the session. Inclusion of freshness information allows the parties to protect against some forms of message replay attacks using secret information from prior sessions.
保全保護体系がセッションに関連している派生している新鮮な秘密を使用することでHMACなどの認証されたセッションまで縛られる新鮮な秘密の情報(攻撃者によって知られない)を利用するのは、重要です。 新しさ情報の包含で、パーティーは、先のセッションから秘密の情報を使用することでいくつかのフォームのメッセージ反射攻撃から守ることができます。
8.3.3. Message Replay or Attribute Theft
8.3.3. メッセージ再生か属性窃盗
An attacker might listen to the network, recording message dialogs or attributes from a compliant endpoint for later reuse to the same NEA Server or just to build an inventory of software running on other systems watching for known vulnerabilities. The NEA Server needs to be capable of detecting the replay of posture and/or the model must assure that the eavesdropper cannot obtain the information in the first place. For this reason, the PT protocol is required to provide confidentiality and replay prevention.
攻撃者はネットワークを聞くかもしれません、同じNEA Serverへの後の再利用かただ知られている脆弱性を待ち兼ねる他のシステムで動くソフトウェアの目録を造るために言いなりになっている終点からメッセージ対話か属性を記録して。 NEA Serverは、姿勢の再生を検出できる必要があります、そして、モデルは立ち聞きする者が第一に情報を得ることができないことを保証しなければなりません。 この理由、秘密性を提供するプロトコルが必要である太平洋標準時、および再生防止のために。
The cryptographic protection from disclosure of the PT, PB, or PA messages prevents the passive listener from observing the exchanged messages and thus prevents theft of the information for future use. However, an active attacker might be able to replay the encrypted message if there is no strong link to the originating party or
太平洋標準時、PB、またはPAメッセージの公開からの暗号の保護は、受け身のリスナーが交換されたメッセージを観測するのを防いで、その結果、今後の使用のための情報の窃盗を防ぎます。 またはしかしながら、起因するパーティーへのどんな強いリンクもなければ活発な攻撃者が暗号化メッセージを再演できるかもしれない。
Sangster, et al. Informational [Page 45] RFC 5209 NEA Requirements June 2008
サングスタ、他 [45ページ]情報のRFC5209NEA要件2008年6月
session. By linking the encrypted message dialog to the authentication event and leveraging per-transaction freshness and keying exchanges, this prevents a replay of the encrypted transaction.
セッション。 暗号化メッセージ対話を認証イベントにリンクして、1トランザクションあたりの新しさを利用して、交換を合わせることによって、これは暗号化されたトランザクションの再生を防ぎます。
8.3.4. Other Types of Attack
8.3.4. 他のタイプの攻撃
This section doesn't claim to present an exhaustive list of attacks against the NEA reference model. Several types of attack will become easier to understand and analyze once the NEA WG has created specifications describing the specific selected technologies and protocols to be used within NEA. One such area is Denial of Service (DoS). At this point in time, it is not practical to try to define all of the potential exposures present within the NEA protocols, so such an analysis should be included in the Security Considerations sections of the selected NEA protocols.
このセクションは、NEA規範モデルに対して攻撃に関する完全なりストを提示すると主張しません。 NEA WGがいったんNEAの中で使用されるために特定の選択された技術とプロトコルについて説明する仕様を作成すると、いくつかのタイプの攻撃は理解して、分析するのが、より簡単になるでしょう。 そのような領域の1つはサービス妨害(DoS)です。 この時点で、そのような分析が選択されたNEAプロトコルのSecurity Considerations部に含まれるべきであって、NEAプロトコルの中の現在の潜在被曝のすべてを定義しようとするのは実用的ではありません。
However, it is important that the NEA Server be resilient to DoS attacks as an outage might affect large numbers of endpoints wishing to join or remain on the network. The NEA reference model expects that the PT protocol would have some amount of DoS resilience and that the PA and PB protocols would need to build upon that base with their own protections. To help narrow the window of attack by unauthenticated parties, it is envisioned that NEA Servers would employ PT protocols that enable an early mutual authentication of the requesting endpoint as one technique for filtering out attacks.
しかしながら、ネットワークに接合するか、または残っていることを願いながら供給停止が多くの終点に影響するかもしれないのでNEA ServerはDoS攻撃に弾力があるのが、重要です。 規範モデルが予想する太平洋標準時が議定書の中で述べるNEAはそれら自身の保護と共にPAとPBプロトコルがそのベースを当てにするために必要とするDoS弾力とそのいくらかの量を持っているでしょう。 非認証されたパーティーによる攻撃の窓を狭くするのを助けるために、思い描かれて、そのNEA Serversがだんだん知られるためのあるテクニックが攻撃されるとき要求終点の早めの互いの認証を可能にするPTプロトコルを使うだろうということです。
Attacks occurring after the authentication would at least come from sources possessing valid credentials and could potentially be held accountable. Similarly, NEA protocols should offer strong replay protection to prevent DoS-based attacks based on replayed sessions and messages. Posture assessment should be strongly linked with the Posture Transport authentications that occurred to assure the posture came from the authenticated party. Cryptographic mechanisms and other potentially resource intensive operations should be used sparingly until the validity of the request can be established. This and other resource/protocol based attacks can be evaluated once the NEA technologies and their cryptographic use have been selected.
認証がソースから少なくとも来た後に起こる攻撃は、正当な証明書を持って、潜在的に責任があるように保つことができました。 同様に、NEAプロトコルは、再演されたセッションとメッセージに基づくDoSベースの攻撃を防ぐために強い反復操作による保護を提供するべきです。 姿勢査定は姿勢が認証されたパーティーから強く保証するために起こったPosture Transport認証にリンクされる状態で来たということであるべきです。 暗号のメカニズムと他の潜在的にリソース徹底的な操作は要求の正当性を確立できるまで控えめに使用されるべきです。 NEA技術と彼らの暗号の使用がいったん選択されると、これとプロトコルに他のリソース/基づいている攻撃を評価できます。
9. Privacy Considerations
9. プライバシー問題
While there are a number of beneficial uses of the NEA technology for organizations that own and operate networks offering services to similarly owned endpoints, these same technologies might enhance the potential for abuse and invasion of personal privacy if misused. This section will discuss a few of the potential privacy concerns raised by the deployment of this technology and offer some guidance to implementers.
同様に所有されている終点に対するサービスを提供しながらネットワークを所有して、経営する組織のためのNEA技術の多くの有益な用途がある間、誤用されるなら、これらの同じ技術は個人のプライバシーの乱用と侵入の可能性を高めるかもしれません。 このセクションは、この技術の展開で提起された潜在的プライバシーの問題のいくつかについて論じて、何らかの指導をimplementersに提供するでしょう。
Sangster, et al. Informational [Page 46] RFC 5209 NEA Requirements June 2008
サングスタ、他 [46ページ]情報のRFC5209NEA要件2008年6月
The NEA technology enables greater visibility into the configuration of an endpoint from the network. Such transparency enables the network to take into consideration the strength of the endpoint's security mechanisms when making access control decisions to network resources. However, this transparency could also be used to enforce restrictive policies to the detriment of the user by limiting their choice of software or prying into past or present uses of the endpoint.
NEA技術はネットワークから、より大きい目に見えることを終点の構成に可能にします。 アクセスをネットワーク資源とのコントロール決定にするとき、そのような透明は、ネットワークが終点のセキュリティー対策の強さを考慮に入れるのを可能にします。 しかしながら、また、彼らのソフトウェアの選択を制限するか、または終点の過去の、または、現在の用途をせんさくすることによってユーザの損傷に引締政策を実施するのにこの透明を使用できました。
The scope of the NEA WG was limited to specifying protocols targeting the use cases where the endpoints and network are owned by the same party or the endpoint owner has established a clear expectation of disclosure/compliance with the network owner. This is a familiar model for governments, institutions, and a wide variety of enterprises that provide endpoints to their employees to perform their jobs. In many of these situations, the endpoint is purchased and owned by the enterprise and they often reserve the right to audit and possibly dictate the allowable uses of the device. The NEA technologies allow them to automate the inspection of the contents of an endpoint and this information may be linked to the access control mechanisms on the network to limit endpoint use should the endpoint not meet minimal compliance levels.
NEA WGの範囲による使用を狙うプロトコルを指定するのに制限されて、終点とネットワークが同じくらいによって所有されているところでケースがパーティーへ行くか、または終点所有者がネットワーク所有者への公開/承諾への明確な期待を確立したということでした。 これは政府(彼らの仕事をするために彼らの従業員に終点を提供する団体、および広いバラエティーの企業)の身近なモデルです。 終点がこれらの状況の多くでは、企業によって購入されて、所有されていて、彼らは、しばしば監査権を保有して、ことによるとデバイスの許容できる用途を書き取ります。 NEA技術で終点のコンテンツの点検を自動化できます、そして、この情報は終点が最小量の承諾レベルを満たさないなら限界終点へのネットワークのメカニズムが使用するアクセス制御にリンクされるかもしれません。
In these environments, the level of personal privacy the employee enjoys may be significantly reduced subject to local laws and customs. However, in situations where the endpoint is owned by the user or where local laws protect the rights of the user even when using endpoints owned by another party, it is critical that the NEA implementation enable the user to control what endpoint information is shared with the network. Such controls imposed by the user might prevent or limit their ability to access certain networks or protected resources, but this must be a user choice.
これらの環境で、地域法と習慣を条件として従業員が楽しむ個人のプライバシーのレベルはかなり減少するかもしれません。しかしながら、別の人によって所有されていた終点を使用さえするとき終点がユーザによって所有されているか、または地域法がユーザの権利を保護する状況で、NEA実装が、ユーザが、どんな終点情報がネットワークと共有されるかを制御するのを可能にするのは、重要です。 ユーザによって設けられたそのような規制は、あるネットワークか保護されたリソースにアクセスする彼らの能力を防ぐか、または制限するかもしれませんが、これはユーザ選択であるに違いありません。
9.1. Implementer Considerations
9.1. Implementer問題
The NEA WG is not defining NEA Client policy content standards nor defining requirements on aspects of an implementation outside of the network protocols; however, the following guidance is provided to encourage privacy friendly implementations for broader use than just the enterprise-oriented setting described above.
NEA WGはネットワーク・プロトコルの外でNEA Client方針内容規格を定義して、実装の局面に関する要件は定義していません。 しかしながら、まさしく上で説明された企業指向の設定より広い使用のためにプライバシーの好意的な実装を奨励するために以下の指導を提供します。
NEA Client implementations are encouraged to offer an opt-in policy to users prior to sharing their endpoint's posture information. The opt-in mechanism should be on a per-user, per-NEA Server basis so each user can control which networks can access any posture information on their system. For those networks that are allowed to assess the endpoint, the user should be able to specify granular restrictions on what particular types and specific attributes Posture
彼らの終点の姿勢情報を共有する前にNEA Client実装がオプトイン方針をユーザに提供するよう奨励されます。 ユーザの上にオプトインメカニズムがあるはずであり、各ユーザがどのネットワークを制御できるように、1NEA Serverあたりの基礎はそれらのシステムのどんな姿勢情報にもアクセスできるか。 終点を評価できるそれらのネットワークにおいて、ユーザはどんな特定のタイプの、そして、特定の属性Postureで粒状の制限を指定できるべきであるか。
Sangster, et al. Informational [Page 47] RFC 5209 NEA Requirements June 2008
サングスタ、他 [47ページ]情報のRFC5209NEA要件2008年6月
Collectors are allowed to disclose. Posture Validator implementations are discouraged from having the default behavior of using wild carded requests for posture potentially leading to overexposure of information (see section 9.2). Instead Posture Validators, by default, should only request the specific attributes that are required to perform their assessment.
コレクタは明らかにすることができます。 姿勢Validator実装は、姿勢に潜在的にワイルドなcarded要求を使用するデフォルトの振舞いを持っていて、情報の露出過度に通じながら、がっかりしています(セクション9.2を見てください)。 代わりに、Posture Validatorsは、デフォルトで彼らの査定を実行するよう必要である特定の属性に要求するだけであるはずです。
Requests for attributes that are not explicitly allowed (or specifically disallowed) to be shared should result in a user notification and/or log record so the user can assess whether the service is doing something undesirable or whether the user is willing to share this additional information in order to gain access. Some products might consider policy-driven support for prompting the user for authorization with a specific description of the posture information being requested prior to sending it to the NEA Server.
サービスが何か望ましくないことをしているか否かに関係なく、ユーザが評価できるか、またはユーザが、アクセサリーを獲得するためにこの追加情報を共有しても構わないと思っていることにかかわらず明らかに共有できない(または、明確に禁じられます)属性を求める要求はユーザ通知、そして/または、ログ記録をもたらすべきです。 いくつかの製品がそれをNEA Serverに送る前に姿勢情報の明確な記述が要求されている状態で承認のためにユーザをうながす方針駆動のサポートを考えるかもしれません。
It is envisioned that the owner of the endpoint is able to specify disclosure policies that may override or influence the user's policies on the attributes visible to the network. If the owner disclosure policy allows for broader posture availability than the user policy, the implementation should provide a feedback mechanism to the user so they understand the situation and can choose whether to use the endpoint in those circumstances.
それは思い描かれます。終点の所有者はネットワークに目に見える属性に関するユーザの方針にくつがえすか、または影響を及ぼすかもしれない公開方針を指定できます。 所有者公開方針がユーザ方針より広い姿勢の有用性を考慮するなら、彼らが、状況を察して、それらの事情で終点を使用するかどうかを選ぶことができるように、実装はフィードバック・メカニズムをユーザに提供するべきです。
In such a system, it is important that the user's policy authoring interface is easy to understand and clearly articulates the current disclosure policy of the system including any influences from the owner policy. Users should be able to understand what posture is available to the network and the general impact of this information being known. In order to minimize the list of restrictions enumerated, use of a conservative default disclosure policy such as "that which is not explicitly authorized for disclosure is not allowed" might make sense to avoid unintentional leakage of information.
そのようなシステムでは、ユーザの方針の書いているインタフェースが分かり易く、所有者方針からシステムがどんな影響も含む現在の公開方針を明確に明確に話すのは、重要です。 ユーザは、どんな姿勢が知られているこの情報のネットワークと一般的な影響に利用可能であるかを理解できるべきです。 列挙された制限のリストを最小にするために、「公開のために明らかに認可されないそれは許容などにされていないことなど」の保守的なデフォルト公開方針の使用が情報の意図的でない漏出を避ける意味になるかもしれません。
NEA Server implementations should provide newly subscribing endpoints with a disclosure statement that clearly states:
NEA Server実装は、新たに終点を申し込むのをそれが明確に述べる開示説明書を提供するべきです:
o What information is required
o どんな情報が必要ですか。
o How this information will be used and protected
o この情報は、どう使用されて、保護されるだろうか。
o What local privacy policies are applicable
o どんな地方のプライバシーに関する方針が適切ですか?
This information will empower subscribing users to decide whether the disclosure of this information is acceptable considering local laws and customs.
この情報は、ユーザを申し込むのが、地域法と習慣を考える場合この情報の公開が許容できるかどうか決めるのに権限を与えるでしょう。
Sangster, et al. Informational [Page 48] RFC 5209 NEA Requirements June 2008
サングスタ、他 [48ページ]情報のRFC5209NEA要件2008年6月
9.2. Minimizing Attribute Disclosure
9.2. 属性公開を最小にします。
One important issue in the design of the NEA reference model and protocols is enabling endpoints to disclose minimal information required to establish compliance with network policies. There are several models that could be considered as to how the disclosed attribute set is established. Each model has privacy related benefits and issues that should be considered by product developers. This section summarizes three potential models for how attribute disclosure might be provided within NEA products and some privacy implications potentially associated with each model.
NEA規範モデルとプロトコルのデザインにおける1つの切迫した課題は最小量の情報を明らかにする可能な終点がネットワーク方針へのコンプライアンスを確立するのが必要であるということです。 明らかにされた属性セットがどう設立されるかに関して考えることができた数個のモデルがあります。 各モデルには、プライバシー関連する利益と製品開発者によって考えられるべきである問題があります。 このセクションは、潜在的に各モデルに関連しているNEA製品といくつかのプライバシー含意の中でどう属性公開を提供できるように3つの潜在的モデルをまとめるか。
The first model is easy to implement and deploy but has privacy and potentially latency and scalability implications. This approach effectively defaults the local policy to send all known NEA Posture Attributes when an assessment occurs. While this might simplify deployment, it exposes a lot of information that is potentially not relevant to the security assessment of the system and may introduce privacy issues. For example, is it really important that the enterprise know whether Firefox is being used on a system instead of other browsers during the security posture assessment?
第1代モデルは、実装して、配布するのが簡単ですが、プライバシー、潜在的に潜在、およびスケーラビリティ意味を持っています。 事実上、このアプローチはデフォルトとします。査定であるときにすべての知られているNEA Posture Attributesを送るローカルの方針は起こります。 これは展開を簡素化しますが、それは、潜在的にシステムのセキュリティ査定に関連していない多くの情報を暴露して、プライバシーの問題を紹介するかもしれません。 例えば、企業が、ファイヤーフォックスが警戒姿勢査定の間の他のブラウザの代わりにシステムの上で使用されているかどうかを知っているのがそれは本当に重要ですか?
The second model involves an out-of-band provisioning of the disclosure policy to all endpoints. This model may involve the enterprise establishing policy that a particular list of attributes must be provided when a NEA exchange occurs. Endpoint privacy policy may filter this attribute list, but such changes could cause the endpoint not to be given network or resource access. This model simplifies the network exchange as the endpoint always sends the filtered list of attributes when challenged by a particular network. However, this approach requires an out-of-band management protocol to establish and manage the NEA disclosure policies of all systems.
公開方針がすべての終点に食糧を供給しながら、第2代モデルはバンドのアウトにかかわります。 NEA交換が起こると、このモデルは属性の特定のリストを提供しなければならない企業制定方針にかかわるかもしれません。 終点プライバシーに関する方針はこの属性リストをフィルターにかけるかもしれませんが、そのような変化で、ネットワークかリソースアクセサリーを終点に与えることができませんでした。 特定のネットワークによって挑戦されると終点がいつも属性のフィルターにかけることのリストを送るのに応じて、このモデルはネットワーク交換を簡素化します。 しかしながら、このアプローチは、すべてのシステムのNEA公開方針を確立して、管理するためにバンドで出ている管理プロトコルを必要とします。
The third model avoids the need for pre-provisioning of a disclosure policy by allowing the NEA Server to specifically request what attributes are required. This is somewhat analogous to the policy being provisioned during the NEA exchanges so is much easier to manage. This model allows for the NEA Server to iteratively ask for attributes based on the values of prior attributes. Note, even in this model the NEA protocols are not expected to be a general purpose query language, but rather allow the NEA Server to request specific attributes as only the defined attributes are possible to request. For example, an enterprise might ask about the OS version in the initial message dialog and after learning the system is running Linux ask for a different set of attributes specific to Linux than it would if the endpoint was a Windows system. It is envisioned that this
NEA Serverが、属性が何であるかということであることが必要であるよう明確に要求するのを許容することによって、第3代モデルは公開方針のプレの食糧を供給することの必要性を避けます。 これがNEA交換の間に食糧を供給される方針にいくらか類似しているので、多くはより管理しやすいですか? このモデルは、NEA Serverが繰り返しに先の属性の値に基づく属性を求めるのを許容します。 NEAプロトコルが汎用の照会言語でないと予想されることにこのモデルでさえ注意しなさい、ただし、定義された属性だけが要求するのにおいて可能であるので、NEA Serverに特定の属性をむしろ要求させてください。 例えば、企業は、初期のメッセージ対話におけるOSバージョンに関して尋ねて、システムがリナックスを実行していることを学んだ後に、リナックスに特定の属性の終点がWindowsシステムであるならそうするのと異なったセットを求めるかもしれません。 それが思い描かれる、それ、これ
Sangster, et al. Informational [Page 49] RFC 5209 NEA Requirements June 2008
サングスタ、他 [49ページ]情報のRFC5209NEA要件2008年6月
approach might minimize the set of attributes sent over the network if the assessment is of a complex system (such as trying to understand what patches are missing from an OS).
アプローチは査定が複合システム(どんなパッチがOSからなくなるかを理解などになろうとすることなどの)のものであるならネットワークの上に送られた属性のセットを最小にするかもしれません。
In each model, the user could create a set of per-network privacy filter policies enforced by the NEA Client to prevent the disclosure of attributes felt to be personal in nature or not relevant to a particular network. Such filters would protect the privacy of the user but might result in the user not being allowed access to the desired asset (or network) or being provided limited access.
各モデルでは、ユーザは特定のネットワークに関連していた状態で現実に個人的であると感じられた属性の公開を防ぐためにNEA Clientによって励行された1セットの1ネットワークあたりのプライバシーフィルタ方針を作成できました。 そのようなフィルタは、ユーザのプライバシーを保護するでしょうが、必要な資産(または、ネットワーク)へのアクセスが許されてもいませんし、限られたアクセサリーが提供もされないユーザをもたらすかもしれません。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[UTF8]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
10.2. Informative References
10.2. 有益な参照
[802.1X] IEEE Standards for Local and Metropolitan Area Networks:
Port based Network Access Control, IEEE Std 802.1X-2001,
June 2001.
地方とメトロポリタンエリアネットワークの[802.1X]IEEE規格: ポートは2001年6月にNetwork Access Control、IEEE Std 802.1X-2001を基礎づけました。
[CNAC] Cisco, Cisco's Network Admission Control Main Web Site,
http://www.cisco.com/go/nac
[CNAC]シスコ、シスコのネットワークの入場のコントロールの主なウェブサイト、 http://www.cisco.com/go/nac
[EAP] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol (EAP)",
RFC 3748, June 2004.
[EAP] AbobaとB.とBlunkとL.とVollbrechtとJ.とカールソン、J.とH.Levkowetz、エド、「拡張認証プロトコル(EAP)」、RFC3748(2004年6月)
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February
1997.
[HMAC] Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[IPSEC] Kent, S. and K. Seo, "Security Architecture for the Internet
Protocol", RFC 4301, December 2005.
[IPSEC] ケントとS.とK.Seo、「インターネットプロトコルのためのセキュリティー体系」、RFC4301、2005年12月。
[NAP] Microsoft, Network Access Protection Main Web Site,
http://www.microsoft.com/nap
[毛羽立てます] マイクロソフト、ネットワークのアクセスの保護の主なウェブサイト、 http://www.microsoft.com/nap
[RADIUS] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865,
June 2000.
[半径]Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」、RFC2865(2000年6月)。
Sangster, et al. Informational [Page 50] RFC 5209 NEA Requirements June 2008
サングスタ、他 [50ページ]情報のRFC5209NEA要件2008年6月
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLS] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[TCG] Trusted Computing Group, Main TCG Web Site,
http://www.trustedcomputinggroup.org/
[TCG]信頼できるコンピューティンググループ、主なTCGウェブサイト、 http://www.trustedcomputinggroup.org/
[TNC] Trusted Computing Group, Trusted Network Connect Main Web
Site, https://www.trustedcomputinggroup.org/groups/network/
グループ、信じられたネットワークを計算しながら信じられた[TNC]は主なウェブサイト、 https://www.trustedcomputinggroup.org/groups/network/ を接続します。
11. Acknowledgments
11. 承認
The authors of this document would like to acknowledge the NEA Working Group members who have contributed to previous requirements and problem statement documents that influenced the direction of this specification: Kevin Amorin, Parvez Anandam, Diana Arroyo, Uri Blumenthal, Alan DeKok, Lauren Giroux, Steve Hanna, Thomas Hardjono, Tim Polk, Ravi Sahita, Joe Salowey, Chris Salter, Mauricio Sanchez, Yaron Sheffer, Jeff Six, Susan Thompson, Gary Tomlinson, John Vollbrecht, Nancy Winget, Han Yin, and Hao Zhou.
このドキュメントの作者は前の要件に貢献したNEA作業部会のメンバーとこの仕様の方向に影響を及ぼした問題声明ドキュメントを承認したがっています: クリス製塩業者(マウリシオ・サンチェス)のケビンAmorin、Parvez Anandam、ダイアナ・アロヨ、ユリ・ブルーメンソル、アランDeKok、ローレン・ジルー、スティーブ・ハンナ、トーマスHardjono、ティム・ポーク、ラービーSahita、ジョーSalowey、ヤロン・シェーファー、ジェフSix、スーザントンプソン、ゲーリー・トムリンスン、ジョンVollbrecht、ナンシーWinget、ハン殷、およびハオ・周。
Sangster, et al. Informational [Page 51] RFC 5209 NEA Requirements June 2008
サングスタ、他 [51ページ]情報のRFC5209NEA要件2008年6月
Authors' Addresses
作者のアドレス
Paul Sangster Symantec Corporation 6825 Citrine Dr Carlsbad, CA 92009 USA Phone: +1 760 438-5656 EMail: Paul_Sangster@symantec.com
カールスバッド博士、ポールサングスタSymantec Corporation6825レモン色カリフォルニア92009米国は以下に電話をします。 +1 760 438-5656 メールしてください: Paul_Sangster@symantec.com
Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 0334 EMail: hormuzd.m.khosravi@intel.com
第25Hormuzd Khosraviインテル2111Ne Avenueヒースボロー、または97124米国電話: +1 0334年の503 264メール: hormuzd.m.khosravi@intel.com
Mahalingam Mani Avaya Inc. 1033 McCarthy Blvd. Milpitas, CA 95035 USA Phone: +1 408 321-4840 EMail: mmani@avaya.com
MahalingamマニAvaya Inc.1033マッカーシーBlvd. カリフォルニア95035ミルピタス(米国)は以下に電話をします。 +1 408 321-4840 メールしてください: mmani@avaya.com
Kaushik Narayan Cisco Systems Inc. 10 West Tasman Drive San Jose, CA 95134 Phone: +1 408 526-8168 EMail: kaushik@cisco.com
サンノゼ、カリフォルニア 95134が電話をするカウシィクナーラーヤンシスコシステムズ株式会社10の西タスマンDrive: +1 408 526-8168 メールしてください: kaushik@cisco.com
Joseph Tardo Nevis Networks 295 N. Bernardo Ave., Suite 100 Mountain View, CA 94043 USA EMail: joseph.tardo@nevisnetworks.com
ジョゼフTardoのネヴィスが295N.ベルナルドAveをネットワークでつなぐ、Suite100カリフォルニア94043マウンテンビュー(米国)は以下をメールします。 joseph.tardo@nevisnetworks.com
Sangster, et al. Informational [Page 52] RFC 5209 NEA Requirements June 2008
サングスタ、他 [52ページ]情報のRFC5209NEA要件2008年6月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Sangster, et al. Informational [Page 53]
サングスタ、他 情報[53ページ]
一覧
スポンサーリンク
