TCG Compliance_TNC IF-PEP Compliance Test Plan

Transcription

1 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.00 Revisin December 2008 Published Cntact: admin@trustedcmputinggrup.rg Cpyright TCG

2 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright Cpyright Trusted Cmputing Grup, Incrprated. Disclaimer THIS SPECIFICATION IS PROVIDED AS IS WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Withut limitatin, TCG disclaims all liability, including liability fr infringement f any prprietary rights, relating t use f infrmatin in this specificatin and t the implementatin f this specificatin, and TCG disclaims all liability fr cst f prcurement f substitute gds r services, lst prfits, lss f use, lss f data r any incidental, cnsequential, direct, indirect, r special damages, whether under cntract, trt, warranty r therwise, arising in any way ut f use r reliance upn this specificatin r any infrmatin herein. N license, express, implied, by estppels, r therwise, t any TCG r TCG member intellectual prperty rights is granted herein. Except that a license is hereby granted by TCG t cpy and reprduce this specificatin fr internal use nly. Cntact the Trusted Cmputing Grup at fr infrmatin n specificatin licensing thrugh membership agreements. Any marks and brands cntained herein are the prperty f their respective wners. Revisin 0.16 Published Page ii f 49

3 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright Table f Cntents 1 Intrductin Purpse Scpe and Audience Specificatins and Cmpnents Specificatins Cmpnents Plicy Enfrcement Pints (PEPs) Netwrk Access Authrities (NAAs) Requirements and Recmmendatins Requirements n PEPs Requirements n NAAs Other Requirements Cnfiguratins and Tplgies Cmmn Setup Test Tplgy Validate Cmmn Setup Test Cases IF-PEP Cmpliance Test Cases fr PEPs Binary Islatin and Basic Authenticatin Functins VLAN-Based Islatin (Success) VLAN-Based Islatin (Failure) Filter-Based Islatin Successful CA with VLANs Successful CA with Filter-ID Successful Discnnect Nn-Obvius RADIUS Secret Supprt Message-Authenticatr Attribute Supprt (Failure) Unrecgnized Service-Type in Access-Accept Access-Request Retransmissins UDP Packet Larger than RADIUS Packet Packet Shrter Than Length Field Varying Attribute Order Invalid Attribute Length State Attribute Value Pst Handshake Enfrcement with Framed-Rute Attribute Vendr-Specific Attribute Unsuccessful Discnnect-Requests Unsuccessful CA-Requests with VLANs Unsuccessful CA-Requests with Filter-ID IF-PEP Cmpliance Test Cases fr NAAs Binary Islatin (Success) and Basic Authenticatin Functins Binary Islatin (Failure) VLAN-Based Islatin Filter-Based Islatin Dynamic Access Plicy Update Dynamic Plicy Change Nn-Obvius RADIUS secrets N Shared Secret UDP Packet Larger than RADIUS Packet Packet Shrter Than Length Field Surce IP Determines Shared Secret Different Attribute Order Invalid Attribute Length Embedded NUL Revisin 0.15 Published Page iii f 49

4 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright Vendr-Specific Attribute References Revisin 0.15 Published Page 4 f 49

5 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright 1 Intrductin 1.1 Purpse The purpse f this dcument is t prvide specific requirements fr the cmpliance tests fr IF- PEP fr RADIUS v1.0. In particular, it defines and lists all the cmpliance test cases that must be passed t prve Cmpliance with respect t the IF-PEP fr RADIUS v1.0 specificatin [2]. This dcument des nt cntain any nrmative statements. 1.2 Scpe and Audience The intended audience fr this dcument includes test designers and implementers, as well as prduct develpers and custmers wh need t understand the IF-PEP fr RADIUS v1.0 cmpliance tests. Readers shuld be familiar with the TNC Architecture [1], with the Cmpliance_TNC Cmpliance and Interperability Principles specificatin [3] and with IF-PEP fr RADIUS v1.0. Revisin 0.15 Published Page 5 f 49

6 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright 2 Specificatins and Cmpnents 2.1 Specificatins This dcument is based n the IF-PEP fr RADIUS v1.0 specificatin [2] n the Cmpliance_TNC Cmpliance and Interperability Principles dcument [1], and n RFC 2865 [4], RFC 2868 [5], RFC 3579 [6], RFC 3576 [7], and RFC 3580 [8]. The IF-PEP v1.0 specificatin defines the IF- PEP interface. The Cmpliance_TNC Cmpliance and Interperability Principles dcument prvides an verview f the Cmpliance_TNC testing. The referenced RFCs define aspects f the RADIUS prtcl and attributes. 2.2 Cmpnents There are tw sets f IF-PEP cmpliance tests that test the tw kinds f cmpnents that interface with IF-PEP: Plicy Enfrcement Pint and Netwrk Access Authrity Plicy Enfrcement Pints (PEPs) The IF-PEP Cmpliance tests fr Plicy Enfrcement Pints (PEPs) tests that a PEP prperly implements IF-PEP. The Test Target fr this test is a PEP. T test a PEP s cmpliance with IF-PEP fr RADIUS, a sequence f RADIUS exchanges must be cnducted with the PEP. After each exchange, test traffic shall be sent t ensure that the test criteria are met and the PEP has prperly implemented the type f netwrk access directed by the PDP Netwrk Access Authrities (NAAs) The IF-PEP Cmpliance test fr Netwrk Access Authrities (NAAs) tests that an NAA prperly implements IF-PEP. The Test Target fr this test is an NAA. T test a PDP s cmpliance with IF-PEP fr RADIUS, a sequence f RADIUS exchanges must be cnducted with the NAA. After each exchange, traffic between the NAA and the PEP shuld be carefully examined t ensure that it cmplies with the IF-PEP fr RADIUS specificatin. Revisin 0.15 Published Page 6 f 49

