Access Requestor and Policy Decision Point in

Transcription

1 Overview Access Requestor and Policy Decision Point in by Martin Schmiedel September 2006 Fachhochschule Hannover Fachbereich Informatik

2

3 Author: Martin Schmiedel (M.Sc., Diplom-Informatiker (FH)) Fachhochschule Hannover Fachbereich Informatik 3

4 4

5 Contents 1 Introduction 7 2 Basic conditions and requirements Basic conditions Non-functional Requirements Functional Requirements Access Requestor for Windows Architecture Network Access Requestor Architecture of NAR Implementation of EAPOL and EAP-TNC Flow inside NAR during connection establishment Flow during Handshake TNC Client Architecture Overview Flows inside TNC Client Development Environment and Build Process Development Environment Build of AR Development of network driver NDISProt Adjustment and Compilation of NDISProt Installation of NDISProt driver Development of User Interface Basics and Technics wxwidgets as GUI framework Policy Decision Point for Linux Overall Architecture Network Access Authority Architecture Overview NAA Flow inside NAA TNC Server Architecture Overview TNCS Flow inside TNC Server End of Handshake and Policy Management

6 Contents 4.4 Development Development Environment Development support for the build of TNCS-SO Development of EAP-TNC Module Development of EAP-TNC Module from FreeRadius Configuration of FreeRadius Extension of EAP Module Generation of EAP submodule EAP-TNC Build of PDP Configuration file tncs fhh.conf Client/Server-spanning concepts Concepts for Platform independence Connecting the IML TNCCS Communication and Fragmentation TNCCS creation and analysis Fragmentation of messages Configuration of network environment 45 A Design Documents 49 A.1 Sequence diagrams A.2 Class diagrams A.3 TNC Client Screenshots B Development, Installation and Configuration 57 B.1 Development Environment in Windows B.2 Entwicklungsumgebung unter Linux B.3 Installation von NDISProt B.4 Build of wxwidgets B.5 Configuration files Bibliography 69 List of Figures 71 6

7 1 Introduction In the project the TNC architecture was built up in a protypical way based on 802.1x in wired Ethernet LANs. This document shall explain the main ideas and design decisions of the developed components Access Requstor and Policy Decision Point and how to build, install and run these components. The developed IMV-IMC-pairs are subject of a different document. It is assumed that the reader is familiar with TNC architecture, it s components and the interfaces. 7

8 1 Introduction 8

9 2 Basic conditions and requirements 2.1 Basic conditions These are the general conditions that were the basis for the development: No commercial targets, only academic ideals use only third-party software that is available for everyone develop with free available IDEs use 802.1x in wired ethernet infrastructures as underlying technology run with any switch that supports 802.1x (tested only with HP Procurve Switches) 2.2 Non-functional Requirements These non-functional requirements were important for the project: develop open source use C and C++ and the C Platform Bindings from IF-IMC and IF-IMV AR runs in Windows XP environment PDP runs in Linux environment (tested with SuSE 9.3) But both components should be easily portable TNC specifications must be implemented as exact as possible (IF-IMC 1.1, IF-IMV 1.1, IF-PEP 1.0, IF-T EAP Methods 1.0, IF-TNCCS) Use 802.1x in NAL and communicate via IF-T 9

10 2 Basic conditions and requirements 2.3 Functional Requirements These are the functions that have been implemented: Integrity of Windows clients can be checked. Integrity check results in one of three action recommendations: access denied, access allowed, isolated access allowed Action recommendations result from a simple security policy. Switch transfers these recommendations to actions on the specific port. Assignment to VLANs depending on the result is supported (via IF-PEP). No automatical remediation of AR is supported (only assignment to remediation VLAN). 10

11 3 Access Requestor for Windows 3.1 Architecture AR is designed as one only application that has to be started manually by the user and does not run in the background. Because of that integrity check is visible and understandable for the user. The overall architecture is shown in picture 3.1. AR is built up of application Figure 3.1: Overall architecture of AR in Deployment Diagram 11

12 3 Access Requestor for Windows TNC-AR and IMC components (DLLs) that are connected to TNC-AR as described in Windows Platform Binding of IF-IMC. TNC-AR includes two components that are similar to the components defined in TNC architecture. These components are loosely coupled so that you can easily change the network technology in NAL without touching component TNC Client. You find a detailled class diagram with all classes of AR in appendix (chapter A.2). The facades between the components of AR are shown in picture 3.2. Figure 3.2: Facades between components of AR 12

