Podobnie jak w architekturze TCG, Network Access Protection towarzyszy szeroki zakres protokołów związanych z zapewnieniem komunikacji pomiędzy klientem, Enforcement Server i Network Policy Server. W tym przypadku oryginalny Enforcement Server, oparty na DHCP i RRAS, jest w całości oprogramowaniem Microsoftu, tak więc posiadanie otwartych protokołów nie jest sprawą najistotniejszą. Aczkolwiek dostępne dokumenty nie mówią o tym, jak może pracować Enforcement Server 802.1X.

Microsoft pracuje także nad koncepcją tzw. Health Certificate. Używając kombinacji istniejących produktów do tworzenia infrastruktury webowych serwerów kluczy publicznych, o nazwie Health Certificate Server, schemat NAC Microsoftu przewiduje tworzenie certyfikatów cyfrowych, które mogą być używane zamiast Statements of Health.

Zamiast ciągłego wysyłania Statements of Health w czasie uwierzytelniania, klient przedstawia swój stan ochrony Health Certificate Server, używając System Health Agents i Statement of Health. Otrzymuje wtedy certyfikat cyfrowy, który może następnie używać zamiast referencji uwierzytelniania użytkownika w ramach 802.1X lub IPSec. Wykorzystanie w ten sposób certyfikatów wynika logicznie ze strategii VPN Microsoftu, w której uwierzytelnianie IPSec jest w dużym stopniu nieistotne - punktem, gdzie użytkownik faktycznie potwierdza swoją tożsamość jest uwierzytelnianie L2TP, które klient Microsoftu uruchamiania nad IPSec.

Korzyści z tak złożonego systemu, jakim są Health Certificate, nie są jednak całkiem jasne. Prawdopodobnie celem jest zwiększenie wydajności przez odseparowanie zadań związanych z określeniem kondycji systemu od faktycznego łączenie się z zasobami sieci. Czy taka koncepcja będzie warta zwiększonej złożoności na tym etapie rozwoju produktu trudno ocenić.

Kontrola sieci w wydaniu Cisco

Cisco Network Admission Control może być bezpośrednio odwzorowane na architekturę TCG TNC. Ponieważ jednak Cisco jest ściśle związane z zainstalowaną bazą sprzętową, jego architektura to zarówno ograniczenia, jak i rozszerzenia tego, co oferuje TCG.

Po stronie klienckiej TCG Network Access Requestor i klient Trusted Network Connect odpowiada bezpłatne oprogramowanie Cisco Trust Agent, TCG Integrity Measurement Collectors pojawiają się w modelu Cisco w postaci agentów zapewnianych przez różnych dostawców oraz jako (opcjonalnie) własny produkt Cisco Secure Access (system IPS pozyskany wraz z przejęciem w 2003 r. firmy Okena).

Firma musiała poważnie podejść do protokołów niezbędnych do obsługi Network Admission Control. Na najniższym poziomie Cisco wybrało Extensible Authentication Protocol (EAP). Chociaż EAP został zaprojektowany przez IETF do uwierzytelniania i jest używany w większości wdrożeń 802.1X, to jednak Cisco zaprojektowało własną odmianę EAP o nawie EAP-FAST (Flexible Authentication via Secure Tunneling). Dysponując EAP-FAST, Cisco może zawrzeć wewnątrz protokołu EAP uwierzytelnianie 802.1X, a także informacje oceny bezpieczeństwa punktów końcowych.

Ponieważ Cisco zakłada, że jego produkty będą współpracować nie tylko z przełącznikami zgodnymi z 802.1X, Cisco Trust Agent wspiera EAP-over-802.1X oraz EAP-over-UDP. Kiedy system końcowy próbuje uzyskać dostęp do sieci, używając metody innej niż 802.1X, takiej jak klient VPN lub coś innego przechodzącego przez przełącznik nieobsługujący 802.1X, ruch EAP jest transportowany przez protokół UDP zamiast bezpośrednio w ramkach Ethernet.

Istotna różnica pomiędzy wersjami 802.1X i UDP Cisco EAP polega jednak na tym, że w wypadku 802.1X EAP zawiera informacje związane z uwierzytelnieniem i oceną bezpieczeństwa punktu końcowego. Używany z UDP, nie wykonuje uwierzytelniania. W tym przypadku użytkownik musi uwierzytelniać się poprzez inne mechanizmy i takie uwierzytelnianie oraz referencje użytkownika nie są wtedy powiązane z regułami polityki dla tego użytkownika.

Brak symetrii pomiędzy wersjami 802.1X i UDP Cisco Network Admission Control oznacza, że dostęp i uwierzytelnienie są obsługiwane różnie, w zależności od tego, czy łączymy się przez LAN, WLAN czy tunel VPN.

