Subject: [Nea] RE: Text for NEA?

From: "Joseph Tardo" <[email-masked]>
Date: Sat, 8 Apr 2006 13:28:45 -0700

Susan,

I have made an attempt to capture my understanding of the different
approaches in terms of processing "phases" in order to compare them for
commonality and derive interoperability points. This table is intended
to emphasize the concepts, recognizing that it might benefit from an
edit to use more NEA-like terminology (which is probably going to be the
subject of many discussions). It is also based on high level
descriptions from vendors; it would be nice if Cisco, Juniper, or
Microsoft in particular corrected any misconceptions.

Phase

802.1X fixed or wireless (NAC, TNC)

IKE EAP authentication

IPsec NAP Quarantine (?)

SSL (Juniper?, others)

Initiation

Normal EAPOL exchange between supplicant in endpoint and authenticator
in network access device enforcement point

IKE protocol between initiator and VPN gateway, initiator includes an
EAP entity.

Endpoint client local service initiates HTTPS session to verification
server. The client has a method to locate the verification server.

Endpoint agent initiates HTTPS session to verification server. This can
use http redirection at an intermediate point to demand download the
agent.

Measurement

Posture broker collects measurement values, multiplexes into PB frames,
and interfaces with supplicant

Posture broker collects measurement values, multiplexes into PB frames,
and interfaces with initiator EAP entity.

Posture broker collects measurement values, multiplexes into PB frames,
and interfaces with client local service

Posture broker collects measurement values, multiplexes into PB frames,
and interfaces with agent

Reporting

Attributes within EAP used to carry PB frames end-to-end between
supplicant and AAA server

Attributes within EAP used to carry PB frames end-to-end between EAP
entity and AAA server

HTTP content used to carry PB frames between client and server

HTTP content frames carry PB frames between agent and server

Verification

AAA server de-multiplexes PB frames, obtains evaluations for measurement
values

AAA server de-multiplexes PB frames, obtains evaluations for measurement
values

Server de-multiplexes PB frames, obtains evaluations for measurement
values

Server de-multiplexes PB frames, obtains evaluations for measurement
values

Enforcement

AAA server sends status to network access device enforcement point using
AAA protocol attributes. Enforcement point determines access control
policy based on this result. AAA server also returns status to endpoint
in inner EAP attributes

AAA server sends status to VPN gateway using AAA protocol attributes.
VPN gateway determines access control policy based on this result. AAA
server also returns status to endpoint in inner EAP attributes

Server returns status and, if success, X.509 "health certificate".
Endpoint provides certificate to IKE, which uses it to negotiate IPsec
keys directly with application server. Server's local policy requires a
valid health certificate 

Server returns status to the agent and also sends status to an
intermediate policy enforcement point, such as a firewall or secure
router. Enforcement point determines access control policy based on this
result.

These are not exhaustive of all known approaches, by the way, but I
think the others can be similarly phased.

Comparing the phases (and paraphrasing your email):

*         Initiation - completely depends on the approach

*         Measurement - can use common attributes but interfaces depend
on the implementation

*         Reporting - can use common elements carried over different
protocols

*         Verification - can use common attributes but interfaces depend
on the implementation

*         Enforcement - can use common actions, but actual enforcement
depends heavily on the approach

When you look at the common elements across all approaches, you get:

*         PA (which is syntax for instrumentation data)

*         PB (which multiplexes PA into protocol frames with control and
status)

*         Status and actions(which are accept, reject, or quarantine,
maybe with embellishments)

Taking things to the next level, e.g., specific attributes for
RADIUS/Diameter or HTTP content/agent types, has real potential for
interoperability benefit but only for a subset of approaches. To show
some commonality for EAP, for example, other EAP users use would be
helpful. This could be NACP, for example,

Personally I would like to de-mystify the stuff in the PA as the PV
functionality is not rocket science. In particular, I would like to see
minimum policy control requirements at the verification end.

Thanks,

--Joe

-----Original Message-----
From: Susan Thomson (sethomso) [mailto:[email-masked]] 
Sent: Friday, April 07, 2006 12:28 PM
To: Joseph Tardo
Cc: Steve Hanna
Subject: RE: Text for NEA?

Hi Joe

Thanks for this. Looks good. 

I think this would be especially helpful if we can use it to clarify

which NEA protocols are common across architectures and which are

architecture-specific.

Based on my understanding of the phases, the mapping would look as

follows:

Reporting phase:

--- Common across architectures

--- Uses PA and PB protocols

--- Interop Requirements: PA and PB

Initiation, Enforcement phases:

--- Architecture-specific. 

--- In EAP instantiation, initiation is through e.g. 802.1x + EAP

tunneling method, and enforcement e.g. through RADIUS, Diameter. Interop

requirements at minimim include EAP tunneling method.

--- In other instantiations of architecture, interoperability is outside

of initial scope.

Measurement phase:

--- Implementation-specific. No interoperabilty requirements

Does this make sense?

Regarding your examples below, I would rather redo the NAC EAPoUDP

example  as a more generic EAP architecture example based on .1x (since

this is  common across more vendors and is where we will have

standardization and interop first given the initial WG scope). In

addition, it may be useful to have a 3rd example, which is not

EAP-based, but where the enforcement is in the network, e.g. SSL-based

example. 

One more comment inline, prefixed by [Susan].

-----Original Message-----

From: Joseph Tardo [mailto:[email-masked]] 

Sent: Thursday, April 06, 2006 1:57 AM

To: Susan Thomson (sethomso)

Cc: Steve Hanna; Joseph Tardo

Subject: RE: Text for NEA?

Susan,

What I was thinking at IETF was something that might help unify the

various seemingly incompatible approaches out there by providing a

common framework as follows:

0. Initiation phase - a measurement cycle is initiated by some event,

such as network attachment or a request from a measurement entity.

1. Measurement phase - instrumentation in the end system collects

measurement values for evaluation.

2. Reporting phase - measurements are marshaled and then communicated to

to a verification entity, which evaluates them for policy conformance

3. Enforcement phase - depending on the evaluation, an enforcement

action is taken at an enforcement point. This can vary depending on the

architecture.

Examples:

---------

                  NAC EApoUDP             Microsoft IPsec

Quarantine

Initiation     Router detects packet,     Client starts,

quarantine agent

                  Connects to agent       contacts

quarantine server

[Susan] In the EAP instantiation, the initiation phase would includes

the EAP tunnel establishment, correct? In other words,  "agent connects

to server" would also be part of the EAP column?

Thanks

Susan

Measurement       Agent reads posture     quarantine agent reads

health

                        Values                  values

Reporting         Agent sends posture     agent sends values to

server

                   values to verifier     server returns result

and

                   and gets back result   X.509 cert

Enforcement       Router ACLs set to     IPsec client users cert

to

                   block or allow         establish IKE tunnel,

enforcement

                                          point at server

tunnel endpoint

Similar tables can be done for TNC/dot1x and Juniper Infranet.

This is nice modeling but doesn't do much to promote interoperability.

Hope this helps, if so I'll put it into a contribution of some sort.

Thanks,

--Joe

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea