Subject: [Nea] Newcomer comments on draft-ietf-nea-requirements-04

From: <[email-masked]>
Date: Mon, 10 Sep 2007 13:10:38 -0700

Hello NEA WG,

Several of us at SonicWALL have recently been following the NEA WG in
general and specifically draft-ietf-nea-requirements-03 and 
draft-ietf-nea-requirements-04.  I have the following comments
pertaining to draft-ietf-nea-requirements-04.

Page 32 Section 7.1, Requirement C-9
At a minimum, C-9 should explicitly require UTF-8 encodings be supported
in strings in order to adhere to the guidance specified in RFC 2277.   
Is there any reason to support character sets other than UTF-8?
Supporting only UTF-8 makes the protocol straightforward on interpreting
string 
encodings and normalization to locale specific character sets is
generally easy to implement on most OS platforms using their intrinsic
libraries.

Page 33, Section 7.2, Requirement PA-1
The NEA model seems to imply an extensible standard attribute name
space, but PA-1 does not incorporate this as a requirement. Nor
does PA-1 specify a requirement for the standard attribute name space
schema to be uniquely identifiable from vendor attribute name 
spaces. 

Page 33, Section 7.2, Requirement PA-2
The NEA model implies a plurality of extensible vendor attribute name
spaces and concurrent instances of each schema, but 
PA-2 does not  incorporate this as a requirement.  Nor does PA-2 specify
a requirement for vendor attribute name space schemas to 
be uniquely identifiable.

Page 33, Section 7.2, Requirement PA-4
The network owner security policy may restrict giving the user complete
visibility into why an assessment failed in order to prevent 
exposing unnecessary information to potential attackers, especially
prior to user authentication.  With this in mind, please consider 
changing "This enables" to "This optionally enables the Posture Client,
subject to disclosure policy of the NEA Server, ".

Page 33, Section 7.12 Requirement PA-5
I am little confused over the recent comments debating downgrading
[MUST] to [SHOULD] or [MAY].  The decision to utilize end-to-end 
cryptography is use case topology dependent.  If these use cases are
deemed to be in scope, then doesn't it make sense for this to be a 
[MUST] requirement and amend the verbiage to read "... MUST be
optionally capable of providing ..."?

Page 34 Section 7.2
I noticed the former PA-8 requirement in draft-ietf-nea-requirements-03
was dropped; apparently in favor of the more generalized new C-9 
requirement in draft-ietf-nea-requirements-04.  I believe there still
exists a need for a PA specific I18N string encoding requirement for
non-
displayable request and response attributes. Request attributes for end
point artifacts such as File, Directory, Process Name, etc are used in 
common practice today in NEA equivalent deployments I am aware of.
Again, as mentioned in the comment regarding the C-9 requirement, 
UTF-8 makes things unambiguous and at a minimum must be a supported
encoding.

Page 34, Section 7.3 Requirement PB-3
Is there any reason in PB-3 not to specify identifiers be based upon SMI
enterprise numbers?  This requirement looks much like that 
already faced by SNMP and LDAP; and we already have the IANA machinery
to leverage here.

Page 35, Section 7.4 Requirement PT-2
In addition to mutual authentication specified in PT-2, the PT protocol
must also be capable of supporting server side only authentication 
as an alternative to mutual authentication.  Server side only
authentication is common practice today in SSL VPNs. With this in mind,
please 
consider changing "mutual authentication" to "mutual and server side
only authentication schemes".

Page 44, Section 9.1 Paragraph 2
In order to prevent privacy abuse by network owners, PA request
attributes must be restricted to information  known apriori  rather 
than be open ended in order to prevent dredging for artifact
information. For example a PV looking for a domain named 
"mydomain.com" should be allowed, whereas requesting a domain named "*"
should be disallowed by the PC.

Page 46, Section 9.2  Paragraph 2
I don't think Model 1 is practical or even possible in some cases.  This
model works only when both the PC and PV have an immutable 
set of attributes known apriori by each.  However, it is common practice
in existing SSL VPN s to request information on the existence of files, 
directories, processes and other artifacts that are configurable
assessment policy on the NEA Server. In order for model 1 to potentially
work, 
the NEA client would have to send enormous amounts of information;
potentially an enumeration of its entire file name space, process name
space, 
registry name space, etc. 

Page 46, Section 9.2 Paragraph 4
Model 3 is used in common practice today by many of the NEA like
deployments.  At a minimum, it must be supported .  I can also see model
2 
being used effectively by a subset of PC/PV providers.  It occurs to me,
the decision to use either model 2 or model 3 is one the PC/PV provider 
makes and that the NEA protocols could consider supporting both models
if necessary; but Model 3 appears to be a superset of Model 2 and as 
such so it might make sense to simply the protocol and only support
model 3. My preference is to always make things simpler if possible.

Gary Tomlinson

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

---

From: <[email-masked]>
Date: Mon, 10 Sep 2007 13:14:27 -0700

I have a few additional comments, following Gary's, that also pertain to
draft-ietf-nea-requirements-04.

Page 35 Section 7.4

Please consider adding a new requirement for the PT protocol to support
non-persistent network connections. This is especially important for
mobile devices that roam or have air time charges.  This has an impact
on reassessments triggered by the NEA server; in some cases (e.g. NAT
traversal), the only option may be for the NEA client to periodically
contact the NEA server to determine whether a reassessment is necessary.

Page 44 Section 9.1 Paragraph 3

As Gary stated, due to security policy, network owners may wish not to
disclose the attributes being requested. Imagine an attacker who
restricts all posture collection in order to determine what the network
operators are looking for.

Page 45 Section 9.1 Paragraph 6

This is a continuation of the thought in the comment above and concerns
this item in the NEA disclosure statement: "What information is
required". Such disclosure must be subject to  the security policy of
the network owner. What is the intent of specificity in this guidance?
Does the network owner have the latitude of providing a more general
disclosure statement?

Parvez Anandam

_____________________________________________
From: Gary Tomlinson 
Sent: Monday, September 10, 2007 1:11 PM
To: [email-masked]
Subject: Newcomer comments on draft-ietf-nea-requirements-04

Hello NEA WG,

Page 34 Section 7.2

Gary Tomlinson

---

From: "todd glassey" <[email-masked]>
Date: Mon, 10 Sep 2007 14:52:31 -0700

RE: Newcomer comments on draft-ietf-nea-requirements-04Parvez - in spirit I understand what you are trying to do but I disagree and will enumerate why below...

---- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] 
  Sent: Monday, September 10, 2007 1:14 PM
  Subject: [Nea] RE: Newcomer comments on draft-ietf-nea-requirements-04

  I have a few additional comments, following Gary's, that also pertain to draft-ietf-nea-requirements-04.

  Page 35 Section 7.4

  Please consider adding a new requirement for the PT protocol to support non-persistent network connections. 

This will not be a viable thing to do in the real world no matter how nice it sounds I fear...

  This is especially important for mobile devices that roam or have air time charges.  This has an impact on reassessments triggered by the NEA server; in some cases (e.g. NAT traversal), the only option may be for the NEA client to periodically contact the NEA server to determine whether a reassessment is necessary.

I disagree...  Supporting Mobile Device (Nomadic Computing) and its Integrity for "devices that are based on non-persistant connections" may not be such a good idea since it will dramatically increase the overhead in any NEA system at a minimum and also will create a HUGE level of pain for people running mixed networks... For instance it would be rather easy to program a PDA to slam a NEA server with continuous requests for service after service.

To deal with these types of devices,  the NEA system will also have to maintain state tables for all of its local "recent" connections since under any reasonable policy requiring continuous certification of competence or NEA policy compliance means repeating the same set of messages again and again... 

  As Gary stated, due to security policy, network owners may wish not to disclose the attributes being requested. 

Then why are they allowing people to plug into their networks at all without disclosing those policies...

  Imagine an attacker who restricts all posture collection in order to determine what the network operators are looking for.