7 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright 3 Requirements and Recmmendatins The IF-PEP v1.0 specificatin includes many requirements and recmmendatins fr Plicy Enfrcement Pints and Netwrk Access Authrities. This sectin lists nly the mandatry requirements since the cmpliance tests fr IF-PEP nly test nrmative requirements (nt recmmendatins). This sectin has three subsectins. The first sectin lists mandatry requirements upn Plicy Enfrcement Pints, which are tested by the IF-PEP cmpliance test fr PEPs. The secnd sectin lists mandatry requirements upn Netwrk Access Authrities, which are tested by the IF-PEP cmpliance test fr NAAs. The third sectin lists ther requirements that will nt be tested by this test plan. As required by the TCG Cmpliance and Interperability Guidelines, each requirement listed belw has a unique name cmpsed f the string CTNC (fr Cmpliance_TNC), IFPEP1.0 (indicating that these are requirements frm IF-PEP v1.0), PEP r NAA depending n which cmpnent the requirement applies t, a requirement number unique within the preceding prefix, REQ indicating it is a requirement, and a cmpliance classifier ( M fr MUST, S fr SHOULD, O fr OPTIONAL r MAY, X fr Expressly Frbidden r MUST NOT). Usage classifiers are nt included in requirement names at this time. 3.1 Requirements n PEPs [CTNC-IFPEP1.0-PEP-REQ-1-M] A PEP MUST supprt at least ne f the three islatin techniques cnsisting f either binary-, vlan-, and filter-based islatin. All RADIUS PEPs supprt binary islatin. Other islatin techniques are ptinal. [CTNC-IFPEP1.0-PEP-REQ-2-M] A PEP MUST allw dynamic access plicy update. This dynamic plicy update may be via ne f a number f methds, such as Change f Authrizatin (CA), RADIUS Filter-Id supprt, r user re-authenticatin. There is n specific test case fr this requirement. [CTNC-IFPEP1.0-PEP-REQ-3-M] If a PEP supprts VLAN-based islatin, it MUST supprt the RFC2868 tunnel attributes enumerated in sectin f IF-PEP 1.0 and RFC3580 sectin 3.31 usage guidelines. [CTNC-IFPEP1.0-PEP-REQ-4-M] If a PEP supprts Filter-based islatin, it MUST supprt the Filter-ID attribute as defined in RFC2865 sectin 5.11 and RFC 3580 sectin 3.9 usage guidelines. [CTNC-IFPEP1.0-PEP-REQ-5-M] If a PEP supprts dynamic plicy changes (as described in sectin 5.4 f IF-PEP), it MUST supprt RFC3576. We nte that Service-Type f Authrize Only is nt part f IF-PEP, s we d nt have test cases fr it. IPsec replay prtectin is als mitted because it is nt used in the IF-PEP 1.0 specificatin. [CTNC-IFPEP1.0-PEP-REQ-6-M] A PEP MUST supprt usage f nn-bvius RADIUS secrets as described in RFC2865. [CTNC-IFPEP1.0-PEP-REQ-7-M] A PEP MUST supprt Message-Authenticatr attribute as described in RFC3579, sectin 3.1. RFC2865 related requirements: [CTNC-IFPEP1.0-PEP-REQ-8-M] A NAS [PEP] that des nt implement a given service MUST NOT implement RADIUS attributes fr that service. (RFC 2865, sectin 1.1) [The term service as used in this requirement refers t services identified by a Service-Type attribute.] Revisin 0.15 Published Page 7 f 49

8 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright [CTNC-IFPEP1.0-PEP-REQ-9-M] A NAS [PEP] MUST treat a RADIUS Access-Accept authrizing an unavailable service as an Access-Reject instead. (RFC 2865, sectin 1.1) [The term service as used in this requirement refers t services identified by a Service- Type attribute.] [CTNC-IFPEP1.0-PEP-REQ-10-M] If the NAS [PEP] is retransmitting a RADIUS request t the same server as befre, and the attributes have nt changed, the PEP MUST use the same Request Authenticatr, ID, and surce prt. If any attributes have changed, the PEP MUST use a new Request Authenticatr and ID. (RFC 2865, sectin 2.5) [CTNC-IFPEP1.0-PEP-REQ-11-M] Octets utside the range f the Length field MUST be treated as padding and ignred n receptin. [CTNC-IFPEP1.0-PEP-REQ-12-M] If the packet is shrter than the Length field indicates, it MUST be silently discarded. The minimum Length is 20 and maximum Length is (RFC 2865, sectin 3) [CTNC-IFPEP1.0-PEP-REQ-13-M] A system [PEP] wishing t authenticate a user MUST transmit a RADIUS packet with the Cde field set t 1 (Access-Request). (RFC 2865, sectin 4.1) [CTNC-IFPEP1.0-PEP-REQ-14-M] An Access-Request MUST cntain either a NAS-IP- Address attribute r a NAS-Identifier attribute. It MAY cntain bth (RFC 2865, sectin 4.1) [CTNC-IFPEP1.0-PEP-REQ-15-M] An Access-Request MUST cntain either a User- Passwrd r a CHAP-Passwrd r a State attribute. An Access-Request MUST NOT cntain bth a User-Passwrd and a CHAP-Passwrd. (RFC 2865, sectin 4.1) [This requirement is qualified by the fllwing sentence in RFC 2865, which says If future extensins allw ther kinds f authenticatin infrmatin t be cnveyed, the attribute fr that can be used in an Access-Request instead f User-Passwrd r CHAP- Passwrd. RFC 3579 further states An Access-Request that cntains either a User- Passwrd r CHAP-Passwrd r ARAP-Passwrd r ne r mre EAP-Message attributes MUST NOT cntain mre than ne type f thse fur attributes. Since EAP is always used fr TNC handshakes ver RADIUS, requirement [CTNC-IFPEP1.0-PEP- REQ-15-M] des nt apply t TNC and therefre n test is included fr it in this test suite.] [CTNC-IFPEP1.0-PEP-REQ-16-M] The Identifier field f an Access-Request MUST be changed whenever the cntent f the Attributes field changes, and whenever a valid reply has been received fr a previus request. [CTNC-IFPEP1.0-PEP-REQ-17-M] Fr retransmissins, the Identifier MUST remain unchanged. (RFC 2865, sectin 4.1) [CTNC-IFPEP1.0-PEP-REQ-18-M] The Request Authenticatr value [f an Access-Request] MUST be changed each time a new Identifier is used. (RFC 2865, sectin 4.1) [CTNC-IFPEP1.0-PEP-REQ-19-M] If a NAS [PEP] des nt supprt challenge/respnse, it MUST treat an Access-Challenge as thugh it had received an Access-Reject instead. (RFC 2865, sectin 4.4) [Because all TNC handshakes ver RADIUS use EAP, which requires supprt fr challenge-respnse, this requirement des nt apply. Therefre n tests are included fr it.] [CTNC-IFPEP1.0-PEP-REQ-20-M] A RADIUS server r client MUST NOT have any dependencies n the rder f attributes f different types. A RADIUS server r client MUST NOT require attributes f the same type t be cntiguus. (RFC 2865, sectin 5.0) [CTNC-IFPEP1.0-PEP-REQ-21-M] If an Attribute is received in an Access-Accept, Access- Reject r Access-Challenge packet with an invalid Attribute length, the packet MUST either be treated as an Access-Reject r else silently discarded. (RFC 2865, sectin 5.0) Revisin 0.15 Published Page 8 f 49