13 3.2 Network Access Requestor 3.2 Network Access Requestor Architecture of NAR The static architecture of NAR is shown in picture 3.3. Figure 3.3: Static architecture of NAR Classes of NAR have clearly separated tasks: NARFascade is access point to NAL for TNC Client. Interface is independent of the network access technology used in NAL. NetAccessControl works as flow control and controls the correct 802.1x flow and all other classes. WinNetAccessor implements access to the network out of Windows (implemented by using a NDIS protocol driver, see chapter 3.5). PacketGenerator creates EAPOL packets with encapsulated EAP-TNC packets. PacketValidator analyses ethernet packets received by WinNetAccessor according to their 802.1x contents. FragmentationManager cares of fragmentation and defragmentation of messages. For detailled descriptions see comments in source code. 13

14 3 Access Requestor for Windows Implementation of EAPOL and EAP-TNC The two classes PacketGenerator and PacketValidator (see picture 3.4) are responsible for analysis of incoming and creation of outgoing ethernet packets. Figure 3.4: Classes for Packet generation and validation Using theses classes NetAccessControl can easily create ethernet packets and can check the relevance of incoming packets to the actual context. For detailled descriptions see comments in source code Flow inside NAR during connection establishment Roughly you can split the flows inside the NAR in two phases: In the first phase the NAR establishs the connection to PDP so that in the second phase TNCCS messages can be transfered between AR and PDP. The flow of the first phase is shown in picture Flow during Handshake In the second phase NAR is responsible for sending and receiving TNCCS messages. The flow (see picture 3.6) is started by TNC Client everytime the TNC Client wants to send a new TNCCS message. In the shown flow we have excluded the fragmentation of messages for simplicity (for fragmentation see chapter 5.3.2). 3.3 TNC Client 14

15 3.3 TNC Client Figure 3.5: Flow inside NAR during connection establishing 15

16 3 Access Requestor for Windows Figure 3.6: Flow in NAR while sending and receiving TNCCS messages Architecture Overview Classes inside the component TNC Client are shown in picture 3.7. These are their tasks: FlowControl controls the flow inside TNC Client. TNCCFascade is access point to the TNC Client for GUI. TNCCSMsgMaster analyses and creates TNCCS messages. ImcImvMsgCoordinator distributes IMC-IMV messages to the IMC components. IMCCommunicator communicates with IMCs via IF-IMC-interface. WinIMCCollector loads IMCs according to Windows Binding from IF-IMC. ImcImvMsgRepository stores messages that should be sent from IMCs to IMVs and that have been sent by IMVs to IMCs. For detailled descriptions see comments in source code. 16

17 3.3 TNC Client Flows inside TNC Client Figure 3.7: Classes inside TNC Client The sequence diagram in picture 3.8 shows the flow inside TNC Client. More detailled sequence diagrams to the flows in TNC Client can be found in chapter A.1 in appendix. 17

18 3 Access Requestor for Windows Figure 3.8: Overview of flows in TNC Client 18

19 3.4 Development Environment and Build Process 3.4 Development Environment and Build Process Development Environment The AR has been developed with Eclipse in Windows XP. The Eclipse-Plugin CDT (C/C++ Development Tooling) SDK allows the development of C and C++ application out of Eclipse Build of AR The Access Requestor is designed as executable application (*.exe) for the Cygwin environment 2. So an emulated gcc is used for compiling the application in Windows. In Eclipse we created a Managed Make C++ Project for the AR so that the AR can be built completely out of Eclipse with CDT. The parameters that have to be set in the Eclipse project are listed in appendix B.1. Especially the usage of wxwidgets as framework for the GUI needs several settings (also see 3.6). 3.5 Development of network driver NDISProt Adjustment and Compilation of NDISProt For accessing the network we need the NDIS Protocol Driver NDISProt because we did not find any other possibility to access the ethernet network (without any stack like TCP/IP) directly from C code out of Windows. This driver is one of the examples from Windows Driver Development Kit. There you can find the driver and an application for testing this driver. Both have to be compiled before we can use them. Customization of NDISProt For the usage in the TNC architecture we have to make some customizations to the driver. Because the driver cannot per default receive packets that are addressed to the address defined in 802.1x for the communication via EAPOL (see [IEE04, p. 31], C ) we have to add another packet type to ndisprot.h. This type is All Multicast (see Listing 3.1). #define NUIOO_PACKET_FILTER (NDIS_PACKET_TYPE_DIRECTED \ NDIS_PACKET_TYPE_MULTICAST \ NDIS_PACKET_TYPE_BROADCAST \ NDIS_PACKET_TYPE_ALL_MULTICAST)

