Network Endpoint Assess Working Jiwei. Wei Group Ke. Jia Internet-Draft Han. Yin Intended status: Standards Track Huawei Technologies Expires: May 13, 2008 November 10, 2007 Mutual Network Endpoint Assessment draft-wei-nea-mnea-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 13, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract A method for mutual network endpoint assessment is introduced in this document. In current NEA requirements, only the assessment performed by network owner is described. However, for some applications like online business and file sharing, the unilateral assessment is not enough to ensure the two communication parties are both secure Especially in P2P application, the endpoints perform equal responsibility and hence the mutual network endpoint assessment seems Wei, et al. Expires May 13, 2008 [Page 1] Internet-Draft Mutual Network Endpoint Assessment November 2007 more necessary. each endpoint may configure its security assessment policy based on its own security concerns. . Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Reference Model . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Abbreviation . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Wei, et al. Expires May 13, 2008 [Page 2] Internet-Draft Mutual Network Endpoint Assessment November 2007 1. Introduction In Current NEA architecture, network owner collects the posture information of the network endpoint via the nea client, judge the compliance with the security policy and then makes a decision about the access request according to the assessment result. Only those endpoints that are compliant with the security policy can access the network; while, those who are not compliant can not access the network，instead by following the updating instruction. This method only describes how the network owner perform the assessment of network endpoints unilaterally. However, in some cases, such as P2P applications, each endpoint acts as a server and a client of its peer simultaneously and hence each of them should collect and then assess the posture information from the peer. As a complementarity of the current NEA, this document defines such mutual assessment method. . 2. Reference Model In mutual Network Endpoint Assessment reference model，every network endpoint can perform the assessment of the peer as well as can assist the peer in assessing itself. Therefore, every endpoint can decide whether or not to continue the subsequent interaction according to the peer's compliance with its security policy. The mutual Network Endpoint Assessment reference model is shown as following figure. PA, PB and PT layer is the same as the current NEA model. Posture Peer(PP) has the function of both PC and PV; Posture Broker peer(PBP) has the function of both PBC and PBS; Posture Transport Peer(PTP) has the function of both PTS and PTC. Wei, et al. Expires May 13, 2008 [Page 3] Internet-Draft Mutual Network Endpoint Assessment November 2007 |-------------| |----------------| | Posture | <--------PA----------> | Posture | | Peer | | Peer | | (1 ...N) | | (1 ...N) | |-------------| |----------------| | | | | | | |-------------| |----------------| | Posture | <--------PB---------> | Posture | | Broker | | Broker | | Peer | | Peer | |--------- ---| |----------------| | | | | |-------------| |----------------| | Posture | <--------PT---------> | Posture | | Transport | | Transport | | Peer | | Peer | |-------------| |----------------| Figure 1: MNEA Reference Model 3. Use Case Mutual assessment can normally be triggered by some certain network application.Each endpoint participating in these applications, such as online business and file sharing, should disclose its posture information to its communicating peer for further assessment. The mutual NEA procedure is shown as following figure. Wei, et al. Expires May 13, 2008 [Page 4] Internet-Draft Mutual Network Endpoint Assessment November 2007 A-PP A-PBP A-PTP B-PTP B-PBP B-PP | | | | | | | | Connection Request | | | | |---------->| | | | | | |-------->| ReqB | | | | | |<----------| | | | ReqB | | | | ReqB |<----------|<--------| | | ReqB |<--------| | | | |<--------| | | | | | | | | | | |PosA ReqA| | | | | |-------->|PosA ReqA| | | | | |-------->| PosA ReqA | | | | |---------->|-------->| PosA ReqA | | | | | |---------->| | | | | | | | | | | | | | | | | | ResB PosB | | | | ResB PosB |<----------| | |ResB PosB|<----------|<--------| | |ResB PosB|<--------| | | | |<--------| | | | | | | | | | | | ResA | | | | | |-------->| ResA | | | | | |-------->| ResA | | | | | | --------> | ResA | | | | | |-------->| ResA | | | | | | --------> | | | | | | | Figure 2: An Example of MNEA Use case 3.1. Procedure Wei, et al. Expires May 13, 2008 [Page 5] Internet-Draft Mutual Network Endpoint Assessment November 2007 1. Endpoint A connects to the Endpoint B. 2. The PBP on EndpointB (B-PBP) is notified of the request from Endpoint A. 3. The B-PBP contacts those local Posture Peers (B-PPs). According to the security policy, each B-PP responds a Posture Request (ReqB) to indicate what posture information the Endpoint A should provide. 4. The B-PBP multiplexes all ReqBs from the B-PPs into one PB message and sends it to the Posture Broker Peer on the endpoint A(A-PBP) via the PTP on Endpoint B and Endpoint A(i.e. B-PTP and A-PTP). 5. The PBP on Endpoint A (A-PBP) de-multiplexes the PB message and delivers each ReqB to its corresponding PP on Endpoint A(A-PP). 6. As requested by B-PP?each involved A-PP returns its posture information (PosA) with the permission of the Endpoint A?s privacy policy. At the same time, each A-PP responds a Posture Request (ReqA) to indicate what posture information the Endpoint B should provide. 7. The A-PBP multiplexes all ReqAs and PosAs from the A-PP into one PB message and sends it to the B-PBP. 8. B-PBP de-multiplexes the PB message and delivers each ReqA and PosA to its corresponding B-PP. 9. Each B-PP assesses its received PosA according to the security policy and returns its assessment result(ResB). (Note: In this case, the Endpoint A is compliant with the security policy of Endpoint B). At the same time, each B-PP returns the related posture information (PosB) requested by A-PP with the permission of the Endpoint B?s privacy policy. 10. The B-PBP multiplexes all ResBs and PosBs from the B-PP into one PB message and sends it to A-PBP via B-PTP and A-PTP. 11. A-PBP de-multiplexes the PB message and delivers each PosB and ResB to the corresponding A-PP. 12. Each A-PP assesses the received PosB according to the security policy and returns the assessment result(ResA). Note: In this case, the Endpoint B is compliant with the security policy of Endpoint A. 13. The A-PBP multiplexes all ResAs from A-PP into one PB messages and sends it to B-PBP via A-PTP and B-PTP. 14. The B-PBP de-multiplexes the PB messages and delivers each ResA to the corresponding B-PP. 15. After the mutual assessment, both Endpoint A and Endpoint B can ensure that the peer is compliant with its own security policy and hence then subsequent interaction is allowed. Wei, et al. Expires May 13, 2008 [Page 6] Internet-Draft Mutual Network Endpoint Assessment November 2007 4. Abbreviation MNEA Mutual Network Endpoint Assessment PA Posture Attribute protocol PB Posture Broker protocol PT Posture Transport Protocol PC Posture Collector PBC Posture Broker Client NAR Network Access Requestor NED Network Enforcement Device: PV Posture Validator PBS Posture Broker Server NAA Network Access Authority PP Posture Peer PBP Posture Broker Peer PTP Posture Transport Peer A-PBP PBP on endpoint A B-PBP PBP on endpoint B A-PP PP on endpoint A B-PP PP on endpoint B A-PTP PTP on endpoint A B-PTP PTP on endpoint B 5. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 6. Security Considerations 7. Acknowledgements 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [NAC] Cisco Systems, "Network Admission Control Technical Overview", 2005. Wei, et al. Expires May 13, 2008 [Page 7] Internet-Draft Mutual Network Endpoint Assessment November 2007 [NAP] Microsoft Corporation, "Network Access Protection Platform Architecture", February 2006. [TNC] TCG, "TNC Architecture for Interoperability Specification v1.0", May 2005. [nea-problem] Susan.Thomson, Thomas.Hardjono, and Steve.Hanna, "Network Endpoint Assessment (NEA) Problem Statement", march 2006. [nea-requirement] Paul Sangster, Hormuzd Khosravi, Mahalingam Mani, Kaushik Narayan, and Joseph Tardo, "Requirements for Network Endpoint Assessment (NEA)", September 2007. Authors' Addresses Wei Jiwei Huawei Technologies ZhongGuanCun Software Park, No.8, Dongbeiwang West Road Beijing 100094 CHINA Phone: +86-10-82829312 Fax: +86-10-82829323 Email: jiwei.wei@huawei.com Jia Ke Huawei Technologies ZhongGuanCun Software Park, No.8, Dongbeiwang West Road Beijing 100094 CHINA Phone: +86-10-82829312 Fax: +86-10-82829323 Email: jiake.cn@huawei.com Wei, et al. Expires May 13, 2008 [Page 8] Internet-Draft Mutual Network Endpoint Assessment November 2007 Yin Han Huawei Technologies ZhongGuanCun Software Park, No.8, Dongbeiwang West Road Beijing 100094 CHINA Phone: +86-10-82829313 Fax: +86-10-82829323 Email: ayinhan@huawei.com Wei, et al. Expires May 13, 2008 [Page 9] Internet-Draft Mutual Network Endpoint Assessment November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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. 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. 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wei, et al. Expires May 13, 2008 [Page 10]