9 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright [CTNC-IFPEP1.0-PEP-REQ-22-M] The Value field is ne r mre ctets and cntains infrmatin specific t the Attribute. The frmat and length f the Value field is determined by the Type and Length fields. Nte that nne f the types in RADIUS terminate with a NUL (hex 00). In particular, types "text" and "string" in RADIUS d nt terminate with a NUL (hex 00). The Attribute has a length field and des nt use a terminatr. Text cntains UTF-8 encded characters and String cntains 8-bit binary data. Servers and servers and clients MUST be able t deal with embedded nulls. (RFC 2865, sectin 5.0) [CTNC-IFPEP1.0-PEP-REQ-23-M] If the Value field is f Text type, then Text f length zer MUST NOT be sent. (RFC 2865, sectin 5.0) [CTNC-IFPEP1.0-PEP-REQ-24-M] If the Value field is f String type, then String f length zer MUST NOT be sent. (RFC 2865, sectin 5.0) [CTNC-IFPEP1.0-PEP-REQ-25-M] This attribute User-Name indicates the name f the user t be authenticated. It MUST be sent in Access-Request packets if available. (RFC 2865, sectin 5.1) [CTNC-IFPEP1.0-PEP-REQ-26-M] The Filter-Id Text field is ne r mre ctets, and it's cntents are implementatin dependent. It is intended t be human readable and MUST NOT affect peratin f the prtcl. (RFC 2865, sectin 5.11) [CTNC-IFPEP1.0-PEP-REQ-27-M] Multiple Reply-Message's MAY be included and if any are displayed, they MUST be displayed in the same rder as they appear in the packet. (RFC 2865, sectin 5.18) [N test fr this requirement is included in this test suite because RFC 3579 says the Reply-Message attribute MUST NOT be used with EAP and TNC always uses EAP when IF-PEP fr RADIUS is used.] [CTNC-IFPEP1.0-PEP-REQ-28-M] The Reply-Message Text field is ne r mre ctets, and its cntents are implementatin dependent. It is intended t be human readable, and MUST NOT affect peratin f the prtcl. (RFC 2865, sectin 5.18) [N test fr this requirement is included in this test suite because RFC 3579 says the Reply-Message attribute MUST NOT be used with EAP and TNC always uses EAP when IF-PEP fr RADIUS is used.] [CTNC-IFPEP1.0-PEP-REQ-29-M] The Framed-Rute Text field is ne r mre ctets, and it's cntents are implementatin dependent. It is intended t be human readable and MUST NOT affect peratin f the prtcl. (RFC 2865, sectin 5.22) [CTNC-IFPEP1.0-PEP-REQ-30-M] The State attribute is available t be sent by the server t the client in an Access-Challenge and MUST be sent unmdified frm the client t the server in the new Access-Request reply t that challenge, if any. The client MUST NOT interpret the attribute lcally. (RFC 2865, sectin 5.24) [CTNC-IFPEP1.0-PEP-REQ-31-M] The State attribute is available t be sent by the server t the client in an Access-Accept that als includes a Terminatin-Actin Attribute with the value f RADIUS-Request. If the NAS perfrms the Terminatin-Actin by sending a new Access-Request upn terminatin f the current sessin, it MUST include the State attribute unchanged in that Access-Request. (RFC 2865, sectin 5.24) [This is nt widely implemented r essential t IF-PEP s n test case is included fr it.] [CTNC-IFPEP1.0-PEP-REQ-32-M] The client MUST NOT interpret the Class attribute lcally. (RFC 2865, sectin 5.25) [CTNC-IFPEP1.0-PEP-REQ-33-M] The Vendr-Specific Attribute MUST nt affect the peratin f the RADIUS prtcl. (RFC 2865, sectin 5.26) [CTNC-IFPEP1.0-PEP-REQ-34-M] A PEP MUST nt use the Framed-Ruting, Filter-Id, Lgin-Service, Lgin-TCP-Prt, Reply-Message, Callback-Id, Framed-Rute, Framed- IPX-Netwrk, Class, Sessin-Timeut, Idle-Timeut, Terminatin-Actin, Framed- AppleTalk-Link, Framed-AppleTalk-Netwrk and Framed-AppleTalk-Zne attributes in Revisin 0.15 Published Page 9 f 49

10 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright Access-Request packets. A PEP MUST nt use mre than ne instance f the fllwing attributes in Access-Request packets, User-Name, Service-Type, Framed-Prtcl, Framed-IP-Address, Framed-IP-Netmask, Framed-MTU, Callback-Number, State, Lgin- LAT-Service, Lgin-LAT-Nde, Lgin-LAT-Grup, Prt-Limit and Lgin-LAT-Prt. (RFC 2865, sectin 5.44) RFC2868 related requirements: [CTNC-IFPEP1.0-PEP-REQ-35-M] If a tunnel initiatr receives an Access-Accept packet which cntains nly unknwn r unsupprted Tunnel-Types, the tunnel initiatr MUST behave as thugh an Access-Reject had been received instead. (RFC 2868, Sectin 3.1) [CTNC-IFPEP1.0-PEP-REQ-36-M] If the Tag field is unused in the Tunnel-Type attribute, it MUST be zer. (RFC 2868, Sectin 3.1) [We have a test case t verify that the PEP can handle zer tag values.] [CTNC-IFPEP1.0-PEP-REQ-37-M] If a tunnel initiatr receives an Access-Accept packet which cntains nly unknwn r unsupprted Tunnel-Medium-Types, the tunnel initiatr MUST behave as thugh as Access-Reject had been received instead. (RFC 2868, Sectin 3.2) [CTNC-IFPEP1.0-PEP-REQ-38-M] If the Tag field is unused in the Tunnel-Medium-Type attribute, it MUST be zer. (RFC 2868, Sectin 3.2) [We have a test case t verify that the PEP can handle zer tag values.] RFC3576 related requirements: [CTNC-IFPEP1.0-PEP-REQ-39-M] A NAS MUST respnd t a Discnnect-Request including a Service-Type Attribute with an unsupprted value with a Discnnect-NAK (RFC 3576, sectin 2.2). [CTNC-IFPEP1.0-PEP-REQ-40-M] A NAS MUST respnd t a CA-Request including a Service-Type Attribute with an unsupprted value with a CA-NAK. (RFC 3576, sectin 2.2) [CTNC-IFPEP1.0-PEP-REQ-41-M] A NAS MUST respnd t a CA-Request cntaining ne r mre unsupprted Attributes r Attribute values with a CA-NAK. (RFC 3576, sectin 2.3) [CTNC-IFPEP1.0-PEP-REQ-42-M] A Discnnect-Request cntaining ne r mre unsupprted Attributes r Attribute values MUST be answered with a Discnnect-NAK. (RFC 3576, sectin 2.3) [CTNC-IFPEP1.0-PEP-REQ-43-M] All NAS identificatin attributes included in a Request message MUST match in rder fr a Discnnect-Request r CA-Request t be successful. (RFC 3576, sectin 3) [CTNC-IFPEP1.0-PEP-REQ-44-M] Fr sessin identificatin attributes, the User-Name and Acct-Sessin-Id Attributes, if included, MUST match in rder fr a Discnnect-Request r CA-Request t be successful. (RFC 3576, sectin 3) [CTNC-IFPEP1.0-PEP-REQ-45-M] The Errr-Cause attribute values f represent successful cmpletin, and can nly be sent within Discnnect-ACK r CA-ACK message. An Errr-Cause attribute with these values MUST NOT be sent within a Discnnect-NAK r CA-NAK. (RFC 3576, sectin 3) [CTNC-IFPEP1.0-PEP-REQ-46-M] Errr-Cause attribute values f represent fatal errrs cmmitted by the RADIUS server, and MUST NOT be sent within CA-ACK r Discnnect-ACK messages. (RFC 3576, sectin 3) [CTNC-IFPEP1.0-PEP-REQ-47-M] Errr-Cause attribute values f Values represent fatal errrs ccurring n a NAS r RADIUS prxy, and MUST NOT be sent within CA-ACK r Discnnect-ACK messages. (RFC 3576, sectin 3) Revisin 0.15 Published Page 10 f 49