20 3 Access Requestor for Windows Listing 3.1: Customizations in ndisprot.h Compilation of NDISProt Using the Build Environment included in the DDK we can compile NDISProt as described in the documentation of this DDK example (see Figure 3.9). Figure 3.9: Build of NDISProt in Windows Server 2003 Free Build Environment After that the setup information file ndisprot.inf and the driver ndisprot.sys have been created and are ready for service Installation of NDISProt driver Now the generated network driver can be installed as protocol for the network card (see Screenshots in appendix B.3). The setup information file ndisprot.inf states that the driver should be started manually. The command is: net start ndisprot Now ethernet packets can be received via ReadFile method and sent via WriteFile method out of C/C++ applications. 20

21 3.6 Development of User Interface Figure 3.10: TNC Client user interface: Integrity assessment ends with granted access. 3.6 Development of User Interface Basics and Technics One target of was to make the integrity check as transparent as possible. Therefore a user interface has been developed so that the user can control the integrity check and can exactly see what happens. Picture 3.10 shows a screenshot of the user interface. Using this GUI the user is able to choose the network interface that should be used for integrity assessment. see which IMCs are installed and available for integrity check and exclude untrustworthy IMCs from integrity check. activate detailled logging to a file with a lot of information about the handshake. see the actual state of check via a log window. cancel the test whenever he wants. 21

22 3 Access Requestor for Windows wxwidgets as GUI framework The user interface of TNCC has been developed by using wxwidgets 3. WxWidgets allows the development for different plattforms with one code-basis. This property can help porting the TNCC to Linux later on. In this project we use wxwidgets in Version Before you can use wxwidgets it has to be installed and built. How this works is described in appendix B.4. The settings for using wxwidgets inside Eclipse can be found in [Don04] and the setting needed in the context of this project are described in B

23 4 Policy Decision Point for Linux 4.1 Overall Architecture Figure 4.1 shows the overall architecture of PDP. PDP is designed as a plugin to FreeRadius RADIUS server. The existing EAP module of FreeRadius has been extended with EAP-TNC functionality (see chapter 4.4.3). So we can reuse network access, RADIUS functionality and EAP functionality. All but the base functionality is linked as shared object so that development is much easier. A detailled class diagram with all classes of PDP can be found in chapter A.2 of appendix. Slim facades between the components of PDP lead to a loosely coupled components. These facades are shown in picture Network Access Authority Architecture Overview NAA In picture 4.3 the most important source files and classes of NAA are shown. Below the dotted line the files belonging to the EAP-TNC-Modul (from FreeRadius in C) are shown, above the dotted line the C++ classes from the Shared Object are shown. 23

24 4 Policy Decision Point for Linux Figure 4.1: Overall architecture of PDP 24

25 4.2 Network Access Authority Figure 4.2: Fascades between components inside PDP 25

26 4 Policy Decision Point for Linux Figure 4.3: Static architecture of NAA component Source files from FreeRadius These are the tasks of the source files from FreeRadius extension: rlm eap tnc is the external access point for the EAP modul. tnc connect includes methods that establish direct connection to the functionality of TNC Shared Object. eap tnc cares of EAP-TNC specific tasks (analyse and create EAP-TNC messages). NAA classes of Shared Object Extended NAA functionality is implemented inside the Shared Object: TNCSBind is a C interface for the FreeRadius module. ConnectionManager administrates all connections to PDP that are active. Additionally, ConnectionManager loads IMVs using LinuxIMVCollector and informs them of new or finished connections via IMVCommunicator. Naa2Tncs exists for every active connection once and builds the bridge between NAA tasks (like fragmentation of TNCCS messages) and the pure TNC Server (via TncsFlowControl). 26