But how would that system work in a NEA environment... it would be getting routing access to the switches right? So what is it that system would be doing?

Remember the key purpose of NEA is to BOTH allow one to force compliance with pre-existing NETWORK POLICIES in a new or recently powered-up system AND the continuously recertifying those systems which passed previously if they still continue to pass their tests. 

To do that there needs to be some way of communicating what those requirements are to the client in an interactive mode. 

  This is a continuation of the thought in the comment above and concerns this item in the NEA disclosure statement: "What information is required". Such disclosure must be subject to  the security policy of the network owner. What is the intent of specificity in this guidance?  Does the network owner have the latitude of providing a more general disclosure statement?

  Parvez Anandam

  Hello NEA WG,

  Several of us at SonicWALL have recently been following the NEA WG in general and specifically draft-ietf-nea-requirements-03 and 

  draft-ietf-nea-requirements-04.  I have the following comments pertaining to draft-ietf-nea-requirements-04.

  At a minimum, C-9 should explicitly require UTF-8 encodings be supported in strings in order to adhere to the guidance specified in RFC 2277.   

  Is there any reason to support character sets other than UTF-8?  Supporting only UTF-8 makes the protocol straightforward on interpreting string 

  encodings and normalization to locale specific character sets is generally easy to implement on most OS platforms using their intrinsic libraries.

  The NEA model seems to imply an extensible standard attribute name space, but PA-1 does not incorporate this as a requirement. Nor

  does PA-1 specify a requirement for the standard attribute name space schema to be uniquely identifiable from vendor attribute name 

  spaces. 

  The NEA model implies a plurality of extensible vendor attribute name spaces and concurrent instances of each schema, but 

  PA-2 does not  incorporate this as a requirement.  Nor does PA-2 specify a requirement for vendor attribute name space schemas to 

  The network owner security policy may restrict giving the user complete visibility into why an assessment failed in order to prevent 

  exposing unnecessary information to potential attackers, especially prior to user authentication.  With this in mind, please consider 

  changing "This enables" to "This optionally enables the Posture Client, subject to disclosure policy of the NEA Server, ".

  I am little confused over the recent comments debating downgrading [MUST] to [SHOULD] or [MAY].  The decision to utilize end-to-end 

  cryptography is use case topology dependent.  If these use cases are deemed to be in scope, then doesn't it make sense for this to be a 

  [MUST] requirement and amend the verbiage to read ". MUST be optionally capable of providing ."?

  Page 34 Section 7.2

  I noticed the former PA-8 requirement in draft-ietf-nea-requirements-03 was dropped; apparently in favor of the more generalized new C-9 

  requirement in draft-ietf-nea-requirements-04.  I believe there still exists a need for a PA specific I18N string encoding requirement for non-

  displayable request and response attributes. Request attributes for end point artifacts such as File, Directory, Process Name, etc are used in 

  common practice today in NEA equivalent deployments I am aware of.  Again, as mentioned in the comment regarding the C-9 requirement, 

  UTF-8 makes things unambiguous and at a minimum must be a supported encoding.

  Is there any reason in PB-3 not to specify identifiers be based upon SMI enterprise numbers?  This requirement looks much like that 

  already faced by SNMP and LDAP; and we already have the IANA machinery to leverage here.

  In addition to mutual authentication specified in PT-2, the PT protocol must also be capable of supporting server side only authentication 

  as an alternative to mutual authentication.  Server side only authentication is common practice today in SSL VPNs. With this in mind, please 

  consider changing "mutual authentication" to "mutual and server side only authentication schemes".

  In order to prevent privacy abuse by network owners, PA request attributes must be restricted to information  known apriori  rather 

  than be open ended in order to prevent dredging for artifact information. For example a PV looking for a domain named 

  "mydomain.com" should be allowed, whereas requesting a domain named "*" should be disallowed by the PC.

  I don't think Model 1 is practical or even possible in some cases.  This model works only when both the PC and PV have an immutable 

  set of attributes known apriori by each.  However, it is common practice in existing SSL VPN s to request information on the existence of files, 

  directories, processes and other artifacts that are configurable assessment policy on the NEA Server. In order for model 1 to potentially work, 

  the NEA client would have to send enormous amounts of information; potentially an enumeration of its entire file name space, process name space, 

  Model 3 is used in common practice today by many of the NEA like deployments.  At a minimum, it must be supported .  I can also see model 2 

  being used effectively by a subset of PC/PV providers.  It occurs to me, the decision to use either model 2 or model 3 is one the PC/PV provider 

  makes and that the NEA protocols could consider supporting both models if necessary; but Model 3 appears to be a superset of Model 2 and as 

  such so it might make sense to simply the protocol and only support model 3. My preference is to always make things simpler if possible.

  Gary Tomlinson

------------------------------------------------------------------------------

---

From: "todd glassey" <[email-masked]>
Date: Mon, 10 Sep 2007 15:08:19 -0700

Newcomer comments on draft-ietf-nea-requirements-04Gary
  ----- Original Message ----- 
  From: [email-masked] 
  To: [email-masked] 
  Sent: Monday, September 10, 2007 1:10 PM
  Subject: [Nea] Newcomer comments on draft-ietf-nea-requirements-04

  Hello NEA WG, 

You mean its its important to keep the compliance with ISO UCS...  I agree - the minimum standard is UCS.

  Page 33, Section 7.2, Requirement PA-1 
  The NEA model seems to imply an extensible standard attribute name space, but PA-1 does not incorporate this as a requirement. Nor does PA-1 specify a requirement for the standard attribute name space schema to be uniquely identifiable from vendor attribute name spaces. 

This is specific to a use model - so document that use model  and its requirement inside of PA-1.

  Page 33, Section 7.2, Requirement PA-2 
  The NEA model implies a plurality of extensible vendor attribute name spaces and concurrent instances of each schema, but PA-2 does not  incorporate this as a requirement.  Nor does PA-2 specify a requirement for vendor attribute name space schemas to be uniquely identifiable. 

Again - a complete set of use models would eliminate this.

  Page 33, Section 7.2, Requirement PA-4 
  The network owner security policy may restrict giving the user complete visibility into why an assessment failed in order to prevent exposing unnecessary information to potential attackers, especially prior to user authentication.  

Here then is a specific use in which the system provides hierarchical error or failure messages with varying detail?

  With this in mind, please consider changing "This enables" to "This optionally enables the Posture Client, subject to disclosure policy of the NEA Server, ".

  Page 33, Section 7.12 Requirement PA-5 
  I am little confused over the recent comments debating downgrading [MUST] to [SHOULD] or [MAY].  The decision to utilize end-to-end cryptography is use case topology dependent.  If these use cases are deemed to be in scope, then doesn't it make sense for this to be a [MUST] requirement and amend the verbiage to read ". MUST be optionally capable of providing ."? 

Again this is use-model specific.

  Page 34 Section 7.2 
  I noticed the former PA-8 requirement in draft-ietf-nea-requirements-03 was dropped; apparently in favor of the more generalized new C-9 requirement in draft-ietf-nea-requirements-04.  I believe there still exists a need for a PA specific I18N string encoding requirement for non-displayable request and response attributes. Request attributes for end point artifacts such as File, Directory, Process Name, etc are used in common practice today in NEA equivalent deployments I am aware of.  Again, as mentioned in the comment regarding the C-9 requirement, UTF-8 makes things unambiguous and at a minimum must be a supported encoding. 

  Page 34, Section 7.3 Requirement PB-3 
  Is there any reason in PB-3 not to specify identifiers be based upon SMI enterprise numbers?  This requirement looks much like that already faced by SNMP and LDAP; and we already have the IANA machinery to leverage here. 

  Page 35, Section 7.4 Requirement PT-2 
  In addition to mutual authentication specified in PT-2, the PT protocol must also be capable of supporting server side only authentication as an alternative to mutual authentication.  Server side only authentication is common practice today in SSL VPNs. With this in mind, please consider changing "mutual authentication" to "mutual and server side only authentication schemes". 