11 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright [CTNC-IFPEP1.0-PEP-REQ-48-M] The State Attribute is available t be sent by the RADIUS server t the NAS in a Discnnect-Request r CA-Request message and MUST be sent unmdified frm the NAS t the RADIUS server in a subsequent ACK r NAK message. (RFC 3576, sectin 3.2) [CTNC-IFPEP1.0-PEP-REQ-49-M] A NAS [PEP] r RADIUS prxy MUST silently discard Discnnect-Request r CA-Request messages frm untrusted surces. (RFC 3576, sectin 5.1) 3.2 Requirements n NAAs [CTNC-IFPEP1.0-NAA-REQ-1] An NAA MUST supprt at least ne f the three islatin techniques cnsisting f either binary-, vlan-, and filter-based islatin. [CTNC-IFPEP1.0-NAA-REQ-2] An NAA MUST allw dynamic access plicy update. This dynamic plicy update may be via ne f a number f methds, such as Change f Authrizatin (CA), RADIUS Filter-Id supprt, r user re-authenticatin. [CTNC-IFPEP1.0-NAA-REQ-3] If an NAA supprts VLAN-based islatin, it MUST supprt RFC2868 tunnel attributes in sectins 3.1, 3.2, and 3.6 and RFC3580 sectin 3.31 usage guidelines. [CTNC-IFPEP1.0-NAA-REQ-4] If an NAA supprts Filter-based islatin, it MUST supprt the Filter-ID attribute as defined in RFC2865 and RFC3580 sectin 3.9 usage guidelines. [CTNC-IFPEP1.0-NAA-REQ-5] If a NAA supprts dynamic plicy changes (as described in sectin 5.4 f IF-PEP), it MUST supprt RFC3576. [CTNC-IFPEP1.0-NAA-REQ-6] An NAA MUST supprt usage f nn-bvius RADIUS secrets as described in RFC2865. [CTNC-IFPEP1.0-NAA-REQ-7] An NAA MUST supprt Message-Authenticatr attribute as described in RFC3579, sectin 3.1. RFC2865 related requirements: [CTNC-IFPEP1.0-NAA-REQ-8] A request frm a client fr which the RADIUS server des nt have a shared secret MUST be silently discarded. (RFC 2865, sectin 2) [CTNC-IFPEP1.0-NAA-REQ-9] If the RADIUS server [NAA] is unable t perfrm the requested authenticatin, it MUST return an Access-Reject. (RFC 2865, sectin 2.2) [CTNC-IFPEP1.0-NAA-REQ-10] Octets utside the range f the Length field MUST be treated as padding and ignred n receptin. (RFC 2865, sectin 3) [CTNC-IFPEP1.0-NAA-REQ-11] If the packet is shrter than the Length field indicates, it MUST be silently discarded. (RFC 2865, sectin 3) [CTNC-IFPEP1.0-NAA-REQ-12] A RADIUS server [NAA] MUST use the surce IP address f the RADIUS UDP packet t decide which shared secret t use, s that RADIUS requests can be prxied. (RFC 2865, sectin 3) [CTNC-IFPEP1.0-NAA-REQ-13] Upn receipt f an Access-Request frm a valid client [PEP], an apprpriate reply MUST be transmitted. (RFC 2865, sectin 4.1) An apprpriate respnse is: Access-Accept, Access-Challenge, Access-Reject. [CTNC-IFPEP1.0-NAA-REQ-14] If all attribute values received in an Access-Request are acceptable then the RADIUS implementatin [NAA] MUST transmit a packet with the Cde field set t 2 (Access-Accept). (RFC 2865, sectin 4.2) [CTNC-IFPEP1.0-NAA-REQ-15] On receptin f an Access-Accept, the Identifier field is matched with a pending Access-Request. The Respnse Authenticatr field [f an Access-Accept] Revisin 0.15 Published Page 11 f 49

12 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright MUST cntain the crrect respnse fr the pending Access-Request. (RFC 2865, sectin 4.2) [CTNC-IFPEP1.0-NAA-REQ-16] If any value f the received Attributes [f an Access-Request] is nt acceptable, then the RADIUS server [NAA] MUST transmit a packet with the Cde field set t 3 (Access-Reject). (RFC 2865, sectin 4.3) [CTNC-IFPEP1.0-NAA-REQ-17] If the RADIUS server [NAA] desires t send the user a challenge requiring a respnse, then the RADIUS server [NAA] MUST respnd t the Access- Request by transmitting a packet with the Cde field set t 11 (Access-Challenge). (RFC 2865, sectin 4.4) [CTNC-IFPEP1.0-NAA-REQ-18] If the RADIUS server [NAA] sends an Access-Challenge, the Identifier field MUST match that f a pending Access-Request. Additinally, the Respnse Authenticatr field MUST cntain the crrect respnse fr the pending Access- Request. (RFC 2865, sectin 4.4) [CTNC-IFPEP1.0-NAA-REQ-19] A RADIUS server [NAA] r client MUST NOT have any dependencies n the rder f attributes f different types. A RADIUS server [NAA] r client MUST NOT require attributes f the same type t be cntiguus. (RFC 2865, sectin 5.0) [CTNC-IFPEP1.0-NAA-REQ-20] If an Attribute is received in an Access-Accept, Access-Reject r Access-Challenge packet with an invalid Attribute length, the packet MUST either be treated as an Access-Reject r else silently discarded. (RFC 2865, sectin 5.0) [CTNC-IFPEP1.0-NAA-REQ-21] The Value field is ne r mre ctets and cntains infrmatin specific t the Attribute. The frmat and length f the Value field is determined by the Type and Length fields. Nte that nne f the types in RADIUS terminate with a NUL (hex 00). In particular, types "text" and "string" in RADIUS d nt terminate with a NUL (hex 00). The Attribute has a length field and des nt use a terminatr. Text cntains UTF-8 encded characters and String cntains 8-bit binary data. Servers and servers and clients MUST be able t deal with embedded nulls. (RFC 2865, sectin 5.0) [CTNC-IFPEP1.0-NAA-REQ-22] If the Value field is f Text type, then Text f length zer MUST NOT be sent. (RFC 2865, sectin 5.0) [CTNC-IFPEP1.0-NAA-REQ-23] If the Value field is f String type, then String f length zer MUST NOT be sent. (RFC 2865, sectin 5.0) [CTNC-IFPEP1.0-NAA-REQ-24] Nte that NAS-IP-Address MUST NOT be used t select the shared secret used t authenticate the request. The surce IP address f the Access- Request packet MUST be used t select the shared secret. (RFC 2865, sectin 5.4) [CTNC-IFPEP1.0-NAA-REQ-25] It [Vendr-Specific Attribute] MUST nt affect the peratin f the RADIUS prtcl. Servers nt equipped t interpret the vendr-specific infrmatin sent by a client MUST ignre it (althugh it may be reprted). (RFC 2865, sectin 5.26) [CTNC-IFPEP1.0-NAA-REQ-26] Nte that NAS-Identifier MUST NOT be used t select the shared secret used t authenticate the request. The surce IP address f the Access- Request packet MUST be used t select the shared secret. (RFC 2865, sectin 5.32) [CTNC-IFPEP1.0-NAA-REQ-27] A RADIUS server [NAA] MUST fllw the attribute usage guide as defined in Table 5.44 in RFC 2865 when placing attributes in packets. An NAA MUST nt use the State, Vendr-Specific, Sessin-Timeut and Idle-Timeut attributes in Access-Reject packets. An NAA MUST nt use the User-Name, Service-Type, Framed-Prtcl, Framed-IP- Address, Framed-IP-Netmask, Framed-Ruting, Filter-Id, Framed-MTU, Framed- Cmpressin, Lgin-IP-Hst, Lgin-Service, Lgin-TCP-Prt, Callback-Number, Callback-Id, Framed-Rute, Framed-IPX-Netwrk, Class, Terminatin-Actin, Lgin-LAT- Service, Lgin-LAT-Nde, Lgin-LAT-Grup, Framed-AppleTalk-Link, Framed-AppleTalk- Revisin 0.15 Published Page 12 f 49