27 4.3 TNC Server FragmentationManager executes fragmentation and defragmentation initiated by Naa2Tncs Flow inside NAA The sequence diagram in picture 4.4 shows roughly how the presented functions and classes interact with each other. 4.3 TNC Server Architecture Overview TNCS The architecture of TNC Server with the most important classes is shown in picture 4.5. The classes are ordered vertically: The classes below the dotted line handle the correct flow and state of TNC Server. TncsFlowControl is the central class that takes TNCCS messages from Naa2Tncs and initiates the processing of the message. TNCCSMsgMaster creates and analyses TNCCS messages. ImcImvMessageRepository stores IMC-IMV messages that come from IMCs remotely and from IMVs locally. IMUnitRepository stores access information to each registered IMV component. LinuxConfigReader reads configuration file tnc_config as described in Linux Binding of IF-IMV. Recommender stores recommendations given by IMV components and generates final recommendations based on a security policy. Classes above the dotted line communicate directly with IMV components: LinuxIMVCollector loads IMV components at server start. IMVCommunicator communicates with IMVs via IF-IMV. tnc imv fascade offers together with tnc_imv_linuxbinding the TNCS functions from IF-IMV to IMVs. 27

28 4 Policy Decision Point for Linux Figure 4.4: Flows inside NAA after having received a RADIUS message 28

29 4.3 TNC Server Flow inside TNC Server Figure 4.5: Static architecture of TNCS Picture 4.6 shows the flow inside TNC Server (diagram can be connected to diagram 4.4 on page 28 at number 15) End of Handshake and Policy Management End of Handshake In our implementation a handshake ends under one of the following conditions: All IMVs already gave a recommendation OR no IMV (although asked) sends new IMC-IMV messages to TNC Server OR a configurable number of batches has been reached. Policy Management The final recommendation is based on a simple security policy in this implementation. There are 6 different settings that can be chosen. After having collected recommendations from all IMVs the TNC Server walks through one of the six flowcharts (see picture 4.7) and so generates a final decision. Which diagram to use can be configured in /etc/tnc/tncs_fhh.config. 29

30 4 Policy Decision Point for Linux Figure 4.6: Flow inside TNCS between Receiving and Sending a TNCCS message 30

31 4.3 TNC Server Figure 4.7: All available policy walk-throughs 31

32 4 Policy Decision Point for Linux 4.4 Development Development Environment We used Eclipse for Linux as development environment. As for the AR in Windows we used the Eclipse plugin CDT SDK here in version Development support for the build of TNCS-SO The development and build of the TNCS Shared Object is done gaining full support of CDT. We created a Managed Make C++ Project and built the TNCS SO completely out of Eclipse. The mandatory Eclipse settings are listed in appendix B.2. At the end of this build process part a Shared Object libtncs.so has been generated that will be included in the complete build of PDP Development of EAP-TNC Module This part of application cannot be built out of Eclipse because it is part of the Free- Radius application that is delivered with a complex build process. So we wrote the code in a text editor and copied the created and modified files into the FreeRadius distribution. 4.5 Development of EAP-TNC Module from FreeRadius Configuration of FreeRadius We can use FreeRadius with its default configuration. Only one adjustment is to be done: In /usr/local/etc/raddb/clients.conf the PEP is registered as client (see example configuration in Listing 4.1). client { secret = mypassword shortname = TNC-PEP nastype = other } Listing 4.1: PEP entry in clients.conf 32