I suggest the following change: 

Page 35, Section 7.4 Requirement PT-2 
"Authentictation schemes specific to the end-use models", so that the type of authentication - whether Server-Side, mutual, or circuit-level only can be done.

  Page 44, Section 9.1 Paragraph 2 
  In order to prevent privacy abuse by network owners, PA request attributes must be restricted to information  known apriori  rather than be open ended in order to prevent dredging for artifact information. For example a PV looking for a domain named "mydomain.com" should be allowed, whereas requesting a domain named "*" should be disallowed by the PC. 

Why? - What you suggest here means that each and ever domain MUST be individually enumerated rather than being able to say "Any Supported or Defined Domain"... I can see many instances - especially those inside of University's and the like which may have hundreds of domains, all which are operated under the University's Security Persona...

  Page 46, Section 9.2  Paragraph 2 
  I don't think Model 1 is practical or even possible in some cases.  This model works only when both the PC and PV have an immutable set of attributes known apriori by each.  However, it is common practice in existing SSL VPN s to request information on the existence of files, directories, processes and other artifacts that are configurable assessment policy on the NEA Server. In order for model 1 to potentially work, the NEA client would have to send enormous amounts of information; potentially an enumeration of its entire file name space, process name space, registry name space, etc. 

yes it would - but what is the value of the assurance it was to provide if the Client side didnt present these qualification datapoints?

  Page 46, Section 9.2 Paragraph 4 
  Model 3 is used in common practice today by many of the NEA like deployments.  At a minimum, it must be supported .  I can also see model 2 being used effectively by a subset of PC/PV providers.  It occurs to me, the decision to use either model 2 or model 3 is one the PC/PV provider makes and that the NEA protocols could consider supporting both models if necessary; but Model 3 appears to be a superset of Model 2 and as such so it might make sense to simply the protocol and only support model 3. My preference is to always make things simpler if possible.

I agree.

  Gary Tomlinson

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 10 Sep 2007 16:31:08 -0700

Hi Gary,

Thanks for your comments. Please find my response inline.

On 9/10/07 1:10 PM, "[email-masked]" <[email-masked]>
wrote:

> Hello NEA WG, 
> 
> Several of us at SonicWALL have recently been following the NEA WG in general
> and specifically draft-ietf-nea-requirements-03 and
> 
> At a minimum, C-9 should explicitly require UTF-8 encodings be supported in
> strings in order to adhere to the guidance specified in RFC 2277.
> 
> Is there any reason to support character sets other than UTF-8?  Supporting
> only UTF-8 makes the protocol straightforward on interpreting string
> 
> encodings and normalization to locale specific character sets is generally
> easy to implement on most OS platforms using their intrinsic libraries.
> 
> 
> <Kaushik> 
> 
> C-9 currently tries to capture i18n requirements for attributes that are both
> ³text² and ³non-text²at the PA and PB layer. We did not want to get into
> specific encoding standards
> and that¹s the reason for a very generically worded requirement
> 
> </Kaushik> 
> 
> 
> 
> The NEA model seems to imply an extensible standard attribute name space, but
> PA-1 does not incorporate this as a requirement. Nor
> 
> does PA-1 specify a requirement for the standard attribute name space schema
> to be uniquely identifiable from vendor attribute name
> 
> spaces. 
> 
> 
> The NEA model implies a plurality of extensible vendor attribute name spaces
> and concurrent instances of each schema, but
> 
> PA-2 does not  incorporate this as a requirement.  Nor does PA-2 specify a
> requirement for vendor attribute name space schemas to
> 
> <Kaushik>
> You are right. The notion of a standard and vendor specific namespaces is
> implicit in the requirements. We will edit the requirements to make the  need
> for separate attribute namespaces more explicit.
> 
> </Kaushik>
> 
> 
> 
> exposing unnecessary information to potential attackers, especially prior to
> user authentication.  With this in mind, please consider
> 
> subject to disclosure policy of the NEA Server, ².
> 
> 
> <Kaushik> Agreed. </Kaushik>
> 
> 
> I am little confused over the recent comments debating downgrading [MUST] to
> [SHOULD] or [MAY].  The decision to utilize end-to-end
> 
> cryptography is use case topology dependent.  If these use cases are deemed to
> be in scope, then doesn't it make sense for this to be a
> 
> [MUST] requirement and amend the verbiage to read "Š MUST be optionally
> capable of providing Š"?
> 
> 
> 
> 
> Page 34 Section 7.2
> I noticed the former PA-8 requirement in draft-ietf-nea-requirements-03 was
> dropped; apparently in favor of the more generalized new C-9
> 
> requirement in draft-ietf-nea-requirements-04.  I believe there still exists a
> need for a PA specific I18N string encoding requirement for non-
> 
> displayable request and response attributes. Request attributes for end point
> artifacts such as File, Directory, Process Name, etc are used in
> 
> common practice today in NEA equivalent deployments I am aware of.  Again, as
> mentioned in the comment regarding the C-9 requirement,
> 
> <Kaushik> C-9 should capture this since there could be non-displayable
> attributes at the PB layer as well. </Kaushik>
> 
> 
> 
> 
> <Kaushik> 
> Are you referring to the use of SMI for  static identifiers for collectors &
> validators ? I think it might be a useful suggestion
> for a potential solution, not sure if need to talk about this in the
> requirements. 
> 
> </Kaushik>
> 
> 
> 
> 
> 
> In addition to mutual authentication specified in PT-2, the PT protocol must
> also be capable of supporting server side only authentication
> 
> as an alternative to mutual authentication.  Server side only authentication
> is common practice today in SSL VPNs. With this in mind, please
> 
> consider changing ³mutual authentication² to ³mutual and server side only
> authentication schemes².
> 
> 
> <Kaushik>
> 
> 
> The requirement is a MUST for mutual authentication between NEA clients & NEA
> servers. The mutual authentication could be achieved as a result
> of two independent authentication transactions (with binding for certain PTs),
> for e.g. For password based credentials, the NEA server will be authenticated
> while a secure channel is being established (such as TLS) and NEA client will
> be subsequently authenticated within that secure channel.
> 
> 
> </Kaushik> 
> 
> 
> 
> 
> 
> 
> In order to prevent privacy abuse by network owners, PA request attributes
> must be restricted to information  known apriori  rather
> 
> ³mydomain.com² should be allowed, whereas requesting a domain named ³*² should
> be disallowed by the PC.
> 
> <Kaushik>
> 
> I guess you are stating a more pointed use of the mechanism stated in
> paragraph 2. It might be a useful to include in that section.
> 
> </Kaushik> 
> 
> 
> 
> I don't think Model 1 is practical or even possible in some cases.  This model
> works only when both the PC and PV have an immutable
> 
> set of attributes known apriori by each.  However, it is common practice in
> existing SSL VPN s to request information on the existence of files,
> 
> directories, processes and other artifacts that are configurable assessment
> policy on the NEA Server. In order for model 1 to potentially work,
> 
> the NEA client would have to send enormous amounts of information; potentially
> an enumeration of its entire file name space, process name space,
> 
> <Kaushik>
> That¹s a fair point but Model 1 might be a useful model to assess endpoints
> that are not owned by the Enterprise, for e.g.  A contractor/guest system
> that is configured to provide a pre-set profile of attributes when challenged
> by a guest/partner network.
> 
> </Kaushik>
>  
> 
> 
> Model 3 is used in common practice today by many of the NEA like deployments.
> At a minimum, it must be supported .  I can also see model 2
> 
> being used effectively by a subset of PC/PV providers.  It occurs to me, the
> decision to use either model 2 or model 3 is one the PC/PV provider
> 
> makes and that the NEA protocols could consider supporting both models if
> necessary; but Model 3 appears to be a superset of Model 2 and as
> 
> such so it might make sense to simply the protocol and only support model 3.
> My preference is to always make things simpler if possible.
> 
> 
> 
> <Kaushik> 
> 
> Just want to point out that all the models described in section 9 are
> implementation considerations and not requirements for NEA protocol
> specification. The models explain how NEA implementations can address privacy
> concerns and it is upto to implementations to support one or more of these
> models.
> 
> regards,
>   kaushik!
> 
> </Kaushik>
> 
> 
> 
> 
> Gary Tomlinson 
> 
> 
>