13 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright Netwrk, Framed-AppleTalk-Zne, Prt-Limit and Lgin-LAT-Prt attributes in Access- Reject and Access-Challenge packets. An NAA MUST nt use the User-Passwrd, CHAP-Passwrd, NAS-IP-Address NAS- Prt, Called-Statin-Id, Calling-Statin-Id, NAS-Identifier, CHAP-Challenge and NAS- Prt-Type attributes in Access-Accept, Access-Reject and Access-Challenge packets. An NAA MUST nt use mre than ne instance f the fllwing attributes in Access- Accept packets, User-Name, Service-Type, Framed-Prtcl, Framed-IP-Address, Framed-IP-Netmask, Framed-MTU, Callback-Number, State, Lgin-LAT-Service, Lgin- LAT-Nde, Lgin-LAT-Grup, Prt-Limit and Lgin-LAT-Prt. An NAA MUST nt use mre than ne instance f the fllwing attributes in Access- Request packets, User-Passwrd, CHAP-Passwrd, NAS-IP-Address, NAS-Prt, Called- Statin-Id, Calling-Statin-Id, NAS-Identifier, CHAP-Challenge and NAS-Prt-Type. An NAA MUST nt use mre than ne instance f the fllwing attributes in Access- Accept packets, Frame-Ruting, Callback-Id, Framed-IPX-Netwrk, Sessin-Timut, Idle- Timeut, Terminatin-Actin, Framed-AppleTalk-Link and Framed-AppleTalk-Zne. An NAA MUST nt use mre than ne instance f the fllwing attributes in Access- Challenge packets, State, Sessin-Timeut and Idle-Timeut. (RFC 2865, sectin 5.44) An NAA MUST nt use any frbidden access reject packet attributes per table 5.44 f RFC RFC2868 related requirements: [CTNC-IFPEP1.0-NAA-REQ-28] If the Tag field is unused in the Tunnel-Type attribute, it MUST be zer. (RFC 2868, Sectin 3.1) [Sme ld PEPs require the Tag field t be nn-zer when it is nt used, in spite f this requirement. Therefre, NAAs may chse allw lcal cnfiguratin t enable nn-zer values when the Tag field is unused. Hwever, the default shuld be t send zer Tag values when the Tag field is unused.] [CTNC-IFPEP1.0-NAA-REQ-29] If the Tag field is unused in the Tunnel-Medium-Type attribute, it MUST be zer. (RFC 2868, Sectin 3.2) [Sme ld PEPs require the Tag field t be nnzer when it is nt used, in spite f this requirement. Therefre, NAAs may chse allw lcal cnfiguratin t enable nn-zer values when the Tag field is unused. Hwever, the default shuld be t send zer Tag values when the Tag field is unused.] 3.3 Other Requirements Requirements listed in this sectin are requirements fr neither PEP nr NAA. They are listed here fr cmpleteness. Hwever, they are ut f scpe and we will nt prvide test cases. [CTNC-IFPEP1.0-OTHER-1] If any Prxy-State attributes were present in the Access- Request, they MUST be cpied unmdified and in rder int the respnse packet. (RFC 2865, sectin 2) [CTNC-IFPEP1.0-OTHER-2] The frwarding server MUST treat any Prxy-State attributes already in the packet as paque data. It's peratin MUST NOT depend n the cntent f Prxy-State attributes added by previus servers. (RFC 2865, sectin 2.3) [CTNC-IFPEP1.0-OTHER-3] If a CHAP-Passwrd attribute is present in the packet and n CHAP-Challenge attribute is present, the frwarding server MUST leave the Request- Authenticatr untuched r cpy it t a CHAP-Challenge attribute. (RFC 2865, sectin 2.3) [CTNC-IFPEP1.0-OTHER-4] The frwarding server MAY add ne Prxy-State attribute t the packet. It MUST NOT add mre than ne. If it adds a Prxy-State, the Prxy-State MUST appear after any ther Prxy-States in the packet. The frwarding server MUST NOT mdify any ther Prxy-States that were in the packet. It may chse nt t frward Revisin 0.15 Published Page 13 f 49

14 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright them, but it MUST NOT change their cntents. The frwarding server MUST NOT change the rder f any attributes f the same type, including Prxy-State. (RFC 2865, sectin 2.3) [CTNC-IFPEP1.0-OTHER-5] The remte server MUST cpy all Prxy-State attributes in rder frm the Access-Request t the respnse packet, withut mdifying them. (RFC 2865, sectin 2.3) [CTNC-IFPEP1.0-OTHER-6] A frwarding server MUST nt mdify existing Prxy-State, State, r Class attributes present in the packet. (RFC 2865, sectin 2.3) [CTNC-IFPEP1.0-OTHER-7] When using a frwarding prxy, the prxy must be able t alter the packet as it passes thrugh in each directin - when the prxy frwards the request, the prxy MAY add a Prxy-State Attribute, and when the prxy frwards a respnse, it MUST remve it's Prxy-State Attribute if it added ne. (RFC 2865, sectin 3) [CTNC-IFPEP1.0-OTHER-8] A NAS which supprts PAP MAY frward the Reply-Message t the NAS and accept a PAP respnse which it can use as thugh the user had entered the respnse. If the NAS cannt d s, it MUST treat the Access-Challenge as thugh it had received an Access-Reject instead. (RFC 2865, sectin 4.4) [CTNC-IFPEP1.0-OTHER-9] If multiple Attributes with the same Type are present, the rder f Attributes with the same Type MUST be preserved by any prxies. (RFC 2865, sectin 5) [CTNC-IFPEP1.0-OTHER-10] The Prxy State attribute is available t be sent by a prxy server t anther server when frwarding an Access-Request and MUST be returned unmdified in the Access-Accept, Access-Reject r Access-Challenge. When the prxy server receives the respnse t its request, it MUST remve its wn Prxy-State (the last Prxy-State in the packet) befre frwarding the respnse t the NAS. If a Prxy-State Attribute is added t a packet when frwarding the packet, the Prxy-State Attribute MUST be added after any existing Prxy-State attributes. The cntent f any Prxy-State ther than the ne added by the current server shuld be treated as paque ctets and MUST NOT affect peratin f the prtcl. (RFC 2865, sectin 5.33) Revisin 0.15 Published Page 14 f 49

15 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright 4 Cnfiguratins and Tplgies 4.1 Cmmn Setup Access Requestr An Access Requestr will be needed t request access t certain netwrks r services. This Access Requestr shuld make prperly frmatted requests and actins t simulate a valid test requirement. It is assumed that all required parameters invlved are cnfigurable n this device. Netwrk Analyzers Netwrk analyzers are used t validate the results f each test. The netwrk analyzers used fr this test plan will have the ability t capture traffic transmitted ver the netwrk at designated spts, and pssess the ability t interpret and verify that traffic. Wireshark (Ethereal) is an pen surce tl that can d this. It als includes RADIUS encde/decde libraries. RADIUS Simulatr RADIUS simulatrs are used fr attribute testing. The RADIUS simulatr must be able t generate a RADIUS exchange, acting as either a PEP r an NAA, with specific custmized attributes. Plicy Enfrcement Pint (PEP) The Plicy Enfrcement Pint (PEP) may be an 802.1X-capable switch r wireless access pint. Netwrk Access Authrity (NAA) The Netwrk Access Authrity decides what netwrk access shuld be granted t the Access Requestr (if any) and cmmunicates the results f its decisin t the PEP. The NAA is a RADIUS server. In the cases where the NAA is nt the device under test, the NAA must respnd t pings t enable cnnectivity tests. DHCP Servers The DHCP server with IP address assigns addresses in /24. The DHCP server with IP address assigns addresses in /24. Bth must respnd t pings t enable cnnectivity tests Test Tplgy The test tplgy depicted belw is used fr all test cases. Fr the NAA test cases, nly traffic between the PEP and the NAA (Netwrk Analyzer 1) must be analyzed. Fr the PEP test cases, traffic within bth VLANs must be analyzed. Revisin 0.15 Published Page 15 f 49

16 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright Tw VLANs are used in this tplgy: VLAN /24 VLAN /24 If the PEP desn't supprt dynamic VLAN assignment, VLAN 20 and all cmpnents n it can be mitted. N ruter r VLAN bridge is included in the test tplgy, s traffic cannt flw frm VLAN 10 t VLAN 20. VLAN 10 MUST be used as the default VLAN (PVID / native VLAN) fr PEP prts. The fllwing address assignments are used: VLAN 10 DHCP server RADIUS Simulatr RADIUS server (NAA) switch / AP (PEP) VLAN 20 DHCP server Netwrk Analyzer 1 (right) analyzes traffic between the PEP and VLAN 10. RADIUS Simulatr generates r replays traffic nt VLAN 10. Netwrk Analyzer 2 (left) analyzes traffic between the PEP and VLAN 20. All devices MUST have cnsistent time and date. The test tplgy MUST be reset t default cnfiguratin at the start f every test case. The PEP must be cnfigured t use the NAA as its RADIUS server. The NAA must be cnfigured t recgnize the PEP as a RADIUS client. Cnfigure the PEP s that if an Access-Accept is received, access will be prvided, and if an Access-Reject is received, n access will be prvided. This is referred t as "binary islatin". The PEP must be further cnfigured as fllws: Manually disable prt access cntrl (802.1X) fr NAA, netwrk analyzer and RADIUS simulatr prts AuthCntrlledPrtStatus -- authrized AuthCntrlledPrtCntrl -- FrceAuthrized Cnfigure default prt VLAN n right side f switch t VLAN 10 This includes prts fr NAA, RADIUS Simulatr, and DHCP server n Cnfigure default prt VLAN n left side f switch t VLAN 20 This includes prt fr DHCP server n Validate Cmmn Setup Befre running any tests, validate the test envirnment as fllws: Validate netwrk frwarding: 1. Discnnect Access Requestr frm PEP if cnnected a. Maintain discnnect state fr at least 10 secnds 2. Set prt VLAN-ID t Manually disable prt access cntrl (802.1X) fr Access Requestr Particular technique may vary based n individual PEP. The MIB settings that are Revisin 0.15 Published Page 16 f 49

17 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright expected t be bserved (using a MIB brwser) are: a. AuthCntrlledPrtStatus -- authrized b. AuthCntrlledPrtCntrl -- FrceAuthrized 4. Begin capturing traffic with bth Netwrk Analyzer 1 and Cnnect Access Requestr 6. Verify Access Requestr IP address n x/24 7. Generate traffic with Access Requestr - ping the DHCP server at and the DHCP server at Stp capturing traffic, and verify that traffic frm the Access Requestr is permitted and shws up n Netwrk Analyzer 1 and nt n Netwrk Analyzer Discnnect Access Requestr frm PEP a. Maintain discnnect state fr at least 10 secnds 10. Set prt VLAN-ID t Begin capturing traffic with bth Netwrk Analyzer 1 and Recnnect Access Requestr t PEP 13. Verify Access Requestr IP address n x/ Generate traffic with Access Requestr - ping the DHCP server at and the DHCP server at Stp capturing traffic, and verify that traffic frm the Access Requestr is permitted and shws up n Netwrk Analyzer 2, but nt n Netwrk Analyzer 1. Validate authenticatin-based netwrk frwarding - NAA 1. Cnfigure PEP t use NAA as its RADIUS server. 2. Cnfigure NAA t send an Access-Accept upn successful authenticatin. 3. Discnnect Access Requestr frm PEP (if cnnected) a. Maintain discnnect state fr at least 10 secnds 4. Set prt VLAN-ID t Enable prt access cntrl (802.1X) t authenticate Access Requestr. Particular technique may vary based n individual PEP techniques, here are the expected MIB settings that are expected t be bserved (using a MIB brwser) a. AuthCntrlledPrtStatus -- unauthrized b. AuthCntrlledPrtCntrl -- Aut 6. Begin capturing traffic with bth Traffic Analyzer 1 and Cnnect Access Requestr 8. Authenticate Access Requestr t netwrk thrugh the PEP. 9. Verify Access Requestr IP address n x/ Generate traffic with Access Requestr - ping the DHCP server at and the DHCP server at Verify that traffic frm the Access Requestr is permitted and shws up n Netwrk Analyzer 1 and nt n Netwrk Analyzer Verify that RADIUS traffic between PEP and NAA appears n Netwrk Analyzer 1 Validate authenticatin-based netwrk frwarding - RADIUS Simulatr 1. Cnfigure PEP t use RADIUS Simulatr as its RADIUS server. Revisin 0.15 Published Page 17 f 49

18 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright 2. Cnfigure RADIUS Simulatr t send an Access-Accept upn successful authenticatin. 3. Discnnect Access Requestr frm PEP (if cnnected) b. Maintain discnnect state fr at least 10 secnds 4. Set prt VLAN-ID t Enable prt access cntrl (802.1X) t authenticate Access Requestr. Particular technique may vary based n individual PEP techniques, here are the expected MIB settings that are expected t be bserved (using a MIB brwser) c. AuthCntrlledPrtStatus -- unauthrized d. AuthCntrlledPrtCntrl -- Aut 6. Begin capturing traffic with bth Traffic Analyzer 1 and Cnnect Access Requestr 8. Authenticate Access Requestr t netwrk thrugh the PEP. 9. Verify Access Requestr IP address n x/ Generate traffic with Access Requestr - ping the DHCP server at and the DHCP server at Verify that traffic frm the Access Requestr is permitted and shws up n Netwrk Analyzer 1 and nt n Netwrk Analyzer Verify that RADIUS traffic between PEP and RADIUS Simulatr appears n Netwrk Analyzer 1 Expected Outcmes: Netwrk traffic flws as expected. Access Requestr successfully authenticates against bth NAA and RADIUS Simulatr. Traffic destined fr each DHCP server is permitted r denied as expected. Revisin 0.15 Published Page 18 f 49

