Subject: [Nea] Problem statement - comments/questions

From: [email-masked]
Date: Wed, 5 Apr 2006 14:40:39 -0400

Hello,
      I have a few questions/comment about the problem statement.  I'm new
to the list so I apologize if these have been addressed previously.  I
understand the problem statement has served its propose for the BOF, but
these comments could be helpful for the upcoming requirements document(s).

[Section 4. Goals]
 "Support endpoint re-assessment when state of endpoints change, or
rules in the NEA server change"

      In the situation of a non NEA client based system, how is the change
of state on the end point known?  Can you include a periodic re-check for
non NEA client based system?

[Section 4. Goals]
"Support endpoints with a NEA client and without a client"

      You may want to  rephrase this to support for all network endpoints?
This would include non 802.1x hosts, non browser based systems (xboxes,
embedded systems),  unless there is a minimum host  requirement for
participating in NEA

[Section 6]
      I think someone already brought this up but shouldn't the IF-PV arrow
in the diagram be pointing vertical?

[Section 6.1 Table 1]
      Would it make sense to map NEA terminology to existing RFC
definitions?

Network Access Authority = Policy Decision Point (RFC 2753 & RFC 3198)
Network Enforcer = Policy Enforcement Point (RFC 2753 & RFC 3198)
NEA Client = Subject (RFC 3198)
....

While there isn't a direct one to one mapping between all elements it would
be nice to reference existing IETF work.  It may also be beneficial to link
to the RFCs in section 2 where NEA terminology is defined.

[Section 6.2.1.1 Client Broker]
"Determining from Posture collectors when posture has changed and
triggering re-assessment where supported by the underlying
transport"

It may be beneficial to allow the NEA server to trigger a re-assessment.

[Section 7 Scope of Standardization]
Posture attributes interface (IF-PA):

Will the format and syntax for the attributes be defined in IF-PA?     Will
all vendors be required to follow this syntax, including vendor proprietary
attributes?

[Section 7 Scope of Standardization]
"The proposed initial scope of the NEA effort is the following:
    IF-PTT
    IF-PTC"

Are you planning on defining the general IF-PT interface in addition to the
specific subprotocols in an EAP instantiation?

Great work, interoperability standards in network access control are
desperately needed.

Best,
Kevin Amorin, CISSP
Sr. Security & Network Engineer
[email-masked]
JFK School of Government
Harvard University

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

---

From: "Carlos Martinez" <[email-masked]>
Date: Thu, 6 Apr 2006 12:55:12 -0300

Sorry about entering the discussion this late:

> embedded systems),  unless there is a minimum host  requirement for

I understand that this means "support endpoints with or withoug NEA
clients". What should be done with these clientless endpoints should
be up to the policies at the site.

And I'm a bit confused about the mention of "non-browser based
systems". I always supposed that it was obvious that NEA should not
make any assumptions outside the fact that the endpoints have some
kind of connectivity and may have a NEA client installed.

I was at IETF 65 and there I thought that everyone was thinking along
this line.

regards

Carlos Martinez

---

From: [email-masked]
Date: Thu, 6 Apr 2006 13:19:06 -0400

>I was at IETF 65 and there I thought that everyone was thinking along

I think this question may have been brought up by Amardeep Sibia and
Tatiana in the BOF.  What should be done with clients that do not speak
EAP?

The NEA group could define an additional IF-PT method.  An example could be
TLS. In that case a person could develop a Java applet that can do IF-PA,
IF-PB and communicate that information over SSL (IF-PT) to the NEA Server.
This would be an attractive option for the non NEA agent based hosts.

Kevin