---

From: <[email-masked]>
Date: Mon, 10 Sep 2007 16:39:33 -0700

Todd,

Thanks for the reply.

[PA] Comments below...

From: todd glassey [mailto:[email-masked]] 
Sent: Monday, September 10, 2007 2:53 PM
To: Parvez Anandam; [email-masked]
Subject: Re: [Nea] RE: Newcomer comments on
draft-ietf-nea-requirements-04

Parvez - in spirit I understand what you are trying to do but I disagree
and will enumerate why below...

---- Original Message ----- 

	To: [email-masked] 

	Subject: [Nea] RE: Newcomer comments on
draft-ietf-nea-requirements-04

	I have a few additional comments, following Gary's, that also
pertain to draft-ietf-nea-requirements-04.

	Page 35 Section 7.4

	Please consider adding a new requirement for the PT protocol to
support non-persistent network connections. 

This will not be a viable thing to do in the real world no matter how
nice it sounds I fear...

[PA] We have empirical evidence that this is possible in the real world,
with our End Point Control solution. A classic example is a smartphone
on a cellular data network, using an SSL VPN.

	This is especially important for mobile devices that roam or
have air time charges.  This has an impact on reassessments triggered by
the NEA server; in some cases (e.g. NAT traversal), the only option may
be for the NEA client to periodically contact the NEA server to
determine whether a reassessment is necessary.

I disagree...  Supporting Mobile Device (Nomadic Computing) and its
Integrity for "devices that are based on non-persistant connections" may
not be such a good idea since it will dramatically increase the overhead
in any NEA system at a minimum and also will create a HUGE level of pain
for people running mixed networks... For instance it would be rather
easy to program a PDA to slam a NEA server with continuous requests for
service after service.

To deal with these types of devices,  the NEA system will also have to
maintain state tables for all of its local "recent" connections since
under any reasonable policy requiring continuous certification of
competence or NEA policy compliance means repeating the same set of
messages again and again... 

[PA] Is the scope of NEA restricted to non-mobile devices, then? I hope
not. Maintaining state is common practice, for VPNs . I'm not sure there
is an alternative, if one is to support devices such as smartphones.
Such devices are increasingly being used to run SSL VPN clients; they
are part of a WAN,  not a LAN. The denial of service considerations are
important, I agree.

	As Gary stated, due to security policy, network owners may wish
not to disclose the attributes being requested. 

Then why are they allowing people to plug into their networks at all
without disclosing those policies...

[PA] The users may be connecting to a corporate network from home, for
example. The attributes the network owners are looking for will, of
course, be disclosed to the Posture Collectors, but that does not mean
that a (human) user should necessarily be aware of what is being
collected. This prevents a user from configuring an unauthorized laptop
to simulate an authorized one (see below). Of course, the privacy issues
increase in scope significantly once the user is out of the loop; thus
Gary's comment about preventing open-ended dredging of attributes.

	Imagine an attacker who restricts all posture collection in
order to determine what the network operators are looking for.

But how would that system work in a NEA environment... it would be
getting routing access to the switches right? So what is it that system
would be doing?

Remember the key purpose of NEA is to BOTH allow one to force compliance
with pre-existing NETWORK POLICIES in a new or recently powered-up
system AND the continuously recertifying those systems which passed
previously if they still continue to pass their tests. 

[PA] The attack I envision goes something like this. The attacker plugs
in her laptop into a conference room jack at a competitor's. She obtains
an IP address from the central VPN gateway that everyone in the building
uses, but this does not allow her to go beyond the VPN gateway. Her
laptop is requested to perform NEA checks. As the NEA requirements are
currently written, she will be informed of all the attributes that are
being requested, say the presence of anti-virus program XYZ and the
presence of a specific Windows registry key. Knowing this critical
information, she runs program XYZ from her large attack arsenal and adds
the registry entry. Her laptop now conforms to the NEA security policies
of the VPN gateway and is indistinguishable from a corporate laptop.

To do that there needs to be some way of communicating what those
requirements are to the client in an interactive mode. 

[PA] Certainly, there needs to be some secure way of communicating those
requirements from the Posture Validators to the Posture Collectors; the
PA, PB and PT protocols take care of that. The end-user need not know
the contents of that communication, however, for the reason I described
above.

[PA] Thanks,

[PA] Parvez Anandam

	This is a continuation of the thought in the comment above and
concerns this item in the NEA disclosure statement: "What information is
required". Such disclosure must be subject to  the security policy of
the network owner. What is the intent of specificity in this guidance?
Does the network owner have the latitude of providing a more general
disclosure statement?

	Parvez Anandam

	Hello NEA WG,

	Several of us at SonicWALL have recently been following the NEA
WG in general and specifically draft-ietf-nea-requirements-03 and 

	At a minimum, C-9 should explicitly require UTF-8 encodings be
supported in strings in order to adhere to the guidance specified in RFC
2277.   

	The NEA model seems to imply an extensible standard attribute
name space, but PA-1 does not incorporate this as a requirement. Nor

	does PA-1 specify a requirement for the standard attribute name
space schema to be uniquely identifiable from vendor attribute name 

	spaces. 

	The NEA model implies a plurality of extensible vendor attribute
name spaces and concurrent instances of each schema, but 

	PA-2 does not  incorporate this as a requirement.  Nor does PA-2
specify a requirement for vendor attribute name space schemas to 

	The network owner security policy may restrict giving the user
complete visibility into why an assessment failed in order to prevent 

	exposing unnecessary information to potential attackers,
especially prior to user authentication.  With this in mind, please
consider 

	changing "This enables" to "This optionally enables the Posture
Client, subject to disclosure policy of the NEA Server, ".

	I am little confused over the recent comments debating
downgrading [MUST] to [SHOULD] or [MAY].  The decision to utilize
end-to-end 

	cryptography is use case topology dependent.  If these use cases
are deemed to be in scope, then doesn't it make sense for this to be a 

	Page 34 Section 7.2

	I noticed the former PA-8 requirement in
draft-ietf-nea-requirements-03 was dropped; apparently in favor of the
more generalized new C-9 

	requirement in draft-ietf-nea-requirements-04.  I believe there
still exists a need for a PA specific I18N string encoding requirement
for non-

	displayable request and response attributes. Request attributes
for end point artifacts such as File, Directory, Process Name, etc are
used in 

	common practice today in NEA equivalent deployments I am aware
of.  Again, as mentioned in the comment regarding the C-9 requirement, 

	UTF-8 makes things unambiguous and at a minimum must be a
supported encoding.

	Is there any reason in PB-3 not to specify identifiers be based
upon SMI enterprise numbers?  This requirement looks much like that 

	already faced by SNMP and LDAP; and we already have the IANA
machinery to leverage here.

	In addition to mutual authentication specified in PT-2, the PT
protocol must also be capable of supporting server side only
authentication 

	consider changing "mutual authentication" to "mutual and server
side only authentication schemes".

	"mydomain.com" should be allowed, whereas requesting a domain
named "*" should be disallowed by the PC.

	I don't think Model 1 is practical or even possible in some
cases.  This model works only when both the PC and PV have an immutable 

	set of attributes known apriori by each.  However, it is common
practice in existing SSL VPN s to request information on the existence
of files, 

	the NEA client would have to send enormous amounts of