33 4.5 Development of EAP-TNC Module from FreeRadius Extension of EAP Module Modifications in configuration files of EAP Module The configuration files of EAP module are modified as following (compare [Rag05]): In /usr/local/etc/raddb/eap.conf a new entry for EAP-TNC is registered in Supported EAP-types and referenced as Default EAP type (see Listing 4.2). eap{ default_eap_type = tnc... #Supported EAP-types tnc{ }... } Listing 4.2: Settings in eap.conf Changes in general EAP Module code The EAP module framework maps the EAP types and EAP type numbers to the responsible module. Therefore in <FREERADIUS>/src/modules/rlm_eap/libeap/ eapcommon.c in array eap_types tnc has to be entered at position 38 (EAP- TNC is assigned to EAP-Type 38) (see Listing 4.3). static const char *eap_types[]={... "37", "tnc", "39" }; Listing 4.3: EAP-TNC in eapcommon.c A similiar addition has to be undertaken in eap_types.h (see Listing 4.4). #define PW_EAP_MAX_TYPES 39 #define PW_EAP_TNC 38 Listing 4.4: EAP-TNC in eap types.h With these additions the EAP module now forwards all EAP messages to the new EAP submodule EAP-TNC presented in the next section Generation of EAP submodule EAP-TNC The easiest way to create the new EAP-TNC module rlm_eap_tnc was to copy the existing module rlm_eap_md5 and change everywhere md5 to tnc so 33

34 4 Policy Decision Point for Linux that we have a module fully functional. RADIUS>/src/modules/rlm_eap/types. The modules can be found in <FREE- We implemented the mandatory functions tnc_initiate and tnc_authenticate in file rlm_eap_tnc.c and registered them in the struct rlm_eap_tnc (see Listing 4.5). static int tnc_initiate(void *type_data, EAP_HANDLER *handler){... } static int tnc_authenticate(void *arg, EAP_HANDLER *handler){... } EAP_TYPE rlm_eap_tnc= { "eap_tnc", NULL, /* attach */ tnc_initiate, /* Start the initial request */ NULL, /* authorization */ tnc_authenticate, /* authentication */ NULL /* attach */ } Listing 4.5: rlm eap tnc.c Important is that these methods fill the passed EAP_HANDLER with the correct EAP Request (based on EAP-TNC) as output parameter. The TNCS-SO is accessed as usual Shared Object out of this module. VLAN Assignment We do not want to configure the VLAN assignment user-oriented as it is usually done in FreeRadius via configuration file /usr/local/etc/raddb/users (see Listing 4.6). Lumpy Auth-Type := EAP, User-Password == "mypassword" Tunnel-Type = "VLAN", Tunnel-Medium-Type = "IEEE-802", Tunnel-Private-Group-ID = 96 Listing 4.6: Configured VLAN assignment in raddb/users Instead we made the assignment programmatically based on the judgement of TNCS. 1 Listing 4.7 shows how the RADIUS attributes according to IF-PEP can be set into EAP_HANDLER. VALUE_PAIR *tunneltype = pairmake("tunnel-type", "VLAN", T_OP_SET); pairadd(&handler->request->reply->vps, tunneltype); 1 An authentication of the users does not take place. 34

35 4.6 Build of PDP VALUE_PAIR *tunnelmedium = pairmake("tunnel-medium-type", "IEEE-802", T_OP_SET); pairadd(&handler->request->reply->vps, tunnelmedium); char *vlannumber="96"; VALUE_PAIR *vlanid = pairmake("tunnel-private-group-id", vlannumber, T_OP_SET); pairadd(&handler->request->reply->vps, vlanid); Listing 4.7: Programmative VLAN assignment 4.6 Build of PDP The complete build of PDP consists of several steps: 1. TNCS-SO is built as described in the last section. 2. TNCS-SO is copied to its target position. 3. All potentially changed *.c- and *.h-files are copied to its destination in Free- Radius distribution. These are the files from the following directories: modules/rlm_eap/types/rlm_eap_tnc modules/rlm_eap/libeap 4. The EAP-TNC module, EAP Module and the whole FreeRadius distribution are compiled. 5. The generated files are copied to its target positions. The steps 2 und 3 are summarized in a script copyall, step 4 and 5 go in accordance with the FreeRadius Build process. (see Listing: 4.8). /home/tncuser/workspace/copyall && make && make install Listing 4.8: Build execution for PDP 4.7 Configuration file tncs fhh.conf To ease the configuration of PDP a configuration file tncs_fhh.conf is part of the system that is built up like a property file. You can see the structure in listing B.2 in appendix. The configuration file offers the following setting possibilities: VLAN ACCESS The VLAN ID for ARs that passed the integrity check 35

36 4 Policy Decision Point for Linux VLAN ISOLATE The VLAN ID for ARs that should be isolated BATCH COUNT Number of batches the TNCS allows before finishing the Handshake POLICY The Number of active security guide line (see chapter and comments in file) TNCS PATH Path to the TNCS-Shared Object The applicable IMVs are registered in file tnc_config according to IF-IMV, Linux Binding. 36

37 5 Client/Server-spanning concepts In order to reach reusement, simple extensibility and portability there are classes and concpts inside that are developed once and used in AR as well as in PDP. 5.1 Concepts for Platform independence Inside TNC architecture there are two areas that are platform dependent: Accessing the network Linking the IMCs/IMVs With the Factory-Pattern we achieved that these areas are implemented plattformdependent but used plattform-independent. Picture 5.1 shows how this works. So it is very simple to port the TNC Client to Linux. You only have to implement LinuxIMCCollector and LinuxNetAccessor. Figure 5.1: Plattform dependent creation with Factory-Pattern 37

38 5 Client/Server-spanning concepts 5.2 Connecting the IML Connecting the IML works very similar in TNC Client and TNC Server. Because of that we implemented the connection in shared classes as far as possible. Figure 5.2 shows all the classes that take part in this process. Figure 5.2: Classes for connecting the IML Figure 5.3 shows the flow during the communication with the components of IML at the example of TNC Client. The flow shown in picture 5.3 can also take place in TNC Server with one exception. Instead of IMCCommunicator IMVCommunicator has to be used. The mechanism shown in picture 5.4 makes possible that the right Communicator is used in a transparent way to the caller. 5.3 TNCCS Communication and Fragmentation The classes responsible for TNCCS communication (defined in IF-TNCCS) and fragmentation (defined in IF-T EAP Binding) are shown in picture TNCCS creation and analysis Figure 5.6 shows how the creation and analysis of TNCCS messages inside IEL work Fragmentation of messages FragmentationManager inside NAL is the main actor in the complex fragmentation and defragmentation process and offers a lot of methods. Figure 5.7 shows which 38

39 5.3 TNCCS Communication and Fragmentation Figure 5.3: Flow of communication between IML components and TNC Client decisions have to be made at the start of the process when a EAP-TNC message arrives. Figure 5.8 and 5.9 continue and finish this process. All these decisions can be mapped to methods of FragmentationManager. Fragmentation works similar in NAR and NAA. Inside the AR Fragmentation- Manager is controlled by NetAccessControl, inside the PDP Naa2Tncs plays this role. 39

40 5 Client/Server-spanning concepts Figure 5.4: Communication with IMCs vs. communication with IMVs Figure 5.5: Classes responsible for implementing IF-TNCCS and fragmentation 40

41 5.3 TNCCS Communication and Fragmentation Figure 5.6: Flow with focus on analysis and creation of TNCCS messages 41

42 5 Client/Server-spanning concepts Figure 5.7: Start of fragmentation process with handle of incoming acknoledgments 42

43 5.3 TNCCS Communication and Fragmentation Figure 5.8: Handle of received TNCCS-message 43

44 5 Client/Server-spanning concepts Figure 5.9: Handle of outgoing TNCCS-messages 44

45 6 Configuration of network environment Now we want to explain how to configure your switch so that it works together with our TNC implementation. We show exemplarily the settings of a HP Procurve 5348xl that we used during our development (also see [HP 05]). We assume that we use network and the IP of the switch is General 802.1x activation We activate 802.1x on the switch with the following steps: config switches to configuration mode aaa authentication portaccess eap-radius thentication defines that we want to use RADIUS for au- show auth shows the latest settings (see figure 6.1) radius host defines the IP address of the RADIUS server (our PDP) radius-server key mypassword as key when accessing the RADIUS server defines that mypassword should be used aaa port-access authenticator activates 802.1x authentication active 802.1x authentication for single ports aaa port-access authenticator A11 switches on 802.1x authentication for Port A11 VLAN setup The webconsole is the simplest way for configuring the VLANs. Via Configuration and VLAN Configuration you can watch existing and add new VLANs. You should configure these two VLANs: 45

46 6 Configuration of network environment Figure 6.1: The authentication configuration of Procurve switch VLAN ID VLAN Name Description 96 AuthZone VLAN for ARs that passed the integrity check 97 IsoZone VLAN for ARs that should be isolated after integrity check Figure 6.2 shows a complete VLAN configuration that could look like yours. Now the switch is ready for TNC. The configuration of a Cisco switch proceed similar and is explained in [Cis04]. 46

47 Figure 6.2: The complete VLAN configuration in Procurve webconsole 47

48 6 Configuration of network environment 48

49 Appendix A Design Documents A.1 Sequence diagrams 49

50 Appendix A Design Documents Figure A.1: Overall flow TNCCS and IMC communication in TNCC 50

51 A.1 Sequence diagrams Figure A.2: Initialization of TNC Client 51

52 Appendix A Design Documents A.2 Class diagrams Figure A.3: Static overall archicture of AR 52

53 A.2 Class diagrams Figure A.4: Static overall architecture of PDP 53

54 Appendix A Design Documents A.3 TNC Client Screenshots Figure A.5: TNC Client User Interface: The integrity checks has ended with Access denied 54

55 A.3 TNC Client Screenshots The in- Figure A.6: TNC Client User Interface when NDISProt is not running. tegrity check cannot be started. 55

56 Appendix A Design Documents 56

57 Appendix B Development, Installation and Configuration B.1 Development Environment in Windows The following tables and Screenshots show the settings to be done in Eclipse in order to compile and build the AR successfully. GCC C++ Compiler/Preprocessor/Defined Symbols Symbol required by GNUWIN32 wxwidgets STRICT wxwidgets WXMSW wxwidgets WINDOWS wxwidgets WXDEBUG wxwidgets The dialog Defined Symbols is shown in figure B.2. GCC C++ Compiler/Directories/Include paths Path required by <WXW>/lib/mswd wxwidgets <WXW>/build-debug/lib/wx/- wxwidgets include/msw-ansi-debug-static- 2.6 <WXW>/include wxwidgets <WXW>/contrib/include wxwidgets <WXW>/src/regex wxwidgets <WXW>/src/png wxwidgets <WXW>/src/jpeg wxwidgets <WXW>/src/zlib wxwidgets <WXW>/src/tiff wxwidgets <WXW> stands for the path to wxwidgets installation. The dialog Include paths is shown in figure B.3. 57

58 Appendix B Development, Installation and Configuration GCC C++ Compiler/Miscellaneous/Other flags Flags required by -c fmessage-length=0 -fno-rtti -fexceptions wxwidgets The dialog Other flags is shown in figure B.4. GCC C++ Linker/Libraries/Libraries Library required by TNCUtil Usage of Util-functions xerces-c27 Xerces (XML-Parsing) wx mswd core-2.6 wxwidgets wx based-2.6 wxwidgets oleaut32 wxwidgets ole32 wxwidgets uuid wxwidgets comctl32 wxwidgets GCC C++ Linker/Libraries/Library Search Path Path required by <Path to libxerces-c27.dll.a> xerces-c27 <Path to libtncutil.a> TNCUtil <WXW>/build-debug/lib wxwidgets <WXW>/contrib/lib wxwidgets The dialog according included libraries is shown in figure B.6. GCC C++ Linker/Miscellaneous/Linker flags Flag required by -mwindows wxwidgets 58

59 B.1 Development Environment in Windows Figure B.1: Overview of Compiler settings Figure B.2: Settings for Preprocessor 59

60 Appendix B Development, Installation and Configuration Figure B.3: Directories where the Compiler should search for source files Figure B.4: Other Compiler settings 60

61 B.1 Development Environment in Windows Figure B.5: Overview of Linker settings Figure B.6: Definition of included libraries 61

62 Appendix B Development, Installation and Configuration B.2 Entwicklungsumgebung unter Linux The following tables and screenshots show the mandatory settings in Eclipse for building the shared object of TNCS successfully. GCC C++ Linker/Libraries/Libraries Library required by dl dynamic loading of so-files (IMV-SO-files) TNCUtilLinux usage of util-functions xerces-c.so Xerces (XML-Parsing) GCC C++ Linker/Libraries/Library search path Path required for <Path to libxerces-c.so.a> xerces-c.so <Path to libtncutillinux.so> TNCUtilLinux The Dialog for library settings is shown in figure B.8. GCC C++ Linker/Shared Library Settings Mark set required for Shared building NAA-TNCS as Shared Object The dialog Shared Library Settings is shown in figure B.9. 62

63 B.2 Entwicklungsumgebung unter Linux Figure B.7: Overview of Linker-settings Figure B.8: Library settings of TNCS 63

64 Appendix B Development, Installation and Configuration Figure B.9: TNCS will be created as Shared Object. 64

65 B.3 Installation von NDISProt B.3 Installation von NDISProt Figure B.10: Properties of LAN connection before NDISProt installation; one click on Install starts the installation. 65

66 Appendix B Development, Installation and Configuration Figure B.11: Now we add a Protocol. Figure B.12: Because NDISProt is not visible we search for it. 66

67 B.3 Installation von NDISProt Figure B.13: After ndisprot.inf has been selected, the driver is found and selected. Figure B.14: Driver is installed and is shown in the properties dialog of LAN connection. 67

68 Appendix B Development, Installation and Configuration B.4 Build of wxwidgets Before we can use wxwidgets for developing applications it has to be built for the specific plattform. In the case of TNC Client this is the cygwin environment in Windows. After the wxwidgets distribution has been installed successfully to $WXWIN we build wxwidgets for Cygwin by executing the steps from Listing B.1 in Cygwin Bash Shell. cd $WXWIN mkdir build-debug cd build-debug../configure --with-msw --enable-debug --enable-debug_gdb --disable-shared make Listing B.1: Build of wxwidgets for Cygwin B.5 Configuration files #VLAN-Configuration VLAN_ACCESS=96 VLAN_ISOLATE=97 #Batch-Configuration BATCH_COUNT=5 #Policy-Configuration POLICY=5 #possible values: #1 (positive simple) #2 (positive unanimity) #3 (positive majority) #4 (negative simple) #5 (negative unanimity) #6 (negative majority) #TNCS-Connection (path max 200 tokens) #if no valid path is given: #default: /usr/local/lib/libtncs.so TNCS_PATH=/tmp/_master-temp/tncs/libTNCS.so Listing B.2: tncs fhh.conf 68

69 Bibliography [Cis04] Cisco Systems, Inc.: Catalyst 3550 Multilayer Switch Software Configuration Guide, Mai Cisco IOS Release 12.1(20)EA2. [Don04] Donaldson, Cameron: C++ GUI Programming on Windows 2000/XP, html Dezember Stand: 08. August [HP 05] HP Procurve Networking: Access Security Guide, Oktober ProCurve Switches E (Series 5300xl), M (Series 3400/6400cl). [IEE04] IEEE Computer Society: 802.1X - Port-Based Network Access Control, 13. Dezember IEEE Standard for Local and metropolitan area networks. [Rag05] Raghu: Rlm eap Extensible Authentication Protocol, freeradius.org/index.php/rlm_eap Dezember FreeRadius Wiki Stand: 29. Mai

70 Bibliography 70

71 List of Figures 3.1 Deployment Diagram: Overall architecture of AR Component Diagram: Fascades between components of AR Class diagram: Static architecture of NAR Class diagram: Packet generation and validation Sequence diagram: NAR during establishing of connection Sequence diagram: NAR during sending and receiving TNCCS messages Class diagram: TNC Client Sequence diagram: Flows inside TNC Client Screenshot: Build of NDISProt Screenshot: TNC Client user interface after granted access Deployment Diagramm: Overall architecture of PDP Component Diagram: Fascades inside PDP Class diagram: Static architecture of NAA Sequence diagram: Flows inside NAA Class diagram: Architecture of TNCS Sequence diagram: TNC Server between Receiving and Sending TNCCS Flussdiagramm: All available Policies Class diagram: Plattform dependent creation with Factory-Pattern Class diagram: Connecting the IML Sequence Diagram: Connecting the IML in TNCC Sequence diagram: Communication with IMCs vs. IMVs Class diagram: Implementation of IF-TNCCS Sequence Diagram: TNCCS messages Flussdiagramm: Start of fragmentation process, incoming acknoledgements Flussdiagramm: Handle of received TNCCS-message Flussdiagramm: Handle of outgoing TNCCS-messages Screenshot: Procurve console show auth Screenshot: VLAN configuration in Procurve-Webconsole A.1 Overall flow TNCCS and IMC communication in TNCC A.2 Initialization of TNC Client A.3 class diagram of AR

72 List of Figures A.4 class diagram of PDP A.5 Screenshot: TNC Client User Interface after Access denied A.6 Screenshot: TNC Client User Interface when NDISProt is not running 55 B.1 Screenshot: Eclipse Compiler Dialog for AR B.2 Screenshot: Eclipse Preprocessor Dialog for AR B.3 Screenshot: Eclipse Include Directories Dialog for AR B.4 Screenshot: Eclipse Compiler Miscellaneous Settings B.5 Screenshot: Eclipse Linker Dialog for AR B.6 Screenshot: Eclipse Linker Library Dialog for AR B.7 Screenshot: Eclipse Linker Settings Dialog for TNCS B.8 Screenshot: Eclipse Library Dialog for TNCS B.9 Screenshot: Eclipse Shared Settings Dialog for TNCS B.10 Screenshot: Properties of LAN-connection before NDISProt B.11 Screenshot: Choice of Protocol as Network component B.12 Screenshot: Search for NDISProt B.13 Screenshot: NDISProt found and selected B.14 Screenshot: NDISProt successfully installed