19 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright 5 Test Cases In test cases where there are multiple expected utcmes listed, all f the expected utcmes must be met in rder t pass the test. In test cases where there are multiple anticipated failures listed, any single failure results in failing the test. 5.1 IF-PEP Cmpliance Test Cases fr PEPs In the IF-PEP Cmpliance Test Cases fr PEPs, the Device Under Test (DUT) is the PEP. T verify that the PEP crrectly implements the authenticatin handshake, the test prgram will examine the authenticatin and test traffic generated by the Access Requestr and captured by Netwrk Analyzer 1. NOTE: Requirement [CTNC-IFPEP1.0-NAA-REQ-1] says that all PEPs MUST supprt at least ne f the fllwing three islatin techniques: binary islatin, VLAN-based islatin, r filterbased islatin. In practice, all NAAs and PEPs supprt binary islatin, and many supprt VLAN-based r filter-based islatin. The test administratr shuld cnsult with the PEP manufacturer t determine which f these islatin techniques are implemented in the PEP and then run every test case fr which the islatin technique is implemented. If the PEP des nt implement binary islatin, then this test suite cannt be run Binary Islatin and Basic Authenticatin Functins [CTNC-IFPEP1.0-PEP-TC-1] Purpse: T verify that the PEP supprts binary islatin, uses a Cde field value equal t 1 (Access-Request packet) in all RADIUS messages that it sends during an authenticatin exchange, includes either a NAS-IP-Address attribute r a NAS-Identifier attribute (r bth) in all Access-Request messages that it sends, and sends valid Identifier and Request Authenticatr field values and Message-Authenticatr attributes. This test case is fr the fllwing requirements: [CTNC-IFPEP1.0-PEP-REQ-1-M], [CTNC-IFPEP1.0-PEP-REQ-7-M], [CTNC- IFPEP1.0-PEP-REQ-13-M], [CTNC-IFPEP1.0-PEP-REQ-14-M], [CTNC-IFPEP1.0-PEP-REQ-16- M], [CTNC-IFPEP1.0-PEP-REQ-18-M], [CTNC-IFPEP1.0-PEP-REQ-23-M], [CTNC-IFPEP1.0- PEP-REQ-24-M], [CTNC-IFPEP1.0-PEP-REQ-25-M], [CTNC-IFPEP1.0-PEP-REQ-32-M], and [CTNC-IFPEP1.0-PEP-REQ-34-M]. Precnditins: Devices cnfigured t Cmmn Setup. NAA cnfigured t send a Class attribute in the Access-Accept. 1. Begin capturing traffic with Netwrk Analyzer Authenticate Access Requestr t NAA thrugh PEP. 3. Ping the DHCP Server at frm the Access Requestr. 4. Stp capturing traffic with Netwrk Analyzer Verify that ping traffic frm the Access Requestr t the DHCP Server at was captured by Netwrk Analyzer By analyzing traffic captured by Netwrk Analyzer 1, verify that the fllwing cnditins apply: a) Verify that the Cde field value is equal t 1 fr all RADIUS packets sent by the PEP during the authenticatin exchange. b) Cmpare the Identifier field value fr all RADIUS packets sent by the PEP during the authenticatin exchange. Verify that the Identifier field value changes whenever the cntents f the Attributes field changes and whenever a valid reply has been Revisin 0.15 Published Page 19 f 49

20 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright received fr a previus request. Further, verify that the Identifier field value is unchanged fr retransmissins (if any). c) Ensure that the Request Authenticatr field value in each RADIUS packet sent by the PEP changes each time a new Identifier is used. d) Verify that all Access-Request messages sent by the PEP during the authenticatin exchange include either a NAS-IP-Address attribute r a NAS-Identifier attribute r bth. e) Verify that all Access-Request messages sent by the PEP during the authenticatin exchange include a User-Name attribute. f) Verify that any Text r String attributes sent by the PEP during the authenticatin exchange (such as User-Name) d nt have a text length f 0 (attribute Length field equal t 2). g) Verify that the Message-Authenticatr sent frm the PEP t the NAA was valid by ding a hash f the Access-Accept using the shared secret (as specified in sectin 3.2 f RFC 3579). h) Verify that the PEP did nt vilate the attribute transmissin requirements cntained in sectin 5.44 f RFC 2865.Discnnect Access Requestr frm PEP. 7. Begin capturing traffic with Netwrk Analyzer Discnnect the Access Requestr, wait 10 secnds, and unsuccessfully authenticate Access Requestr. 9. Attempt t ping the DHCP Server at frm the Access Requestr. 10. Stp capturing traffic with Netwrk Analyzer Verify that NO traffic frm the Access Requestr is captured by Netwrk Analyzer 1. Expected Outcmes: When the Access Requestr has successfully authenticated, traffic frm the Access Requestr is delivered t DHCP Server 1. When the Access Requestr has nt successfully authenticated, traffic frm the Access Requestr is NOT delivered t DHCP Server 1. All f the cnditins listed in test step 6 apply. When the Access Requestr has successfully authenticated, traffic frm Access Requestr is nt captured by Netwrk Analyzer 1. When the Access Requestr has nt successfully authenticated, traffic frm the Access Requestr is captured by Netwrk Analyzer 1. One f the cnditins listed in test step 6 is nt met VLAN-Based Islatin (Success) [CTNC-IFPEP1.0-PEP-TC-2] Purpse: T verify that if the PEP supprts VLAN-based islatin, it adheres t RFC2868 tunnel attributes sectin 3.1 and 3.2, and 3.6 and RFC3580 sectin 3.31 usage guidelines. This test case nly applies if the PEP supprts VLAN-based islatin. This test case is fr the fllwing requirement: [CTNC-IFPEP1.0-PEP-REQ-3-M], [CTNC- IFPEP1.0-PEP-REQ-36-M], and [CTNC-IFPEP1.0-PEP-REQ-38-M]. Revisin 0.15 Published Page 20 f 49