information; potentially an enumeration of its entire file name space,
process name space, 

	being used effectively by a subset of PC/PV providers.  It
occurs to me, the decision to use either model 2 or model 3 is one the
PC/PV provider 

	makes and that the NEA protocols could consider supporting both
models if necessary; but Model 3 appears to be a superset of Model 2 and
as 

	such so it might make sense to simply the protocol and only
support model 3. My preference is to always make things simpler if
possible.

	Gary Tomlinson

________________________________

---

From: Kaushik Narayan <[email-masked]>
Date: Mon, 10 Sep 2007 18:26:39 -0700

Hi Parvez,

Please find my reply inline.

> <snipped>
> 
> I have a few additional comments, following Gary¹s, that also pertain to
> non-persistent network connections. This is especially important for mobile
> devices that roam or have air time charges.  This has an impact on
> reassessments triggered by the NEA server; in some cases (e.g. NAT traversal),
> the only option may be for the NEA client to periodically contact the NEA
> server to determine whether a reassessment is necessary.
> 
> 
> 
> <Kaushik> 
> 
> I am not sure about what you mean by ³persistent network connection², i.e.
> What does that mean for a PT that runs over a network access protocol such as
> 802.1x or IKEv2. In any case the requirements to support client & server
> triggered assessment/re-assessment is a SHOULD and not a MUST.
> 
> 
> regards,
>   kaushik
> 
> 
> </Kaushik>
> 
> 
> disclose the attributes being requested. Imagine an attacker who restricts all
> posture collection in order to determine what the network operators are
> looking for.
> 
> This is a continuation of the thought in the comment above and concerns this
> item in the NEA disclosure statement: ³What information is required². Such
> disclosure must be subject to  the security policy of the network owner. What
> is the intent of specificity in this guidance?  Does the network owner have
> the latitude of providing a more general disclosure statement?
> 
> Parvez Anandam
>

---

From: <[email-masked]>
Date: Tue, 11 Sep 2007 11:56:50 -0700

Hello Todd,

Thanks for you comments. My comments are inline with the appropriate
Snippet. 

>> -----Original Message-----
>> Sent: Monday, September 10, 2007 3:08 PM
>> To: Gary Tomlinson; [email-masked]
>> Subject: Re: [Nea] Newcomer comments on 
>> Gary

[omitted]

>> 	At a minimum, C-9 should explicitly require UTF-8 
>> encodings be supported in strings in order to adhere to the 
>> guidance specified in RFC 2277.   
>> 
> You mean its its important to keep the compliance with ISO 
> UCS...  I agree - the minimum standard is UCS.
 
Actually, I literally meant UTF-8 for the following reasons; a) it is
the encoding
specified in RFC 2277; b) it represents the ISO Universal Character Set
(UCS);
and c) is an encoding standard in addition to a character set.

[omitted]

>> 	The NEA model seems to imply an extensible standard 
>> attribute name space, but PA-1 does not incorporate this as a 
>> requirement. Nor does PA-1 specify a requirement for the 
>> standard attribute name space schema to be uniquely 
>> identifiable from vendor attribute name spaces. 
>> 

The use case I had in mind is one in which there are multiple PC's
and PV's involved in the assessment of an endpoint. I assumed this 
was implied in the model as required in section 7.3. The 
reasoning behind the need for a name space identifier is 
to distinguish the standard attributes from the vendor attributes;
although
it may be the case the WG is relying on PB-3 to implicitly serve this 
purpose.  If so, that should be stated in PA-1. The reasoning behind an 
extensible name space schema is two fold; one the schema needs to be
public for 
any PV/PC combo to interoperate, and two extensibility allows the
protocol
to adapt over time.

> 	The NEA model implies a plurality of extensible vendor 
> attribute name spaces and concurrent instances of each 
> schema, but PA-2 does not  incorporate this as a requirement. 
>  Nor does PA-2 specify a requirement for vendor attribute 
> name space schemas to be uniquely identifiable. 
> 

I'm not sure I can describe a complete set of use cases; although again
I assumed
the same use case as in PA-1 and thus the need to distinguish the vendor
specific 
attributes from each other and from the standard attributes as well.
Again, if the WG 
assumed PB-3 will provide this distinction this should be stated in
PA-2.  As to the
extensible vendor attribute name space I was thinking SNMP MIB OID model
in order to 
enable the possibility of interoperability between PV/PC implementations
from different 
vendors.  However, if this capability is out of scope and the WG expects
the standard 
attribute set to serve this purpose, I'll retract this part of my PA-2
comment.

>> 	The network owner security policy may restrict giving 
>> the user complete visibility into why an assessment failed in 
>> order to prevent exposing unnecessary information to 
>> potential attackers, especially prior to user authentication.  
>> 
> Here then is a specific use in which the system provides 
> hierarchical error or failure messages with varying detail?

Yes, although I think the reasons are outside the scope of the 
protocol itself.  I'm not sure how to phrase the guidance here 
regarding how to provide useful information to the user as it is 
at the discretion of the network operator's policy.  It seems fine to
me to have errors or failures which can be cryptic to users in policies 
which don't want to provide such information to untrusted parties.

> 
>> 	With this in mind, please consider changing "This 
>> enables" to "This optionally enables the Posture Client, 
>> downgrading [MUST] to [SHOULD] or [MAY].  The decision to 
>> utilize end-to-end cryptography is use case topology 
>> dependent.  If these use cases are deemed to be in scope, 
>> then doesn't it make sense for this to be a [MUST] 
>> requirement and amend the verbiage to read "... MUST be 

Yes, many of these are use case specific, however the PA protocol
needs to enable use cases that are in scope; which I inferred from
Section 8.2.

[omitted]

>>	In addition to mutual authentication specified in PT-2, 
>> the PT protocol must also be capable of supporting server 
>> side only authentication as an alternative to mutual 
>> authentication.  Server side only authentication is common 
>> practice today in SSL VPNs. With this in mind, please 
>> consider changing "mutual authentication" to "mutual and 
>> server side only authentication schemes". 
> 
> "Authentictation schemes specific to the end-use models", so 
> that the type of authentication - whether Server-Side, 
> mutual, or circuit-level only can be done.
> 

Yes, this is more of the intent I'm thinking as well. 

>> 	In order to prevent privacy abuse by network owners, PA 
>> request attributes must be restricted to information  known 
>> apriori  rather than be open ended in order to prevent 
>> dredging for artifact information. For example a PV looking 
>> for a domain named "mydomain.com" should be allowed, whereas 
>> requesting a domain named "*" should be disallowed by the PC. 
>> 
> Why? - What you suggest here means that each and ever domain 
> MUST be individually enumerated rather than being able to say 
> "Any Supported or Defined Domain"... I can see many instances 
> - especially those inside of University's and the like which 
> may have hundreds of domains, all which are operated under 
> the University's Security Persona...
> 

Good point, although I think my comment still stands in this case.
Asking are you a member of "myuniversity.edu" isn't open ended
in my mind since this is explicitly scoped as a specific group query.
My comment was to provide guidance to PC & PV developers to exercise
good judgment in maintaining user privacy in their disclosures via the
PA protocol exchanges.

>> 	I don't think Model 1 is practical or even possible in 
>> some cases.  This model works only when both the PC and PV 
>> have an immutable set of attributes known apriori by each.  
>> However, it is common practice in existing SSL VPN s to 
>> request information on the existence of files, directories, 
>> processes and other artifacts that are configurable 
>> assessment policy on the NEA Server. In order for model 1 to 
>> potentially work, the NEA client would have to send enormous 
>> amounts of information; potentially an enumeration of its 
>> entire file name space, process name space, registry name space, etc.

> 
> yes it would - but what is the value of the assurance it was 
> to provide if the Client side didnt present these 
> qualification datapoints?
> 

I'm not following you on this one.  Can you provide more clarity on
this comment?

Gary

---

From: "todd glassey" <[email-masked]>
Date: Tue, 11 Sep 2007 13:04:22 -0700

Thanks Gary - response inline :-)
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Tuesday, September 11, 2007 11:56 AM
Subject: RE: [Nea] Newcomer comments on draft-ietf-nea-requirements-04

Hello Todd,

[omitted]

[omitted]

TSG: COOL

> The use case I had in mind is one in which there are multiple PC's
and PV's involved in the assessment of an endpoint.

> I assumed this was implied in the model as required in section 7.3. The 
> reasoning behind the need for a name space identifier is to distinguish 
> the standard attributes from the vendor attributes; althoughit may be the 
> case the WG is relying on PB-3 to implicitly serve this purpose.  If so, 
> that should be stated in PA-1. The reasoning behind an extensible name 
> space schema is two fold; one the schema needs to be  public for any PV/PC 
> combo to interoperate, and two extensibility allows the
protocol to adapt over time.

> Again - a complete set of use models would eliminate this.

I'm not sure I can describe a complete set of use cases; although again I 
assumed the same use case as in PA-1 and thus the need to distinguish the 
vendor specific  attributes from each other and from the standard attributes 
as well.

TSG: Gary - You nor anyone else here as individuals needs to docuemtn all of 
the use models or cases - the group collectively does need to document say 
about 5 or more solid use cases and the controls for each one.

TSG: It would also would be a good idea to map COBIT and ISO17799 use cases 
on top of the protocol as well so it is easier to absorb into Audit 
Regulatred environments.

Again, if the WG assumed PB-3 will provide this distinction this should be 
stated in PA-2.  As to the extensible vendor attribute name space I was 
thinking SNMP MIB OID model in order to  enable the possibility of 
interoperability between PV/PC implementations from different  vendors.

TSG: Gary - How will that fit into the control framework of SNMP then? Can 
we use SNMP to talk to the NEA Agent PC/PV systems?

However, if this capability is out of scope and the WG expects the standard 
attribute set to serve this purpose, I'll retract this part of my PA-2 
comment.

> hierarchical error or failure messages with varying detail?

Yes, although I think the reasons are outside the scope of the  protocol 
itself.  I'm not sure how to phrase the guidance here  regarding how to 
provide useful information to the user as it is  at the discretion of the 
network operator's policy.

TSG: Then perhaps... the scope of the protocol definition may need to be 
adjusted then since these control systems are key to a successful deployment 
of NEA IMHO.

> It seems fine to me to have errors or failures which can be cryptic to 
> users in policies  which don't want to provide such information to 
> untrusted parties.

TSG: This is one of the things we need to complete. The Inferring of Use 
Models with NEA is a no-no IMHO. The uses of NEA need to be tight and very 
very secure, meaning that they are well defined and controlled so there is 
little if any wiggle room in them to allow developers to improperly 
implement or operator's to improperly configure NEA systems (again IMHO).

[omitted]

> Why? - What you suggest here means that each and every domain

TSG: OK but in this case the system is one that already is qualified or has 
had something to point it at MYUniversity.COM. What happens when you pull a 
fresh machine from the box and plug it into the network. How is it going to 
get its basic info - like its IP address for instance, and what will setup 
the server. Seems to me that in that use-case, the hosting network would 
want the NEA assurance process to work at the DHCP level or have I missed 
something?

TSG: Other cases are where a previously known system was turned off for a 
period or removed from the local network so its NEA Certification Status is 
expired or temporarilly set aside...

TSG: arent those specific to the policy controls of the hosting org? - I 
understand the need to build a baseline but what features make that up?

TSG: Sure - if NEA is to provide a stateful assurance of complaince with 
specific policies, then the scope of what triggers or forms those policies 
on the Device Under Test (aka a "DUT" in the Chip Test Systems world), then 
we need to be able to force both flattened and hierarchical compliance. 
Flattened compliance is a single set of tests wherein the client sends the 
querying system a notice saying it is in compliance with POLICY XYZ... and 
in the hierarchical mode the Client responds to remote test questions of 
compliance and the Statement of Compliance with the sum of those policies is 
generated by the evaluating system or machine.

TSG: Does that give you enough detail?

T

Gary

---

From: <[email-masked]>
Date: Tue, 11 Sep 2007 17:17:12 -0700

Hello Kaushik,

Thanks for the clarifications. Please find my response inline. 

> From: Kaushik Narayan [mailto:[email-masked]] 
> Sent: Monday, September 10, 2007 4:31 PM
> Subject: Re: [Nea] Newcomer comments on draft-ietf-nea-requirements-04
> 
> Hi Gary,
> 
> On 9/10/07 1:10 PM, "[email-masked]" 
> <[email-masked]> wrote:
> 
> 
> 	
> 	Is there any reason to support character sets other 
> than UTF-8?  Supporting only UTF-8 makes the protocol 
> straightforward on interpreting string 
> 	
> 	encodings and normalization to locale specific 
> character sets is generally easy to implement on most OS 
> platforms using their intrinsic libraries.
> 	
> 	
> 	<Kaushik> 
> 	
> 	C-9 currently tries to capture i18n requirements for 
> attributes that are both "text" and "non-text"at the PA and 
> PB layer. We did not want to get into specific encoding standards
> 	and that's the reason for a very generically worded requirement
> 	
> 	</Kaushik> 
> 	

<Gary>
I'm not sure how "non-text" fits into i18n?  Did you mean
"display-strings" and
"non-display-strings"?  If so, why not change the phrasing of C-9 to
"For all string
attributes, the...."? Since this is a common requirement for PA & PB,
why did you make
the requirement so generically?  Does the WG plan to provide this much
leeway to the
PA and PB protocol design teams? If so, I'll retract my UTF-8 comments
here and look to
apply them to the forthcoming PA & PB protocol drafts.
</Gary>

> draft-ietf-nea-requirements-03 was dropped; apparently in 
> favor of the more generalized new C-9 
> 	
> 	requirement in draft-ietf-nea-requirements-04.  I 
> believe there still exists a need for a PA specific I18N 
> string encoding requirement for non-
> 	
> 	displayable request and response attributes. Request 
> attributes for end point artifacts such as File, Directory, 
> Process Name, etc are used in 
> 	
> 	common practice today in NEA equivalent deployments I 
> am aware of.  Again, as mentioned in the comment regarding 
> the C-9 requirement, 
> 	
> 	<Kaushik> C-9 should capture this since there could be 
> non-displayable attributes at the PB layer as well. </Kaushik>
> 	
> 

<Gary>
Understood.  Please disregard this comment.
</Gary>
	
> 	Is there any reason in PB-3 not to specify identifiers 
> be based upon SMI enterprise numbers?  This requirement looks 
> much like that 
> 	
> 	Are you referring to the use of SMI for  static 
> identifiers for collectors & validators ? I think it might be 
> a useful suggestion
> 	for a potential solution, not sure if need to talk 
> about this in the requirements. 
> 	
> 	</Kaushik>
> 	
> 

<Gary>
Yes, I am referring to SMI for PV & PC identifiers.  I tend to want
tight
requirements and made the leap of incorporating an already existing IETF
standard
in here; but that may be beyond what the WG wants at this stage.  At a
minimum, I 
do think PB-3 needs to specify identifiers must be globally unique
within the NEA 
PB name space.
</Gary>
	
> side only authentication 
> 	as an alternative to mutual authentication.  Server 
> side only authentication is common practice today in SSL 
> VPNs. With this in mind, please 
> 	
> 	consider changing "mutual authentication" to "mutual 
> and server side only authentication schemes". 
> 	
> 	
> 	<Kaushik>
> 	
> 	
> 	The requirement is a MUST for mutual authentication 
> between NEA clients & NEA servers. The mutual authentication 
> could be achieved as a result
> 	of two independent authentication transactions (with 
> binding for certain PTs), for e.g. For password based 
> credentials, the NEA server will be authenticated 
> 	while a secure channel is being established (such as 
> TLS) and NEA client will be subsequently authenticated within 
> that secure channel.
> 	
> 	
> 	</Kaushik> 
> 