Kolejnym przejawem takiego niesymetrycznego wsparcia jest brak obsługi połączeń bezprzewodowych w bezpłatnym Cisco Trust Agent. Dla bezprzewodowych połączeń 802.1X konieczne jest zastąpienie bezpłatnego Cisco Trust Agent 802.1X innym suplikantem 802.1X, np. z Meetinghouse Data Communications lub Funk Software (obecnie Juniper). Realnym celem bieżącej wersji Network Admission Control jest ocena bezpieczeństwa punktu końcowego. Uwierzytelnianie, które pojawia się przy dialogach 802.1X, jest w rzeczywistości efektem ubocznym.

Jako dominujący producent przełączników, routerów i urządzeń VPN, Cisco bierze na swoje barki trudne zadanie włączenia Network Admission Control do swoich urządzeń. Egzekwowanie reguł polityki TCG w architekturze Cisco jest odwzorowane w sieciowych urządzeniach dostępowych. Cisco w swojej dokumentacji wyjaśnia, które urządzenia będą obsługiwać różne scenariusze klienta: EAP-over-UDP i EAP-over-802.1X.

Ocena takiego podejścia jest trudna i jest ono przedmiotem krytyki. Za główną wadę koncepcji Cisco konkurenci uznają konieczność uaktualnienia wszystkich przełączników, chociaż Cisco ma przekonanie, że większość użytkowników zainteresowanych Network Admission Control posiada już odpowiednie wyposażenie i może je od razu wykorzystać.

Jedną z jaśniejszych kwestii jest fakt, że możliwości egzekwowania reguł polityki w różnych urządzeniach są bardzo różne. Wysyłanie pełnych, dobrze uszczegółowionych reguł polityki kontroli dostępu do punktów egzekwowania polityki będzie możliwe jedynie w sieciach z ograniczonym zestawem urządzeń, takich jak przełączniki Cisco z górnej półki serii 6500. Wsparcie przez Cisco bardziej ogólnej kontroli dostępu, takiej jak izolowanie oparte na wirtualnych LAN, czy nawet uproszczony dostęp do sieci typu "wpuścić/nie wpuścić", zawiera się w większości produktów Cisco dostępnych dzisiaj.

Cisco oferuje drugie podejście do Network Admission Control z urządzeniem Cisco Clean Access, uzyskanym wraz z przejęciem firmy Perfigo w roku 2004. Urządzenie przeznaczone jest dla firm, które potrzebują oceny bezpieczeństwa punktów końcowych, ale nie chcą zmieniać swojej infrastruktury w celu osiągnięcia tego celu. Docelowa integracja pomiędzy serwerem Clean Access, agentem Clean Access i ogólnym schematem NAC jest jednak niepewna, prezentowana dzisiaj głównie na slajdach.

Ekwiwalentem zaplecza Policy Decision Point TCG w wydaniu Cisco jest serwer kontroli dostępu i wiele interfejsów do serwerów polityki bezpieczeństwa, uwierzytelniania i audytu, pochodzących od dostawców niezależnych. Access Control Server, wersji 4.0 lub wyższej, to odpowiednik TCG Network Access Authority połączonego z TNC Server. Integrity Measurements Verifiers nazywają się w architekturze Cisco Policy Server Decisions Points i łączą się z Access Control Server, używając protokołów zdefiniowanych przez Cisco.

Architektura Cisco wychodzi poza schemat NAC TCG z serwerem audytu, przeprowadzającym audyt stanu bezpieczeństwa punktów końcowych, na których nie ma zainstalowanego Cisco Trusted Agent. Kiedy taki "bezagentowy" system próbuje podłączyć się do sieci chronionej przez Network Admission Control, punkt egzekwowania polityki (w terminologii Cisco: network-access device) może wykrywać brak agenta. Wtedy podejmuje decyzję o zastosowaniu serwera audytu w odniesieniu do systemu końcowego - próbuje skanować system z zewnątrz albo podejmuje próbę załadowania oprogramowania agenta do przeglądarki, pozwalając na wykonanie takiego audytu. Chociaż serwer audytu wypełnia pewną lukę architektoniczną, nie jest całkiem jasne, na ile użyteczne są dane, które zbiera, oraz czy będzie to wystarczające do ustawienia reguł polityki dostępu do sieci.

Network Admission Architecture jest jedną z poważniejszych strategii i jest szeroko wspierana po stronie linii produktowych Cisco. Ma jednak pewne niedostatki, takie jak brak integracji reguł polityki, kiedy nie używa się metod 802.1X. Aczkolwiek Cisco zachowało dobry balans pomiędzy tym, co jest w architekturze eleganckie a tym, co realnie pracuje w istniejących sieciach. Pewnym mankamentem architektury Cisco jest też skupienie się na bezpieczeństwie punktów końcowych i relatywnie mała uwaga poświęcana szczegółowej kontroli dostępu i uwierzytelnianiu.

Juniper Networks Infranet