21 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright Pre-cnditins: Devices cnfigured t Cmmn Setup. Additinally: Cnfigure NAA t infrm PEP t enfrce VLAN-based islatin using the fllwing set f attributes: Tunnel-type (set t a value 13 fr "VLAN"), Tunnel-Medium-Type (set t a value f 6 fr "802") Tunnel-Private-Grup-ID attributes (set t the string "10" t refer t VLAN 10) The Tag field shuld set t 0 fr bth the Tunnel-Type and Tunnel-Medium-Type attributes. 1. Begin capturing traffic with bth Netwrk Analyzer 1 and Netwrk Analyzer Authenticate Access Requestr t NAA thrugh PEP. 3. Generate traffic with Access Requestr - attempt t ping bth DHCP servers ( and ). 4. By analyzing traffic captured by Netwrk Analyzer 1 and Netwrk Analyzer 2, verify that traffic frm the Access Requestr appears nly n VLAN 10. Expected Outcmes: NAA sends the VLAN attributes (Tunnel-Type, Tunnel-Medium-Type, and Tunnel-Private- Grup-ID) t PEP Access Requestr sends ping traffic that appears nly n VLAN 10 PEP might nt supprt VLAN-based Islatin Traffic appears n VLAN 20 Traffic des nt appear n VLAN 10 PEP des nt supprt RFC 3580 sectin 3.31 requirements, such as: Expects t receive VLANID in Tunnel-Private-Grup-ID as a RADIUS integer, nt a string Expects t receive Tunnel-Medium-Type value f "802" instead f "6" (the enumerated value representing IEEE 802 tunnel types) PEP des nt respnd t Tunnel-Private-Grup-ID attribute Tag field set t 0, but may respnd t Tag field set t 01 r Tag field nt present VLAN-Based Islatin (Failure) [CTNC-IFPEP1.0-PEP-TC-3] Purpse: T verify that if the PEP supprts VLAN-based islatin, it adheres t RFC2868 tunnel attributes sectin 3.1, 3.2, and 3.6 and RFC3580 sectin 3.31 usage guidelines, specifically, the requirement that unknwn Tunnel-Type and Tunnel-Medium-Types are treated as rejectin messages by the PEP. This test case nly applies if the PEP supprts VLAN-based islatin. This test case is fr the fllwing requirements: [CTNC-IFPEP1.0-PEP-REQ-3-M], [CTNC- IFPEP1.0-PEP-REQ-35-M], and [CTNC-IFPEP1.0-PEP-REQ-37-M]. Precnditins: Devices cnfigured t Cmmn Setup. Additinally: Cnfigure NAA t infrm PEP t enfrce VLAN-based islatin using the fllwing set f attributes: Revisin 0.15 Published Page 21 f 49

22 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright Tunnel-type (set t the invalid value f 0xFFFFFF) Tunnel-Medium-Type (set t a value f 6 fr "802") and Tunnel-Private-Grup-ID (set t "10" fr the internal VLAN). The Tag field shuld set t 0 fr bth the Tunnel-Type and Tunnel-Medium-Type attributes. 1. Begin capturing traffic with bth Netwrk Analyzer 1 and Netwrk Analyzer Authenticate Access Requestr t NAA thrugh PEP. 3. Generate traffic with Access Requestr - ping bth DHCP servers ( and By analyzing traffic captured by Netwrk Analyzer 1 and Netwrk Analyzer 2, verify that traffic frm Access Requestr is nt seen n either VLAN 10 r VLAN Change the cnfiguratin f the NAA t infrm PEP t enfrce VLAN-based islatin using the fllwing set f attributes: a. Tunnel-type (set t a value 13 fr "VLAN") b. Tunnel-Medium-Type (set t the invalid value f 0xFFFFFF) and c. Tunnel-Private-Grup-ID (set t "10" fr the internal VLAN). d. The Tag field shuld set t 0 fr bth the Tunnel-Type and Tunnel-Medium-Type attributes. 6. Authenticate Access Requestr t NAA thrugh PEP. 7. Generate traffic with Access Requestr - ping bth DHCP servers ( and By analyzing traffic captured by Netwrk Analyzer 1 and Netwrk Analyzer 2, verify that traffic frm Access Requestr is nt seen n either VLAN 10 r VLAN 20. Expected Outcmes: NAA sends the VLAN attributes (Tunnel-Type, Tunnel-Medium-Type, and Tunnel-Private- Grup-ID) t PEP In bth steps 4 & 8, the attempt t cnnect t the netwrk by Access Requestr is rejected, and n client traffic is seen by either netwrk analyzer. PEP might nt supprt VLAN-based Islatin PEP des nt supprt RFC 2868 requirements t treat unknwn values f Tunnel-Type and Tunnel-Medium type as reject messages and therefre passes traffic. Traffic sent by the Access Requestr is seen n VLAN 10 r VLAN Filter-Based Islatin [CTNC-IFPEP1.0-PEP-TC-4] Purpse: T verify that if the PEP supprts Filter-based islatin, it supprts the Filter-ID attribute as defined in RFC This test case nly applies if the PEP supprts filter-based islatin. This test case is fr the fllwing requirements: [CTNC-IFPEP1.0-PEP-REQ-4-M] and [CTNC- IFPEP1.0-PEP-REQ-26-M]. Revisin 0.15 Published Page 22 f 49

23 TCG Cmpliance_TNC IF-PEP Cmpliance Test Plan Versin 1.0 TCG Cpyright Precnditins: Devices cnfigured t Cmmn Setup. Additinally: Cnfigure PEP in an unspecified manner with a filter that blcks access t the NAA at and allws access t the DHCP server at Cnfigure NAA t infrm PEP t enfrce filter-based islatin using fllwing attribute: Filter-ID (set t name f the filter defined in the precnditins) 1. Begin capturing traffic with Netwrk Analyzer Authenticate Access Requestr t NAA thrugh PEP. 3. Generate traffic with Access Requestr - ping the DHCP server at and the NAA at Stp capturing traffic with Netwrk Analyzer By analyzing traffic captured by Netwrk Analyzer 1, verify that traffic frm the Access Requestr appears n VLAN 10 nly ging t the DHCP server at Expected Outcmes: NAA sends the Filter attribute t PEP. Client sends ping traffic t bth the NAA and DHCP server Traffic destined fr the DHCP server is permitted. Traffic destined fr the NAA n is nt permitted. Traffic destined fr the NAA is permitted. Traffic destined fr the DHCP server is nt permitted Successful CA with VLANs [CTNC-IFPEP1.0-PEP-TC-5] Purpse: T verify that if the PEP supprts dynamic plicy changes (as described in sectin 5.4 f IF-PEP), it supprts CA as described in RFC3576. This test case nly applies if the PEP supprts VLAN-based islatin and dynamic plicy changes. This test case is fr the fllwing requirements: [CTNC-IFPEP1.0-PEP-REQ-5-M], [CTNC- IFPEP1.0-PEP-REQ-46-M], [CTNC-IFPEP1.0-PEP-REQ-47-M], and [CTNC-IFPEP1.0-PEP- REQ-48-M]. Precnditins: Devices cnfigured t Cmmn Setup. Additinally: Cnfigure NAA t place cmpliant endpints n VLAN 10 and nn-cmpliant endpints n VLAN 20. Ensure that endpint is cmpliant with NAA plicy. 1. Begin capturing traffic with Netwrk Analyzer Authenticate Access Requestr t NAA thrugh PEP. Access Requestr shuld be placed n VLAN Verify that Access Requestr is n VLAN 10 by pinging DHCP servers and Respnses shuld nly be received frm DHCP server If this is nt true, cnfiguratin r peratin is incrrect. Revisin 0.15 Published Page 23 f 49