<Gary>
Understood on the multi-layer approach. However, this requirement is 
beyond the scope of the PT protocol and I think a new common C-XX 
requirement is necessary that states the NEA Client and NEA Server 
must provide  a secure channel via mutual authentication,
confidentiality 
and integrity through one or more of the PA, PB and PT protocols
collectively.  
As to my comment on PT-2, I believe that still stands as it is required
for
many if not most SSL VPN TLS connections.
</Gary>
	
> apriori  rather 
> 	than be open ended in order to prevent dredging for 
> artifact information. For example a PV looking for a domain named 
> 	"mydomain.com" should be allowed, whereas requesting a 
> domain named "*" should be disallowed by the PC. 
> 	
> 	<Kaushik>
> 	
> 	I guess you are stating a more pointed use of the 
> mechanism stated in paragraph 2. It might be a useful to 
> include in that section.
> 	
> 	</Kaushik> 
> 	
> 

<Gary>
Yes, that is correct. What I am concerned about is providing guidance
on user disclosure policies.  If the administrator of the user's machine
wants to allow open ended dredging, then so be it, but it should be
explicitly
allowed and default to denied as many user's won't possess the skills to

protect themselves properly.
</Gary>

> have an immutable 
> 	set of attributes known apriori by each.  However, it 
> is common practice in existing SSL VPN s to request 
> information on the existence of files, 
> 	
> 	directories, processes and other artifacts that are 
> configurable assessment policy on the NEA Server. In order 
> for model 1 to potentially work, 
> 	
> information; potentially an enumeration of its entire file 
> name space, process name space, 
> 	
> 	That's a fair point but Model 1 might be a useful model 
> to assess endpoints that are not owned by the Enterprise, for 
> e.g.  A contractor/guest system
> 	that is configured to provide a pre-set profile of 
> attributes when challenged by a guest/partner network.
> 	
> 	</Kaushik>
> 	 
> 

<Gary>
Yes.  I'll retract this comment in light of the clarification
you made on Model 3.  I miss interpreted the context to construe
only one model would emerge as most feasible for the reference
architecture.
</Gary>

> 	Model 3 is used in common practice today by many of the 
> NEA like deployments.  At a minimum, it must be supported .  
> I can also see model 2 
> 	
> 	being used effectively by a subset of PC/PV providers.  
> It occurs to me, the decision to use either model 2 or model 
> 3 is one the PC/PV provider 
> 	
> 	makes and that the NEA protocols could consider 
> supporting both models if necessary; but Model 3 appears to 
> be a superset of Model 2 and as 
> 	
> 	such so it might make sense to simply the protocol and 
> only support model 3. My preference is to always make things 
> simpler if possible.
> 	
> 	
> 	
> 	<Kaushik> 
> 	
> 	Just want to point out that all the models described in 
> section 9 are implementation considerations and not 
> requirements for NEA protocol specification. The models 
> explain how NEA implementations can address privacy concerns 
> and it is upto to implementations to support one or more of 
> these models.
> 	
> 	regards,
> 	  kaushik!
> 	
> 	</Kaushik>
> 	
> 

<Gary>
Understood, although I don't think section 9.2 paragraph 1 clearly 
states this.  I suggest rephrasing this paragraph to explicitly state
the NEA reference architecture and its protocols can be used with any
and
all of the 3 NEA Client to NEA Server interaction models; and that the
selection of an interaction model by a PC/PV implementer is use case 
dependent. Once this context is established, I think it is fine to
switch 
the context to protocol consideration guidance for the forthcoming PB
and 
PA design teams.

Regards,
Gary
</Gary>

---

From: <[email-masked]>
Date: Tue, 11 Sep 2007 19:34:22 -0700

Hi Kaushik,
 
Ah yes, SHOULD. Good, thanks!
 
Regards,
Parvez

From: Kaushik Narayan [mailto:[email-masked]]
Sent: Mon 9/10/2007 6:26 PM
To: Parvez Anandam; [email-masked]
Subject: Re: [Nea] RE: Newcomer comments on draft-ietf-nea-requirements-04

Hi Parvez,

	<snipped>

	Page 35 Section 7.4
	
	Please consider adding a new requirement for the PT protocol to support non-persistent network connections. This is especially important for mobile devices that roam or have air time charges.  This has an impact on reassessments triggered by the NEA server; in some cases (e.g. NAT traversal), the only option may be for the NEA client to periodically contact the NEA server to determine whether a reassessment is necessary.

	<Kaushik> 
	
	I am not sure about what you mean by "persistent network connection", i.e. What does that mean for a PT that runs over a network access protocol such as 802.1x or IKEv2. In any case the requirements to support client & server triggered assessment/re-assessment is a SHOULD and not a MUST.

	regards,
	  kaushik

	</Kaushik>

	As Gary stated, due to security policy, network owners may wish not to disclose the attributes being requested. Imagine an attacker who restricts all posture collection in order to determine what the network operators are looking for.

	
	Parvez Anandam

	Hello NEA WG,

	

	

	
	
	spaces. 

	

	

	

	
	[MUST] requirement and amend the verbiage to read "... MUST be optionally capable of providing ..."?

	Page 34 Section 7.2

	

	

	

	

	

	

	

	

	

	Gary Tomlinson

---

From: Kaushik Narayan <[email-masked]>
Date: Tue, 11 Sep 2007 21:46:16 -0700

Hi Gary,

<snipped>

> apply them to the forthcoming PA & PB protocol drafts.

<Kaushik-Response>

I did mean display strings (unicode). I think your suggestion is valid and
we will augment text in requirement C-9.

</Kaushik-Response>

> do think PB-3 needs to specify identifiers must be globally unique

<Kaushik-Response>

I agree about the suggestion of unique identifier, we will add text to PB-3
to specify that identifiers are required to be unique.

</Kaushik-Response>

> many if not most SSL VPN TLS connections.

<Kaushik-Response>

The common requirement would be redundant because we already have individual
requirements in PA, PB and PT for authentication, integrity & privacy
protection. The reason for individual requirements is because priority for
the PA, PB and PT layer requirements are different.

Re-wording PT-2 to change "mutual authentication" to "mutual and server side
only authentication schemes" would mean that it would acceptable have
server-only authentication for PT which does not seem sufficient.

</Kaushik-Response>

> the context to protocol consideration guidance for the forthcoming PB

<Kaushik-Response>

The second sentence in Section 9 states

" This section will discuss a few of the potential privacy concerns raised
by the deployment of this technology and offer some guidance to
implementers."

Does that seem adequate or do you think we need additional text in section
9.2 

regards,
 kaushik

</Kaushik-Response>

---

From: <[email-masked]>
Date: Wed, 12 Sep 2007 08:55:21 -0700

Todd,

Please find my response inline.

[snippet]

> about 5 or more solid use cases and the controls for each one.

<Gary>
It is always tough to decide when a sufficient number of use cases are
present to establish a baseline context.  I am familiar with assessment
used in conjunction with real-time access control enforcement and thus
have been able to mostly understand the requirements so far; however
one could argue a use case for remote access VPN usage might be useful.
I am only marginally familiar with assessment for compliance auditing
which seems to be your area of expertise and thus not in a position to
judge the utility of the current set of use cases for this purpose.
I'll
have defer to the WG at large on this one.
</Gary>

> on top of the protocol as well so it is easier to absorb into Audit 

<Gary>
Again, I'm not sure if this is in the current WG charter scope.  If it
is, I would imagine you could provide assistance in this mapping.
</Gary>

[snippet]

> we use SNMP to talk to the NEA Agent PC/PV systems?