Chociaż możliwe jest odwzorowanie podstawowych komponentów Juniper Infranet na architekturę Trusted Network Connect TCG, to w praktyce Juniper próbuje osiągnąć całkiem inne cele, skupiając się na zaporach ogniowych i kontroli dostępu, z mniejszym zaangażowaniem w kontrolę bezpieczeństwa punktów końcowych.

Junipera różni się od innych dostawców NAC w zakresie kontroli, jaką daje administratorowi sieci podczas budowania infrastruktury. Strategia Junipera zależy zarówno od uwierzytelniania, jak i szczegółowej kontroli dostępu wykorzystującej zapory. Każde połączenie do sieci pod kontrolą NAC Junipera, przechodzące przez zaporę ogniową z filtrowaniem pakietów, może być szyfrowane i jest łączone z polityką kontroli dostępu opartą na tożsamości użytkownika.

Gdy wchodzi się do systemu zabezpieczanego np. przez Microsoft Network Access Protection z DHCP, głównym zmartwieniem jest to, czy użytkownik dysponuje odpowiednim poziomem bezpieczeństwa punktu końcowego. Jeżeli tak, to dostaje nielimitowany dostęp do sieci. W przypadku Juniper Infranet ocena bezpieczeństwa punktu końcowego sieci jest opcjonalna, ale już oparta na tożsamości polityka kontroli dostępu do sieci - obowiązkowa.

Po stronie klienckiej, w charakterze centralnego punktu zarządzania klientem, Juniper używa Enterprise Infranet Agent. Infranet Agent łączy się z Integrity Measurement Collectors dostawców niezależnych poprzez własny JEDI API. Juniper zapewnia także narzędzia oceny bezpieczeństwa punktów końcowych - mechanizm własnego SSL VPN o nazwie Host Checker - do kontroli stanu punktów końcowych, np. otwartych portów czy działających na nich procesów.

Ponieważ architektura Infranet zakłada, że użytkownik jest już podłączony do sieci, Infranet Agent nie bierze udziału w schemacie uwierzytelniania w warstwie 2, takim jak 802.1X. Rolą agenta Infranet jest zapewnienie uwierzytelnienia użytkownika w odpowiedniku Policy Enforcement Point (umieszczonym głębiej w sieci) i dostarczenie informacji dotyczącej oceny bezpieczeństwa punktu końcowego zwrotnie do odpowiednika Policy Decision Point o nazwie Infranet Controllers.

W charakterze Policy Enforcement Points działają: zapora ogniowa Juniper i produkty SSL VPN, o nazwie Infranet Enforces, zazwyczaj zlokalizowane głębiej w sieci.

Infranet Agent zarządza także szyfrowaniem pomiędzy systemem końcowym a Infranet Enforcer. Stosując szyfrowanie IPSec pomiędzy klientem i Infranet Enforcer, Juniper silnie wiąże stację końcową z jej uwierzytelnieniem i stosowanymi regułami polityki. Takie bezpieczeństwo zaczyna się jednak dopiero na Policy Enforcement Point - jakiekolwiek niewłaściwe zachowanie po stronie klienckiej przed osiągnięciem Infranet Enforcer jest w modelu Juniper Infranet niekontrolowane.

Juniper Infranet Controllers, przypominające TCG Policy Decision Points, opierają się ściśle na linii produktowej SSL VPN Juniper (używają tego samego motoru reguł).

Policy Decision Points w wydaniu Junipera, odmiennie niż w innych architekturach NAC, nie mają czystego połączenia z Integrity Measurement Verifiers. Te ostatnie oceniają informacje o bezpieczeństwie punktów końcowych, pochodzące z Juniper Host Checker (odpowiednik Integrity Measurement Collector w schemacie TCG) i przekazują decyzję zwrotną do Infranet Controller.

W sprawie sposobu przekazywania informacji z Integrity Measurement Collectors do Integrity Measurements Verifiers w Policy Decision Point, architektura Infranet odsyła do specyfikacji JEDI. W praktyce jednak specyfikacja JEDI nie wyjaśnia, jak takie połączenie ma pracować. To słaby punkt architektury Infranet, ponieważ zarządzanie desktopami i roaming reguł polityk dla użytkowników musi działać niezależnie od tego, jaka konsola jest używana do kontroli narzędzi ochronnych dostawców niezależnych, a także wewnątrz środowiska Infranet Controller.

Podsumowanie

Wybór architektury NAC zależy od celów, jakie stawia się w strategii integracji. Jeżeli sieć jest wyposażona w nowe urządzenia Cisco, to rozsądnym wyborem może być architektura tej firmy, która jest stosunkowa najbardziej kompletna.

Dla zainteresowanych rozwiązaniem opartym na standardach jedynym realnym wyborem jest TCG TNC, niezależnie od pewnego ryzyka. Podejście Microsoftu bardziej pasuje do mniejszych sieci, gdzie zamierza się kontrolować stacje robocze, bardziej koncentrując się na wirusach niż uwierzytelnianiu i kontroli dostępu.