<Gary>
Sorry I wasn't clearer in my comments.  I'm not suggesting NEA have any
SNMP MIBs, but rather consider using the SMI numbering scheme already 
employed in SNMP for PC & PV identifiers and possibly consider using it
to
enumerate attributes as well. But as Kaushik correctly pointed out, this

is beyond the scope of the requirements specification and is something
to 
consider for the PB protocol work. For those interested, I'd see this 
being done where the standard attribute name space would be orthogonal 
to mib2 as an OID and vendor specific PC/PV would be rooted off of their

own enterprise OIDs.
</Gary>

[snippet]

> adjusted then since these control systems are key to a 

<Gary>
Clearly the protocol must provide a complete state graph for error and
remediation transitions. We'll have to cross that bridge once the WG
gets
to doing the PA protocol work.
</Gary>

[snippet]

> implement or operator's to improperly configure NEA systems 

<Gary>
As I previously stated, at some point we'll have sufficient use cases to
describe the model. The question is, do we now?  I'm not sure we can
ever 
completely make this a closed system though as vendor PA name spaces are

under the control of 3rd parties. We can only provide guidance and let
the
market sort things out here for poor implementations.
</Gary>

[snippet]

> want the NEA assurance process to work at the DHCP level or 

<Gary>
A classic way, and one that is used prevalently today starts the user
on a quarantined network (i.e. VLAN segmented) to interact with their
DHCP server.  Once their network layer config is provisioned, the NEA
assessment begins and if they are compliant, their end point is mapped
onto the trusted network.  This is of course a LAN example.  Hope that 
helps?  Use case section 6.1.1 glossed over these important details
between steps 1 and 2.
</Gary>

> understand the need to build a baseline but what features 

<Gary>
Please see my comments dated 9/11 to Kaushik for more information.
</Gary>

[snippet]

> TSG: Does that give you enough detail?

<Gary>
Yes.  And now that Kaushik clarified my understanding that NEA
isn't standardizing an interaction model, I don't have issues
with model 1.

Regards
Gary

</Gary>

---

From: "todd glassey" <[email-masked]>
Date: Wed, 12 Sep 2007 09:21:49 -0700

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 12, 2007 8:55 AM
Subject: RE: [Nea] Newcomer comments on draft-ietf-nea-requirements-04

 Todd,

[snippet]

<Gary>

TSG:  I agree. VPN for remote access will be a critical value-add for the 
Audit Community.

TSG:  My concern is that the Auditor's ***will*** control whether NEA is 
rolled out in arena's they control and so its important to either get their 
buy-in conceptually early on, or to answer all of the major questions they 
would have in a manner that doesnt make it critically expensive to 
implement.

</Gary>

<Gary>

TSG: I dont think its in the defined charter - but as a matter of what IT 
operations contain these days, there is a formal requirement for regulatory 
compliance and technologies that make that easier are winners here and the 
rest - well... you get the picture I am sure.

[snippet]

<Gary>

own enterprise OIDs.
</Gary>

[snippet]

<Gary>

[snippet]

<Gary>

[snippet]

<Gary>

<Gary>

[snippet]

<Gary>

Regards
Gary

</Gary>

---

From: <[email-masked]>
Date: Wed, 12 Sep 2007 09:48:50 -0700

Hi Kausik,

[PA] One comment inline...

Regards,
Parvez

-----Original Message-----
From: Kaushik Narayan [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2007 9:46 PM
To: Gary Tomlinson; [email-masked]
Subject: Re: [Nea] Newcomer comments on draft-ietf-nea-requirements-04

Hi Gary,

<snipped>

<Kaushik-Response>

The common requirement would be redundant because we already have
individual
requirements in PA, PB and PT for authentication, integrity & privacy
protection. The reason for individual requirements is because priority
for
the PA, PB and PT layer requirements are different.

Re-wording PT-2 to change "mutual authentication" to "mutual and server
side
only authentication schemes" would mean that it would acceptable have
server-only authentication for PT which does not seem sufficient.

</Kaushik-Response>

[PA] The example you give above is a good one: 1) the NEA server is
first authenticated while a secure channel is being established and 2)
The NEA client subsequently authenticates within that secure channel. In
this example, I would have thought that 1) is part of the PT protocol
whereas 2) would be part of a higher-level protocol such as PB, in which
case the mutual authentication does not happen exclusively within PT. Am
I incorrect in this assumption? Thanks for clarifying...

---

From: <[email-masked]>
Date: Wed, 12 Sep 2007 09:52:35 -0700

Hi Todd,

Regards,
Parvez

-----Original Message-----
From: todd glassey [mailto:[email-masked]] 
Sent: Wednesday, September 12, 2007 9:22 AM
To: Gary Tomlinson; [email-masked]
Subject: Re: [Nea] Newcomer comments on draft-ietf-nea-requirements-04

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 12, 2007 8:55 AM
Subject: RE: [Nea] Newcomer comments on draft-ietf-nea-requirements-04

 Todd,

[snippet]

<Gary>

TSG:  I agree. VPN for remote access will be a critical value-add for
the 
Audit Community.

[PA] Gary and I would be happy to write a TLS VPN remote access use
case, if the WG wishes.

---

From: "todd glassey" <[email-masked]>
Date: Wed, 12 Sep 2007 10:47:20 -0700

TSG: PLEASE DO! - I will work on the COBITization of the control 
descriptions and we can produce a COBIT compliance document for the use of 
NEA. We can then literally just put ISACA on notice that we are designing a 
protocol specifically with COBIT compliance built in from the gate, and they 
will probably be pretty happy about that I would think.

Todd

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 12, 2007 9:52 AM
Subject: RE: [Nea] Newcomer comments on draft-ietf-nea-requirements-04

Hi Todd,

Regards,
Parvez

-----Original Message-----
From: todd glassey [mailto:[email-masked]]
Sent: Wednesday, September 12, 2007 9:22 AM
To: Gary Tomlinson; [email-masked]
Subject: Re: [Nea] Newcomer comments on draft-ietf-nea-requirements-04

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Wednesday, September 12, 2007 8:55 AM
Subject: RE: [Nea] Newcomer comments on draft-ietf-nea-requirements-04

 Todd,

[snippet]

<Gary>

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 13 Sep 2007 09:09:26 -0700

Hi Parvez,

<snipped>

> I incorrect in this assumption? Thanks for clarifying...

The PT protocol MUST authenticate the NEA client, it's fairly
straight-forward for protocols such as TLS or EAP to support this. In
general the NEA reference model requires the NEA protocols, i.e. PA, PB & PT
to satisfy the security requirements independently.

regards,
  kaushik

---

From: <[email-masked]>
Date: Thu, 13 Sep 2007 16:58:23 -0700

Hi Kaushik,

[PA] Please find my reply inline.

Regards,
Parvez

<snipped>

The PT protocol MUST authenticate the NEA client, it's fairly
straight-forward for protocols such as TLS or EAP to support this. In
general the NEA reference model requires the NEA protocols, i.e. PA, PB
& PT
to satisfy the security requirements independently.

regards,
  kaushik 

[PA] I do agree with you that TLS and EAP certainly support mutual
authentication and implementing that is not the problem. What I'm having
a hard time with is why it's so important for PT to have the MUST for
mutual authentication whereas the PB protocol has a MAY. After all,
isn't the main trust relationship between the Posture Broker Client and
the Posture Broker Server? If that trust relationship can be
transitively derived from the PT layer, well and good, but I'm not sure
I see why that transitivity needs to be mandated.

---

From: Kaushik Narayan <[email-masked]>
Date: Thu, 13 Sep 2007 22:58:17 -0700

Hi Parvez,

<snipped>
> I see why that transitivity needs to be mandated.

Protocols such as TLS, EAP etc. that NEA will rely on to provide posture
transport are already capable of providing mutual authentication,
confidentiality and privacy protection. This allows simplification of the PB
protocol.

Regards,
 kaushik